[Bug target/68214] New: gcc.dg/cwsc1.c fails on arm-none-eabi

[sandra at gcc dot gnu.org]

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

Bug ID: 68214
   Summary: gcc.dg/cwsc1.c fails on arm-none-eabi
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sandra at gcc dot gnu.org
  Target Milestone: ---

Created attachment 36651
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36651=edit
cwsc1.s

The testcase gcc.dg/cwsc1.c seems to assume that register "ip" is always
reserved for the static chain pointer on ARM, but it's being re-used as a
temporary to hold the value of the variable "ptr" prior to calling it:

arm-none-eabi-gcc src/gcc-mainline/gcc/testsuite/gcc.dg/cwsc1.c -S -O

produces:

main:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 8
@ frame_needed = 0, uses_anonymous_args = 0
stmfd   sp!, {r4, lr}
sub sp, sp, #8
add r4, sp, #7
mov ip, r4
ldr r3, .L6
ldr ip, [r3]
mov lr, pc
bx  ip
cmp r4, r0
bne .L5

Invalid testcase or bug in the ARM backend?

Re: [PATCH] Fix vms targets

[Jeff Law]

On 11/04/2015 08:51 AM, Andrew MacLeod wrote:

On 11/02/2015 12:28 AM, Jeff Law wrote:


The header reduction didn't seem to handle the vms targets correctly.
This reverts that part of Andrew's patch which allows the alpha,
alpha64 and ia64 vms targets to build again.

Installed on the trunk.  That covers all the fallout from standard
builds of config-list.mk that I'm aware of.


how weird.. really.  I ran all config-list.mk and saw no failures...
huh.   maybe because I only ran c/c++ instead of 'all' to save time? I'm
still surprised.
It was a link failure with a reference from dwarf2out.o that should have 
been satisfied by vmsdbgout.o IIRC.


As why I saw it and not you.  I have no clue as I'd expect it to have 
failed linking cc1 or cc1plus.


Jeff

Remove obsolete openacc reduction code

[Nathan Sidwell]

I've committed this patch to trunk as obvious.  I'd missed some code obsoleted 
by the new reduction implementation.  This code was simply creating a splay 
tree, not adding anything to it and then processing the splay tree.  Nuked from 
orbit.


nathan
2015-11-04  Nathan Sidwell  

	* omp-low.c (struct omp_context): Remove reduction_map field.
	(lookup_oacc_reduction, maybe_lookup_oacc_reduction): Delete.
	(new_omp_context, delete_omp_context, scan_omp_target): Remove
	reduction_map handling.
	(lower_omp_target): Remove obsolete openacc reduction handling.

Index: gcc/omp-low.c
===
--- gcc/omp-low.c	(revision 229779)
+++ gcc/omp-low.c	(working copy)
@@ -169,11 +169,6 @@ struct omp_context
  construct.  In the case of a parallel, this is in the child function.  */
   tree block_vars;
 
-  /* A map of reduction pointer variables.  For accelerators, each
- reduction variable is replaced with an array.  Each thread, in turn,
- is assigned to a slot on that array.  */
-  splay_tree reduction_map;
-
   /* Label to which GOMP_cancel{,llation_point} and explicit and implicit
  barriers should jump to during omplower pass.  */
   tree cancel_label;
@@ -1090,23 +1085,6 @@ maybe_lookup_field (tree var, omp_contex
   return maybe_lookup_field ((splay_tree_key) var, ctx);
 }
 
-static inline tree
-lookup_oacc_reduction (const char *id, omp_context *ctx)
-{
-  splay_tree_node n;
-  n = splay_tree_lookup (ctx->reduction_map, (splay_tree_key) id);
-  return (tree) n->value;
-}
-
-static inline tree
-maybe_lookup_oacc_reduction (tree var, omp_context *ctx)
-{
-  splay_tree_node n = NULL;
-  if (ctx->reduction_map)
-n = splay_tree_lookup (ctx->reduction_map, (splay_tree_key) var);
-  return n ? (tree) n->value : NULL_TREE;
-}
-
 /* Return true if DECL should be copied by pointer.  SHARED_CTX is
the parallel context if DECL is to be shared.  */
 
@@ -1667,7 +1645,6 @@ new_omp_context (gimple *stmt, omp_conte
   ctx->cb = outer_ctx->cb;
   ctx->cb.block = NULL;
   ctx->depth = outer_ctx->depth + 1;
-  ctx->reduction_map = outer_ctx->reduction_map;
 }
   else
 {
@@ -1740,13 +1717,6 @@ delete_omp_context (splay_tree_value val
 splay_tree_delete (ctx->field_map);
   if (ctx->sfield_map)
 splay_tree_delete (ctx->sfield_map);
-  /* Reduction map is copied to nested contexts, so only delete it in the
- owner.  */
-  if (ctx->reduction_map
-  && gimple_code (ctx->stmt) == GIMPLE_OMP_TARGET
-  && is_gimple_omp_offloaded (ctx->stmt)
-  && is_gimple_omp_oacc (ctx->stmt))
-splay_tree_delete (ctx->reduction_map);
 
   /* We hijacked DECL_ABSTRACT_ORIGIN earlier.  We need to clear it before
  it produces corrupt debug information.  */
@@ -3077,10 +3047,6 @@ scan_omp_target (gomp_target *stmt, omp_
   TYPE_ARTIFICIAL (ctx->record_type) = 1;
   if (offloaded)
 {
-  if (is_gimple_omp_oacc (stmt))
-	ctx->reduction_map = splay_tree_new (splay_tree_compare_pointers,
-	 0, 0);
-
   create_omp_child_function (ctx, false);
   gimple_omp_target_set_child_fn (stmt, ctx->cb.dst_fn);
 }
@@ -14549,7 +14515,7 @@ lower_omp_target (gimple_stmt_iterator *
   tree child_fn, t, c;
   gomp_target *stmt = as_a  (gsi_stmt (*gsi_p));
   gbind *tgt_bind, *bind, *dep_bind = NULL;
-  gimple_seq tgt_body, olist, ilist, orlist, irlist, new_body;
+  gimple_seq tgt_body, olist, ilist, new_body;
   location_t loc = gimple_location (stmt);
   bool offloaded, data_region;
   unsigned int map_cnt = 0;
@@ -14602,9 +14568,6 @@ lower_omp_target (gimple_stmt_iterator *
 
   push_gimplify_context ();
 
-  irlist = NULL;
-  orlist = NULL;
-
   for (c = clauses; c ; c = OMP_CLAUSE_CHAIN (c))
 switch (OMP_CLAUSE_CODE (c))
   {
@@ -14900,13 +14863,8 @@ lower_omp_target (gimple_stmt_iterator *
 	ctx);
 		else
 		  x = build_sender_ref (ovar, ctx);
-		if (maybe_lookup_oacc_reduction (var, ctx))
-		  {
-		gcc_checking_assert (offloaded
-	 && is_gimple_omp_oacc (stmt));
-		gimplify_assign (x, var, );
-		  }
-		else if (OMP_CLAUSE_CODE (c) == OMP_CLAUSE_MAP
+
+		if (OMP_CLAUSE_CODE (c) == OMP_CLAUSE_MAP
 			 && OMP_CLAUSE_MAP_KIND (c) == GOMP_MAP_POINTER
 			 && !OMP_CLAUSE_MAP_ZERO_BIAS_ARRAY_SECTION (c)
 			 && TREE_CODE (TREE_TYPE (ovar)) == ARRAY_TYPE)
@@ -15553,11 +15511,9 @@ lower_omp_target (gimple_stmt_iterator *
 			tgt_bind ? gimple_bind_block (tgt_bind)
  : NULL_TREE);
   gsi_replace (gsi_p, dep_bind ? dep_bind : bind, true);
-  gimple_bind_add_seq (bind, irlist);
   gimple_bind_add_seq (bind, ilist);
   gimple_bind_add_stmt (bind, stmt);
   gimple_bind_add_seq (bind, olist);
-  gimple_bind_add_seq (bind, orlist);
 
   pop_gimplify_context (NULL);
 

[Bug fortran/63331] Fortran -fcompare-debug issues

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #4 from Dominique d'Humieres  ---
> Untested patch to fix (or work around) all but the last 2 FAILs.

Is this patch committed as revision r215516? Setting GCC_COMPARE_DEBUG=1, I see

FAIL: gfortran.dg/iso_c_binding_compiler_1.f90   -O  (test for excess errors)
FAIL: gfortran.dg/iso_c_binding_compiler_3.f90   -O  (test for excess errors)

at r229727. Is this OK. Any reason to keep this PR opened?

Re: [PATCH c/c++] use explicit locations for some warnings in c-pragma.c

[Manuel López-Ibáñez]

On 4 November 2015 at 09:45, Mike Stump  wrote:
> in the top of the tree.  This is bad as the same line appears in a PASS: and 
> an XFAIL:.  Each test case should be unique.  Should it be updated to 64?

I think it is sufficient to change it to:

/* { dg-warning "24:missing" "wrong column" { xfail *-*-* }  2 } */

This dg-warning is there to show that the column number is wrong and
tell whoever fixes this that there is already a test that only needs
updating. Changing 24 to 64 defeats the purpose of having it in the
first place.

Cheers,

Manuel.

[Bug c++/68195] gcc//ld produces invalid ABI results (cxx11 problem?)

[dushistov at mail dot ru]

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

--- Comment #3 from Evgeniy Dushistov  ---
I build gcc with last commit:
commit 06d6724083a2cb1f35e36f4a0db3025bfde20667
Author: nathan <nathan@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Wed Nov 4 17:01:23 2015 +

* libgomp.oacc-c-c++-common/loop-red-g-1.c: New.
* libgomp.oacc-c-c++-common/loop-red-gwv-1.c: New.
* libgomp.oacc-c-c++-common/loop-red-v-1.c: New.
* libgomp.oacc-c-c++-common/loop-red-v-2.c: New.
* libgomp.oacc-c-c++-common/loop-red-w-1.c: New.
* libgomp.oacc-c-c++-common/loop-red-w-2.c: New.
* libgomp.oacc-c-c++-common/loop-red-wv-1.c: New.
* libgomp.oacc-fortran/reduction-5.f90: Avoid reference var.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@229770
138bc75d-0d04-0410-961f-82ee72b054a4

$/home/evgeniy/local/bin/g++ --version | head -n 1
g++ (GCC) 6.0.0 20151104 (experimental)

$ LANG=C make
/home/evgeniy/local/bin/g++ -std=c++03 -g3 -shared -fPIC -o libmyLib.so Lib.cpp
-O2
/home/evgeniy/local/bin/g++ -std=c++11 -g3 main.cpp -o main -L. -l myLib
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/evgeniy/local/lib64:./ ./main
Makefile:7: recipe for target 'test1' failed
make: *** [test1] Segmentation fault

So the bug should be in trunk also, linux/amd64

Re: [PATCH], Add power9 support to GCC, patch #1

[Segher Boessenkool]

Hi,

Some minor things...

On Tue, Nov 03, 2015 at 03:29:11PM -0500, Michael Meissner wrote:
>   * config/rs6000/rs6000.opt (-mfusion-toc): Add new switches for
>   ISA 3.0 (power9).

"-mtoc-fusion" sounds more natural, and is more in line with the other
switches I think.

> +  /* ISA 2.08 vector instructions include ISA 2.07.  */

ISA 3.0

> +@item -mmodulo
> +@itemx -mno-modulo
> +@opindex mmodulo
> +@opindex mno-module
> +Generate code that uses (does not use) the ISA 2.08 integer modulo
> +instructions.  The @option{-mmodulo} option is enabled by default
> +with the @option{-mcpu=power9} option.

Again.  I think it was just these two, but please check.

> +@item -mpower9-fusion
> +@itemx -mno-power9-fusion
> +@opindex mpower9-fusion
> +@opindex mno-power9-fusion
> +Generate code that keeps (does not keeps) some operations adjacent so
> +that the instructions can be fused together on power9 and later
> +processors.

> +@item -mpower9-vector
> +@itemx -mno-power9-vector
> +@opindex mpower9-vector
> +@opindex mno-power9-vector
> +Generate code that uses (does not use) the vector and scalar
> +instructions that were added in version 2.07 of the PowerPC ISA.  Also
> +enable the use of built-in functions that allow more direct access to
> +the vector instructions.

3.0 here as well?


Segher

Re: [PATCH 10/10] Compress short ranges into source_location

[Dodji Seketeli]

[...]

> diff --git a/libcpp/line-map.c b/libcpp/line-map.c

[...]

> +
> +  /* Any ordinary locations ought to be "pure" at this point: no
> + compressed ranges.  */
> +  linemap_assert (locus < RESERVED_LOCATION_COUNT
> +   || locus >= LINE_MAP_MAX_LOCATION_WITH_COLS
> +   || locus >= LINEMAPS_MACRO_LOWEST_LOCATION (set)
> +   || pure_location_p (set, locus));

Just for my own education, why aren't the tests

locus < RESERVED_LOCATION_COUNT
|| locus >= LINE_MAP_MAX_LOCATION_WITH_COLS
|| locus >= LINEMAPS_MACRO_LOWEST_LOCATION (set)

not part of pure_location_p() ?  I mean, would it make sense to say that
a locus that that satisfies that condition is pure?

By the way, I like this great piece of code of yours, kudos!

Cheers,

-- 
Dodji

Re: [PATCH 1/2][ARM] PR/65956 AAPCS update for alignment attribute

[Florian Weimer]

On 11/04/2015 02:13 PM, Jakub Jelinek wrote:
> On Mon, Jul 06, 2015 at 05:38:35PM +0100, Alan Lawrence wrote:
>> Trying to push these now (svn!), patch 2 is going first.
>>
>> I realize my second iteration of patch 1/2, dropped the testcases from the
>> first version. Okay to include those as per
>> https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00215.html ?
> 
> FYI, it seems that (most likely) the PR65956 changes on gcc-5-branch
> broke libgnat ABI compatibility on arm - it seems that getsubs.adb
> from macrosub proglet (and others) are during make check compiled/linked
> with system gnatmake/gcc, but the program is run at runtime
> against the new libgnat-5.so.  If I run it manually against
> system libgnat, it works, otherwise it hangs, when Fill_Table from
> getsubs.adb calls Get_Line, and indeed it looks like the argument passing
> for Get_Line changed and on the callee side it thinks Item (which is 400
> chars string) has random (and in the hanging case negative) number of chars
> in it.

The patch looks at TYPE_MAIN_VARIANT without checking first if the type
has any qualifiers:

+  if (!AGGREGATE_TYPE_P (type))
+return TYPE_ALIGN (TYPE_MAIN_VARIANT (type)) > PARM_BOUNDARY;

I'm not sure if this is valid, and what happens here if the type refers
to a fat pointer type generated by the Ada front end.

Florian

[Bug c++/68209] C++11 code compiled without -std=c++11 but doesn't work as expected

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

   Keywords||accepts-invalid

--- Comment #4 from Marc Glisse  ---
(Oups, pressed return by mistake)
Yes it is QoI, but we could still do better.

(the -Wall warning is a better sign that something is going wrong:
x.cc:8:22: warning: 'aa' may be used uninitialized in this function
[-Wmaybe-uninitialized]
  cout << aa << endl;
  ^
)

Re: [PATCH], Add power9 support to GCC, patch #1

[Michael Meissner]

On Wed, Nov 04, 2015 at 03:15:53PM -0600, Segher Boessenkool wrote:
> Hi,
> 
> Some minor things...
> 
> On Tue, Nov 03, 2015 at 03:29:11PM -0500, Michael Meissner wrote:
> > * config/rs6000/rs6000.opt (-mfusion-toc): Add new switches for
> > ISA 3.0 (power9).
> 
> "-mtoc-fusion" sounds more natural, and is more in line with the other
> switches I think.

That's reasonable.  At present, -mfusion-toc is not documented, as it was
intended to be a debug switch.

David, do you have an opinion one way or the other?

> > +  /* ISA 2.08 vector instructions include ISA 2.07.  */
> 
> ISA 3.0

Thanks for catching that.  I missed a few places that were written earlier
before we decided the new ISA would be 3.0 instead of 2.8.  I'll make those
changes before submitting.

> > +@item -mmodulo
> > +@itemx -mno-modulo
> > +@opindex mmodulo
> > +@opindex mno-module
> > +Generate code that uses (does not use) the ISA 2.08 integer modulo
> > +instructions.  The @option{-mmodulo} option is enabled by default
> > +with the @option{-mcpu=power9} option.
> 
> Again.  I think it was just these two, but please check.
> 
> > +@item -mpower9-fusion
> > +@itemx -mno-power9-fusion
> > +@opindex mpower9-fusion
> > +@opindex mno-power9-fusion
> > +Generate code that keeps (does not keeps) some operations adjacent so
> > +that the instructions can be fused together on power9 and later
> > +processors.
> 
> > +@item -mpower9-vector
> > +@itemx -mno-power9-vector
> > +@opindex mpower9-vector
> > +@opindex mno-power9-vector
> > +Generate code that uses (does not use) the vector and scalar
> > +instructions that were added in version 2.07 of the PowerPC ISA.  Also
> > +enable the use of built-in functions that allow more direct access to
> > +the vector instructions.
> 
> 3.0 here as well?

I only found 3 references to 2.08 in the patch.

Thanks.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797

Re: [OpenACC] num_gangs, num_workers and vector_length in c++

[Cesar Philippidis]

On 11/04/2015 10:09 AM, Jason Merrill wrote:

> A single function is better, to avoid unnecessary code duplication.

Thanks. I've applied this patch to trunk.

Cesar

2015-11-04  Cesar Philippidis  

	gcc/cp/
	* (cp_parser_oacc_single_int_clause): New function.
	(cp_parser_oacc_clause_vector_length): Delete.
	(cp_parser_omp_clause_num_gangs): Delete.
	(cp_parser_omp_clause_num_workers): Delete.
	(cp_parser_oacc_all_clauses): Use cp_parser_oacc_single_int_clause
	for num_gangs, num_workers and vector_length.

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 12452e6..4f6cd2d 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -29590,6 +29590,39 @@ cp_parser_oacc_simple_clause (cp_parser * /* parser  */,
   return c;
 }
 
+ /* OpenACC:
+   num_gangs ( expression )
+   num_workers ( expression )
+   vector_length ( expression )  */
+
+static tree
+cp_parser_oacc_single_int_clause (cp_parser *parser, omp_clause_code code,
+  const char *str, tree list)
+{
+  location_t loc = cp_lexer_peek_token (parser->lexer)->location;
+
+  if (!cp_parser_require (parser, CPP_OPEN_PAREN, RT_OPEN_PAREN))
+return list;
+
+  tree t = cp_parser_assignment_expression (parser, NULL, false, false);
+
+  if (t == error_mark_node
+  || !cp_parser_require (parser, CPP_CLOSE_PAREN, RT_CLOSE_PAREN))
+{
+  cp_parser_skip_to_closing_parenthesis (parser, /*recovering=*/true,
+	 /*or_comma=*/false,
+	 /*consume_paren=*/true);
+  return list;
+}
+
+  check_no_duplicate_clause (list, code, str, loc);
+
+  tree c = build_omp_clause (loc, code);
+  OMP_CLAUSE_OPERAND (c, 0) = t;
+  OMP_CLAUSE_CHAIN (c) = list;
+  return c;
+}
+
 /* OpenACC:
 
 gang [( gang-arg-list )]
@@ -29713,45 +29746,6 @@ cp_parser_oacc_shape_clause (cp_parser *parser, omp_clause_code kind,
   return list;
 }
 
-/* OpenACC:
-   vector_length ( expression ) */
-
-static tree
-cp_parser_oacc_clause_vector_length (cp_parser *parser, tree list)
-{
-  tree t, c;
-  location_t location = cp_lexer_peek_token (parser->lexer)->location;
-  bool error = false;
-
-  if (!cp_parser_require (parser, CPP_OPEN_PAREN, RT_OPEN_PAREN))
-return list;
-
-  t = cp_parser_condition (parser);
-  if (t == error_mark_node || !INTEGRAL_TYPE_P (TREE_TYPE (t)))
-{
-  error_at (location, "expected positive integer expression");
-  error = true;
-}
-
-  if (error || !cp_parser_require (parser, CPP_CLOSE_PAREN, RT_CLOSE_PAREN))
-{
-  cp_parser_skip_to_closing_parenthesis (parser, /*recovering=*/true,
-	   /*or_comma=*/false,
-	   /*consume_paren=*/true);
-  return list;
-}
-
-  check_no_duplicate_clause (list, OMP_CLAUSE_VECTOR_LENGTH, "vector_length",
-			 location);
-
-  c = build_omp_clause (location, OMP_CLAUSE_VECTOR_LENGTH);
-  OMP_CLAUSE_VECTOR_LENGTH_EXPR (c) = t;
-  OMP_CLAUSE_CHAIN (c) = list;
-  list = c;
-
-  return list;
-}
-
 /* OpenACC 2.0
Parse wait clause or directive parameters.  */
 
@@ -30130,42 +30124,6 @@ cp_parser_omp_clause_nowait (cp_parser * /*parser*/,
   return c;
 }
 
-/* OpenACC:
-   num_gangs ( expression ) */
-
-static tree
-cp_parser_omp_clause_num_gangs (cp_parser *parser, tree list)
-{
-  tree t, c;
-  location_t location = cp_lexer_peek_token (parser->lexer)->location;
-
-  if (!cp_parser_require (parser, CPP_OPEN_PAREN, RT_OPEN_PAREN))
-return list;
-
-  t = cp_parser_condition (parser);
-
-  if (t == error_mark_node
-  || !cp_parser_require (parser, CPP_CLOSE_PAREN, RT_CLOSE_PAREN))
-cp_parser_skip_to_closing_parenthesis (parser, /*recovering=*/true,
-	   /*or_comma=*/false,
-	   /*consume_paren=*/true);
-
-  if (!INTEGRAL_TYPE_P (TREE_TYPE (t)))
-{
-  error_at (location, "expected positive integer expression");
-  return list;
-}
-
-  check_no_duplicate_clause (list, OMP_CLAUSE_NUM_GANGS, "num_gangs", location);
-
-  c = build_omp_clause (location, OMP_CLAUSE_NUM_GANGS);
-  OMP_CLAUSE_NUM_GANGS_EXPR (c) = t;
-  OMP_CLAUSE_CHAIN (c) = list;
-  list = c;
-
-  return list;
-}
-
 /* OpenMP 2.5:
num_threads ( expression ) */
 
@@ -30374,43 +30332,6 @@ cp_parser_omp_clause_defaultmap (cp_parser *parser, tree list,
   return list;
 }
 
-/* OpenACC:
-   num_workers ( expression ) */
-
-static tree
-cp_parser_omp_clause_num_workers (cp_parser *parser, tree list)
-{
-  tree t, c;
-  location_t location = cp_lexer_peek_token (parser->lexer)->location;
-
-  if (!cp_parser_require (parser, CPP_OPEN_PAREN, RT_OPEN_PAREN))
-return list;
-
-  t = cp_parser_condition (parser);
-
-  if (t == error_mark_node
-  || !cp_parser_require (parser, CPP_CLOSE_PAREN, RT_CLOSE_PAREN))
-cp_parser_skip_to_closing_parenthesis (parser, /*recovering=*/true,
-	   /*or_comma=*/false,
-	   /*consume_paren=*/true);
-
-  if (!INTEGRAL_TYPE_P (TREE_TYPE (t)))
-{
-  error_at (location, "expected positive integer expression");
-  return list;
-}
-
-  check_no_duplicate_clause (list, 

[Bug c++/68213] New: Exception handling corrupts a VLA in MinGW

[hedayat.fwd at gmail dot com]

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

Bug ID: 68213
   Summary: Exception handling corrupts a VLA in MinGW
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hedayat.fwd at gmail dot com
  Target Milestone: ---

Code:
-
#include 
#include 
#include 
#include 

using namespace std;

int main(int argc, char **argv)
{
int n;
stringstream ss(argv[1]);
ss >> n;
cout << "N: " << n << endl;
char tbuff[n];
try
{
memset(tbuff, 0, n);
throw runtime_error("ERR");
}
catch (exception )
{
cout << "Writing to VLA" << endl;
memset(tbuff, 0, n);
cout << "Wrote" << endl;
}
}
-

Compiled with: 
/usr/bin/i686-w64-mingw32-g++ -O2  test.cpp -o t

Run with wine (similar results under Windows) results in crash:
[]% ./t 100 
fixme:winediag:start_process Wine Staging is a testing version containing
experimental patches.
fixme:winediag:start_process Please report bugs at http://bugs.wine-staging.com
(instead of winehq.org).
N: 100
Writing to VLA
wine: Unhandled page fault on read access to 0x at address (nil)
(thread 0009), starting debugger...
Unhandled exception: page fault on read access to 0x in 32-bit code
(0x).

[Bug c++/68209] C++11 code compiled without -std=c++11 but doesn't work as expected

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

   Keywords||diagnostic, wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-04
 Ever confirmed|0   |1

gcc-4.9-20151104 is now available

[gccadmin]

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

This snapshot has been generated from the GCC 4.9 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch 
revision 229787

You'll find:

 gcc-4.9-20151104.tar.bz2 Complete GCC

  MD5=a49019ce23c79f0f097636340ee6c455
  SHA1=751ddf37ff1656cc9de442c1127a8b56089d671e

Diffs from 4.9-20151028 are available in the diffs/ subdirectory.

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

[Bug fortran/63327] Poor caret location in error mesage

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
See also pr54224 comment 22 for other examples: Manuel López-Ibáñez wrote

> You will get a more precise column info (and better location for '^')
> if Fortran gives a more precise DECL_SOURCE_LOCATION() when generating
> this tree.

May be related to 29819.

[Bug c++/68209] C++11 code compiled without -std=c++11 but doesn't work as expected

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #3 from Daniel Krügler  ---
> What is the reason why it compiled on C++98?
> I expect that it is incorrect
> syntax for C++98 and code doesn't match language grammatics. So expected
> behavior is "compilation error".

There is no requirement for your expected behaviour. The standard only requires
a diagnostics in such a case, see [intro.compliance] p2:

If a program contains a violation of any diagnosable rule or an occurrence of a
construct described in this Standard as “conditionally-supported” when the
implementation does not support that construct, a conforming implementation
shall issue at least one diagnostic message.

This diagnostics is produced. I'd like to point out that clang behaves
similarly (albeit this is not really relevant when we talk about the
correctness).

[PATCH] remove parameter_rename_map

[Sebastian Pop]

This map was used in the transition to the new scop detection: with the new scop
detection, we do not need this map anymore.

   * graphite-isl-ast-to-gimple.c (gcc_expression_from_isl_ast_expr_id):
   Remove use of parameter_rename_map.
   (copy_def): Remove.
   (copy_internal_parameters): Remove.
   (graphite_regenerate_ast_isl): Remove call to copy_internal_parameters.
   * sese.c (new_sese_info): Do not initialize parameter_rename_map.
   (free_sese_info): Do not free parameter_rename_map.
   (set_rename): Do not use parameter_rename_map.
   (rename_uses): Update call to set_rename.
   (graphite_copy_stmts_from_block): Do not use parameter_rename_map.
   * sese.h (parameter_rename_map_t): Remove.
   (struct sese_info_t): Remove field parameter_rename_map.
---
 gcc/graphite-isl-ast-to-gimple.c | 73 +---
 gcc/sese.c   | 44 ++--
 gcc/sese.h   |  5 ---
 3 files changed, 4 insertions(+), 118 deletions(-)

diff --git a/gcc/graphite-isl-ast-to-gimple.c b/gcc/graphite-isl-ast-to-gimple.c
index 975e106..628fc90 100644
--- a/gcc/graphite-isl-ast-to-gimple.c
+++ b/gcc/graphite-isl-ast-to-gimple.c
@@ -288,11 +288,7 @@ gcc_expression_from_isl_ast_expr_id (tree type,
  "Could not map isl_id to tree expression");
   isl_ast_expr_free (expr_id);
   tree t = res->second;
-  tree *val = region->parameter_rename_map->get(t);
-
-  if (!val)
-   val = 
-  return fold_convert (type, *val);
+  return fold_convert (type, t);
 }
 
 /* Converts an isl_ast_expr_int expression E to a GCC expression tree of
@@ -1089,70 +1085,6 @@ scop_to_isl_ast (scop_p scop, ivs_params )
   return ast_isl;
 }
 
-/* Copy def from sese REGION to the newly created TO_REGION. TR is defined by
-   DEF_STMT. GSI points to entry basic block of the TO_REGION.  */
-
-static void
-copy_def (tree tr, gimple *def_stmt, sese_info_p region, sese_info_p to_region,
- gimple_stmt_iterator *gsi)
-{
-  if (!defined_in_sese_p (tr, region->region))
-return;
-
-  ssa_op_iter iter;
-  use_operand_p use_p;
-  FOR_EACH_SSA_USE_OPERAND (use_p, def_stmt, iter, SSA_OP_USE)
-{
-  tree use_tr = USE_FROM_PTR (use_p);
-
-  /* Do not copy parameters that have been generated in the header of the
-scop.  */
-  if (region->parameter_rename_map->get(use_tr))
-   continue;
-
-  gimple *def_of_use = SSA_NAME_DEF_STMT (use_tr);
-  if (!def_of_use)
-   continue;
-
-  copy_def (use_tr, def_of_use, region, to_region, gsi);
-}
-
-  gimple *copy = gimple_copy (def_stmt);
-  gsi_insert_after (gsi, copy, GSI_NEW_STMT);
-
-  /* Create new names for all the definitions created by COPY and
- add replacement mappings for each new name.  */
-  def_operand_p def_p;
-  ssa_op_iter op_iter;
-  FOR_EACH_SSA_DEF_OPERAND (def_p, copy, op_iter, SSA_OP_ALL_DEFS)
-{
-  tree old_name = DEF_FROM_PTR (def_p);
-  tree new_name = create_new_def_for (old_name, copy, def_p);
-  region->parameter_rename_map->put(old_name, new_name);
-}
-
-  update_stmt (copy);
-}
-
-static void
-copy_internal_parameters (sese_info_p region, sese_info_p to_region)
-{
-  /* For all the parameters which definitino is in the if_region->false_region,
- insert code on true_region (if_region->true_region->entry). */
-
-  int i;
-  tree tr;
-  gimple_stmt_iterator gsi = gsi_start_bb(to_region->region.entry->dest);
-
-  FOR_EACH_VEC_ELT (region->params, i, tr)
-{
-  // If def is not in region.
-  gimple *def_stmt = SSA_NAME_DEF_STMT (tr);
-  if (def_stmt)
-   copy_def (tr, def_stmt, region, to_region, );
-}
-}
-
 /* GIMPLE Loop Generator: generates loops from STMT in GIMPLE form for
the given SCOP.  Return true if code generation succeeded.
 
@@ -1192,9 +1124,6 @@ graphite_regenerate_ast_isl (scop_p scop)
 
   context_loop = region->region.entry->src->loop_father;
 
-  /* Copy all the parameters which are defined in the region.  */
-  copy_internal_parameters(if_region->false_region, if_region->true_region);
-
   translate_isl_ast_to_gimple t(region);
   edge e = single_succ_edge (if_region->true_region->region.entry->dest);
   split_edge (e);
diff --git a/gcc/sese.c b/gcc/sese.c
index c176b8a..644c87c 100644
--- a/gcc/sese.c
+++ b/gcc/sese.c
@@ -259,7 +259,6 @@ new_sese_info (edge entry, edge exit)
   SESE_LOOPS (region) = BITMAP_ALLOC (NULL);
   SESE_LOOP_NEST (region).create (3);
   SESE_PARAMS (region).create (3);
-  region->parameter_rename_map = new parameter_rename_map_t;
   region->bbs.create (3);
 
   return region;
@@ -275,8 +274,6 @@ free_sese_info (sese_info_p region)
 
   SESE_PARAMS (region).release ();
   SESE_LOOP_NEST (region).release ();
-  delete region->parameter_rename_map;
-  region->parameter_rename_map = NULL;
 
   XDELETE (region);
 }
@@ -370,8 +367,7 @@ get_rename (rename_map_type *rename_map, tree old_name)
 /* Register in RENAME_MAP the rename 

OpenaCC dimension checking

[Nathan Sidwell]

Now the core of the execution model is committed, I've applied this patch to 
enable the nvptx dimension checking.  We force the vector size to be 32 in all 
cases, and check the worker size is not above 32.  Warnings are given if the 
user specifies an unacceptable dimension.


This patch  exposed some unacceptable testcases which I've modified to specify 
an acceptable vector length.   I also took the opportunity to fix up their 
reduction variable copying, which is only working right now because we default 
to copy, rather than firstprvate (that's the next patch for review).


Also a new testcase to exercise the error handling.

Committed to trunk.

nathan
2015-11-04  Nathan Sidwell  

	gcc/
	* config/nvptx/nvptx.c (nvptx_goacc_validate_dims): Add checking.

	libgomp/
	* testsuite/libgomp.oacc-fortran/reduction-1.f90: Fix dimensions
	and reduction copy.
	* testsuite/libgomp.oacc-fortran/reduction-2.f90: Likewise.
	* testsuite/libgomp.oacc-fortran/reduction-3.f90: Likewise.
	* testsuite/libgomp.oacc-fortran/reduction-4.f90: Likewise.
	* testsuite/libgomp.oacc-fortran/reduction-6.f90: Likewise.
	* testsuite/libgomp.oacc-c-c++-common/par-reduction-1.c: Likewise.
	* testsuite/libgomp.oacc-c-c++-common/reduction-3.c: Likewise.
	* testsuite/libgomp.oacc-c-c++-common/collapse-2.c: Likewise.
	* testsuite/libgomp.oacc-c-c++-common/par-reduction-2.c: Likewise.
	* testsuite/libgomp.oacc-c-c++-common/reduction-4.c: Likewise.
	* testsuite/libgomp.oacc-c-c++-common/reduction-initial-1.c: Likewise.
	* testsuite/libgomp.oacc-c-c++-common/reduction-1.c: Likewise.
	* testsuite/libgomp.oacc-c-c++-common/reduction-5.c: Likewise.
	* testsuite/libgomp.oacc-c-c++-common/reduction-2.c: Likewise.
	* testsuite/libgomp.oacc-c-c++-common/parallel-dims.c: New.

Index: gcc/config/nvptx/nvptx.c
===
--- gcc/config/nvptx/nvptx.c	(revision 229771)
+++ gcc/config/nvptx/nvptx.c	(working copy)
@@ -3472,8 +3472,29 @@ nvptx_goacc_validate_dims (tree ARG_UNUS
 {
   bool changed = false;
 
-  /* TODO: Leave dimensions unaltered.  Reductions need
- porting before filtering dimensions makes sense.  */
+  /* The vector size must be 32, unless this is a SEQ routine.  */
+  if (fn_level <= GOMP_DIM_VECTOR
+  && dims[GOMP_DIM_VECTOR] != PTX_VECTOR_LENGTH)
+{
+  if (dims[GOMP_DIM_VECTOR] >= 0 && fn_level < 0)
+	warning_at (DECL_SOURCE_LOCATION (decl), 0,
+		dims[GOMP_DIM_VECTOR]
+		? "using vector_length (%d), ignoring %d"
+		: "using vector_length (%d), ignoring runtime setting",
+		PTX_VECTOR_LENGTH, dims[GOMP_DIM_VECTOR]);
+  dims[GOMP_DIM_VECTOR] = PTX_VECTOR_LENGTH;
+  changed = true;
+}
+
+  /* Check the num workers is not too large.  */
+  if (dims[GOMP_DIM_WORKER] > PTX_WORKER_LENGTH)
+{
+  warning_at (DECL_SOURCE_LOCATION (decl), 0,
+		  "using num_workers (%d), ignoring %d",
+		  PTX_WORKER_LENGTH, dims[GOMP_DIM_WORKER]);
+  dims[GOMP_DIM_WORKER] = PTX_WORKER_LENGTH;
+  changed = true;
+}
 
   return changed;
 }
Index: libgomp/testsuite/libgomp.oacc-fortran/reduction-1.f90
===
--- libgomp/testsuite/libgomp.oacc-fortran/reduction-1.f90	(revision 229771)
+++ libgomp/testsuite/libgomp.oacc-fortran/reduction-1.f90	(working copy)
@@ -5,7 +5,7 @@
 program reduction_1
   implicit none
 
-  integer, parameter:: n = 10, vl = 2
+  integer, parameter:: n = 10, vl = 32
   integer   :: i, vresult, result
   logical   :: lresult, lvresult
   integer, dimension (n) :: array
@@ -19,7 +19,7 @@ program reduction_1
 
   ! '+' reductions
 
-  !$acc parallel vector_length(vl) num_gangs(1)
+  !$acc parallel vector_length(vl) num_gangs(1) copy(result)
   !$acc loop reduction(+:result)
   do i = 1, n
  result = result + array(i)
@@ -38,7 +38,7 @@ program reduction_1
 
   ! '*' reductions
 
-  !$acc parallel vector_length(vl) num_gangs(1)
+  !$acc parallel vector_length(vl) num_gangs(1) copy(result)
   !$acc loop reduction(*:result)
   do i = 1, n
  result = result * array(i)
@@ -57,7 +57,7 @@ program reduction_1
 
   ! 'max' reductions
 
-  !$acc parallel vector_length(vl) num_gangs(1)
+  !$acc parallel vector_length(vl) num_gangs(1) copy(result)
   !$acc loop reduction(max:result)
   do i = 1, n
  result = max (result, array(i))
@@ -76,7 +76,7 @@ program reduction_1
 
   ! 'min' reductions
 
-  !$acc parallel vector_length(vl) num_gangs(1)
+  !$acc parallel vector_length(vl) num_gangs(1) copy(result)
   !$acc loop reduction(min:result)
   do i = 1, n
  result = min (result, array(i))
@@ -95,7 +95,7 @@ program reduction_1
 
   ! 'iand' reductions
 
-  !$acc parallel vector_length(vl) num_gangs(1)
+  !$acc parallel vector_length(vl) num_gangs(1) copy(result)
   !$acc loop reduction(iand:result)
   do i = 1, n
  result = iand (result, array(i))
@@ -114,7 +114,7 @@ program reduction_1
 
   ! 'ior' 

Re: [ping] Fix PR debug/66728

[Richard Sandiford]

Mike Stump  writes:
> Index: dwarf2out.c
> ===
> --- dwarf2out.c   (revision 229720)
> +++ dwarf2out.c   (working copy)
> @@ -15593,8 +15593,13 @@
>return true;
>  
>  case CONST_WIDE_INT:
> -  add_AT_wide (die, DW_AT_const_value,
> -std::make_pair (rtl, GET_MODE (rtl)));
> +  {
> + wide_int w1 = std::make_pair (rtl, MAX_MODE_INT);
> + int prec = MIN (wi::min_precision (w1, UNSIGNED),
> + (unsigned int)CONST_WIDE_INT_NUNITS (rtl) * 
> HOST_BITS_PER_WIDE_INT);
> + wide_int w = wide_int::from (w1, prec, UNSIGNED);
> + add_AT_wide (die, DW_AT_const_value, w);
> +  }
>return true;
>  
>  case CONST_DOUBLE:

Setting the precision based on CONST_WIDE_INT_NUNITS means that
we might end up with two different precisions for two values of
the same variable.  E.g. for a 192-bit type, 1<<64 would be given
a precision of 128 (because it needs two HWIs to store) but 1<<128
would be given a precision of 192 (because it needs three HWIs to store).
We could then abort when comparing them for equality, since equality
needs both integers to have the same precision.  E.g. from same_dw_val_p:

case dw_val_class_wide_int:
  return *v1->v.val_wide == *v2->v.val_wide;

Thanks,
Richard

[Bug c++/68195] gcc//ld produces invalid ABI results (cxx11 problem?)

[dushistov at mail dot ru]

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

--- Comment #4 from Evgeniy Dushistov  ---
Created attachment 36650
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36650=edit
preprocessed sources

I attached files created with gcc -E from main.cpp and Lib.cpp, hope this helps
reproduce bug (used xz compressor to work around 1000KB restriction from
bugzilla).

Re: [PATCH] PR67305, tighten neon_vector_mem_operand on eliminable registers

[Jim Wilson]

On 11/04/2015 01:45 AM, Jiong Wang wrote:
> So as Jim Wilson commented on the bugzilla, instead of "return !strict",
> we need to only do the check if strict be true, and only does rejection
> which means return FALSE, for all other cases, we need to go through
> those normal checks below.

I was just about to submit the same patch myself; my testsuite run
finished last night.  This testsuite run was with a toolchain configured
"--with-arch=armv8-a --with-fpu=neon-fp-armv8 --with-float=hard
--with-mode=thumb --enable-languages=c,c++".  I see 10 fewer unexpected
failures on the gcc testsuite with the patch, and no changes to the
other testsuite results.

Jim

[Bug rtl-optimization/68212] Loop unroller breaks basic block frequencies

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-04
 CC||dje at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from David Edelsohn  ---
Confirmed.

[Bug fortran/54224] Warn for unused internal procedures

[dominiq at lps dot ens.fr]

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

--- Comment #30 from Dominique d'Humieres  ---
> so I give up. I am planning to submit the following patch, open a new PR
> for the bad locus, then close this PR as fixed.

The new PR won't be necessary: it is already pr63327.

Re: [PATCH][combine][RFC] Don't transform sign and zero extends inside mults

[Segher Boessenkool]

Hi Kyrill,

On Mon, Nov 02, 2015 at 02:15:27PM +, Kyrill Tkachov wrote:
> This patch attempts to restrict combine from transforming ZERO_EXTEND and 
> SIGN_EXTEND operations into and-bitmask
> and weird SUBREG expressions when they appear inside MULT expressions. This 
> is because a MULT rtx containing these
> extend operations is usually a well understood widening multiply operation.

Right.  I have often wanted for combine to try plain substitution as well
as substitution and simplification: simplification (which uses nonzero_bits
etc.) often makes a mess of even moderately complex instructions.

But since we do not have that yet, and your 24% number is nicely impressive,
let's try to do no simplification for widening mults, as in your patch.

> With this patch on aarch64 I saw increased generation of smaddl and umaddl 
> instructions where
> before the combination of smull and add instructions were rejected because 
> the extend operands
> were being transformed into these weird equivalent expressions.
> 
> Overall, I see 24% more [su]maddl instructions being generated for SPEC2006 
> and with no performance regressions.
> 
> The testcase in the patch is the most minimal one I could get that 
> demonstrates the issue I'm trying to solve.
> 
> Does this approach look ok?

In broad lines it does.  Could you try this patch instead?  Not tested
etc. (other than building an aarch64 cross and your test case); I'll do
that tomorrow if you like the result.


Segher


diff --git a/gcc/combine.c b/gcc/combine.c
index c3db2e0..3bf7ffb 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -5284,6 +5284,15 @@ subst (rtx x, rtx from, rtx to, int in_dest, int 
in_cond, int unique_copy)
  || GET_CODE (SET_DEST (x)) == PC))
fmt = "ie";
 
+  /* Substituting into the operands of a widening MULT is not likely
+to create RTL matching a machine insn.  */
+  if (code == MULT
+ && (GET_CODE (XEXP (x, 0)) == ZERO_EXTEND
+ || GET_CODE (XEXP (x, 0)) == SIGN_EXTEND)
+ && (GET_CODE (XEXP (x, 1)) == ZERO_EXTEND
+ || GET_CODE (XEXP (x, 1)) == SIGN_EXTEND))
+   return x;
+
   /* Get the mode of operand 0 in case X is now a SIGN_EXTEND of a
 constant.  */
   if (fmt[0] == 'e')
@@ -8455,6 +8464,15 @@ force_to_mode (rtx x, machine_mode mode, unsigned 
HOST_WIDE_INT mask,
   /* ... fall through ...  */
 
 case MULT:
+  /* Substituting into the operands of a widening MULT is not likely to
+create RTL matching a machine insn.  */
+  if (code == MULT
+ && (GET_CODE (XEXP (x, 0)) == ZERO_EXTEND
+ || GET_CODE (XEXP (x, 0)) == SIGN_EXTEND)
+ && (GET_CODE (XEXP (x, 1)) == ZERO_EXTEND
+ || GET_CODE (XEXP (x, 1)) == SIGN_EXTEND))
+   return gen_lowpart_or_truncate (mode, x);
+
   /* For PLUS, MINUS and MULT, we need any bits less significant than the
 most significant bit in MASK since carries from those bits will
 affect the bits we are interested in.  */
-- 
1.9.3

[Bug fortran/53694] [OOP] GENERIC type-bound procs should be available without part-ref syntax

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #9 from Dominique d'Humieres  ---
More than three years ago Tobias Burnus wrote

> Actually, I am no longer sure that this PR is valid - nor is Richard Maine
> in c.l.f. Janus seems to have the same doubts, if I read comment 5 correctly.
>
> The standard seems to make a distinction between 'generic type-bound 
> procedure'
> and 'generic procedure name'.

Any reason to keep this PR opened?

Note that the tests now fail with

Error: INTENT(OUT) argument 'a' of pure procedure 'scalar_equals_field' at (1)
may not be polymorphic

[Bug rtl-optimization/67753] [6 Regression] FAIL: cxg1005, cxg2002, cxg2006, cxg2007, cxg2008, cxg2018, cxg2019 and cxg2020

[dave.anglin at bell dot net]

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

--- Comment #5 from dave.anglin at bell dot net ---
On 2015-11-04, at 1:57 AM, aoliva at gcc dot gnu.org wrote:

> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36645=edit
> Here's a patch I'm testing to fix this problem

Testing...

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

Re: [ping] Fix PR debug/66728

[Mike Stump]

On Nov 4, 2015, at 12:50 PM, Richard Sandiford  
wrote:

> Mike Stump  writes:
>> Index: dwarf2out.c
>> ===
>> --- dwarf2out.c  (revision 229720)
>> +++ dwarf2out.c  (working copy)
>> @@ -15593,8 +15593,13 @@
>>   return true;
>> 
>> case CONST_WIDE_INT:
>> -  add_AT_wide (die, DW_AT_const_value,
>> -   std::make_pair (rtl, GET_MODE (rtl)));
>> +  {
>> +wide_int w1 = std::make_pair (rtl, MAX_MODE_INT);
>> +int prec = MIN (wi::min_precision (w1, UNSIGNED),
>> +(unsigned int)CONST_WIDE_INT_NUNITS (rtl) * 
>> HOST_BITS_PER_WIDE_INT);
>> +wide_int w = wide_int::from (w1, prec, UNSIGNED);
>> +add_AT_wide (die, DW_AT_const_value, w);
>> +  }
>>   return true;
>> 
>> case CONST_DOUBLE:
> 
> Setting the precision based on CONST_WIDE_INT_NUNITS means that
> we might end up with two different precisions for two values of
> the same variable.  E.g. for a 192-bit type, 1<<64 would be given
> a precision of 128 (because it needs two HWIs to store) but 1<<128
> would be given a precision of 192 (because it needs three HWIs to store).
> We could then abort when comparing them for equality, since equality
> needs both integers to have the same precision.  E.g. from same_dw_val_p:
> 
>case dw_val_class_wide_int:
>  return *v1->v.val_wide == *v2->v.val_wide;

Yeah, seems like we should have a v1.prec == v2.prec && on that.  The bad news, 
there are four of them that are like this.  The good news, 3 of them are 
location operands, and I don’t think they can hit for a very long time.  I 
think this is an oversight from the double_int version of the code where we 
just check the 128 bits for equality.  We can see if Richard wants to weigh in. 
 I think I’d just pre-approve the change, though, I think a helper to perform 
mixed equality testing would be the way to go as there are 4 of them, and I 
pretty sure they should all use the mixed version.  Though, maybe the location 
list versions are never mixed.  If they aren’t, then there is only 1 client, 
so, I’d just do the precision test inline.  Anyone able to comment on the 
location list aspect of this?

Re: [PING 2] [PATCH] c++/67942 - diagnose placement new buffer overflow

[Martin Sebor]

There was a lot of discussion of C++ aliasing rules at the recent
meeting; we really seem to be moving in the direction of being stricter
about which union member is active.  So I think we do want to diagnose
the new-expression above; the user should write new () if that's what
they mean.


Okay. I changed that in the latest patch.


Adjust is negative when the offset to a buffer of known size is
negative. For example:

 char buf [sizeof (int)];
 new ( [1] - 1) int;


OK, so because we're looking at the expression from the outside in, we
first see the subtraction and adjust becomes -1, then we see the
array_ref and adjust returns to 0.  We still don't have a negative
adjust by the time we get to the quoted if/else.


I think I see what you mean. I've changed the type of the variables
and the computation to unsigned. That made it possible to eliminate
the final else and do some other cleanup. Attached is an updated
patch.

Tested on x86_64 by botstrapping C and C++ and running make check.

Martin
gcc ChangeLog
2015-11-04  Martin Sebor  

	PR c++/67942
* invoke.texi (-Wplacement-new): Document new option.
	* gcc/testsuite/g++.dg/warn/Wplacement-new-size.C: New test.

gcc/c-family ChangeLog
2015-11-04  Martin Sebor  

	PR c++/67942
* c.opt (-Wplacement-new): New option.

gcc/cp ChangeLog
2015-11-04  Martin Sebor  

	PR c++/67942
	* cp/init.c (warn_placement_new_too_small): New function.
	(build_new_1): Call it.

diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 47ba070..5e9d7a3 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -760,6 +760,10 @@ Wprotocol
 ObjC ObjC++ Var(warn_protocol) Init(1) Warning
 Warn if inherited methods are unimplemented

+Wplacement-new
+C++ Var(warn_placement_new) Init(1) Warning
+Warn for placement new expressions with undefined behavior
+
 Wredundant-decls
 C ObjC C++ ObjC++ Var(warn_redundant_decls) Warning
 Warn about multiple declarations of the same object
diff --git a/gcc/cp/init.c b/gcc/cp/init.c
index 1ed8f6c..e2285ec 100644
--- a/gcc/cp/init.c
+++ b/gcc/cp/init.c
@@ -2269,6 +2269,199 @@ throw_bad_array_new_length (void)
   return build_cxx_call (fn, 0, NULL, tf_warning_or_error);
 }

+/* Attempt to verify that the argument, OPER, of a placement new expression
+   refers to an object sufficiently large for an object of TYPE or an array
+   of NELTS of such objects when NELTS is non-null, and issue a warning when
+   it does not.  SIZE specifies the size needed to construct the object or
+   array and captures the result of NELTS * sizeof (TYPE). (SIZE could be
+   greater when the array under construction requires a cookie to store
+   NELTS.  GCC's placement new expression stores the cookie when invoking
+   a user-defined placement new operator function but not the default one.
+   Placement new expressions with user-defined placement new operator are
+   not diagnosed since we don't know how they use the buffer (this could
+   be a future extension).  */
+static void
+warn_placement_new_too_small (tree type, tree nelts, tree size, tree oper)
+{
+  location_t loc = EXPR_LOC_OR_LOC (oper, input_location);
+
+  /* The number of bytes to subtract from the size of the provided buffer
+ based on an offset into an array or an array element reference.
+ Although intermediate results may be negative (as in a[3] - 2),
+ the ultimate result cannot be and so the computation is done in
+ unsigned HOST_WIDE_INT.  */
+  unsigned HOST_WIDE_INT adjust = 0;
+  /* True when the size of the entire destination object should be used
+ to compute the possibly optimistic estimate of the available space.  */
+  bool use_obj_size = false;
+  /* True when the reference to the destination buffer is an ADDR_EXPR.  */
+  bool addr_expr = false;
+
+  STRIP_NOPS (oper);
+
+  /* Using a function argument or a (non-array) variable as an argument
+ to placement new is not checked since it's unknown what it might
+ point to.  */
+  if (TREE_CODE (oper) == PARM_DECL
+  || TREE_CODE (oper) == VAR_DECL
+  || TREE_CODE (oper) == COMPONENT_REF)
+return;
+
+  /* Evaluate any constant expressions.  */
+  size = fold_non_dependent_expr (size);
+
+  /* Handle the common case of array + offset expression when the offset
+ is a constant.  */
+  if (TREE_CODE (oper) == POINTER_PLUS_EXPR)
+{
+  /* If the offset is comple-time constant, use it to compute a more
+	 accurate estimate of the size of the buffer.  Otherwise, use
+	 the size of the entire array as an optimistic estimate (this
+	 may lead to false negatives).  */
+  const_tree adj = TREE_OPERAND (oper, 1);
+  if (CONSTANT_CLASS_P (adj))
+	adjust += tree_to_uhwi (adj);
+  else
+	use_obj_size = true;
+
+  oper = TREE_OPERAND (oper, 0);
+
+  STRIP_NOPS (oper);
+}
+
+  if (TREE_CODE (oper) == TARGET_EXPR)
+oper = TREE_OPERAND (oper, 1);
+  else if (TREE_CODE (oper) == ADDR_EXPR)
+{

[Bug middle-end/68215] New: [6 regression] FAIL: c-c++-common/opaque-vector.c -std=c++11 (internal compiler error)

[sch...@linux-m68k.org]

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

Bug ID: 68215
   Summary: [6 regression] FAIL: c-c++-common/opaque-vector.c
-std=c++11 (internal compiler error)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
CC: ienkovich at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc-*-*

$ gcc/xg++ -Bgcc/ ../gcc/testsuite/c-c++-common/opaque-vector.c -nostdinc++
-Ipowerpc64-suse-linux/32/libstdc++-v3/include/powerpc64-suse-linux
-Ipowerpc64-suse-linux/32/libstdc++-v3/include -I../libstdc++-v3/libsupc++
-I../libstdc++-v3/include/backward -I../libstdc++-v3/testsuite/util -std=c++11
-S -m32
../gcc/testsuite/c-c++-common/opaque-vector.c: In function ‘void f()’:
../gcc/testsuite/c-c++-common/opaque-vector.c:3:153: internal compiler error:
in expand_shift_1, at expmed.c:2334
 peof((v

[Bug c++/67625] some constexpr expressions rejected as enumerator value

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-05
 CC||olegendo at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||5.2.1

--- Comment #1 from Oleg Endo  ---
I just ran into the very same issue.

[PATCH 0/4][AArch64] Add scheduling and cost models for Exynos M1

[Evandro Menezes]

Following the suggestions to add the support for the Exynos M1 models, 
the following series of patches are broken down into:


 * add more target specific tuning data
 * add heuristics tuning
 * add the Exynos M1 cost model
 * add the Exynos M1 scheduling model

Thank you,

--
Evandro Menezes

[PATCH 1/4][AArch64] Add scheduling and cost models for Exynos M1

[Evandro Menezes]

This patch adds extra tuning information about AArch64 targets:

 * Maximum number of case values before resorting to a jump table
   The default values assumed independently of the specific backends
   may be rather low for modern processors, which sport quite efficient
   direct branch prediction, whereas indirect branch prediction is
   still typically not so efficient.  This value may be specifically
   set for a processor or left at zero to use the default values.
 * L1 cache line size
   The auto-prefetcher uses this information when emitting software
   prefetch insns.

Please, commit if it's alright.

Thank you,

--
Evandro Menezes


diff --git a/gcc/config/aarch64/aarch64-cores.def b/gcc/config/aarch64/aarch64-cores.def
index 0ab1ca8..66be417 100644
--- a/gcc/config/aarch64/aarch64-cores.def
+++ b/gcc/config/aarch64/aarch64-cores.def
@@ -43,7 +43,7 @@
 AARCH64_CORE("cortex-a53",  cortexa53, cortexa53, 8A,  AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC, cortexa53, "0x41", "0xd03")
 AARCH64_CORE("cortex-a57",  cortexa57, cortexa57, 8A,  AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC, cortexa57, "0x41", "0xd07")
 AARCH64_CORE("cortex-a72",  cortexa72, cortexa57, 8A,  AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC, cortexa72, "0x41", "0xd08")
-AARCH64_CORE("exynos-m1",   exynosm1,  cortexa57, 8A,  AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO, cortexa72, "0x53", "0x001")
+AARCH64_CORE("exynos-m1",   exynosm1,  exynosm1,  8A,  AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO, exynosm1, "0x53", "0x001")
 AARCH64_CORE("thunderx",thunderx,  thunderx,  8A,  AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO, thunderx,  "0x43", "0x0a1")
 AARCH64_CORE("xgene1",  xgene1,xgene1,8A,  AARCH64_FL_FOR_ARCH8, xgene1, "0x50", "0x000")
 
diff --git a/gcc/config/aarch64/aarch64-protos.h b/gcc/config/aarch64/aarch64-protos.h
index 81792bc..ecf4685 100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -195,6 +195,9 @@ struct tune_params
   int vec_reassoc_width;
   int min_div_recip_mul_sf;
   int min_div_recip_mul_df;
+  int max_case_values; /* Case values threshold; or 0 for the default.  */
+
+  int cache_line_size; /* Cache line size; or 0 for the default.  */
 
 /* An enum specifying how to take into account CPU autoprefetch capabilities
during instruction scheduling:
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 5c8604f..e7f1c07 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -355,6 +355,8 @@ static const struct tune_params generic_tunings =
   1,	/* vec_reassoc_width.  */
   2,	/* min_div_recip_mul_sf.  */
   2,	/* min_div_recip_mul_df.  */
+  0,	/* max_case_values.  */
+  0,	/* cache_line_size.  */
   tune_params::AUTOPREFETCHER_OFF,	/* autoprefetcher_model.  */
   (AARCH64_EXTRA_TUNE_NONE)	/* tune_flags.  */
 };
@@ -378,6 +380,8 @@ static const struct tune_params cortexa53_tunings =
   1,	/* vec_reassoc_width.  */
   2,	/* min_div_recip_mul_sf.  */
   2,	/* min_div_recip_mul_df.  */
+  0,	/* max_case_values.  */
+  0,	/* cache_line_size.  */
   tune_params::AUTOPREFETCHER_WEAK,	/* autoprefetcher_model.  */
   (AARCH64_EXTRA_TUNE_NONE)	/* tune_flags.  */
 };
@@ -401,6 +405,8 @@ static const struct tune_params cortexa57_tunings =
   1,	/* vec_reassoc_width.  */
   2,	/* min_div_recip_mul_sf.  */
   2,	/* min_div_recip_mul_df.  */
+  0,	/* max_case_values.  */
+  0,	/* cache_line_size.  */
   tune_params::AUTOPREFETCHER_WEAK,	/* autoprefetcher_model.  */
   (AARCH64_EXTRA_TUNE_RENAME_FMA_REGS)	/* tune_flags.  */
 };
@@ -424,6 +430,8 @@ static const struct tune_params cortexa72_tunings =
   1,	/* vec_reassoc_width.  */
   2,	/* min_div_recip_mul_sf.  */
   2,	/* min_div_recip_mul_df.  */
+  0,	/* max_case_values.  */
+  0,	/* cache_line_size.  */
   tune_params::AUTOPREFETCHER_OFF,	/* autoprefetcher_model.  */
   (AARCH64_EXTRA_TUNE_NONE)	/* tune_flags.  */
 };
@@ -446,6 +454,8 @@ static const struct tune_params thunderx_tunings =
   1,	/* vec_reassoc_width.  */
   2,	/* min_div_recip_mul_sf.  */
   2,	/* min_div_recip_mul_df.  */
+  0,	/* max_case_values.  */
+  0,	/* cache_line_size.  */
   tune_params::AUTOPREFETCHER_OFF,	/* autoprefetcher_model.  */
   (AARCH64_EXTRA_TUNE_NONE)	/* tune_flags.  */
 };
@@ -468,6 +478,8 @@ static const struct tune_params xgene1_tunings =
   1,	/* vec_reassoc_width.  */
   2,	/* min_div_recip_mul_sf.  */
   2,	/* min_div_recip_mul_df.  */
+  0,	/* max_case_values.  */
+  0,	/* cache_line_size.  */
   tune_params::AUTOPREFETCHER_OFF,	/* autoprefetcher_model.  */
   (AARCH64_EXTRA_TUNE_NONE)	/* tune_flags.  */
 };
@@ -3242,6 +3254,20 @@ aarch64_cannot_force_const_mem (machine_mode mode ATTRIBUTE_UNUSED, rtx x)
   return aarch64_tls_referenced_p (x);
 }
 
+/* Implement TARGET_CASE_VALUES_THRESHOLD.  */
+
+static unsigned int
+aarch64_case_values_threshold (void)
+{
+  /* Use the specified limit for the number of cases before using jump
+ tables at higher 

Re: [PATCH] clarify documentation of -Q --help=optimizers

[Joseph Myers]

On Wed, 4 Nov 2015, Martin Sebor wrote:

> Improving the compiler output is a good idea. The attached patch
> prints "[disabled by -O0]" instead of "[enabled]" when an optimization
> option is enabled by default but when optimization (i.e., -O1 or
> greater) is not enabled.

I don't think it's entirely accurate that all options marked as 
Optimization in *.opt are actually disabled by -O0.  Many are, but it 
depends on the actual logic controlling each optimization.

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

Re: [PATCH 1/4][AArch64] Add scheduling and cost models for Exynos M1

[Evandro Menezes]

Please, ignore the previous patch.  This is the intended patch.

Sorry.

--
Evandro Menezes

On 11/04/2015 05:18 PM, Evandro Menezes wrote:

This patch adds extra tuning information about AArch64 targets:

 * Maximum number of case values before resorting to a jump table
   The default values assumed independently of the specific backends
   may be rather low for modern processors, which sport quite efficient
   direct branch prediction, whereas indirect branch prediction is
   still typically not so efficient.  This value may be specifically
   set for a processor or left at zero to use the default values.
 * L1 cache line size
   The auto-prefetcher uses this information when emitting software
   prefetch insns.

Please, commit if it's alright.

Thank you,



diff --git a/gcc/config/aarch64/aarch64-protos.h b/gcc/config/aarch64/aarch64-protos.h
index 81792bc..ecf4685 100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -195,6 +195,9 @@ struct tune_params
   int vec_reassoc_width;
   int min_div_recip_mul_sf;
   int min_div_recip_mul_df;
+  int max_case_values; /* Case values threshold; or 0 for the default.  */
+
+  int cache_line_size; /* Cache line size; or 0 for the default.  */
 
 /* An enum specifying how to take into account CPU autoprefetch capabilities
during instruction scheduling:
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 5c8604f..e7f1c07 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -355,6 +355,8 @@ static const struct tune_params generic_tunings =
   1,	/* vec_reassoc_width.  */
   2,	/* min_div_recip_mul_sf.  */
   2,	/* min_div_recip_mul_df.  */
+  0,	/* max_case_values.  */
+  0,	/* cache_line_size.  */
   tune_params::AUTOPREFETCHER_OFF,	/* autoprefetcher_model.  */
   (AARCH64_EXTRA_TUNE_NONE)	/* tune_flags.  */
 };
@@ -378,6 +380,8 @@ static const struct tune_params cortexa53_tunings =
   1,	/* vec_reassoc_width.  */
   2,	/* min_div_recip_mul_sf.  */
   2,	/* min_div_recip_mul_df.  */
+  0,	/* max_case_values.  */
+  0,	/* cache_line_size.  */
   tune_params::AUTOPREFETCHER_WEAK,	/* autoprefetcher_model.  */
   (AARCH64_EXTRA_TUNE_NONE)	/* tune_flags.  */
 };
@@ -401,6 +405,8 @@ static const struct tune_params cortexa57_tunings =
   1,	/* vec_reassoc_width.  */
   2,	/* min_div_recip_mul_sf.  */
   2,	/* min_div_recip_mul_df.  */
+  0,	/* max_case_values.  */
+  0,	/* cache_line_size.  */
   tune_params::AUTOPREFETCHER_WEAK,	/* autoprefetcher_model.  */
   (AARCH64_EXTRA_TUNE_RENAME_FMA_REGS)	/* tune_flags.  */
 };
@@ -424,6 +430,8 @@ static const struct tune_params cortexa72_tunings =
   1,	/* vec_reassoc_width.  */
   2,	/* min_div_recip_mul_sf.  */
   2,	/* min_div_recip_mul_df.  */
+  0,	/* max_case_values.  */
+  0,	/* cache_line_size.  */
   tune_params::AUTOPREFETCHER_OFF,	/* autoprefetcher_model.  */
   (AARCH64_EXTRA_TUNE_NONE)	/* tune_flags.  */
 };
@@ -446,6 +454,8 @@ static const struct tune_params thunderx_tunings =
   1,	/* vec_reassoc_width.  */
   2,	/* min_div_recip_mul_sf.  */
   2,	/* min_div_recip_mul_df.  */
+  0,	/* max_case_values.  */
+  0,	/* cache_line_size.  */
   tune_params::AUTOPREFETCHER_OFF,	/* autoprefetcher_model.  */
   (AARCH64_EXTRA_TUNE_NONE)	/* tune_flags.  */
 };
@@ -468,6 +478,8 @@ static const struct tune_params xgene1_tunings =
   1,	/* vec_reassoc_width.  */
   2,	/* min_div_recip_mul_sf.  */
   2,	/* min_div_recip_mul_df.  */
+  0,	/* max_case_values.  */
+  0,	/* cache_line_size.  */
   tune_params::AUTOPREFETCHER_OFF,	/* autoprefetcher_model.  */
   (AARCH64_EXTRA_TUNE_NONE)	/* tune_flags.  */
 };
@@ -3242,6 +3254,20 @@ aarch64_cannot_force_const_mem (machine_mode mode ATTRIBUTE_UNUSED, rtx x)
   return aarch64_tls_referenced_p (x);
 }
 
+/* Implement TARGET_CASE_VALUES_THRESHOLD.  */
+
+static unsigned int
+aarch64_case_values_threshold (void)
+{
+  /* Use the specified limit for the number of cases before using jump
+ tables at higher optimization levels.  */
+  if (optimize > 2
+  && selected_cpu->tune->max_case_values != 0)
+return selected_cpu->tune->max_case_values;
+  else
+return default_case_values_threshold ();
+}
+
 /* Return true if register REGNO is a valid index register.
STRICT_P is true if REG_OK_STRICT is in effect.  */
 
@@ -7672,6 +7698,13 @@ aarch64_override_options_internal (struct gcc_options *opts)
 			 opts->x_param_values,
 			 global_options_set.x_param_values);
 
+  /* Set the L1 cache line size.  */
+  if (selected_cpu->tune->cache_line_size != 0)
+maybe_set_param_value (PARAM_L1_CACHE_LINE_SIZE,
+			   selected_cpu->tune->cache_line_size,
+			   opts->x_param_values,
+			   global_options_set.x_param_values);
+
   aarch64_override_options_after_change_1 (opts);
 }
 
@@ -13385,6 +13418,7 @@ aarch64_promoted_type (const_tree t)
 return float_type_node;
   return NULL_TREE;
 }
+
 #undef TARGET_ADDRESS_COST
 #define TARGET_ADDRESS_COST aarch64_address_cost
 
@@ -13432,6 

Re: [PATCH] clarify documentation of -Q --help=optimizers

[Martin Sebor]

On 11/03/2015 03:19 AM, Alexander Monakov wrote:

On Thu, 22 Oct 2015, Martin Sebor wrote:


[Sending to the right list this time]

The documentation of the -Q --help=optimizers options leads some
to expect that when options are reported as enabled imply the
corresponding optimization will take place.  (See the following
question on gcc-help:
https://gcc.gnu.org/ml/gcc-help/2015-10/msg00133.html)

The patch below tries to make it clear that that's not always
the case.


Hi,

The issue is due to optimization passes being skipped at -O0, and yet
corresponding optimization options not explicitely disabled.  The effect of -O
is an old source of confusion, and now the intro to "Optimization Options"
says,

 Most optimizations are only enabled if an -O level is set on the command
 line.  Otherwise they are disabled, even if individual optimization flags
 are specified.

(added with this patch:
https://gcc.gnu.org/ml/gcc-patches/2009-10/msg00739.html )


Thanks for the reference! Despite the improvement, this continues
to be a recurring problem. Users tend to miss the added text, maybe
because it's on a different HTML page than the --help option. That
certainly seemed to be the case in this post:

  https://gcc.gnu.org/ml/gcc-help/2015-10/msg00135.html

It's also possible that it's because the caveat is mentioned in
a context that doesn't match their use case. In the originally
referenced thread, the user wasn't looking to enable additional
optimizations. Rather, they were trying to see what (if any)
optimizations are enabled by default, with -O0.



As we observe, it's not visible enough, and I'm not sure saying that again in
the documentation (in a different section) is a good way to go.  Maybe we'd
warn for attempts to enable optimizations at -O0, but that's not trivial.
Perhaps go with Richard's suggestion in the end of this mail ("Thus, at the
end of --help-optimizers print ...")?
https://gcc.gnu.org/ml/gcc-patches/2012-05/msg00113.html


Improving the compiler output is a good idea. The attached patch
prints "[disabled by -O0]" instead of "[enabled]" when an optimization
option is enabled by default but when optimization (i.e., -O1 or
greater) is not enabled.

The patch also further clarifies the wording in the documentation
to help users avoid falling into the trap of assuming, based on
an incomplete reading of the manual, that some optimizations are
performed even at -O0.

Martin
gcc/ChangeLog:
2015-11-04  Martin Sebor  

	* opts.c (print_filtered_help): Indicate when an optimization option
	is disabled as a result of -O0.
	* doc/invoke.texi: Further clarify the effect of -O options
	on individual optimization options.

gcc/testsuite/ChangeLog:
2015-11-04  Martin Sebor  

	* testsuite/gcc.misc-tests/help.exp: Verify that optimization options
	are printed as disabled when -O0 is specified and enabled otherwise.

Index: doc/invoke.texi
===
--- doc/invoke.texi	(revision 229716)
+++ doc/invoke.texi	(working copy)
@@ -1509,6 +1509,14 @@
 disabled or set to a specific value (assuming that the compiler
 knows this at the point where the @option{--help=} option is used).

+It's important to remember that when a given optimization option is
+enabled, either explicitly on the command line or implicitly, whether
+or not the optimization it controls will be performed during an
+invocation of the compiler may depend on other options, most commonly
+one of the @option{-O} options.  This is because many options control
+various finer aspects of other more general optimizations that must
+be enabled in order for the former option to have any effect.
+
 Here is a truncated example from the ARM port of @command{gcc}:

 @smallexample
@@ -1524,7 +1532,7 @@
 are enabled at @option{-O2} by using:

 @smallexample
--Q -O2 --help=optimizers
+  % gcc -Q -O2 --help=optimizers
 @end smallexample

 Alternatively you can discover which binary optimizations are enabled
@@ -1531,11 +1539,22 @@
 by @option{-O3} by using:

 @smallexample
-gcc -c -Q -O3 --help=optimizers > /tmp/O3-opts
-gcc -c -Q -O2 --help=optimizers > /tmp/O2-opts
-diff /tmp/O2-opts /tmp/O3-opts | grep enabled
+  % gcc -c -Q -O3 --help=optimizers > /tmp/O3-opts
+  % gcc -c -Q -O2 --help=optimizers > /tmp/O2-opts
+  % diff /tmp/O2-opts /tmp/O3-opts | grep enabled
 @end smallexample

+Finally, the following example shows the difference in output for
+an option that, while technically enabled, is disabled as a consequence
+of the implicit @option{-O0} option, and for one that is disabled by
+default.  This distinction is typically only of interest to GCC developers.
+@smallexample
+  % gcc -Q --help=optimizers
+  The following options control optimizations:
+  -faggressive-loop-optimizations 	[disabled by -O0]
+  -falign-functions   		[disabled]
+@end smallexample
+
 @item -no-canonical-prefixes
 @opindex no-canonical-prefixes
 Do not expand any 

Re: [PATCH] clarify documentation of -Q --help=optimizers

[Sandra Loosemore]

On 11/04/2015 04:52 PM, Martin Sebor wrote:


gcc/ChangeLog:
2015-11-04  Martin Sebor  

* opts.c (print_filtered_help): Indicate when an optimization option
is disabled as a result of -O0.
* doc/invoke.texi: Further clarify the effect of -O options
on individual optimization options.


invoke.texi is a huge file.  In ChangeLogs, please use (node name) to 
indicate which sections have been changed unless the changes really do 
apply throughout the whole file.



@@ -1509,6 +1509,14 @@
 disabled or set to a specific value (assuming that the compiler
 knows this at the point where the @option{--help=} option is used).

+It's important to remember that when a given optimization option is
+enabled, either explicitly on the command line or implicitly, whether
+or not the optimization it controls will be performed during an


s/will be performed/is performed/


+Finally, the following example shows the difference in output for
+an option that, while technically enabled, is disabled as a consequence
+of the implicit @option{-O0} option, and for one that is disabled by
+default.  This distinction is typically only of interest to GCC developers.


If the distinction is only interesting to developers, why does it need 
an example in GCC's user documentation?  :-S


I don't have any other comments on the writing aspects of the patch, but 
others may want to comment on technical accuracy, etc.


-Sandra

[Bug c++/67625] some constexpr expressions rejected as enumerator value

[olegendo at gcc dot gnu.org]

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

--- Comment #2 from Oleg Endo  ---
There is a funny work around for this though ...

#include 

struct bswapped16
{
  const uint16_t val;
  constexpr bswapped16 (uint16_t v) : val (__builtin_bswap16 (v)) { }
};

constexpr uint16_t bswap16 (uint16_t x)
{
  return bswapped16 (x).val;
}

enum { foo_4 = bswap16 (1) };  // OK

Re: [PATCH] clarify documentation of -Q --help=optimizers

[Martin Sebor]

On 11/04/2015 06:09 PM, Sandra Loosemore wrote:

On 11/04/2015 04:52 PM, Martin Sebor wrote:


gcc/ChangeLog:
2015-11-04  Martin Sebor  

* opts.c (print_filtered_help): Indicate when an optimization option
is disabled as a result of -O0.
* doc/invoke.texi: Further clarify the effect of -O options
on individual optimization options.


invoke.texi is a huge file.  In ChangeLogs, please use (node name) to
indicate which sections have been changed unless the changes really do
apply throughout the whole file.


@@ -1509,6 +1509,14 @@
 disabled or set to a specific value (assuming that the compiler
 knows this at the point where the @option{--help=} option is used).

+It's important to remember that when a given optimization option is
+enabled, either explicitly on the command line or implicitly, whether
+or not the optimization it controls will be performed during an


s/will be performed/is performed/


+Finally, the following example shows the difference in output for
+an option that, while technically enabled, is disabled as a consequence
+of the implicit @option{-O0} option, and for one that is disabled by
+default.  This distinction is typically only of interest to GCC
developers.


If the distinction is only interesting to developers, why does it need
an example in GCC's user documentation?  :-S


Thank you for the feedback. I'll incorporate it into the next version
of the patch.

The point of the example is to make it clear to users that despite
the different output the effect of both kinds of options on
optimization is the same (i.e., none). I made the output different
only because I expect the distinction between the state of the two
kinds of options to be of interest to GCC developers. Otherwise,
it could just say [disabled] for both.

Martin

Re: [PING 2] [PATCH] c++/67942 - diagnose placement new buffer overflow

[Jason Merrill]

On 11/04/2015 07:15 PM, Martin Sebor wrote:

There was a lot of discussion of C++ aliasing rules at the recent
meeting; we really seem to be moving in the direction of being stricter
about which union member is active.  So I think we do want to diagnose
the new-expression above; the user should write new () if that's what
they mean.


Okay. I changed that in the latest patch.


Adjust is negative when the offset to a buffer of known size is
negative. For example:

 char buf [sizeof (int)];
 new ( [1] - 1) int;


OK, so because we're looking at the expression from the outside in, we
first see the subtraction and adjust becomes -1, then we see the
array_ref and adjust returns to 0.  We still don't have a negative
adjust by the time we get to the quoted if/else.


I think I see what you mean. I've changed the type of the variables
and the computation to unsigned. That made it possible to eliminate
the final else and do some other cleanup. Attached is an updated
patch.


Hmm, I was suggesting that bytes_avail change to unsigned, but I don't 
think adjust should change; I believe that 0u - 1u is undefined due to 
overflow even though (-1u) and (unsigned)-1 are well defined.  Sorry for 
the muddled messages.  I think let's leave adjust signed and assert that 
it ends up non-negative.


Jason

[Bug rtl-optimization/68217] Wrong constant folding

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-05
  Component|c   |rtl-optimization
 Ever confirmed|0   |1
  Known to fail||4.8.5, 4.9.3, 5.2.1

--- Comment #1 from Marc Glisse  ---
Might happen during the combine pass (or not).

Re: [PR64164] drop copyrename, integrate into expand

[Alexandre Oliva]

On Sep 23, 2015, Alexandre Oliva  wrote:

> @@ -2982,38 +2887,39 @@ assign_parm_setup_block (struct assign_parm_data_all 
> *all,
[snip]
> +  if (GET_CODE (reg) != CONCAT)
> +stack_parm = reg;
> +  else
> +/* This will use or allocate a stack slot that we'd rather
> +   avoid.  FIXME: Could we avoid it in more cases?  */
> +target_reg = reg;

It turns out that we can, and that helps fixing PR67753.  In the end, I
ended up using the ABI-reserved stack slot if there is one, but just
allocating an unsplit complex pseudo fixes all remaining cases that used
to require the allocation of a stack slot.  Yay!

As for pr67753 proper, we emitted the store of the PARALLEL entry_parm
into the stack parm only in the conversion seq, which was ultimately
emitted after the copy from stack_parm to target_reg that was supposed
to copy the value originally in entry_parm.  So we copied an
uninitialized stack slot, and the subsequent store in the conversion seq
was optimized out as dead.

This caused a number of regressions on hppa-linux-gnu.  The fix for this
is to arrange for the copy to target_reg to be emitted in the conversion
seq if the copy to stack_parm was.  I can't determine whether this fix
all reported regressions, but from visual inspection of the generated
code I'm pretty sure it fixes at least gcc.c-torture/execute/pr38969.c.


When we do NOT have an ABI-reserved stack slot, the store of the
PARALLEL entry_parm into the intermediate pseudo doesn't need to go in
the conversion seq (emit_group_store from a PARALLEL to a pseudo only
uses registers, according to another comment in function.c), so I've
simplified that case.


This was regstrapped on x86_64-linux-gnu, i686-linux-gnu,
ppc64-linux-gnu, ppc64el-linux-gnu, and cross-build-tested for all
targets for which I've tested the earlier patches in the patchset.
Ok to install?



[PR67753] fix copy of PARALLEL entry_parm to CONCAT target_reg

From: Alexandre Oliva 

In assign_parms_setup_block, the copy of args in PARALLELs from
entry_parm to stack_parm is deferred to the parm conversion insn seq,
but the copy from stack_parm to target_reg was inserted in the normal
copy seq, that is executed before the conversion insn seq.  Oops.

We could do away with the need for an actual stack_parm in general,
which would have avoided the need for emitting the copy to target_reg
in the conversion seq, but at least on pa, due to the need for stack
to copy between SI and SF modes, it seems like using the reserved
stack slot is beneficial, so I put in logic to use a pre-reserved
stack slot when there is one, and emit the copy to target_reg in the
conversion seq if stack_parm was set up there.

for  gcc/ChangeLog

PR rtl-optimization/67753
PR rtl-optimization/64164
* function.c (assign_parm_setup_block): Avoid allocating a
stack slot if we don't have an ABI-reserved one.  Emit the
copy to target_reg in the conversion seq if the copy from
entry_parm is in it too.  Don't use the conversion seq to copy
a PARALLEL to a REG or a CONCAT.
---
 gcc/function.c |   39 ++-
 1 file changed, 34 insertions(+), 5 deletions(-)

diff --git a/gcc/function.c b/gcc/function.c
index aaf49a4..156c72b 100644
--- a/gcc/function.c
+++ b/gcc/function.c
@@ -2879,6 +2879,7 @@ assign_parm_setup_block (struct assign_parm_data_all *all,
   rtx entry_parm = data->entry_parm;
   rtx stack_parm = data->stack_parm;
   rtx target_reg = NULL_RTX;
+  bool in_conversion_seq = false;
   HOST_WIDE_INT size;
   HOST_WIDE_INT size_stored;
 
@@ -2895,9 +2896,23 @@ assign_parm_setup_block (struct assign_parm_data_all 
*all,
   if (GET_CODE (reg) != CONCAT)
stack_parm = reg;
   else
-   /* This will use or allocate a stack slot that we'd rather
-  avoid.  FIXME: Could we avoid it in more cases?  */
-   target_reg = reg;
+   {
+ target_reg = reg;
+ /* Avoid allocating a stack slot, if there isn't one
+preallocated by the ABI.  It might seem like we should
+always prefer a pseudo, but converting between
+floating-point and integer modes goes through the stack
+on various machines, so it's better to use the reserved
+stack slot than to risk wasting it and allocating more
+for the conversion.  */
+ if (stack_parm == NULL_RTX)
+   {
+ int save = generating_concat_p;
+ generating_concat_p = 0;
+ stack_parm = gen_reg_rtx (mode);
+ generating_concat_p = save;
+   }
+   }
   data->stack_parm = NULL;
 }
 
@@ -2938,7 +2953,9 @@ assign_parm_setup_block (struct assign_parm_data_all *all,
   mem = validize_mem (copy_rtx (stack_parm));
 
   /* Handle values in multiple non-contiguous locations.  */
-  if (GET_CODE (entry_parm) == PARALLEL)
+  if 

[gomp4] assorted trunk backports

[Cesar Philippidis]

I've applied this patch to gomp-4_0-branch which does the following:

 * reverts some of the fortran changes that Jakub rejected for
   trunk, specifically those involving resolve_omp_duplicate_list

 * updates how num_gangs, num_workers and vector_length are parsed by
   the c++ FE

 * changes how errors are reported for acc update when no clauses are
   specified and updates the test cases for c, c++ and fortran

 * shuffles around various code to match trunk in the fortran FE

We probably should update the way the c FE handles num_gangs,
num_workers and vector_length too, but I left it as-is since it works.
The c++ FE would have had problems with template support eventually
because it was doing type checking during scanning.

Cesar
2015-11-04  Cesar Philippidis  

	gcc/c/
	* c-parser.c (c_parser_oacc_update): Update the error message for
	missing clauses.

	gcc/cp/
	* parser.c (cp_parser_oacc_simple_clause): New function.
	(cp_parser_oacc_clause_vector_length): Delete.
	(cp_parser_omp_clause_num_gangs): Delete.
	(cp_parser_omp_clause_num_workers): Delete.
	(cp_parser_oacc_all_clauses): Use cp_parser_oacc_simple_clause for
	num_gangs, num_workers and vector_length.
	(cp_parser_oacc_update): Update the error message for missing
	clauses.

	gcc/fortran/
	* openmp.c (gfc_match_omp_clauses): Update how default is parsed.
	(gfc_match_oacc_update): Update error message.
	(resolve_omp_clauses): Don't use resolve_omp_duplicate_list for
	omp clauses.
	(oacc_code_to_statement): Merge atomic placement from trunk.

	gcc/testsuite/
	* c-c++-common/goacc/update-1.c: Update expected error.
	* gfortran.dg/goacc/update.f95: Likewise.

diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index 45e4248..fa70055 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -14060,7 +14060,7 @@ c_parser_oacc_update (c_parser *parser)
 {
   error_at (loc,
 		"%<#pragma acc update%> must contain at least one "
-		"% or % clause");
+		"% or % or % clause");
   return;
 }
 
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 1e2afdb..ce8bc6a 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -29652,6 +29652,39 @@ cp_parser_oacc_simple_clause (cp_parser * /* parser  */,
   return c;
 }
 
+ /* OpenACC:
+   num_gangs ( expression )
+   num_workers ( expression )
+   vector_length ( expression )  */
+
+static tree
+cp_parser_oacc_single_int_clause (cp_parser *parser, omp_clause_code code,
+  const char *str, tree list)
+{
+  location_t loc = cp_lexer_peek_token (parser->lexer)->location;
+
+  if (!cp_parser_require (parser, CPP_OPEN_PAREN, RT_OPEN_PAREN))
+return list;
+
+  tree t = cp_parser_assignment_expression (parser, NULL, false, false);
+
+  if (t == error_mark_node
+  || !cp_parser_require (parser, CPP_CLOSE_PAREN, RT_CLOSE_PAREN))
+{
+  cp_parser_skip_to_closing_parenthesis (parser, /*recovering=*/true,
+	 /*or_comma=*/false,
+	 /*consume_paren=*/true);
+  return list;
+}
+
+  check_no_duplicate_clause (list, code, str, loc);
+
+  tree c = build_omp_clause (loc, code);
+  OMP_CLAUSE_OPERAND (c, 0) = t;
+  OMP_CLAUSE_CHAIN (c) = list;
+  return c;
+}
+
 /* OpenACC:
 
 gang [( gang-arg-list )]
@@ -29923,45 +29956,6 @@ cp_parser_oacc_clause_tile (cp_parser *parser, tree list, location_t here)
   return c;
 }
 
-/* OpenACC:
-   vector_length ( expression ) */
-
-static tree
-cp_parser_oacc_clause_vector_length (cp_parser *parser, tree list)
-{
-  tree t, c;
-  location_t location = cp_lexer_peek_token (parser->lexer)->location;
-  bool error = false;
-
-  if (!cp_parser_require (parser, CPP_OPEN_PAREN, RT_OPEN_PAREN))
-return list;
-
-  t = cp_parser_condition (parser);
-  if (t == error_mark_node || !INTEGRAL_TYPE_P (TREE_TYPE (t)))
-{
-  error_at (location, "expected positive integer expression");
-  error = true;
-}
-
-  if (error || !cp_parser_require (parser, CPP_CLOSE_PAREN, RT_CLOSE_PAREN))
-{
-  cp_parser_skip_to_closing_parenthesis (parser, /*recovering=*/true,
-	   /*or_comma=*/false,
-	   /*consume_paren=*/true);
-  return list;
-}
-
-  check_no_duplicate_clause (list, OMP_CLAUSE_VECTOR_LENGTH, "vector_length",
-			 location);
-
-  c = build_omp_clause (location, OMP_CLAUSE_VECTOR_LENGTH);
-  OMP_CLAUSE_VECTOR_LENGTH_EXPR (c) = t;
-  OMP_CLAUSE_CHAIN (c) = list;
-  list = c;
-
-  return list;
-}
-
 /* OpenACC 2.0
Parse wait clause or directive parameters.  */
 
@@ -30345,42 +30339,6 @@ cp_parser_omp_clause_nowait (cp_parser * /*parser*/,
   return c;
 }
 
-/* OpenACC:
-   num_gangs ( expression ) */
-
-static tree
-cp_parser_omp_clause_num_gangs (cp_parser *parser, tree list)
-{
-  tree t, c;
-  location_t location = cp_lexer_peek_token (parser->lexer)->location;
-
-  if (!cp_parser_require (parser, CPP_OPEN_PAREN, RT_OPEN_PAREN))
-return list;
-
-  t = cp_parser_condition (parser);
-
-  if (t == error_mark_node
-  || !cp_parser_require (parser, 

Re: [openacc] tile, independent, default, private and firstprivate support in c/++

[Cesar Philippidis]

On 11/04/2015 02:24 AM, Jakub Jelinek wrote:
> Have you verified pt.c does the right thing when instantiating the
> OMP_CLAUSE_TILE clause (I mean primarily the TREE_VEC in there)?
> There really should be testcases for that.

Here's a patch which adds template support for the oacc clauses. Is it
ok for trunk?

Cesar
2015-11-04  Cesar Philippidis  

	gcc/cp/
	* pt.c (tsubst_omp_clauses): Add support for OMP_CLAUSE_{NUM_GANGS,
	NUM_WORKERS,VECTOR_LENGTH,GANG,WORKER,VECTOR,ASYNC,WAIT,TILE,AUTO,
	INDEPENDENT,SEQ}. 
	(tsubst_expr): Add support for OMP_CLAUSE_{KERNELS,PARALLEL,LOOP}.

	gcc/testsuite/
	* g++.dg/goacc/template-reduction.C: New test.
	* g++.dg/goacc/template.C: New test.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index e3f55a7..4424596 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -14395,6 +14395,15 @@ tsubst_omp_clauses (tree clauses, bool declare_simd, bool allow_fields,
 	case OMP_CLAUSE_PRIORITY:
 	case OMP_CLAUSE_ORDERED:
 	case OMP_CLAUSE_HINT:
+	case OMP_CLAUSE_NUM_GANGS:
+	case OMP_CLAUSE_NUM_WORKERS:
+	case OMP_CLAUSE_VECTOR_LENGTH:
+	case OMP_CLAUSE_GANG:
+	case OMP_CLAUSE_WORKER:
+	case OMP_CLAUSE_VECTOR:
+	case OMP_CLAUSE_ASYNC:
+	case OMP_CLAUSE_WAIT:
+	case OMP_CLAUSE_TILE:
 	  OMP_CLAUSE_OPERAND (nc, 0)
 	= tsubst_expr (OMP_CLAUSE_OPERAND (oc, 0), args, complain, 
 			   in_decl, /*integral_constant_expression_p=*/false);
@@ -14449,6 +14458,9 @@ tsubst_omp_clauses (tree clauses, bool declare_simd, bool allow_fields,
 	case OMP_CLAUSE_THREADS:
 	case OMP_CLAUSE_SIMD:
 	case OMP_CLAUSE_DEFAULTMAP:
+	case OMP_CLAUSE_INDEPENDENT:
+	case OMP_CLAUSE_AUTO:
+	case OMP_CLAUSE_SEQ:
 	  break;
 	default:
 	  gcc_unreachable ();
@@ -15197,6 +15209,15 @@ tsubst_expr (tree t, tree args, tsubst_flags_t complain, tree in_decl,
   }
   break;
 
+case OACC_KERNELS:
+case OACC_PARALLEL:
+  tmp = tsubst_omp_clauses (OMP_CLAUSES (t), false, false, args, complain,
+in_decl);
+  stmt = begin_omp_parallel ();
+  RECUR (OMP_BODY (t));
+  finish_omp_construct (TREE_CODE (t), stmt, tmp);
+  break;
+
 case OMP_PARALLEL:
   r = push_omp_privatization_clauses (OMP_PARALLEL_COMBINED (t));
   tmp = tsubst_omp_clauses (OMP_PARALLEL_CLAUSES (t), false, true,
@@ -15227,6 +15248,7 @@ tsubst_expr (tree t, tree args, tsubst_flags_t complain, tree in_decl,
 case CILK_FOR:
 case OMP_DISTRIBUTE:
 case OMP_TASKLOOP:
+case OACC_LOOP:
   {
 	tree clauses, body, pre_body;
 	tree declv = NULL_TREE, initv = NULL_TREE, condv = NULL_TREE;
@@ -15235,7 +15257,8 @@ tsubst_expr (tree t, tree args, tsubst_flags_t complain, tree in_decl,
 	int i;
 
 	r = push_omp_privatization_clauses (OMP_FOR_INIT (t) == NULL_TREE);
-	clauses = tsubst_omp_clauses (OMP_FOR_CLAUSES (t), false, true,
+	clauses = tsubst_omp_clauses (OMP_FOR_CLAUSES (t), false,
+  TREE_CODE (t) != OACC_LOOP,
   args, complain, in_decl);
 	if (OMP_FOR_INIT (t) != NULL_TREE)
 	  {
@@ -15305,9 +15328,11 @@ tsubst_expr (tree t, tree args, tsubst_flags_t complain, tree in_decl,
   pop_omp_privatization_clauses (r);
   break;
 
+case OACC_DATA:
 case OMP_TARGET_DATA:
 case OMP_TARGET:
-  tmp = tsubst_omp_clauses (OMP_CLAUSES (t), false, true,
+  tmp = tsubst_omp_clauses (OMP_CLAUSES (t), false,
+TREE_CODE (t) != OACC_DATA,
 args, complain, in_decl);
   keep_next_level (true);
   stmt = begin_omp_structured_block ();
@@ -15331,6 +15356,16 @@ tsubst_expr (tree t, tree args, tsubst_flags_t complain, tree in_decl,
   add_stmt (t);
   break;
 
+case OACC_ENTER_DATA:
+case OACC_EXIT_DATA:
+case OACC_UPDATE:
+  tmp = tsubst_omp_clauses (OMP_STANDALONE_CLAUSES (t), false, false,
+args, complain, in_decl);
+  t = copy_node (t);
+  OMP_STANDALONE_CLAUSES (t) = tmp;
+  add_stmt (t);
+  break;
+
 case OMP_ORDERED:
   tmp = tsubst_omp_clauses (OMP_ORDERED_CLAUSES (t), false, true,
 args, complain, in_decl);
diff --git a/gcc/testsuite/g++.dg/goacc/template-reduction.C b/gcc/testsuite/g++.dg/goacc/template-reduction.C
new file mode 100644
index 000..668eeb3
--- /dev/null
+++ b/gcc/testsuite/g++.dg/goacc/template-reduction.C
@@ -0,0 +1,104 @@
+// This error is temporary.  Remove when support is added for these clauses
+// in the middle end.
+// { dg-prune-output "sorry, unimplemented" }
+
+extern void abort ();
+
+const int n = 100;
+
+// Check explicit template copy map
+
+template T
+sum (T array[])
+{
+   T s = 0;
+
+#pragma acc parallel loop num_gangs (10) gang reduction (+:s) copy (s, array[0:n])
+  for (int i = 0; i < n; i++)
+s += array[i];
+
+  return s;
+}
+
+// Check implicit template copy map
+
+template T
+sum ()
+{
+  T s = 0;
+  T array[n];
+
+  for (int i = 0; i < n; i++)
+array[i] = i+1;
+
+#pragma acc parallel loop num_gangs (10) gang reduction (+:s) copy (s)
+  for (int i = 0; i < n; i++)
+s += array[i];
+
+  return s;
+}
+
+// Check present and async

[Bug fortran/68216] New: [F2003] IO problem with allocatable, deferred character length arrays

[pault at gcc dot gnu.org]

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

Bug ID: 68216
   Summary: [F2003] IO problem with allocatable, deferred
character length arrays
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pault at gcc dot gnu.org
  Target Milestone: ---

The following segfaults in the READ statement:

PROGRAM hello
IMPLICIT NONE

CHARACTER(LEN=:),DIMENSION(:),ALLOCATABLE :: array_lineas
INTEGER :: largo , cant_lineas , i
WRITE(*,*) ' Escriba un numero para el largo de cada linea'
READ(*,*) largo

WRITE(*,*) ' Escriba la cantidad de lineas'
READ(*,*) cant_lineas

ALLOCATE(CHARACTER(LEN=largo) :: array_lineas(cant_lineas))

WRITE(*,*) 'Escriba el array', len(array_lineas), size(array_lineas)
READ(*,*) (array_lineas(i),i=1,cant_lineas)

WRITE(*,*) 'Array guardado: '
DO i=1,cant_lineas
WRITE(*,*) array_lineas(i)
ENDDO

READ(*,*)

END PROGRAM

Reported on clf
https://groups.google.com/forum/#!topic/comp.lang.fortran/eWQTKfqKLZc

Paul

[Bug fortran/68216] [F2003] IO problem with allocatable, deferred character length arrays

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-11-05
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
I am not sure it has anything to do with IO, but I think it is rather a
duplicate of pr50221.

[Bug c/68217] New: Wrong constant folding

[ishiura-compiler at ml dot kwansei.ac.jp]

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

Bug ID: 68217
   Summary: Wrong constant folding
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ishiura-compiler at ml dot kwansei.ac.jp
  Target Milestone: ---

GCC-6.0.0 miscompiles the following code.

$ cat error.c

int main(void){
volatile int a = -1;
long long b = -9223372036854775807LL-1; // LLONG_MIN
long long x = (a & b); // x == 0x8000
if ( x < 1LL ) { ; } else { __builtin_abort(); }
return 0;
}

$ gcc-6.0 error.c -O3 && ./a.out
[1]26572 abort (core dumped)  ./a.out

$ gcc-6.0 -v
Using built-in specs.
COLLECT_GCC=gcc-6.0
COLLECT_LTO_WRAPPER=$HOME/opt/gcc-6.0.0/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=$HOME/opt/gcc-6.0.0
--enable-languages=c --program-suffix=-6.0
Thread model: posix
gcc version 6.0.0 20151105 (experimental) (GCC)

[Bug c/61588] Optimization defaults are not what documentation say they should be

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-05
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Martin Sebor  ---
Confirmed with the latest trunk.

The -Os documentation states:

  -Os disables the following optimization flags:

 -falign-functions  -falign-jumps  -falign-loops 
 -falign-labels  -freorder-blocks  -freorder-blocks-algorithm=stc 
 -freorder-blocks-and-partition  -fprefetch-loop-arrays

Invoking "gcc -Os -Q --help=optimizers" to "to find out the exact set of
optimizations that are enabled at [the given optimization] level" indicates
that all the options are enabled:

$ /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -Os -o/dev/null -Q
--help=optimizers | grep -E
"[-]f(align-functions|align-jumps|align-loops|align-labels|reorder-blocks|reorder-blocks-algorithm|reorder-blocks-and-partition|prefetch-loop-arrays)"
 
  -falign-functions [enabled]
  -falign-jumps [enabled]
  -falign-labels[enabled]
  -falign-loops [enabled]
  -fprefetch-loop-arrays[enabled]
  -freorder-blocks  [enabled]
  -freorder-blocks-algorithm=   simple
  -freorder-blocks-and-partition[enabled]

Re: Division Optimization in match and simplify

[Hurugalawadi, Naveen]

Hi,

Please find attached the modified patch as per review comments.

>> use :s on both inner rdiv in both patterns.  With that the two patterns are 
>> ok.
Done.

>> Omit the parens around REAL_CST@0
Done.

Regression tested on X86_64.

Thanks,
Naveendiff --git a/gcc/fold-const.c b/gcc/fold-const.c
index ee9b349..88dbbdd 100644
--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -10163,54 +10163,9 @@ fold_binary_loc (location_t loc,
 	return fold_build2_loc (loc, RDIV_EXPR, type,
 			negate_expr (arg0),
 			TREE_OPERAND (arg1, 0));
-
-  /* Convert A/B/C to A/(B*C).  */
-  if (flag_reciprocal_math
-	  && TREE_CODE (arg0) == RDIV_EXPR)
-	return fold_build2_loc (loc, RDIV_EXPR, type, TREE_OPERAND (arg0, 0),
-			fold_build2_loc (loc, MULT_EXPR, type,
-	 TREE_OPERAND (arg0, 1), arg1));
-
-  /* Convert A/(B/C) to (A/B)*C.  */
-  if (flag_reciprocal_math
-	  && TREE_CODE (arg1) == RDIV_EXPR)
-	return fold_build2_loc (loc, MULT_EXPR, type,
-			fold_build2_loc (loc, RDIV_EXPR, type, arg0,
-	 TREE_OPERAND (arg1, 0)),
-			TREE_OPERAND (arg1, 1));
-
-  /* Convert C1/(X*C2) into (C1/C2)/X.  */
-  if (flag_reciprocal_math
-	  && TREE_CODE (arg1) == MULT_EXPR
-	  && TREE_CODE (arg0) == REAL_CST
-	  && TREE_CODE (TREE_OPERAND (arg1, 1)) == REAL_CST)
-	{
-	  tree tem = const_binop (RDIV_EXPR, arg0,
-  TREE_OPERAND (arg1, 1));
-	  if (tem)
-	return fold_build2_loc (loc, RDIV_EXPR, type, tem,
-TREE_OPERAND (arg1, 0));
-	}
-
   return NULL_TREE;
 
 case TRUNC_DIV_EXPR:
-  /* Optimize (X & (-A)) / A where A is a power of 2,
-	 to X >> log2(A) */
-  if (TREE_CODE (arg0) == BIT_AND_EXPR
-	  && !TYPE_UNSIGNED (type) && TREE_CODE (arg1) == INTEGER_CST
-	  && integer_pow2p (arg1) && tree_int_cst_sgn (arg1) > 0)
-	{
-	  tree sum = fold_binary_loc (loc, PLUS_EXPR, TREE_TYPE (arg1),
-  arg1, TREE_OPERAND (arg0, 1));
-	  if (sum && integer_zerop (sum)) {
-	tree pow2 = build_int_cst (integer_type_node,
-   wi::exact_log2 (arg1));
-	return fold_build2_loc (loc, RSHIFT_EXPR, type,
-TREE_OPERAND (arg0, 0), pow2);
-	  }
-	}
-
   /* Fall through */
   
 case FLOOR_DIV_EXPR:
diff --git a/gcc/match.pd b/gcc/match.pd
index f6c5c07..d11ad79 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -247,6 +247,27 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
  (if (!HONOR_SNANS (type))
   (negate @0)))
 
+(if (flag_reciprocal_math)
+ /* Convert (A/B)/C to A/(B*C)  */
+ (simplify
+  (rdiv (rdiv:s @0 @1) @2)
+   (rdiv @0 (mult @1 @2)))
+
+ /* Convert A/(B/C) to (A/B)*C  */
+ (simplify
+  (rdiv @0 (rdiv:s @1 @2))
+   (mult (rdiv @0 @1) @2)))
+
+/* Optimize (X & (-A)) / A where A is a power of 2, to X >> log2(A) */
+(for div (exact_div trunc_div)
+ (simplify
+  (div (convert? (bit_and @0 INTEGER_CST@1)) INTEGER_CST@2)
+  (if (integer_pow2p (@2)
+   && tree_int_cst_sign_bit (@2) == 0
+   && wi::add (@2, @1) == 0
+   && tree_nop_conversion_p (type, TREE_TYPE (@0)))
+   (rshift (convert @0) { build_int_cst (integer_type_node, wi::exact_log2 (@2)); }
+
 /* If ARG1 is a constant, we can convert this to a multiply by the
reciprocal.  This does not have the same rounding properties,
so only do this if -freciprocal-math.  We can actually
@@ -464,6 +485,15 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
 (if (tem)
  (rdiv { tem; } @1)
 
+/* Convert C1/(X*C2) into (C1/C2)/X  */
+(simplify
+ (rdiv REAL_CST@0 (mult @1 REAL_CST@2))
+  (if (flag_reciprocal_math)
+   (with
+{ tree tem = const_binop (RDIV_EXPR, type, @0, @2); }
+(if (tem)
+ (rdiv { tem; } @1)
+
 /* Simplify ~X & X as zero.  */
 (simplify
  (bit_and:c (convert? @0) (convert? (bit_not @0)))

Re: Division Optimization in match and simplify

[Marc Glisse]

+/* Optimize (X & (-A)) / A where A is a power of 2, to X >> log2(A) */
+(for div (exact_div trunc_div)

Actually, it probably works for all integer divisions (floor_div, etc) 
since it is exact and thus does not depend on the rounding.


(sorry for giving the comments small piece by small piece, I write them as 
I think of them...)


+ (simplify
+  (div (convert? (bit_and @0 INTEGER_CST@1)) INTEGER_CST@2)
+  (if (integer_pow2p (@2)
+   && tree_int_cst_sign_bit (@2) == 0

I think the previous test tree_int_cst_sgn > 0 was better: for unsigned, 
it is ok if that bit is set, it is only for signed that we want to avoid 
-1/-1 which gives 1 (while a shift by 31 would give -1, except that 
wi::exact_log2 might return -1 so we would end up with a negative shift).


(actually, we could generate (unsigned)x>>31 in that case, but let's 
forget it for now)


+   && wi::add (@2, @1) == 0
+   && tree_nop_conversion_p (type, TREE_TYPE (@0)))
+   (rshift (convert @0) { build_int_cst (integer_type_node, wi::exact_log2 
(@2)); }

(does this fit in 80 cols?)

Note that if we port the following to match.pd from wherever it currently 
is, the 'convert?' becomes much less useful on this transformation


(simplify
 (convert (bit_and:s @0 INTEGER_CST@1))
 (if (tree_nop_conversion_p (type, TREE_TYPE (@0)))
  (bit_and (convert @0) (convert @1

--
Marc Glisse

[Bug fortran/68218] New: ALLOCATE with size given by a module function

[ysheofue at imgof dot com]

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

Bug ID: 68218
   Summary: ALLOCATE with size given by a module function
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ysheofue at imgof dot com
  Target Milestone: ---

Calling ALLOCATE with an array size that is given by a function argument
results in multiple calls of this function.
This issue is present (at least) on gfortran versions 4.7 ... 5

The following program unintentionally calls "nquery()" four times:

MODULE mo_test

CONTAINS

  FUNCTION nquery()
INTEGER :: nquery
WRITE (0,*) "hello!"
nquery = 1
  END FUNCTION nquery

END MODULE mo_test


! --
! MAIN PROGRAM
! --
PROGRAM example
   USE mo_test
   INTEGER, ALLOCATABLE :: query_buf(:)
   ALLOCATE(query_buf(nquery()))
END PROGRAM example

[Bug fortran/63859] OpenACC DEVICE_RESIDENT clause

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-05
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed at revision r229787 (trunk 6.0)

 !$acc declare device_resident (a)
^
sorry, unimplemented: directive not yet implemented

Re: [openacc] tile, independent, default, private and firstprivate support in c/++

[Jakub Jelinek]

On Wed, Nov 04, 2015 at 08:58:32PM -0800, Cesar Philippidis wrote:
> diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
> index e3f55a7..4424596 100644
> --- a/gcc/cp/pt.c
> +++ b/gcc/cp/pt.c
> @@ -14395,6 +14395,15 @@ tsubst_omp_clauses (tree clauses, bool declare_simd, 
> bool allow_fields,
>   case OMP_CLAUSE_PRIORITY:
>   case OMP_CLAUSE_ORDERED:
>   case OMP_CLAUSE_HINT:
> + case OMP_CLAUSE_NUM_GANGS:
> + case OMP_CLAUSE_NUM_WORKERS:
> + case OMP_CLAUSE_VECTOR_LENGTH:
> + case OMP_CLAUSE_GANG:

GANG has two arguments, so you want to handle it differently, you need
to tsubst both arguments.

> + case OMP_CLAUSE_WORKER:
> + case OMP_CLAUSE_VECTOR:
> + case OMP_CLAUSE_ASYNC:
> + case OMP_CLAUSE_WAIT:
> + case OMP_CLAUSE_TILE:

I don't think tile will work well this way, if the only argument is a
TREE_VEC, then I think you hit:
case TREE_VEC:
  /* A vector of template arguments.  */
  gcc_assert (!type);
  return tsubst_template_args (t, args, complain, in_decl);
which does something very much different from making a copy of the TREE_VEC
and calling tsubst_expr on each argument.
Thus, either you need to handle it manually here, or think about different
representation of OMP_CLAUSE_TILE?  It seems you allow at most one tile
clause, so perhaps you could split the single source tile clause into one
tile clause per expression in there (the only issue is that the FEs
emit the clauses in last to first order, so you'd need to nreverse the
tile clause list before adding it to the list of all clauses).

Otherwise it looks ok, except:

> diff --git a/gcc/testsuite/g++.dg/goacc/template-reduction.C 
> b/gcc/testsuite/g++.dg/goacc/template-reduction.C
> new file mode 100644
> index 000..668eeb3
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/goacc/template-reduction.C
> +++ b/gcc/testsuite/g++.dg/goacc/template.C

the testsuite coverage is orders of magnitude smaller than it should be.
Just look at the amount of OpenMP template tests (both compile time and
runtime):
grep template libgomp/testsuite/libgomp.c++/*[^4] | wc -l; grep -l template 
libgomp/testsuite/libgomp.c++/*[^4] | wc -l; grep template 
gcc/testsuite/g++.dg/gomp/* | wc -l; grep -l template 
gcc/testsuite/g++.dg/gomp/* | wc -l
629 # templates
45 # tests with templates
151 # templates
58 # tests with templates
and even that is really not sufficient.  From my experience, special care is
needed in template tests to test both non-type dependent and type-dependent
cases (e.g. some diagnostics is emitted already when parsing the templates
even when they won't be instantiated at all, other diagnostic is done during
instantiation), or for e.g. references there are interesting cases where
a reference to template parameter typename is used or where a reference to
some time is tsubsted into a template parameter typename.
E.g. you don't have any test coverage for the vector (num: ...)
or gang (static: *, num: type_dep)
or gang (static: type_dep1, type_dep2)
(which would show you the above issue with the gang clause), or sufficient
coverage for tile, etc.
Of course that coverage can be added incrementally.

Jakub

[Bug fortran/68218] ALLOCATE with size given by a module function

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-05
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.3.1 up to trunk (6.0).

[Bug fortran/58769] RFC: Creating SIMD variant for Fortran's ELEMENTAL functions

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-11-05
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
WTF? No activity for over two years.

[Bug fortran/61819] [4.9/4.10 Regression] ICE in gfc_conv_descriptor_data_get

[pault at gcc dot gnu.org]

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

--- Comment #15 from Paul Thomas  ---
Author: pault
Date: Wed Nov  4 20:00:19 2015
New Revision: 229777

URL: https://gcc.gnu.org/viewcvs?rev=229777=gcc=rev
Log:
2015-01-25  Paul Thomas  

Backported from trunk.
PR fortran/67171
* trans-array.c (structure_alloc_comps): On deallocation of
class components, reset the vptr to the declared type vtable
and reset the _len field of unlimited polymorphic components.
*trans-expr.c (gfc_find_and_cut_at_last_class_ref): Bail out on
allocatable component references to the right of part reference
with non-zero rank and return NULL.
(gfc_reset_vptr): Simplify this function by using the function
gfc_get_vptr_from_expr. Return if the vptr is NULL_TREE.
(gfc_reset_len): If gfc_find_and_cut_at_last_class_ref returns
NULL return.

2015-01-25  Paul Thomas  

Backported from trunk.
PR fortran/67171
* gfortran.dg/allocate_with_source_12.f03: New test

Backported from trunk.
PR fortran/61819
* gfortran.dg/allocate_with_source_13.f03: New test

Backported from trunk.
PR fortran/61830
* gfortran.dg/allocate_with_source_14.f03: New test

Backported from trunk.
PR fortran/67933
* gfortran.dg/allocate_with_source_15.f03: New test

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_12.f03
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_13.f03
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_14.f03
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_15.f03
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/trans-array.c
branches/gcc-5-branch/gcc/fortran/trans-expr.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug fortran/67171] [6 regression] sourced allocation

[pault at gcc dot gnu.org]

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

--- Comment #11 from Paul Thomas  ---
Author: pault
Date: Wed Nov  4 20:00:19 2015
New Revision: 229777

URL: https://gcc.gnu.org/viewcvs?rev=229777=gcc=rev
Log:
2015-01-25  Paul Thomas  

Backported from trunk.
PR fortran/67171
* trans-array.c (structure_alloc_comps): On deallocation of
class components, reset the vptr to the declared type vtable
and reset the _len field of unlimited polymorphic components.
*trans-expr.c (gfc_find_and_cut_at_last_class_ref): Bail out on
allocatable component references to the right of part reference
with non-zero rank and return NULL.
(gfc_reset_vptr): Simplify this function by using the function
gfc_get_vptr_from_expr. Return if the vptr is NULL_TREE.
(gfc_reset_len): If gfc_find_and_cut_at_last_class_ref returns
NULL return.

2015-01-25  Paul Thomas  

Backported from trunk.
PR fortran/67171
* gfortran.dg/allocate_with_source_12.f03: New test

Backported from trunk.
PR fortran/61819
* gfortran.dg/allocate_with_source_13.f03: New test

Backported from trunk.
PR fortran/61830
* gfortran.dg/allocate_with_source_14.f03: New test

Backported from trunk.
PR fortran/67933
* gfortran.dg/allocate_with_source_15.f03: New test

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_12.f03
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_13.f03
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_14.f03
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_15.f03
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/trans-array.c
branches/gcc-5-branch/gcc/fortran/trans-expr.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug fortran/61830] [4.9/5/6 regression] Memory leak with assignment to array of derived types with allocatable components

[pault at gcc dot gnu.org]

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

--- Comment #9 from Paul Thomas  ---
Author: pault
Date: Wed Nov  4 20:00:19 2015
New Revision: 229777

URL: https://gcc.gnu.org/viewcvs?rev=229777=gcc=rev
Log:
2015-01-25  Paul Thomas  

Backported from trunk.
PR fortran/67171
* trans-array.c (structure_alloc_comps): On deallocation of
class components, reset the vptr to the declared type vtable
and reset the _len field of unlimited polymorphic components.
*trans-expr.c (gfc_find_and_cut_at_last_class_ref): Bail out on
allocatable component references to the right of part reference
with non-zero rank and return NULL.
(gfc_reset_vptr): Simplify this function by using the function
gfc_get_vptr_from_expr. Return if the vptr is NULL_TREE.
(gfc_reset_len): If gfc_find_and_cut_at_last_class_ref returns
NULL return.

2015-01-25  Paul Thomas  

Backported from trunk.
PR fortran/67171
* gfortran.dg/allocate_with_source_12.f03: New test

Backported from trunk.
PR fortran/61819
* gfortran.dg/allocate_with_source_13.f03: New test

Backported from trunk.
PR fortran/61830
* gfortran.dg/allocate_with_source_14.f03: New test

Backported from trunk.
PR fortran/67933
* gfortran.dg/allocate_with_source_15.f03: New test

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_12.f03
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_13.f03
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_14.f03
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_15.f03
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/trans-array.c
branches/gcc-5-branch/gcc/fortran/trans-expr.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug fortran/67933] [5 Regression] ICE for array of a derived type with allocatable class in derived type object

[pault at gcc dot gnu.org]

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

--- Comment #10 from Paul Thomas  ---
Author: pault
Date: Wed Nov  4 20:00:19 2015
New Revision: 229777

URL: https://gcc.gnu.org/viewcvs?rev=229777=gcc=rev
Log:
2015-01-25  Paul Thomas  

Backported from trunk.
PR fortran/67171
* trans-array.c (structure_alloc_comps): On deallocation of
class components, reset the vptr to the declared type vtable
and reset the _len field of unlimited polymorphic components.
*trans-expr.c (gfc_find_and_cut_at_last_class_ref): Bail out on
allocatable component references to the right of part reference
with non-zero rank and return NULL.
(gfc_reset_vptr): Simplify this function by using the function
gfc_get_vptr_from_expr. Return if the vptr is NULL_TREE.
(gfc_reset_len): If gfc_find_and_cut_at_last_class_ref returns
NULL return.

2015-01-25  Paul Thomas  

Backported from trunk.
PR fortran/67171
* gfortran.dg/allocate_with_source_12.f03: New test

Backported from trunk.
PR fortran/61819
* gfortran.dg/allocate_with_source_13.f03: New test

Backported from trunk.
PR fortran/61830
* gfortran.dg/allocate_with_source_14.f03: New test

Backported from trunk.
PR fortran/67933
* gfortran.dg/allocate_with_source_15.f03: New test

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_12.f03
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_13.f03
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_14.f03
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_15.f03
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/trans-array.c
branches/gcc-5-branch/gcc/fortran/trans-expr.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug fortran/61819] [4.9/4.10 Regression] ICE in gfc_conv_descriptor_data_get

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #16 from Paul Thomas  ---
Fixed on trunk and 5 branch.

Thanks for the report.

Paul

[Bug fortran/61830] [4.9/5/6 regression] Memory leak with assignment to array of derived types with allocatable components

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #10 from Paul Thomas  ---
Fixed on trunk and 5 branch.

I'll take a look at fixing it on 4.9 but, for now, I am closing this PR.

Thanks for the report.

Paul

[Bug fortran/67933] [5 Regression] ICE for array of a derived type with allocatable class in derived type object

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #11 from Paul Thomas  ---
Fixed on trunk and 5 branch.

Thanks for the report.

Paul

Re: [PING 2] [PATCH] c++/67942 - diagnose placement new buffer overflow

[Jason Merrill]

On 11/04/2015 12:11 PM, Martin Sebor wrote:

On 11/02/2015 07:40 PM, Jason Merrill wrote:

On 10/26/2015 09:48 PM, Martin Sebor wrote:

+  while (TREE_CODE (oper) == NOP_EXPR)
+oper = TREE_OPERAND (oper, 0);


This is STRIP_NOPS.


+ to placement new is not checked since it's unknownwhat it might


Missing space.


+  else if (TREE_CODE (oper) == ADDR_EXPR) {


The brace should go on its own line.


+  /* A possibly optimistic estimate Number of bytes available


Maybe "of the number"?


Thanks for the review. I've fixed the issues above in the latest
patch (attached).




+  /* When the referenced object is a member of a union, use the
size
+ of the entire union as the size of the buffer.  */


Why?  If we're accessing one union member, we should limit the allowed
space to the size of that member.


I followed the more permissive approach taken by _FORTIFY_SOURCE
where the size of the whole object is used (on the assumption that
we will eventually want to adopt the same mechanism here). For
instance, given:

   union U { char c; int i; } u;

GCC doesn't diagnose:

   memset (, 0, sizeof u);

so I didn't expect we'd want the following diagnosed either:

   new () U ();

But if you think it's preferable to use the size of the member
for this iteration of the placement new warning I can change it.
Can you confirm?


There was a lot of discussion of C++ aliasing rules at the recent 
meeting; we really seem to be moving in the direction of being stricter 
about which union member is active.  So I think we do want to diagnose 
the new-expression above; the user should write new () if that's what 
they mean.



+  if (bytes_avail <= abs (adjust))
+bytes_avail = 0;
+  else if (0 <= adjust)
+bytes_avail -= adjust;
+  else
+bytes_avail += adjust;


If adjust is negative, I would think that we would have returned already
because we were dealing with an offset from a pointer of unknown value.


Adjust is negative when the offset to a buffer of known size is
negative. For example:

 char buf [sizeof (int)];
 new ( [1] - 1) int;


OK, so because we're looking at the expression from the outside in, we 
first see the subtraction and adjust becomes -1, then we see the 
array_ref and adjust returns to 0.  We still don't have a negative 
adjust by the time we get to the quoted if/else.



It also seems that you're being careful to avoid bytes_avail going
negative, so I wonder why you have it signed and bytes_need unsigned.


+  warning_at (EXPR_LOC_OR_LOC (orig_oper, input_location),


Let's remember this location early on so you don't need orig_oper.


Done.

Martin

Re: [ping] Fix PR debug/66728

[Mike Stump]

On Nov 4, 2015, at 4:15 AM, Richard Biener  wrote:
> I wonder if we'll manage to to get mode_for_size return BLKmode
> in case of an original mode that was not of a size multiple of
> HOST_BITS_PER_WIDE_INT (and that's host dependent even…).

> We probably should use smallest_mode_for_size on a precision
> derived from the value

Once we want to go stomping around the value, we might as well just do 
everything.  I prefer this version over one that has a call to assert.  I 
thought about creating a helper function, but since there is only 1 client for 
it, and since it was only 4 lines, I didn’t create one.  I’d propose deferring 
creation until we have more clients.  The generated dwarf remains fixed, as 
expected.

> Please use gcc_checking_assert here.

Done.  My test suite run with the assert did finish, and on x86_64 linux, it 
was never hit.

Any other issues you can spot?


Index: dwarf2out.c
===
--- dwarf2out.c (revision 229720)
+++ dwarf2out.c (working copy)
@@ -15593,8 +15593,13 @@
   return true;
 
 case CONST_WIDE_INT:
-  add_AT_wide (die, DW_AT_const_value,
-  std::make_pair (rtl, GET_MODE (rtl)));
+  {
+   wide_int w1 = std::make_pair (rtl, MAX_MODE_INT);
+   int prec = MIN (wi::min_precision (w1, UNSIGNED),
+   (unsigned int)CONST_WIDE_INT_NUNITS (rtl) * 
HOST_BITS_PER_WIDE_INT);
+   wide_int w = wide_int::from (w1, prec, UNSIGNED);
+   add_AT_wide (die, DW_AT_const_value, w);
+  }
   return true;
 
 case CONST_DOUBLE:
Index: rtl.h
===
--- rtl.h   (revision 229720)
+++ rtl.h   (working copy)
@@ -2086,6 +2086,7 @@
 inline unsigned int
 wi::int_traits ::get_precision (const rtx_mode_t )
 {
+  gcc_checking_assert (x.second != BLKmode && x.second != VOIDmode);
   return GET_MODE_PRECISION (x.second);
 }
 

Re: [c++-delayed-folding] Introduce convert_to_real_nofold

[Jason Merrill]

On 11/04/2015 12:34 PM, Marek Polacek wrote:

On Wed, Nov 04, 2015 at 10:31:44AM -0500, Jason Merrill wrote:

Then let's do that rather than introduce maybe_fold.


Like so?



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


Yes, thanks.


diff --git gcc/convert.c gcc/convert.c
index ec6ff37..9355f2b 100644
--- gcc/convert.c
+++ gcc/convert.c
@@ -119,17 +119,19 @@ convert_to_pointer_nofold (tree type, tree expr)
  /* Convert EXPR to some floating-point type TYPE.

 EXPR must be float, fixed-point, integer, or enumeral;
-   in other cases error is called.  */
+   in other cases error is called.  If FOLD_P is true, try to fold
+   the expression.  */

-tree
-convert_to_real (tree type, tree expr)
+static tree
+convert_to_real_1 (tree type, tree expr, bool fold_p)
  {
enum built_in_function fcode = builtin_mathfn_code (expr);
tree itype = TREE_TYPE (expr);
+  location_t loc = EXPR_LOCATION (expr);

if (TREE_CODE (expr) == COMPOUND_EXPR)
  {
-  tree t = convert_to_real (type, TREE_OPERAND (expr, 1));
+  tree t = convert_to_real_1 (type, TREE_OPERAND (expr, 1), fold_p);
if (t == TREE_OPERAND (expr, 1))
return expr;
return build2_loc (EXPR_LOCATION (expr), COMPOUND_EXPR, TREE_TYPE (t),
@@ -237,14 +239,13 @@ convert_to_real (tree type, tree expr)
  || TYPE_MODE (newtype) == TYPE_MODE (float_type_node)))
{
  tree fn = mathfn_built_in (newtype, fcode);
-
  if (fn)
- {
-   tree arg = fold (convert_to_real (newtype, arg0));
-   expr = build_call_expr (fn, 1, arg);
-   if (newtype == type)
- return expr;
- }
+   {
+ tree arg = convert_to_real_1 (newtype, arg0, fold_p);
+ expr = build_call_expr (fn, 1, arg);
+ if (newtype == type)
+   return expr;
+   }
}
}
default:
@@ -263,9 +264,11 @@ convert_to_real (tree type, tree expr)
  if (!flag_rounding_math
  && FLOAT_TYPE_P (itype)
  && TYPE_PRECISION (type) < TYPE_PRECISION (itype))
-   return build1 (TREE_CODE (expr), type,
-  fold (convert_to_real (type,
- TREE_OPERAND (expr, 0;
+   {
+ tree arg = convert_to_real_1 (type, TREE_OPERAND (expr, 0),
+   fold_p);
+ return build1 (TREE_CODE (expr), type, arg);
+   }
  break;
/* Convert (outertype)((innertype0)a+(innertype1)b)
   into ((newtype)a+(newtype)b) where newtype
@@ -301,8 +304,10 @@ convert_to_real (tree type, tree expr)
  || newtype == dfloat128_type_node)
{
  expr = build2 (TREE_CODE (expr), newtype,
-fold (convert_to_real (newtype, arg0)),
-fold (convert_to_real (newtype, arg1)));
+convert_to_real_1 (newtype, arg0,
+   fold_p),
+convert_to_real_1 (newtype, arg1,
+   fold_p));
  if (newtype == type)
return expr;
  break;
@@ -341,8 +346,10 @@ convert_to_real (tree type, tree expr)
  && !excess_precision_type (newtype
{
  expr = build2 (TREE_CODE (expr), newtype,
-fold (convert_to_real (newtype, arg0)),
-fold (convert_to_real (newtype, arg1)));
+convert_to_real_1 (newtype, arg0,
+   fold_p),
+convert_to_real_1 (newtype, arg1,
+   fold_p));
  if (newtype == type)
return expr;
}
@@ -373,20 +380,39 @@ convert_to_real (tree type, tree expr)

  case COMPLEX_TYPE:
return convert (type,
- fold_build1 (REALPART_EXPR,
-  TREE_TYPE (TREE_TYPE (expr)), expr));
+ maybe_fold_build1_loc (fold_p, loc, REALPART_EXPR,
+TREE_TYPE (TREE_TYPE (expr)),
+expr));

  case POINTER_TYPE:
  case REFERENCE_TYPE:
error ("pointer value used where a floating point value was expected");
-  return convert_to_real (type, integer_zero_node);
+  return convert_to_real_1 (type, integer_zero_node, fold_p);

  default:
error 

Re: [PATCH] Add support for ARM embedded multilibs

[Jasmin J.]

Hello Ramana!

> There are usually features on the embedded-X_X-branch used to create
> releases that may not be on an FSF release branch.
Not on the embedded-5 branch and as far as I analysed it, all changes of
embedded-4.9 branch are now at Trunk.

>> I would like to ask if  you have a copyright assignment on file with the
>> FSF
> So, you don't have one ? In which case it may make more sense for Tejas to
> deal with this given he can handle it under ARM's copyright assignment. If
> you make changes to this without a copyright assignment on file and submit
> it, it may be difficult to review this from a copyright position.
So shall I communicate with Tejas instead of gcc-patches?

On the other hand I just read
" Small changes can be accepted without a copyright disclaimer or a copyright
  assignment on file. "
And at the end, it is the same code as Terry's patch. But I will investigate
the things you mentioned in your first answer, if they are really required and
if no simplify the patch.

> Changing the way in which you build GCC is a real change to GCC that affects
> many developers.
Does it really? It is enabled only, if you use the "--with-multilib-list"
configure option. Without the option, gcc is build exactly the same.
Without the patch "--with-multilib-list" even to allowed for any ARM target.

> I think mapping all the remaining -mcpu=cortex-a* cores and -mcpu=cortex-m*
> cores in there would be a sensible first step.
THX for the hint.

BR
   Jasmin

Re: [PATCH] Fix declaration of pthread-structs in s-osinte-rtems.ads

[Jan Sommer]

Am Tuesday 03 November 2015, 20:13:50 schrieb Arnaud Charlet:
> > > Your ChangeLog entry is not in the proper format, see sections 6.8.1 and
> > > 6.8.2 from http://www.gnu.org/prep/standards/standards.html
> > > 
> > > The diff itself is OK.
> > 
> > Ok, fixed this. See the new diff below.
> 
> This is now OK, you can go ahead and commit it.
> 

Attached are the 2 final patches. One for trunk and the other one for both the 
gcc-5-branch and the gcc-4_9-branch.
I don't have write access, so one of you would need to commit it.

Thanks,

   JanIndex: gcc/ada/ChangeLog
===
--- gcc/ada/ChangeLog	(Revision 229739)
+++ gcc/ada/ChangeLog	(Arbeitskopie)
@@ -1,3 +1,9 @@
+2015-11-03  Jan Sommer 
+
+	* s-oscons-tmplt.c: Generate pthread constants for RTEMS
+	* s-osinte-rtems.ads: Declare pthread structs as opaque types in Ada
+	Fixes PR ada/68169
+
 2015-10-09  Eric Botcazou  
 
 	* gcc-interface/Make-lang.in: Make sure that GNAT1_OBJS and not just
Index: gcc/ada/s-oscons-tmplt.c
===
--- gcc/ada/s-oscons-tmplt.c	(Revision 229739)
+++ gcc/ada/s-oscons-tmplt.c	(Arbeitskopie)
@@ -157,7 +157,7 @@ pragma Style_Checks ("M32766");
 # include <_types.h>
 #endif
 
-#ifdef __linux__
+#if defined (__linux__) || defined (__rtems__)
 # include 
 # include 
 #endif
@@ -1456,7 +1456,8 @@ CND(CLOCK_THREAD_CPUTIME_ID, "Thread CPU clock")
 CNS(CLOCK_RT_Ada, "")
 #endif
 
-#if defined (__APPLE__) || defined (__linux__) || defined (DUMMY)
+#if defined (__APPLE__) || defined (__linux__) || defined (__rtems__) || \
+  defined (DUMMY)
 /*
 
--  Sizes of pthread data types
@@ -1499,7 +1500,7 @@ CND(PTHREAD_RWLOCKATTR_SIZE, "pthread_rwlockattr_t
 CND(PTHREAD_RWLOCK_SIZE, "pthread_rwlock_t")
 CND(PTHREAD_ONCE_SIZE,   "pthread_once_t")
 
-#endif /* __APPLE__ || __linux__ */
+#endif /* __APPLE__ || __linux__ || __rtems__*/
 
 /*
 
Index: gcc/ada/s-osinte-rtems.ads
===
--- gcc/ada/s-osinte-rtems.ads	(Revision 229739)
+++ gcc/ada/s-osinte-rtems.ads	(Arbeitskopie)
@@ -51,6 +51,8 @@
 --  It is designed to be a bottom-level (leaf) package.
 
 with Interfaces.C;
+with System.OS_Constants;
+
 package System.OS_Interface is
pragma Preelaborate;
 
@@ -60,6 +62,7 @@ package System.OS_Interface is
subtype rtems_id   is Interfaces.C.unsigned;
 
subtype intis Interfaces.C.int;
+   subtype char   is Interfaces.C.char;
subtype short  is Interfaces.C.short;
subtype long   is Interfaces.C.long;
subtype unsigned   is Interfaces.C.unsigned;
@@ -68,7 +71,6 @@ package System.OS_Interface is
subtype unsigned_char  is Interfaces.C.unsigned_char;
subtype plain_char is Interfaces.C.plain_char;
subtype size_t is Interfaces.C.size_t;
-
---
-- Errno --
---
@@ -76,11 +78,11 @@ package System.OS_Interface is
function errno return int;
pragma Import (C, errno, "__get_errno");
 
-   EAGAIN: constant := 11;
-   EINTR : constant := 4;
-   EINVAL: constant := 22;
-   ENOMEM: constant := 12;
-   ETIMEDOUT : constant := 116;
+   EAGAIN: constant := System.OS_Constants.EAGAIN;
+   EINTR : constant := System.OS_Constants.EINTR;
+   EINVAL: constant := System.OS_Constants.EINVAL;
+   ENOMEM: constant := System.OS_Constants.ENOMEM;
+   ETIMEDOUT : constant := System.OS_Constants.ETIMEDOUT;
 
-
-- Signals --
@@ -448,6 +450,7 @@ package System.OS_Interface is
   ss_low_priority : int;
   ss_replenish_period : timespec;
   ss_initial_budget   : timespec;
+  sched_ss_max_repl   : int;
end record;
pragma Convention (C, struct_sched_param);
 
@@ -621,43 +624,34 @@ private
end record;
pragma Convention (C, timespec);
 
-   CLOCK_REALTIME :  constant clockid_t := 1;
-   CLOCK_MONOTONIC : constant clockid_t := 4;
+   CLOCK_REALTIME :  constant clockid_t := System.OS_Constants.CLOCK_REALTIME;
+   CLOCK_MONOTONIC : constant clockid_t := System.OS_Constants.CLOCK_MONOTONIC;
 
+   subtype char_array is Interfaces.C.char_array;
+
type pthread_attr_t is record
-  is_initialized  : int;
-  stackaddr   : System.Address;
-  stacksize   : int;
-  contentionscope : int;
-  inheritsched: int;
-  schedpolicy : int;
-  schedparam  : struct_sched_param;
-  cputime_clocked_allowed : int;
-  detatchstate: int;
+  Data : char_array (1 .. OS_Constants.PTHREAD_ATTR_SIZE);
end record;
pragma Convention (C, pthread_attr_t);
+   for pthread_attr_t'Alignment use Interfaces.C.double'Alignment;
 
type pthread_condattr_t is record
-  flags   : int;
-  process_shared  : int;
+  Data : char_array (1 .. OS_Constants.PTHREAD_CONDATTR_SIZE);
end record;

Re: Division Optimization in match and simplify

[Richard Biener]

On Wed, Nov 4, 2015 at 12:18 PM, Marc Glisse  wrote:
> On Wed, 4 Nov 2015, Hurugalawadi, Naveen wrote:
>
 I thought we were mostly using the 'convert?'
 and tree_nop_conversion_p on integers

Yes, on floats they shouldn't be used.

>>
>> Done. Cleared all instances of convert which are not required.
>> However, I am still confused about the use of "convert" in match
>> and simplify.
>
>
> It could be that I am wrong, you'll have to wait for Richard's comments
> anyway. The one place where a convert could be useful is:
> (div (convert? (bit_and @0 INTEGER_CST@1)) INTEGER_CST@2)
> but I didn't check if we want it (it would probably at least require
> (convert @0) instead of plain @0 in the result so the division and the shift
> are done with the same signedness).
>
 So all patterns looking at arg[01] are handling nop-conversions on their
 outermost operands while those looking at op[01] do not.
>>
>>
>> These patterns are looking at arg[01] rather than op[01] ?
>
>
> Might be a case where it doesn't really matter which one you look at, and
> the easiest one in fold-const may not be the same as in match.pd.
>
> +/* Convert (A/B)/C to A/(B*C)  */
> +(simplify
> + (rdiv (rdiv @0 @1) @2)
> +  (if (flag_reciprocal_math)
>
> I would indent this line the same as the one above.

Yep.

> +   (rdiv @0 (mult @1 @2
> +
> +/* Convert A/(B/C) to (A/B)*C  */
> +(simplify
> + (rdiv @0 (rdiv @1 @2))
> +  (if (flag_reciprocal_math)
> +   (mult (rdiv @0 @1) @2)))
>
> I believe you might want a :s on the inner rdiv (?).
> Note that you can factor out the test on flag_reciprocal_math so you write
> it only once for 2 patterns.

Please use :s on both inner rdiv in both patterns.  With that the two patterns
are ok.

+/* Convert C1/(X*C2) into (C1/C2)/X  */
+(simplify
+ (rdiv (REAL_CST@0) (mult @1 REAL_CST@2))

Omit the parens around REAL_CST@0

+  (if (flag_reciprocal_math)
+   (with
+{ tree tem = const_binop (RDIV_EXPR, type, @0, @2); }
+(if (tem)
+ (rdiv { tem; } @1)

with that the pattern is ok.

>
> I don't really remember what the tests !TYPE_UNSIGNED (type) and
> tree_int_cst_sgn are for in the other pattern, but since you are only moving
> the transformation...

+/* Optimize (X & (-A)) / A where A is a power of 2, to X >> log2(A) */
+(for div (exact_div trunc_div)
+ (simplify
+  (div (bit_and @0 INTEGER_CST@1) INTEGER_CST@2)
+  (if (!TYPE_UNSIGNED (type) && integer_pow2p (@2)
+   && tree_int_cst_sgn (@2) > 0
+   && wi::add (@2, @1) == 0)
+   (rshift @0 { build_int_cst (integer_type_node, wi::exact_log2 (@2)); }

the TYPE_UNSIGNED test is because right shift of negative values is undefined,
so is a shift with a negative value.  I believe we can safely handle
conversions here
just like fold-const.c does with

 (div (convert? (bit_and @0 INTEGER_CST@1) INTEGER_CST@2)
 (if (tree_nop_conversion_p (type, TREE_TYPE (@0)))
  ...

With that the pattern looks ok to me.

Richard.


>
> --
> Marc Glisse

[PATCH/RFC/RFA] Machine modes for address printing (all targets)

[Julian Brown]

Hi,

Depending on assembler syntax and supported addressing modes, several
targets need to know the machine mode for a memory access when printing
an address (i.e. for automodify addresses that need to know the size
of their access), but it is not available with the current
TARGET_PRINT_OPERAND_ADDRESS hook. This leads to an ugly corner in the
operand output mechanism, where address printing gets split between
different parts of a backend, or some other hack (e.g. a global
variable) is used to communicate the machine mode to the address
printing hook.

Using a global variable also leads to a latent (?) bug on at least
AArch64: attempts to use the 'a' operand printing code cause final.c
to call output_address (in turn invoking the PRINT_OPERAND_ADDRESS
macro) *without* first setting the magic global
aarch64_memory_reference_mode, which means a stale value will be used
instead.

The full list of targets that use some form of workaround for the lack
of machine mode in the address printing hook is (E):

aarch64: uses magic global.
arc: pre/post inc/dec handled in print_operand.
arm: uses magic global.
c6x
epiphany: offsets handled in print_operand.
m32r: hard-wires 4 for access size.
nds32
tilegx: uses magic global.
tilepro: uses magic global.

That's not all targets by any means, but may be enough to warrant a
change in the interface. I propose that:

* The output_address function should have a machine_mode argument
  added. Bare addresses (e.g. the 'a' case in final.c) should pass
  "VOIDmode" for this argument.

* Other callers of output_address -- actually all in backends -- can
  pass the machine mode for the memory access in question.

* The TARGET_PRINT_OPERAND_ADDRESS hook shall also have a machine_mode
  argument added. The legacy PRINT_OPERAND_ADDRESS hook can be left
  alone. (The documentation for the operand-printing hooks needs fixing
  too, incidentally.)

The attached patch makes this change, fairly mechanically. This removes
(most of) the magic globals for address printing, but I haven't tried
to refactor the targets that use other hacks to print correct
auto-modify addresses (that can be done by their respective
maintainers, hopefully, and should result in a nice cleanup).

Unfortunately I can't hope to test all the targets affected, though the
subset of targets that it's relatively easy for me to build, build
fine. I also ran regression tests for AArch64.

OK to apply, or any comments, or any further testing required?

Thanks,

Julian

ChangeLog

gcc/
* final.c (output_asm_insn): Pass VOIDmode to output_address.
(output_address): Add MODE argument. Pass to print_operand_address
hook.
* targhooks.c (default_print_operand_address): Add MODE argument.
* targhooks.h (default_print_operand_address): Update prototype.
* output.h (output_address): Update prototype.
* target.def (print_operand_address): Add MODE argument.
* config/vax/vax.c (print_operand_address): Pass VOIDmode to
output_address.
(print_operand): Pass access mode to output_address.
* config/mcore/mcore.c (mcore_print_operand_address): Add MODE
argument.
(mcore_print_operand): Update calls to mcore_print_operand_address.
* config/fr30/fr30.c (fr30_print_operand): Pass VOIDmode to
output_address.
* config/lm32/lm32.c (lm32_print_operand): Pass mode in calls to
output_address.
* config/tilegx/tilegx.c (output_memory_reference_mode): Remove
global.
(tilegx_print_operand): Don't set above global. Update calls to
output_address.
(tilegx_print_operand_address): Add MODE argument. Use instead of
output_memory_reference_mode global.
* config/frv/frv.c (frv_print_operand_address): Add MODE argument.
* config/mn10300/mn10300.c (mn10300_print_operand): Pass mode to
output_address.
* config/cris/cris.c (cris_print_operand_address): Add MODE
argument.
(cris_print_operand): Pass mode to output_address calls.
* config/spu/spu.c (print_operand): Pass mode to output_address
calls.
* config/aarch64/aarch64.h (aarch64_print_operand)
(aarch64_print_operand_address): Remove prototypes.
* config/aarch64/aarch64.c (aarch64_memory_reference_mode): Delete
global.
(aarch64_print_operand): Make static. Update calls to
output_address.
(aarch64_print_operand_address): Add MODE argument. Use instead of
aarch64_memory_reference_mode global.
(TARGET_PRINT_OPERAND, TARGET_PRINT_OPERAND_ADDRESS): Define target
hooks.
* config/aarch64/aarch64.h (PRINT_OPERAND, PRINT_OPERAND_ADDRESS):
Delete macro definitions.
* config/pa/pa.c (pa_print_operand): Pass mode in output_address
calls.
* config/xtensa/xtensa.c (print_operand): Pass mode in
output_address calls.
* config/h8300/h8300.c (h8300_print_operand_address): Add MODE
argument.
(h83000_print_operand): Update calls to h8300_print_operand_address
and output_address.
* config/ia64/ia64.c 

Re: [PATCH 9/9] ENABLE_CHECKING refactoring: C family front ends

[Mikhail Maltsev]

On 11/03/2015 02:34 AM, Jeff Law wrote:
> 
>> @@ -14279,8 +14272,9 @@ tsubst_copy (tree t, tree args, tsubst_flags_t
>> complain, tree in_decl)
>> return tsubst_binary_right_fold (t, args, complain, in_decl);
>>
>>   default:
>> -  /* We shouldn't get here, but keep going if !ENABLE_CHECKING.  */
>> -  gcc_checking_assert (false);
>> +  /* We shouldn't get here, but keep going if !flag_checking.  */
>> +  if (!flag_checking)
>> +gcc_unreachable ();
>> return t;
>>   }
>>   }
> I think this condition was reversed, right?
> 
> Please fix that and install on the trunk.
> 
> Thanks again!
> 
> jeff

Fixed and committed as r229756.

-- 
Regards,
Mikhail Maltsev

[Bug fortran/64973] Duplicate use-statements could be diagnosed

[dominiq at lps dot ens.fr]

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

--- Comment #1 from Dominique d'Humieres  ---
Correct link: https://gcc.gnu.org/ml/fortran/2015-02/msg00036.html.

[Bug middle-end/64247] malloc alignment and -mavx

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #11 from Joost VandeVondele  
---
(In reply to Dominique d'Humieres from comment #10)
> A few comments:
> 
> (1) Why do you want to use PURE in this context?

because this is a pure procedure ? 

Comment 7 is not too the point (indeed reassociation can happen) as explained
afterwards

The bug here is that the same (serial) binary gives different results from run
to run, as soon as the user enables avx, and there is no way around.

I agree that it would be fixed if there was an option as askin in pr68101. (and
yes, this could help with performance as well).

Re: [PATCH 3/6] Share code from fold_array_ctor_reference with fold.

[Alan Lawrence]

> s/explicitely/explicitly/  And remove the '*' from the 2nd and 3rd lines
> of the comment.
>
> It looks like get_ctor_element_at_index has numerous formatting
> problems.  In particular you didn't indent the braces across the board
> properly.  Also check for tabs vs spaces issues please.

Yes, you are quite right, I'm not quite sure how those crept in. (Well, the
'explicitely' I am sure was a copy-paste error but the others!). Apologies...

I already committed the offending code as r229605, but here's a patch to clean
it up - does it look ok now?

Thanks, Alan
---
 gcc/fold-const.c | 58 
 1 file changed, 29 insertions(+), 29 deletions(-)

diff --git a/gcc/fold-const.c b/gcc/fold-const.c
index ee9b349..e977b49 100644
--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -11855,16 +11855,16 @@ get_array_ctor_element_at_index (tree ctor, 
offset_int access_index)
   offset_int low_bound = 0;
 
   if (TREE_CODE (TREE_TYPE (ctor)) == ARRAY_TYPE)
-  {
-tree domain_type = TYPE_DOMAIN (TREE_TYPE (ctor));
-if (domain_type && TYPE_MIN_VALUE (domain_type))
 {
-  /* Static constructors for variably sized objects makes no sense.  */
-  gcc_assert (TREE_CODE (TYPE_MIN_VALUE (domain_type)) == INTEGER_CST);
-  index_type = TREE_TYPE (TYPE_MIN_VALUE (domain_type));
-  low_bound = wi::to_offset (TYPE_MIN_VALUE (domain_type));
+  tree domain_type = TYPE_DOMAIN (TREE_TYPE (ctor));
+  if (domain_type && TYPE_MIN_VALUE (domain_type))
+   {
+ /* Static constructors for variably sized objects makes no sense.  */
+ gcc_assert (TREE_CODE (TYPE_MIN_VALUE (domain_type)) == INTEGER_CST);
+ index_type = TREE_TYPE (TYPE_MIN_VALUE (domain_type));
+ low_bound = wi::to_offset (TYPE_MIN_VALUE (domain_type));
+   }
 }
-  }
 
   if (index_type)
 access_index = wi::ext (access_index, TYPE_PRECISION (index_type),
@@ -11880,29 +11880,29 @@ get_array_ctor_element_at_index (tree ctor, 
offset_int access_index)
   tree cfield, cval;
 
   FOR_EACH_CONSTRUCTOR_ELT (CONSTRUCTOR_ELTS (ctor), cnt, cfield, cval)
-  {
-/* Array constructor might explicitely set index, or specify range
- * or leave index NULL meaning that it is next index after previous
- * one.  */
-if (cfield)
 {
-  if (TREE_CODE (cfield) == INTEGER_CST)
-   max_index = index = wi::to_offset (cfield);
+  /* Array constructor might explicitly set index, or specify a range,
+or leave index NULL meaning that it is next index after previous
+one.  */
+  if (cfield)
+   {
+ if (TREE_CODE (cfield) == INTEGER_CST)
+   max_index = index = wi::to_offset (cfield);
+ else
+   {
+ gcc_assert (TREE_CODE (cfield) == RANGE_EXPR);
+ index = wi::to_offset (TREE_OPERAND (cfield, 0));
+ max_index = wi::to_offset (TREE_OPERAND (cfield, 1));
+   }
+   }
   else
-  {
-   gcc_assert (TREE_CODE (cfield) == RANGE_EXPR);
-   index = wi::to_offset (TREE_OPERAND (cfield, 0));
-   max_index = wi::to_offset (TREE_OPERAND (cfield, 1));
-  }
-}
-else
-{
-  index += 1;
-  if (index_type)
-   index = wi::ext (index, TYPE_PRECISION (index_type),
-TYPE_SIGN (index_type));
-   max_index = index;
-}
+   {
+ index += 1;
+ if (index_type)
+   index = wi::ext (index, TYPE_PRECISION (index_type),
+TYPE_SIGN (index_type));
+ max_index = index;
+   }
 
 /* Do we have match?  */
 if (wi::cmpu (access_index, index) >= 0
-- 
1.9.1

[PATCH] PR driver/67613 - spell suggestions for misspelled command line options

[David Malcolm]

This patch adds hints to the option-not-found error in the driver,
using the Levenshtein distance implementation posted here:
"[PATCH 0/2] Levenshtein-based suggestions (v3)"
  https://gcc.gnu.org/ml/gcc-patches/2015-10/msg03379.html

It splits out the identifier-based implementation into a new
spellcheck-tree.c, keeping the core in spellcheck.c, since the tree
checking code needed for IDENTIFIER_POINTER etc isn't available in
the driver.

Bootstrapped on top of the other patch kit (with nit fixes)
on x86_64-pc-linux-gnu; adds 5 PASS results to gcc.sum.

OK for trunk as a followup to that patch kit?

gcc/ChangeLog:
PR driver/67613
* Makefile.in (GCC_OBJS): Add spellcheck.o.
(OBJS): Add spellcheck-tree.o.
* gcc.c: Include "spellcheck.h".
(suggest_option): New function.
(driver::handle_unrecognized_options): Call suggest_option to
provide a hint about misspelled options.
* spellcheck.c: Update file comment.
(levenshtein_distance): Convert 4-param implementation from static
to extern scope.  Remove note about unit tests from leading
comment for const char * implementation.  Move tree
implementation to...
* spellcheck-tree.c: New file.
* spellcheck.h (levenshtein_distance):  Add 4-param decl.

gcc/testsuite/ChangeLog:
PR driver/67613
* gcc/testsuite/gcc.dg/spellcheck-options-1.c: New file.
* gcc/testsuite/gcc.dg/spellcheck-options-2.c: New file.
---
 gcc/Makefile.in |  3 +-
 gcc/gcc.c   | 51 -
 gcc/spellcheck-tree.c   | 39 ++
 gcc/spellcheck.c| 21 ++--
 gcc/spellcheck.h|  4 +++
 gcc/testsuite/gcc.dg/spellcheck-options-1.c |  4 +++
 gcc/testsuite/gcc.dg/spellcheck-options-2.c |  5 +++
 7 files changed, 107 insertions(+), 20 deletions(-)
 create mode 100644 gcc/spellcheck-tree.c
 create mode 100644 gcc/testsuite/gcc.dg/spellcheck-options-1.c
 create mode 100644 gcc/testsuite/gcc.dg/spellcheck-options-2.c

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 9fb643e..a57bd40 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1151,7 +1151,7 @@ CXX_TARGET_OBJS=@cxx_target_objs@
 FORTRAN_TARGET_OBJS=@fortran_target_objs@
 
 # Object files for gcc many-languages driver.
-GCC_OBJS = gcc.o gcc-main.o ggc-none.o
+GCC_OBJS = gcc.o gcc-main.o ggc-none.o spellcheck.o
 
 c-family-warn = $(STRICT_WARN)
 
@@ -1395,6 +1395,7 @@ OBJS = \
simplify-rtx.o \
sparseset.o \
spellcheck.o \
+   spellcheck-tree.o \
sreal.o \
stack-ptr-mod.o \
statistics.o \
diff --git a/gcc/gcc.c b/gcc/gcc.c
index bbc9b23..ef0fb4e 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -42,6 +42,7 @@ compilation is specified by a string called a "spec".  */
 #include "opts.h"
 #include "params.h"
 #include "filenames.h"
+#include "spellcheck.h"
 
 
 
@@ -7598,6 +7599,45 @@ driver::maybe_putenv_OFFLOAD_TARGETS () const
   offload_targets = NULL;
 }
 
+/* Helper function for driver::handle_unrecognized_options.
+
+   Given an unrecognized option BAD_OPT (without the leading dash),
+   locate the closest reasonable matching option (again, without the
+   leading dash), or NULL.  */
+
+static const char *
+suggest_option (const char *bad_opt)
+{
+  const cl_option *best_option = NULL;
+  edit_distance_t best_distance = MAX_EDIT_DISTANCE;
+
+  for (unsigned int i = 0; i < cl_options_count; i++)
+{
+  edit_distance_t dist = levenshtein_distance (bad_opt,
+  cl_options[i].opt_text + 1);
+  if (dist < best_distance)
+   {
+ best_distance = dist;
+ best_option = _options[i];
+   }
+}
+
+  if (!best_option)
+return NULL;
+
+  /* If more than half of the letters were misspelled, the suggestion is
+ likely to be meaningless.  */
+  if (best_option)
+{
+  unsigned int cutoff = MAX (strlen (bad_opt),
+strlen (best_option->opt_text + 1)) / 2;
+  if (best_distance > cutoff)
+   return NULL;
+}
+
+  return best_option->opt_text + 1;
+}
+
 /* Reject switches that no pass was interested in.  */
 
 void
@@ -7605,7 +7645,16 @@ driver::handle_unrecognized_options () const
 {
   for (size_t i = 0; (int) i < n_switches; i++)
 if (! switches[i].validated)
-  error ("unrecognized command line option %<-%s%>", switches[i].part1);
+  {
+   const char *hint = suggest_option (switches[i].part1);
+   if (hint)
+ error ("unrecognized command line option %<-%s%>;"
+" did you mean %<-%s%>?",
+switches[i].part1, hint);
+   else
+ error ("unrecognized command line option %<-%s%>",
+switches[i].part1);
+  }
 }
 
 /* Handle the various -print-* options, returning 0 if the driver
diff --git 

Re: OpenACC dimension range propagation optimization

[Richard Biener]

On Wed, Nov 4, 2015 at 2:56 PM, Nathan Sidwell  wrote:
> On 11/04/15 05:26, Richard Biener wrote:
>>
>> On Tue, Nov 3, 2015 at 7:11 PM, Nathan Sidwell  wrote:
>>>
>>> Richard,
>>> this patch implements VRP for the 2 openacc axis internal fns I've added.
>>> We know the position within  a dimension cannot exceed that dimensions
>>> extend. Further, if the extend is dynamic, the target backend may well
>>> know
>>> there's a hardware-mandated maximum value.
>>>
>>> Hence, added a new target hook to allow the backend to specify that upper
>>> bound, and added smarts to extract_range_basic to process the two
>>> internal
>>> functions.
>>>
>>> Incidentally, this was the bit I was working on at the cauldron, which
>>> caused me to work on the min/max range combining.
>>>
>>> ok for trunk?
>>
>>
>> + /* Optimizing these two internal functions helps the loop
>> +optimizer eliminate outer comparisons.  Size is [1,N]
>> +and pos is [0,N-1].  */
>> + {
>> +   bool is_pos = ifn_code == IFN_GOACC_DIM_POS;
>> +   tree attr = get_oacc_fn_attrib (current_function_decl);
>> +   tree arg = gimple_call_arg (stmt, 0);
>> +   int axis = TREE_INT_CST_LOW (arg);
>> +   tree dims = TREE_VALUE (attr);
>> +
>> +   for (int ix = axis; ix--;)
>> + dims = TREE_CHAIN (dims);
>> +   int size = TREE_INT_CST_LOW (TREE_VALUE (dims));
>> +
>> +   if (!size)
>> + /* If it's dynamic, the backend might know a hardware
>> +limitation.  */
>> + size = targetm.goacc.dim_limit (axis);
>>
>> this all seems a little bit fragile and relying on implementation details?
>> Is the attribute always present?
>
>
> Yes.  The ifns are inserted by a pass (execute_oacc_device_lower) that only
> operates on such functions. (I considered adding  an assert, but figured the
> resulting segfault  would be loud enough)
>
>> Is the call argument always a constant
>> that fits in a HOST_WIDE_INT (or even int here)?
>
>
> Yes.
>
>
> Are there always enough
>>
>> 'dims' in the tree list?
>
>
> Yes.  The oacc_device_lower pass has already validated and canonicalized the
> dimensions.
>
>
> Is the 'dim' value always an INTEGER_CST that
>>
>> fits a HOST_WIDE_INT (or even an int here)?
>
>
> Yes.  That's part of the validation.  see set_oacc_fn_attrib (omp-low.c)
>
>> I hope all these constraints (esp. 'int' fitting) are verified by the
>> parser.
>
>
> It's an internal function not visible the user.  Generation is entirely
> within the compiler
>
>> If so I'd like to see helper functions to hide these implementation
>> details
>> from generic code like this.
>
>
> ok.
>
>>
>> You miss to provide the known lower bound to VRP when size is 0
>> in the end.  Just unconditioonally do
>>
>>tree type = TREE_TYPE (gimple_call_lhs (stmt));
>>set_value_range (vr, VR_RANGE,
>> build_int_cst (type, is_pos ? 0 : 1),
>> size
>> ? build_int_cst (type, size - is_pos)
>> : vrp_val_max (type), NULL);
>
>
> I'm confused.  If size is zero, we never execute that path, and IIUC
> therefore never specify a range.  What you suggest looks like an additional
> improvement though.  Is that what you meant?

Yes.

> nathan

Re: [gomp4] fortran cleanups and c/c++ loop parsing backport

[Cesar Philippidis]

On 11/04/2015 03:39 AM, Thomas Schwinge wrote:

> On Tue, 27 Oct 2015 11:36:10 -0700, Cesar Philippidis 
>  wrote:
>>   * Proposed fortran cleanups and enhanced error reporting changes:
>> https://gcc.gnu.org/ml/gcc-patches/2015-10/msg02288.html
> 
> ... has now been applied to trunk, in an altered version, so we now got
> some divergence between trunk and gomp-4_0-branch to resolve.

I've been concentrating on trunk lately. I'll backport these changes
when my other fortran changes go in
(https://gcc.gnu.org/ml/gcc-patches/2015-11/msg00287.html).

Cesar

Re: [PATCH] Add configure flag for operator new (std::nothrow)

[Martin Sebor]

I share your concerns, but I'm also sympathetic to the changes that
the Taller Technologies team are trying to make, to allow libstdc++ to
be more useful in exception-free systems.

At the very least the patch to doc/xml/manual/configure.xml must
document that this option enables behaviour that violates the standard
and so produces a non-conforming implementation. It should probably
also explain how to use the resulting implementation, so that users on
embedded systems who might want to enable this know how to write a
suitable new-handler.


If there is a problem with programs too easily getting themselves
into an infinite loop because of improperly written new handlers
it might be worth proposing a change to C++ to make the minimum
number of iterations the loop must make before giving up
implementation-defined. That way this could be handled the same
way regardless of the environment.

Martin

[Bug fortran/53699] Missing "restrict" qualifier for OPTIONAL dummy arguments

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-04
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Still missing at revision r229727 (trunk 6.0).

Re: [PATCH] Pass manager: add support for termination of pass list

[Richard Biener]

On Wed, Nov 4, 2015 at 11:38 AM, Martin Liška  wrote:
> On 11/03/2015 03:44 PM, Richard Biener wrote:
>> On Tue, Nov 3, 2015 at 3:13 PM, Martin Liška  wrote:
>>> On 11/03/2015 02:46 PM, Richard Biener wrote:
 On Fri, Oct 30, 2015 at 1:53 PM, Martin Liška  wrote:
> On 10/30/2015 01:13 PM, Richard Biener wrote:
>> So I suggest to do the push/pop of cfun there.
>> do_per_function_toporder can be made static btw.
>>
>> Richard.
>
> Right, I've done that and it works (bootstrap has been currently running),
> feasible for HSA branch too.
>
> tree-pass.h:
>
> /* Declare for plugins.  */
> extern void do_per_function_toporder (void (*) (function *, void *), void 
> *);
>
> Attaching the patch that I'm going to test.

 Err.

 +  cgraph_node::get (current_function_decl)->release_body ();
 +
 +  current_function_decl = NULL;
 +  set_cfun (NULL);

 I'd have expected

   tree fn = cfun->decl;
   pop_cfun ();
   gcc_assert (!cfun);
   cgraph_node::get (fn)->release_body ();

 here.
>>>
>>> Yeah, that works, but we have to add following hunk:
>>>
>>> diff --git a/gcc/function.c b/gcc/function.c
>>> index aaf49a4..4718fe1 100644
>>> --- a/gcc/function.c
>>> +++ b/gcc/function.c
>>> @@ -4756,6 +4756,13 @@ push_cfun (struct function *new_cfun)
>>>  void
>>>  pop_cfun (void)
>>>  {
>>> +  if (cfun_stack.is_empty ())
>>> +{
>>> +  set_cfun (NULL);
>>> +  current_function_decl = NULL_TREE;
>>> +  return;
>>> +}
>>> +
>>>struct function *new_cfun = cfun_stack.pop ();
>>>/* When in_dummy_function, we do have a cfun but current_function_decl is
>>>   NULL.  We also allow pushing NULL cfun and subsequently changing
>>
>> Why again?  cfun should be set via push_cfun here so what's having cfun == 
>> NULL
>> at the pop_cfun point?  Or rather, what code used set_cfun () instead
>> of push_cfun ()?
>>
>>>
>>> If you are fine with that, looks we've fixed all issues related to the 
>>> change, right?
>>> Updated version of the is attached.
>>>
>>> Martin
>>>

> Martin
>
>>>
>
> Hi Richard.
>
> There's the patch we talked about yesterday. It contains a few modification 
> that
> were necessary to make it working:
>
> 1) cgraph_node::expand_thunk uses just set_cfun (NULL) & 
> current_function_decl = NULL because
>
>   bb = then_bb = else_bb = return_bb
> = init_lowered_empty_function (thunk_fndecl, true, count);
>
> in last branch of expand_thunk which calls allocate_struct_function.
>
> 2) i386.c and rs6000.c call init_function_start, as I move preamble to 
> callers, I did the same
> for these two functions
>
> I've been running regression test and bootstrap.

Looks good to me.

Thanks,
Richard.

> Martin

Re: [gomp4, committed] Implement -foffload-alias

[Tom de Vries]

On 04/11/15 09:47, Thomas Schwinge wrote:

+/* Check that the loop has been split off into a function.  */
>+/* { dg-final { scan-tree-dump-times "(?n);; Function .*foo._omp_fn.0" 1 
"optimized" } } */

For C we get:

 ;; Function foo._omp_fn.0 (foo._omp_fn.0, funcdef_no=12, decl_uid=2534, 
cgraph_uid=14, symbol_order=14)

..., so that matches, but for C++ we get:

 ;; Function foo(unsigned int*, unsigned int*, unsigned int*) [clone 
._omp_fn.0] (_ZL3fooPjS_S_._omp_fn.0, funcdef_no=12, decl_uid=2416, 
cgraph_uid=14, symbol_order=14)

..., which doesn't match, so this directive FAILs.



Hi Thomas,

thanks for noticing.

Fixed as attached.

Committed to gomp-4_0-branch.

Thanks,
- Tom
Fixup goacc/kernels-loop-offload-alias-none.c

2015-11-04  Tom de Vries  

	* c-c++-common/goacc/kernels-loop-offload-alias-none.c: Fix
	foo._omp_fn.0 function name scanning.
---
 gcc/testsuite/c-c++-common/goacc/kernels-loop-offload-alias-none.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/c-c++-common/goacc/kernels-loop-offload-alias-none.c b/gcc/testsuite/c-c++-common/goacc/kernels-loop-offload-alias-none.c
index bb96330..79d8daa 100644
--- a/gcc/testsuite/c-c++-common/goacc/kernels-loop-offload-alias-none.c
+++ b/gcc/testsuite/c-c++-common/goacc/kernels-loop-offload-alias-none.c
@@ -49,7 +49,7 @@ main (void)
 }
 
 /* Check that the loop has been split off into a function.  */
-/* { dg-final { scan-tree-dump-times "(?n);; Function .*foo._omp_fn.0" 1 "optimized" } } */
+/* { dg-final { scan-tree-dump-times "(?n);; Function .*foo.*\\._omp_fn\\.0" 1 "optimized" } } */
 
 /* { dg-final { scan-tree-dump-times "clique 1 base 1" 3 "alias" } } */
 /* { dg-final { scan-tree-dump-times "clique 1 base 2" 1 "alias" } } */
-- 
1.9.1

[Bug tree-optimization/67742] 3rd-level restrict ignored

[vries at gcc dot gnu.org]

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

--- Comment #7 from vries at gcc dot gnu.org ---
Author: vries
Date: Wed Nov  4 14:18:43 2015
New Revision: 229755

URL: https://gcc.gnu.org/viewcvs?rev=229755=gcc=rev
Log:
Handle recursive restrict in function parameter

2015-11-04  Tom de Vries  

PR tree-optimization/67742
* tree-ssa-structalias.c (struct fieldoff): Add restrict_pointed_type
field.
(push_fields_onto_fieldstack): Handle restrict_pointed_type field.
(create_variable_info_for_1): Add and handle handle_param parameter.
Add restrict handling.
(create_variable_info_for): Call create_variable_info_for_1 with extra
arg.
(make_param_constraints): Drop restrict_name parameter.  Ignore
vi->only_restrict_pointers.
(intra_create_variable_infos): Call create_variable_info_for_1 with
extra arg.  Remove restrict handling.  Call make_param_constraints with
one less arg.

* gcc.dg/tree-ssa/restrict-7.c: New test.
* gcc.dg/tree-ssa/restrict-8.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/restrict-7.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/restrict-8.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-structalias.c

[Bug tree-optimization/67742] 3rd-level restrict ignored

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from vries at gcc dot gnu.org ---
patch and test-cases committed, marking resolved-fixed.

[Bug driver/67613] spell suggestions for misspelled command line options

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org

--- Comment #1 from David Malcolm  ---
Candidate patch posted here:
  https://gcc.gnu.org/ml/gcc-patches/2015-11/msg00355.html

Re: [RFC PR43721] Optimize a/b and a%b to single divmod call

[Richard Biener]

On Wed, 4 Nov 2015, Prathamesh Kulkarni wrote:

> On 2 November 2015 at 18:31, Richard Biener  wrote:
> > On Mon, 2 Nov 2015, Prathamesh Kulkarni wrote:
> >
> >> On 2 November 2015 at 13:20, Prathamesh Kulkarni
> >>  wrote:
> >> > On 30 October 2015 at 15:57, Richard Biener  
> >> > wrote:
> >> >> On Fri, Oct 30, 2015 at 8:39 AM, Prathamesh Kulkarni
> >> >>  wrote:
> >> >>> Hi,
> >> >>> I have attached revamped version of Kugan's patch
> >> >>> (https://gcc.gnu.org/ml/gcc/2013-06/msg00100.html) for PR43721.
> >> >>> Test-case: http://pastebin.com/QMfpXLD9
> >> >>> divmod pass dump: http://pastebin.com/yMY1ikCp
> >> >>> Assembly: http://pastebin.com/kk2HZpvA
> >> >>>
> >> >>> The approach I took is similar to sincos pass, which involves two 
> >> >>> parts:
> >> >>> a) divmod pass that transforms:
> >> >>> t1 = a / b;
> >> >>> t2 = a % b;
> >> >>> to the following sequence:
> >> >>> complex_tmp = DIVMOD (a, b);
> >> >>> t1 = REALPART_EXPR(a);
> >> >>> t2 = IMAGPART_EXPR(b);
> >> >>>
> >> >>> b) DIVMOD(a, b) is represented as an internal-fn and is expanded by
> >> >>> expand_DIVMOD().
> >> >>> I am not sure if I have done this correctly. I was somehow looking to
> >> >>> reuse expand_divmod() but am not able to figure out how to do that
> >> >>> (AFAIU expand_divmod() strictly returns either the quotient or
> >> >>> remainder but never both which is what I want), so ended up with
> >> >>> manually expanding to rtx.
> >> >>>
> >> >>> While going through the sincos pass in execute_cse_sincos_1, I didn't
> >> >>> understand the following:
> >> >>>  if (gimple_purge_dead_eh_edges (gimple_bb (stmt)))
> >> >>>   cfg_changed = true;
> >> >>> Um why is the call to gimple_purge_dead_eh_edges necessary here?
> >> >>
> >> >> The call replacement might no longer throw.
> >> >>
> >> >>> A silly question, what options to pass to gcc to print statistics ? I
> >> >>> added statistics_counter_event to keep track of number of calls
> >> >>> inserted/used but not sure how to print them :/
> >> >>
> >> >> -fdump-tree-XXX-stats or -fdump-statistics-stats
> >> > Thanks, I can see it now -;)
> >> >>
> >> >>> I would be grateful for suggestions for improving the patch.
> >> >>
> >> >> First of all new functions need comments (expand_DIVMOD).
> >> >>
> >> >> Second - what's the reasoning for the pass placement seen?  I think
> >> >> the transform is a lowering one, improving RTL expansion.  The
> >> >> DIVMOD representation is harmful for GIMPLE optimizers.
> >> >>
> >> >> Third - I'd have integrated this with an existing pass - we have another
> >> >> lowering / RTL expansion kind pass which is pass_optimize_widening_mul.
> >> >> Please piggy-back on it.
> >> >>
> >> >> You seem to do the transform unconditionally even if the target has
> >> >> instructions for division and modulus but no instruction for divmod
> >> >> in which case you'll end up emitting a library call in the end instead
> >> >> of a div and mod instruction.  I think the transform should be gated on
> >> >> missing div/mod instructions or the availability of a divmod one.
> >> >>
> >> >> + if (is_gimple_assign (stmt)
> >> >> + && TREE_CODE_CLASS (gimple_assign_rhs_code (stmt)) == 
> >> >> tcc_binary)
> >> >> +   {
> >> >> + if (gimple_assign_rhs_code (stmt) == TRUNC_DIV_EXPR)
> >> >> +   cfg_changed |= execute_divmod_1 (stmt);
> >> >>
> >> >> you can directly check gimple_assign_rhs_code.  I'd check for 
> >> >> TRUNC_MOD_EXPR
> >> >> which seems to be less common and thus should cut down compile-time.
> >> >>
> >> >> +  /* Case 2: When both are in top_bb */
> >> >> +  else if (op1_def_in_bb && op2_def_in_bb)
> >> >> +{
> >> >> +  /* FIXME: better way to compare iterators?.  */
> >> >> +  gimple_stmt_iterator gsi = get_later_stmt (top_bb,
> >> >> def_stmt_op1, def_stmt_op2);
> >> >>
> >> >> You can't use get_later_stmt, it's a vectorizer speciality.  To do
> >> >> this test efficiently
> >> >> you need stmt UIDs computed.
> >> >>
> >> >> I miss a testcase (or two).
> >> > I have tried to address your comments in the attached patch.
> >> oops, unsigned uid_no = 0; should be outside the loop in
> >> pass_optimize_widening_mul::execute.
> >> Done in this version of the patch.
> >>
> >> Thanks,
> >> Prathamesh
> >> > Could you please review it for me ?
> >
> > For the testcases you need a new target check for divmod.
> Sorry I didn't understand.
> Should I add sth similar to /* {  dg-require-effective-target divmod } */ ?

Yes.

> >
> >> > I have a few questions:
> >> >
> >> > a) Is the check for availability of divmod correct ?
> >
> > You simply want optab_handler (tab, mode) != CODE_FOR_nothing
> >
> > The libfunc is always available.
> Um I am probably missing something, I thought libfuncs are initialized
> by init_optabs()
> but the target can override/delete that with the target 

[Bug fortran/68196] [4.9/5/6 Regression] ICE on function result with procedure pointer component

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
The patch in comment 2 looks good (works as advertised without regression, no
duplicate in store)!

[trivial, committed] Use decl_type in create_variable_info_for_1

[Tom de Vries]

Hi,

this patch uses the the decl_type variable more consistently in 
create_variable_info_for_1.


Bootstrapped and reg-tested on x86_64.

Committed to trunk as trivial.

Thanks,
- Tom
Use decl_type in create_variable_info_for_1

2015-11-04  Tom de Vries  

	* tree-ssa-structalias.c (create_variable_info_for_1): Use decl_type
	variable.
---
 gcc/tree-ssa-structalias.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/tree-ssa-structalias.c b/gcc/tree-ssa-structalias.c
index ded5a1e..98b5f16 100644
--- a/gcc/tree-ssa-structalias.c
+++ b/gcc/tree-ssa-structalias.c
@@ -5718,8 +5718,8 @@ create_variable_info_for_1 (tree decl, const char *name, bool add_id)
   vi->fullsize = tree_to_uhwi (declsize);
   vi->size = vi->fullsize;
   vi->is_full_var = true;
-  if (POINTER_TYPE_P (TREE_TYPE (decl))
-	  && TYPE_RESTRICT (TREE_TYPE (decl)))
+  if (POINTER_TYPE_P (decl_type)
+	  && TYPE_RESTRICT (decl_type))
 	vi->only_restrict_pointers = 1;
   fieldstack.release ();
   return vi;
-- 
1.9.1

[committed] Handle recursive restrict in function parameter

[Tom de Vries]

On 04/11/15 10:28, Richard Biener wrote:

I think I can postpone the creation of the heapvar till where you suggest in
>create_variable_info_for_1, but I'd still need a means
>to communicate the TREE_TYPE (field_type) from push_fields_onto_fieldstack to
>create_variable_info_for_1.
>
>A simple implementation would be a new field:
>...
>@@ -5195,6 +5197,8 @@ struct fieldoff
>unsigned may_have_pointers : 1;
>
>unsigned only_restrict_pointers : 1;
>+
>+ tree restrict_pointed_type;
>};
>...
>Which AFAIU will change fieldoff size.

It's ok to change fieldoff size if there is a reason to;)

Patch is ok along this line.


Updated patch accordingly.

Bootstrapped and reg-tested on x86_64.

Committed to trunk as attached.

Thanks,
- Tom
Handle recursive restrict in function parameter

2015-11-04  Tom de Vries  

	PR tree-optimization/67742
	* tree-ssa-structalias.c (struct fieldoff): Add restrict_pointed_type
	field.
	(push_fields_onto_fieldstack): Handle restrict_pointed_type field.
	(create_variable_info_for_1): Add and handle handle_param parameter.
	Add restrict handling.
	(create_variable_info_for): Call create_variable_info_for_1 with extra
	arg.
	(make_param_constraints): Drop restrict_name parameter.  Ignore
	vi->only_restrict_pointers.
	(intra_create_variable_infos): Call create_variable_info_for_1 with
	extra arg.  Remove restrict handling.  Call make_param_constraints with
	one less arg.

	* gcc.dg/tree-ssa/restrict-7.c: New test.
	* gcc.dg/tree-ssa/restrict-8.c: New test.
---
 gcc/testsuite/gcc.dg/tree-ssa/restrict-7.c | 12 +
 gcc/testsuite/gcc.dg/tree-ssa/restrict-8.c | 17 +++
 gcc/tree-ssa-structalias.c | 78 +-
 3 files changed, 74 insertions(+), 33 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/restrict-7.c
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/restrict-8.c

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/restrict-7.c b/gcc/testsuite/gcc.dg/tree-ssa/restrict-7.c
new file mode 100644
index 000..f7a68c7
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/restrict-7.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-fre1" } */
+
+int
+f (int *__restrict__ *__restrict__ *__restrict__ a, int *b)
+{
+  *b = 1;
+  ***a  = 2;
+  return *b;
+}
+
+/* { dg-final { scan-tree-dump-times "return 1" 1 "fre1" } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/restrict-8.c b/gcc/testsuite/gcc.dg/tree-ssa/restrict-8.c
new file mode 100644
index 000..b0ab164
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/restrict-8.c
@@ -0,0 +1,17 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-fre1" } */
+
+struct s
+{
+  int *__restrict__ *__restrict__ pp;
+};
+
+int
+f (struct s s, int *b)
+{
+  *b = 1;
+  **s.pp = 2;
+  return *b;
+}
+
+/* { dg-final { scan-tree-dump-times "return 1" 1 "fre1" } } */
diff --git a/gcc/tree-ssa-structalias.c b/gcc/tree-ssa-structalias.c
index 98b5f16..52a35f6 100644
--- a/gcc/tree-ssa-structalias.c
+++ b/gcc/tree-ssa-structalias.c
@@ -307,6 +307,7 @@ static varinfo_t first_or_preceding_vi_for_offset (varinfo_t,
 		   unsigned HOST_WIDE_INT);
 static varinfo_t lookup_vi_for_tree (tree);
 static inline bool type_can_have_subvars (const_tree);
+static void make_param_constraints (varinfo_t);
 
 /* Pool of variable info structures.  */
 static object_allocator variable_info_pool
@@ -393,7 +394,6 @@ new_var_info (tree t, const char *name, bool add_id)
   return ret;
 }
 
-
 /* A map mapping call statements to per-stmt variables for uses
and clobbers specific to the call.  */
 static hash_map *call_stmt_vars;
@@ -5195,6 +5195,8 @@ struct fieldoff
   unsigned may_have_pointers : 1;
 
   unsigned only_restrict_pointers : 1;
+
+  tree restrict_pointed_type;
 };
 typedef struct fieldoff fieldoff_s;
 
@@ -5340,7 +5342,8 @@ push_fields_onto_fieldstack (tree type, vec *fieldstack,
 	if (!pair
 		&& offset + foff != 0)
 	  {
-		fieldoff_s e = {0, offset + foff, false, false, false, false};
+		fieldoff_s e
+		  = {0, offset + foff, false, false, false, false, NULL_TREE};
 		pair = fieldstack->safe_push (e);
 	  }
 
@@ -5374,6 +5377,8 @@ push_fields_onto_fieldstack (tree type, vec *fieldstack,
 		  = (!has_unknown_size
 		 && POINTER_TYPE_P (field_type)
 		 && TYPE_RESTRICT (field_type));
+		if (e.only_restrict_pointers)
+		  e.restrict_pointed_type = TREE_TYPE (field_type);
 		fieldstack->safe_push (e);
 	  }
 	  }
@@ -5642,10 +5647,11 @@ check_for_overlaps (vec fieldstack)
 
 /* Create a varinfo structure for NAME and DECL, and add it to VARMAP.
This will also create any varinfo structures necessary for fields
-   of DECL.  */
+   of DECL.  DECL is a function parameter if HANDLE_PARAM is set.  */
 
 static varinfo_t
-create_variable_info_for_1 (tree decl, const char *name, bool add_id)
+create_variable_info_for_1 (tree decl, const char *name, bool add_id,
+			bool handle_param)
 {
   varinfo_t vi, newvi;
   tree decl_type = 

Re: [Patch AArch64] Switch constant pools to separate rodata sections.

[Ramana Radhakrishnan]

On 03/11/15 17:09, James Greenhalgh wrote:
> On Tue, Nov 03, 2015 at 04:36:45PM +, Ramana Radhakrishnan wrote:
>> Hi,
>>
>>  Now that PR63304 is fixed and we have an option to address
>> any part of the memory using adrp / add or adrp / ldr instructions
>> it makes sense to switch out literal pools into their own
>> mergeable sections by default.
>>
>> This would mean that by default we could now start getting
>> the benefits of constant sharing across the board, potentially
>> improving code size. The other advantage of doing so, for the
>> security conscious is that this prevents intermingling of literal
>> pools with code.
>>
>> Wilco's kindly done some performance measurements and suggests that
>> there is not really a performance regression in doing this.
>> I've looked at the code size for SPEC2k6 today at -Ofast and
>> in general there is a good code size improvement as expected
>> by sharing said constants.
>>
>> Tested on aarch64-none-elf with no regressions and bootstrapped 
>> and regression tested in my tree for a number of days now.
>>
>> Ok to commit ?
> 
> OK with the comment nits below fixed up.
> 
>>* config/aarch64/aarch64.c (aarch64_select_rtx_section): Switch
>> to default section handling for non PC relative literal loads.
> 
>> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
>> index 5c8604f..9d709e5 100644
>> --- a/gcc/config/aarch64/aarch64.c
>> +++ b/gcc/config/aarch64/aarch64.c
>> @@ -5244,13 +5244,22 @@ aarch64_use_blocks_for_constant_p (machine_mode mode 
>> ATTRIBUTE_UNUSED,
>>return false;
>>  }
>>  
>> +/* Force all constant pool entries into the current function section.
> 
> Is this comment accurate now? I think it only applied to -mcmodel=large
> but maybe I'm misunderstanding?
> 
>> +   In the large model we cannot reliably address all the address space
>> +   thus for now, inline this with the text.  */
>>  static section *
>> +aarch64_select_rtx_section (machine_mode mode,
>> +rtx x,
>> +unsigned HOST_WIDE_INT align)
>> +{
>> +  /* Force all constant pool entries into the current function section.
>> + In the large model we cannot reliably address all the address space
>> + thus for now, inline this with the text.  */
>> +  if (!aarch64_nopcrelative_literal_loads
>> +  || aarch64_cmodel == AARCH64_CMODEL_LARGE)
>> +return function_section (current_function_decl);
> 
> This is just a copy paste of the text above (and probably the better place
> for it).
> 
> I think we'd want a more general comment at the top of the function,
> then this can stay.
> 

True and I've just been reading more of the backend - We could now start using 
blocks for constant pools as well. So let's do that.

How does something like this look ?

Tested on aarch64-none-elf - no regressions.

2015-11-04  Ramana Radhakrishnan  

* config/aarch64/aarch64.c
(aarch64_can_use_per_function_literal_pools_p): New.
(aarch64_use_blocks_for_constant_p): Adjust declaration
and use aarch64_can_use_function_literal_pools_p.
(aarch64_select_rtx_section): Update.
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 5c8604f..4f5e069 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -5235,24 +5235,37 @@ aarch64_uxt_size (int shift, HOST_WIDE_INT mask)
   return 0;
 }
 
+/* Constant pools are per function only when PC relative
+   literal loads are true or we are in the large memory
+   model.  */
+static inline bool
+aarch64_can_use_per_function_literal_pools_p (void)
+{
+  return (!aarch64_nopcrelative_literal_loads
+ || aarch64_cmodel == AARCH64_CMODEL_LARGE);
+}
+
 static bool
-aarch64_use_blocks_for_constant_p (machine_mode mode ATTRIBUTE_UNUSED,
-  const_rtx x ATTRIBUTE_UNUSED)
+aarch64_use_blocks_for_constant_p (machine_mode, const_rtx)
 {
   /* We can't use blocks for constants when we're using a per-function
  constant pool.  */
-  return false;
+  return !aarch64_can_use_per_function_literal_pools_p ();
 }
 
+/* Select appropriate section for constants depending
+   on where we place literal pools.  */
+
 static section *
-aarch64_select_rtx_section (machine_mode mode ATTRIBUTE_UNUSED,
-   rtx x ATTRIBUTE_UNUSED,
-   unsigned HOST_WIDE_INT align ATTRIBUTE_UNUSED)
+aarch64_select_rtx_section (machine_mode mode,
+   rtx x,
+   unsigned HOST_WIDE_INT align)
 {
-  /* Force all constant pool entries into the current function section.  */
-  return function_section (current_function_decl);
-}
+  if (aarch64_can_use_per_function_literal_pools_p ())
+return function_section (current_function_decl);
 
+  return default_elf_select_rtx_section (mode, x, align);
+}
 
 /* Costs.  */
 

Re: [PATCH v2] [PR debug/67192] Fix C loops' back-jump location

[Andreas Arnez]

On Thu, Oct 29 2015, Andreas Arnez wrote:

> On Thu, Oct 29 2015, Bernd Schmidt wrote:
>> [...]
>> i.e. the breakpoint on the code inside the loop is reached before the
>> while statement itself. This may be the expected behaviour with your
>> patch, but I'm not sure it's really desirable for debugging.
>
> [...]
> Maybe we could also improve the behavior of breaking on "while (1)" by
> generating a NOP for it?  Or by using the first loop body's token
> instead?

I've basically tried the latter, and it seems to work pretty well.  It
solves all the issues discussed in this mail thread, and I haven't found
any other issues with it.  I'll post the patch separately.

>> I'd suggest you commit your original patch to fix the
>> misleading-indent problem while we sort this out.
>
> I can certainly do that.  But note that the original patch does not
> solve the misleading-indent regression caused for f2() in the new
> version of pr67192.c.  Thus the PR is not really fixed by it.

I've slightly changed the test case for that one, so I'll repost it as
well before committing it.

--
Andreas

Re: [PATCH 10/9] ENABLE_CHECKING refactoring: remove remaining occurrences

[Mikhail Maltsev]

On 11/03/2015 02:35 AM, Jeff Law wrote:
> This is good fore the trunk too.  Please install.
> 
> Thanks!
> 
> jeff

Committed as r229758.

-- 
Regards,
Mikhail Maltsev

[Patch, fortran] PR68196 [4.9/5/6 Regression] ICE on function result with procedure pointer component

[Paul Richard Thomas]

Dear All,

The patch for these PRs is fully explained by the the comments and/or
changelogs. PR66465 has no connection with PR68196, other than Damian
asking if it is connected!

Bootstrapped and regtested on x86_64/FC21 - OK for trunk and a few
weeks later 4.9 and 5 branches?

Cheers

Paul

2015-11-04  Paul Thomas  

PR fortran/68196
* class.c (has_finalizer_component): Prevent infinite recursion
through this function if the derived type and that of its
component are the same.
* trans-types.c (gfc_get_derived_type): Do the same for proc
pointers by ignoring the explicit interface for the component.

PR fortran/66465
* check.c (same_type_check): If either of the expressions is
BT_PROCEDURE, use the typespec from the symbol, rather than the
expression.

2015-11-04  Paul Thomas  

PR fortran/68196
* gfortran.dg/proc_ptr_47.f90: New test.

PR fortran/66465
* gfortran.dg/pr66465.f90: New test.
Index: gcc/fortran/check.c
===
*** gcc/fortran/check.c (revision 229571)
--- gcc/fortran/check.c (working copy)
*** less_than_bitsize2 (const char *arg1, gf
*** 399,405 
  static bool
  same_type_check (gfc_expr *e, int n, gfc_expr *f, int m)
  {
!   if (gfc_compare_types (>ts, >ts))
  return true;
  
gfc_error ("%qs argument of %qs intrinsic at %L must be the same type "
--- 399,413 
  static bool
  same_type_check (gfc_expr *e, int n, gfc_expr *f, int m)
  {
!   gfc_typespec *ets = >ts;
!   gfc_typespec *fts = >ts;
! 
!   if (e->ts.type == BT_PROCEDURE && e->symtree->n.sym)
! ets = >symtree->n.sym->ts;
!   if (f->ts.type == BT_PROCEDURE && f->symtree->n.sym)
! fts = >symtree->n.sym->ts;
! 
!   if (gfc_compare_types (ets, fts))
  return true;
  
gfc_error ("%qs argument of %qs intrinsic at %L must be the same type "
Index: gcc/fortran/class.c
===
*** gcc/fortran/class.c (revision 229571)
--- gcc/fortran/class.c (working copy)
*** has_finalizer_component (gfc_symbol *der
*** 843,849 
--- 843,853 
  && c->ts.u.derived->f2k_derived->finalizers)
return true;
  
+   /* Stop infinite recursion through this function by inhibiting
+calls when the derived type and that of the component are
+the same.  */
if (c->ts.type == BT_DERIVED
+ && !gfc_compare_derived_types (derived, c->ts.u.derived)
  && !c->attr.pointer && !c->attr.allocatable
  && has_finalizer_component (c->ts.u.derived))
return true;
Index: gcc/fortran/trans-types.c
===
*** gcc/fortran/trans-types.c   (revision 229571)
--- gcc/fortran/trans-types.c   (working copy)
*** gfc_get_derived_type (gfc_symbol * deriv
*** 2366,2371 
--- 2366,2372 
gfc_component *c;
gfc_dt_list *dt;
gfc_namespace *ns;
+   tree tmp;
  
if (derived->attr.unlimited_polymorphic
|| (flag_coarray == GFC_FCOARRAY_LIB
*** gfc_get_derived_type (gfc_symbol * deriv
*** 2517,2524 
   node as DECL_CONTEXT of each FIELD_DECL.  */
for (c = derived->components; c; c = c->next)
  {
!   if (c->attr.proc_pointer)
field_type = gfc_get_ppc_type (c);
else if (c->ts.type == BT_DERIVED || c->ts.type == BT_CLASS)
  field_type = c->ts.u.derived->backend_decl;
else
--- 2518,2536 
   node as DECL_CONTEXT of each FIELD_DECL.  */
for (c = derived->components; c; c = c->next)
  {
!   /* Prevent infinite recursion, when the procedure pointer type is
!the same as derived, by forcing the procedure pointer component to
!be built as if the explicit interface does not exist.  */
!   if (c->attr.proc_pointer
! && ((c->ts.type != BT_DERIVED && c->ts.type != BT_CLASS)
!  || (c->ts.u.derived
!  && !gfc_compare_derived_types (derived, c->ts.u.derived
field_type = gfc_get_ppc_type (c);
+   else if (c->attr.proc_pointer && derived->backend_decl)
+   {
+ tmp = build_function_type_list (derived->backend_decl, NULL_TREE);
+ field_type = build_pointer_type (tmp);
+   }
else if (c->ts.type == BT_DERIVED || c->ts.type == BT_CLASS)
  field_type = c->ts.u.derived->backend_decl;
else
Index: gcc/testsuite/gfortran.dg/pr66465.f90
===
*** gcc/testsuite/gfortran.dg/pr66465.f90   (revision 0)
--- gcc/testsuite/gfortran.dg/pr66465.f90   (working copy)
***
*** 0 
--- 1,23 
+ ! { dg-do compile }
+ !
+ ! Tests the fix for PR66465, in which the arguments of the call to
+ ! ASSOCIATED were falsly detected to have different type/kind.
+ !
+ ! Contributed by Damian Rouson  
+ 

Re: abi_tag questions

[Jonathan Wakely]

On 4 November 2015 at 14:37, Stephan Bergmann  wrote:
> I have two questions regarding the abi_tag attribute (as documented at
> ):
>
>
> 1  "The attribute can also be applied to an inline namespace, but does not
> affect the mangled name of the namespace; in this case it is only used for
> -Wabi-tag warnings and automatic tagging of functions and variables."
>
> I would naively assume that the "automatic tagging" part means that with
>
>> inline namespace n __attribute__((__abi_tag__("t"))) { void f() {} }
>
>
> n::f would be tagged, but that appears not to be the case?

It's not tagged, because the tagged namespace "n" is already part of
the mangled name.

> 2  "The argument can be a list of strings of arbitrary length."
>
> Does that mean the list can be empty?
>
>> void f() __attribute__((__abi_tag__()));
>
>
> fails with "error: wrong number of arguments specified for ‘__abi_tag__’
> attribute" while
>
>> inline namespace n __attribute__((__abi_tag__())) {}
>
>
> is accepted by recent trunk GCC (as well as older versions).

That seems like a bug.

> (I stumbled across the latter on Fedora 23, where libstdc++'s
>  "Fix abi_tag
> in special modes" is not yet fixed, so it contains such an empty abi_tag on
> an inline namespace, and Clang with patch 
> "add gcc abi_tag support" produces an error.)

OpenACC declare directive updates

[James Norris]

This patch updates the processing of OpenACC declare directive for
Fortran in the following areas:

1) module support
2) device_resident and link clauses
3) clause checking
4) directive generation

Commentary on the changes is included as an attachment (NOTES).

All of the code is in the gomp-4_0-branch.

Regtested on x86_64-linux.

Thanks!
Jim
Background

The declare directive is used to allocate device memory for the
entire scope of a variable / array within a program, function,
or subroutine. Consider the following example.

module vars
  integer b
  !$acc declare device_resident (b)
  integer c
  !$acc declare link (c)
end module vars

program main
  use vars
  integer, parameter :: N = 8
  integer :: a(N)

  a(:) = 2
  c = 12

  !$acc parallel copy (a) present (b) copyin(c)
  do i = 1, N
b = a(i)
c = b
a(i) = c + i
  end do
  !$acc end parallel

end program

In the example, 'b' will be allocated on the device at the outset
of device activity and be available for the duration. Whereas the
allocation of 'c' will be delayed until the parallel region is
entered. The device memory for 'c' will be deallocated upon exit
of the parallel region.

Fortran front-end

The changes are concentrated into four (4) areas.

1) module support
The neccesary functionality has been added to handle the
reading in and writing out of the appropriate attributes
for the declare directive. Additional functionality has
been added at read in time to setup the required declare
handling.

2) device_resident and link clauses
Add the functionality necessary to process the link and
device_resident clauses.

3) clause checking
The clause checking has been cleaned up to better check
for duplicates and correctness.

4) directive generation

Prior to handling the fortran execution body a code
body is created to handle the clause(s) that accompany
the declare directive(s). Each clause is examined and
determined whether the clause need to be modified to 
perform an action at the beginning of the module, function,
subroutine, or program. Furthermore, an additional
clause may be added to the list to perform an action
at the time the function or subroutine returns.

Once all the clauses have been handled, the code body
is added to the chain.

libgomp

TODO

Testing

New compile and runtime tests have been added. Also some have
been modified.
2015-10-29  James Norris  
Cesar Philippidis  

gcc/fortran/
* dump-parse-tree.c (show_namespace): Reimplement.
* f95-lang.c (gfc_attribute_table): New entry.
* gfortran.h (struct symbol_attribute): New fields.
(enum gfc_omp_map_map): Add OMP_MAP_DEVICE_RESIDENT and OMP_MAP_LINK.
(OMP_LIST_LINK): New enum.
(struct gfc_oacc_declare): New structure.
(gfc_get_oacc_declare): New definition.
(struct gfc_namespace): Change type.
(enum gfc_exec_op): Add EXEC_OACC_DECLARE.
(struct gfc_code): New field.
* module.c (enum ab_attribute): Add AB_OACC_DECLARE_CREATE,
AB_OACC_DECLARE_COPYIN, AB_OACC_DECLARE_DEVICEPTR,
AB_OACC_DECLARE_DEVICE_RESIDENT, AB_OACC_DECLARE_LINK
(attr_bits): Add new initializers.
(mio_symbol_attribute): Handle new atributes.
* openmp.c (gfc_free_oacc_declare_clauses): New.
(OMP_CLAUSE_LINK): New definition.
(gfc_match_omp_clauses): Handle OMP_CLAUSE_LINK.
(OACC_DECLARE_CLAUSES): Add OMP_CLAUSE_LINK
(gfc_match_oacc_declare): Add checking and module handling.
(resolve_omp_duplicate_list, resolve_oacc_declare_map): New.
(gfc_resolve_oacc_declare): Use duplicate detection.
* parse.c (case_decl): Add ST_OACC_DECLARE.
(parse_spec): Remove handling.
(parse_progunit): Remove handling.
* parse.h (struct gfc_state_data): Change type.
* resolve.c (gfc_resolve_blocks): Handle EXEC_OACC_DECLARE.
* st.c (gfc_free_statement): Handle EXEC_OACC_DECLARE.
* symbol.c (check_conflict): Add conflict checks.
(gfc_add_oacc_declare_create, gfc_add_oacc_declare_copyin, 
gfc_add_oacc_declare_deviceptr, gfc_add_oacc_declare_device_resident):
New functions.
(gfc_copy_attr): 

Re: [PATCH 1/2][ARM] PR/65956 AAPCS update for alignment attribute

[Jakub Jelinek]

On Mon, Jul 06, 2015 at 05:38:35PM +0100, Alan Lawrence wrote:
> Trying to push these now (svn!), patch 2 is going first.
> 
> I realize my second iteration of patch 1/2, dropped the testcases from the
> first version. Okay to include those as per
> https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00215.html ?

FYI, it seems that (most likely) the PR65956 changes on gcc-5-branch
broke libgnat ABI compatibility on arm - it seems that getsubs.adb
from macrosub proglet (and others) are during make check compiled/linked
with system gnatmake/gcc, but the program is run at runtime
against the new libgnat-5.so.  If I run it manually against
system libgnat, it works, otherwise it hangs, when Fill_Table from
getsubs.adb calls Get_Line, and indeed it looks like the argument passing
for Get_Line changed and on the callee side it thinks Item (which is 400
chars string) has random (and in the hanging case negative) number of chars
in it.

Jakub

Re: [PATCH] Better error messages for merge-conflict markers (v3)

[Bernd Schmidt]

On 10/30/2015 04:16 PM, David Malcolm wrote:

The idea is to more gracefully handle merger conflict markers
in the source code being compiled.  Specifically, in the C and
C++ frontends, if we're about to emit an error, see if the
source code is at a merger conflict marker, and if so, emit
a more specific message, so that the user gets this:

foo.c:1:1: error: source file contains patch conflict marker
  <<< HEAD
  ^

It's something of a "fit and finish" cosmetic item, but these
things add up.


This seems like fairly low impact but also low cost, so I'm fine with it 
in principle. I wonder whether the length of the marker is the same 
across all versions of patch (and VC tools)?



+static bool
+c_parser_peek_conflict_marker (c_parser *parser, enum cpp_ttype tok1_kind)
+{
+  c_token *token2 = c_parser_peek_2nd_token (parser);
+  if (token2->type != tok1_kind)
+return false;
+  c_token *token3 = c_parser_peek_nth_token (parser, 3);
+  if (token3->type != tok1_kind)
+return false;
+  c_token *token4 = c_parser_peek_nth_token (parser, 4);
+  if (token4->type != conflict_marker_get_final_tok_kind (tok1_kind))
+return false;
+  return true;
+}


Just thinking out loud - I guess it would be too much to hope for to 
share lexers between frontends so that we need only one copy of this?



+extern short some_var; /* this line would lead to a warning */


Would or does? I don't see anything suppressing it?

There seems to be no testcase verifying what happens if the marker is 
not at the start of the line (IMO it should not be interpreted as a marker).


It would be good to have buy-in from the frontend maintainers (Joseph 
commented on v1 and as far as I can see you've addressed his feedback). 
If you do not hear back from them by the end of the week, I'll approve 
it if the start-of-line thing is sorted.



Bernd

Re: [c++-delayed-folding] Introduce convert_to_real_nofold

[Marek Polacek]

On Wed, Nov 04, 2015 at 10:32:52AM +0100, Richard Biener wrote:
> On Tue, Nov 3, 2015 at 5:53 PM, Marek Polacek  wrote:
> > The last piece for convert.c.  Since convert_to_real uses fold ()
> > rather than fold_buildN, I defined a new macro to keep the code
> > more compact.
> >
> > With this committed, convert.c should be dealt with.  If there's
> > anything else I could help with, please let me know.
> >
> > Bootstrapped/regtested on x86_64-linux, ok for branch?
> 
> I wonder what happens (on trunk) when you just remove the fold () calls.

Nothing much, at least the following patch passes testing.

Bootstrapped/regtested on x86_64-linux.

2015-11-04  Marek Polacek  

* convert.c (convert_to_real): Remove calls to fold.

diff --git gcc/convert.c gcc/convert.c
index 113c11f..8ef1949 100644
--- gcc/convert.c
+++ gcc/convert.c
@@ -211,7 +211,7 @@ convert_to_real (tree type, tree expr)
 
  if (fn)
  {
-   tree arg = fold (convert_to_real (newtype, arg0));
+   tree arg = convert_to_real (newtype, arg0);
expr = build_call_expr (fn, 1, arg);
if (newtype == type)
  return expr;
@@ -235,8 +235,7 @@ convert_to_real (tree type, tree expr)
  && FLOAT_TYPE_P (itype)
  && TYPE_PRECISION (type) < TYPE_PRECISION (itype))
return build1 (TREE_CODE (expr), type,
-  fold (convert_to_real (type,
- TREE_OPERAND (expr, 0;
+  convert_to_real (type, TREE_OPERAND (expr, 0)));
  break;
/* Convert (outertype)((innertype0)a+(innertype1)b)
   into ((newtype)a+(newtype)b) where newtype
@@ -272,8 +271,8 @@ convert_to_real (tree type, tree expr)
  || newtype == dfloat128_type_node)
{
  expr = build2 (TREE_CODE (expr), newtype,
-fold (convert_to_real (newtype, arg0)),
-fold (convert_to_real (newtype, arg1)));
+convert_to_real (newtype, arg0),
+convert_to_real (newtype, arg1));
  if (newtype == type)
return expr;
  break;
@@ -312,8 +311,8 @@ convert_to_real (tree type, tree expr)
  && !excess_precision_type (newtype
{
  expr = build2 (TREE_CODE (expr), newtype,
-fold (convert_to_real (newtype, arg0)),
-fold (convert_to_real (newtype, arg1)));
+convert_to_real (newtype, arg0),
+convert_to_real (newtype, arg1));
  if (newtype == type)
return expr;
}

Marek

Re: [1/3] OpenACC reductions

[Jakub Jelinek]

On Wed, Nov 04, 2015 at 08:58:26AM -0500, Nathan Sidwell wrote:
> On 11/04/15 05:31, Jakub Jelinek wrote:
> >On Tue, Nov 03, 2015 at 11:01:57AM -0500, Nathan Sidwell wrote:
> >>On 11/03/15 10:46, Jakub Jelinek wrote:
> >>>On Mon, Nov 02, 2015 at 11:18:37AM -0500, Nathan Sidwell wrote:
> This is the core execution bits of OpenACC reductions.
> 
> We have a new internal fn 'IFN_GOACC_REDUCTION' and a new target hook
> goacc.reduction, to lower it on the target compiler.
> >>>
> >>>So, let me start with a few questions:
> >>>1) does OpenACC allow UDRs or only the built-in reductions?  If it
> >>>does not allow UDRs, do you have it covered by testcases that you
> >>>disallow parsing of them (e.g. when you have
> >>
> >>no UDR reductions.  Will check test cases for that.
> >
> >BTW, what about min/max reductions for C/C++?  Those were added in OpenMP
> >3.1, so perhaps OpenACC copied them.
> 
> OpenACC has min/max, and this is exercised on gomp4.  we'll get to porting
> more testcases after this rush is done, ok?  (Or is there something specific
> about min/max?)

No, just wanted to know what you need to disable in the reduction clause
parsing...
For e.g. C it might be enough to add
if (!openacc)
{
and } around:
reduc_id = c_parser_peek_token (parser)->value;
break;

Jakub

Re: [2/3] OpenACC reductions

[Nathan Sidwell]

On 11/04/15 08:27, Bernd Schmidt wrote:

On 11/02/2015 05:35 PM, Nathan Sidwell wrote:





There are two such switch statements, and it's possible to write this more
compactly:
   if (!INTEGRAL_MODE_P (...))
 code = VIEW_CONVERT_EXPR;
   if (GET_MODE_SIZE (...) == 8)
 fn = CMP_SWAPLL;
Not required, you can decide which you like better.


thanks, not noticed that (the switch was originally more complex)

nathan

Re: [gomp4] fortran cleanups and c/c++ loop parsing backport

[Thomas Schwinge]

Hi Cesar!

On Tue, 27 Oct 2015 11:36:10 -0700, Cesar Philippidis  
wrote:
>   * Proposed fortran cleanups and enhanced error reporting changes:
> https://gcc.gnu.org/ml/gcc-patches/2015-10/msg02288.html

... has now been applied to trunk, in an altered version, so we now got
some divergence between trunk and gomp-4_0-branch to resolve.

> I'll apply this patch to gomp-4_0-branch shortly. I know that I should
> have broken this patch down into smaller patches, but it was already
> arranged as one big patch in my source tree.

> --- a/gcc/fortran/openmp.c
> +++ b/gcc/fortran/openmp.c

> @@ -1473,8 +1468,8 @@ gfc_match_oacc_declare (void)
> if (n->u.map_op != OMP_MAP_FORCE_ALLOC
> && n->u.map_op != OMP_MAP_FORCE_TO)
>   {
> -   gfc_error ("Invalid clause in module with "
> -  "$!ACC DECLARE at %C");
> +   gfc_error ("Invalid clause in module with $!ACC DECLARE at %L",
> +  >where);
> return MATCH_ERROR;
>   }
>  
> @@ -1483,29 +1478,29 @@ gfc_match_oacc_declare (void)
>  
>if (ns->proc_name->attr.oacc_function)
>   {
> -   gfc_error ("Invalid declare in routine with " "$!ACC DECLARE at %C");
> +   gfc_error ("Invalid declare in routine with $!ACC DECLARE at %C");
> return MATCH_ERROR;
>   }

Shouldn't the "%C" -> "%L (>where)" substitution also be done for that
one?  If yes, please do so; if no, please add a source code comment, why.

>  
>if (s->attr.in_common)
>   {
> -   gfc_error ("Unsupported: variable in a common block with "
> -  "$!ACC DECLARE at %C");
> +   gfc_error ("Variable in a common block with $!ACC DECLARE at %L",
> +  >where);
> return MATCH_ERROR;
>   }
>  
>if (s->attr.use_assoc)
>   {
> -   gfc_error ("Unsupported: variable is USE-associated with "
> -  "$!ACC DECLARE at %C");
> +   gfc_error ("Variable is USE-associated with $!ACC DECLARE at %L",
> +  >where);
> return MATCH_ERROR;
>   }
>  
>if ((s->attr.dimension || s->attr.codimension)
> && s->attr.dummy && s->as->type != AS_EXPLICIT)
>   {
> -   gfc_error ("Unsupported: assumed-size dummy array with "
> -  "$!ACC DECLARE at %C");
> +   gfc_error ("Assumed-size dummy array with $!ACC DECLARE at %L",
> +  >where);
> return MATCH_ERROR;
>   }

> -/* Returns true if clause in list 'list' is compatible with any of
> -   of the clauses in lists [0..list-1].  E.g., a reduction variable may
> -   appear in both reduction and private clauses, so this function
> -   will return true in this case.  */
> +/* Check if a variable appears in multiple clauses.  */
>  
> -static bool
> -oacc_compatible_clauses (gfc_omp_clauses *clauses, int list,
> -gfc_symbol *sym, bool openacc)
> +static void
> +resolve_omp_duplicate_list (gfc_omp_namelist *clause_list, bool openacc,
> + int list)

If I understand correctly, that has not been approved for trunk, so we
should revert this on gomp-4_0-branch, too?

>  {
>gfc_omp_namelist *n;
> +  const char *error_msg = "Symbol %qs present on multiple clauses at %L";
>  
> -  if (!openacc)
> -return false;
> +  /* OpenACC reduction clauses are compatible with everything.  We only
> + need to check if a reduction variable is used more than once.  */
> +  if (openacc && list == OMP_LIST_REDUCTION)
> +{
> +  hash_set reductions;
>  
> -  if (list != OMP_LIST_REDUCTION)
> -return false;
> +  for (n = clause_list; n; n = n->next)
> + {
> +   if (reductions.contains (n->sym))
> + gfc_error (error_msg, n->sym->name, >where);
> +   else
> + reductions.add (n->sym);
> + }
>  
> -  for (n = clauses->lists[OMP_LIST_FIRST]; n; n = n->next)
> -if (n->sym == sym)
> -  return true;
> +  return;
> +}
>  
> -  return false;
> +  /* Ensure that variables are only used in one clause.  */
> +  for (n = clause_list; n; n = n->next)
> +{
> +  if (n->sym->mark)
> + gfc_error (error_msg, n->sym->name, >where);
> +  else
> + n->sym->mark = 1;
> +}
>  }

> @@ -4966,64 +4927,27 @@ gfc_resolve_oacc_declare (gfc_namespace *ns)
>  {
>loc = oc->where;

As far as I can tell, given the following changes, the "loc" local
variable is now unused, so should be removed?

>  
> -  for (list = OMP_LIST_DEVICE_RESIDENT;
> -list <= OMP_LIST_DEVICE_RESIDENT; list++)
> - for (n = oc->clauses->lists[list]; n; n = n->next)
> -   {
> - n->sym->mark = 0;
> - if (n->sym->attr.flavor == FL_PARAMETER)
> -   gfc_error ("PARAMETER object %qs is not allowed at %L",
> -  n->sym->name, );
> -   }
> -
> -  for (list = OMP_LIST_DEVICE_RESIDENT;
> - list <= OMP_LIST_DEVICE_RESIDENT; 

Re: [ping] Fix PR debug/66728

[Richard Biener]

On Wed, Nov 4, 2015 at 12:57 PM, Mike Stump  wrote:
> On Nov 4, 2015, at 1:43 AM, Richard Biener  wrote:
>> I think you should limit the effect of this patch to the dwarf2out use
>> as the above doesn't make sense to me.
>
> Since dwarf is so special, and since other clients already do something sort 
> of like this anyway, it isn’t unreasonable to make the client be responsible 
> for picking a sensible mode, and asserting if they fail to.  This also 
> transfers the cost of the special case code out to the one client that needs 
> it, and avoids that cost for all the other clients.
>
> The new patch is below for your consideration.
>
> Ok?
>
>> Ideally we'd have an assert that you don't create a rtx_mode_t with
>> VOIDmode or BLKmode.
>
> Added.
>
>> Handling the CONST_WIDE_INT in dwarf2out.c the same as we did before
>> (with CONST_DOUBLE)
>> looks sensible as far of fixing a regression (I assume the diff to the
>> dwarf results in essentially the
>> same DWARF as what was present before wide-int).
>
> Yes, the dwarf is the same.
>
> Index: dwarf2out.c
> ===
> --- dwarf2out.c (revision 229720)
> +++ dwarf2out.c (working copy)
> @@ -15593,8 +15593,15 @@
>return true;
>
>  case CONST_WIDE_INT:
> -  add_AT_wide (die, DW_AT_const_value,
> -  std::make_pair (rtl, GET_MODE (rtl)));
> +  {
> +   machine_mode mode = GET_MODE (rtl);
> +   if (mode == VOIDmode)
> + mode = mode_for_size (CONST_WIDE_INT_NUNITS (rtl)
> +   * HOST_BITS_PER_WIDE_INT,
> +   MODE_INT, 0);
> +   add_AT_wide (die, DW_AT_const_value,
> +std::make_pair (rtl, mode));

I wonder if we'll manage to to get mode_for_size return BLKmode
in case of an original mode that was not of a size multiple of
HOST_BITS_PER_WIDE_INT (and that's host dependent even...).

We probably should use smallest_mode_for_size on a precision
derived from the value (ignore leading ones and zeros or so, exact
details need to be figured out).  Eventually hide this detail in a
smallest_mode_for_const_wide_int () helper.

> +  }
>return true;
>
>  case CONST_DOUBLE:
> Index: rtl.h
> ===
> --- rtl.h   (revision 229720)
> +++ rtl.h   (working copy)
> @@ -2086,6 +2086,7 @@
>  inline unsigned int
>  wi::int_traits ::get_precision (const rtx_mode_t )
>  {
> +  gcc_assert (x.second != BLKmode && x.second != VOIDmode);

Please use gcc_checking_assert here.

Richard.

>return GET_MODE_PRECISION (x.second);
>  }
>
>