[PATCH] Fix bootstrap after estimate_move_change

[Richard Biener]

Targets may not use the speed_p argument of MOVE_RATIO which makes
the function argument unused.

[should we fix the warning to account a macro argument use as use?]

Applied as obvious.

Richard.

2014-07-25  Richard Biener  

* tree-inline.c (estimate_move_cost): Mark speed_p argument
as possibly unused.

Index: gcc/tree-inline.c
===
--- gcc/tree-inline.c   (revision 213040)
+++ gcc/tree-inline.c   (working copy)
@@ -3628,7 +3628,7 @@ tree_inlinable_function_p (tree fn)
cost based on whether optimizing for size or speed according to SPEED_P.  */
 
 int
-estimate_move_cost (tree type, bool speed_p)
+estimate_move_cost (tree type, bool ARG_UNUSED (speed_p))
 {
   HOST_WIDE_INT size;
 

Re: Make the string_view literal operators constexpr like the ctors they call.

[Jonathan Wakely]

On 25 July 2014 04:50, Ed Smith-Rowland <3dw...@verizon.net> wrote:
> On 03/08/2014 01:33 PM, Jonathan Wakely wrote:
>>
>> On 8 March 2014 16:29, Ed Smith-Rowland wrote:
>>>
>>> On 03/08/2014 11:27 AM, Ed Smith-Rowland wrote:

 The title says it all.  This was just an oversight in the original
 patch.

 This could wait until stage 1 obviously.  I just wanted to post it.

 There are a lot of post-Issaquah constexpr changes but these will have
 to
 wait for front-end support for C++14 constexpr.

 Builds and tests clean on x86_64-linux.

 OK?
>>
>> OK for stage 1, but not now.  (And please remember to CC gcc-patches)
>>
> I had completely forgotten about this until now.
>
> Rebased, retested, committed.


Nice, thanks.

Re: [PATCH, libffi, alpha]: Use FFI_ASSERT in ffi_closure_osf_inner

[Uros Bizjak]

On Mon, Jul 21, 2014 at 8:21 PM, Uros Bizjak  wrote:

> Attached patch fixes libgo reflect test failure with libffi closures.
> The gccgo compiler started to use FFI closures recently; the compiler
> passes ffi_type_void for structures with zero members.
>
> ffi_call form src/alpha/ffi.c allows FFI_TYPE_VOID arguments in
> non-debug mode through the default: case, but ffi_closure_osf_inner
> aborts with this type of argument.
>
> The patch changes the default case in ffi_closure_osf_inner from abort
> to FFI_ASSERT, an this way synchronizes argument handling in both
> cases.
>
> 2014-07-21  Uros Bizjak  
>
> * src/alpha/ffi.c: Do not include stdlib.h.
> (ffi_closure_osf_inner) : Use FFI_ASSERT instead of abort.
>
> Patch was tested with libffi testsuite on alphaev6-linux-gnu.
> Additionally, the patch fixed reflect test from the libgo testsuite
> and go.test/test/recover.go test from the gcc testsuite.

I have installed the patch in gcc mainline SVN as r213049.

Uros.

Re: [PATCH 2/3] PR other/61321 - demangler crash on casts in template parameters

[Pedro Alves]

On 07/24/2014 11:35 PM, Cary Coutant wrote:
>> It seems that the problem here is more general; a template argument list is
>> not in scope within that same template argument list.  Can't we fix that
>> without special-casing conversion ops?
> 
> I think conversion ops really are a special case. 

Thanks Cary.  FWIW, I agree.

(GDB 7.8 hasn't been released yet, though it's close.  If this
patch is approved as is, we'll be able to have the crash
fixed there.  If this requires a significant rewrite though,
I'm afraid I might not be able to do it myself anytime soon.)

> It's the only case
> where the template parameters refer to the template argument list from
> the cast operator's enclosing template. In a cast expression, like
> anywhere else you might have a template parameter, the template
> parameter refers to the template argument list of the immediately
> enclosing template.
> 
> I think this note from Section 5.1.3 (Operator Encodings) of the ABI
> is what makes this a special case (it's an informative comment in the
> document, but seems to me to be normative):
> 
> "For a user-defined conversion operator the result type (i.e., the
> type to which the operator converts) is part of the mangled name of
> the function. If the conversion operator is a member template, the
> result type will appear before the template parameters. There may be
> forward references in the result type to the template parameters."
> 

-- 
Thanks,
Pedro Alves

Re: werror fallout for cross-builds (was: Re: [BUILDROBOT][PATCH] Fix mmix (unused variable))

[Jan-Benedict Glaw]

On Thu, 2014-07-24 16:30:13 -0400, Hans-Peter Nilsson  wrote:
> On Thu, 24 Jul 2014, Jan-Benedict Glaw wrote:
> > On Tue, 2014-07-22 16:40:31 -0400, Hans-Peter Nilsson  
> > wrote:
> > > Jan-Benedict, which host gcc version do you use when getting
> > > most targets to build with config-list.mk?  Maybe we can just
> > > set the initial version to that instead of 4.4.4.
> >
> > darkeye gcc (Debian 4.8.1-7) 4.8.1
> > gccbuildgcc (Debian 4.8.1-7) 4.8.1
> > pluto   gcc (Debian 4.9.1-1) 4.9.1
> > gcc20   gcc (Debian 4.4.5-8) 4.4.5
> > gcc76   gcc (Debian 4.4.5-8) 4.4.5
> > gcc110  gcc (GCC) 4.7.2 20121109 (Red Hat 4.7.2-8)
> > gcc111  gcc (GCC) 4.8.1
> > XL 12.1.0.0 (if I ever get that properly working...)
> 
> I tried to repeat that, for the CFarm hosts.  On gcc111 trying
> config-list.mk on the 0720 snapshot (and with mpc, mpfr and gmp
> in-tree) gives me: "configure: error: GNAT is required to build
> ada" already for aarch64-unknown-elf.  Somewhat expected, as I
> don't think many of the targets in the config-list.mk LIST have
> Ada bits ported, but maybe there are no Ada specific bits needed
> to build the GNAT compiler proper, just a host GNAT.
> 
> On gcc110 which *has* gnat, I get:
> 
> /gcc/o/aarch64-elf/./mpfr -I/home/hp/gcc/gcc/mpfr -I/opt/cfarm/mpc/include  
> -I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd 
> -I../libdecnumber -I../../../gcc/gcc/../libbacktrace-o dwarf2out.o -MT 
> dwarf2out.o -MMD -MP -MF ./.deps/dwarf2out.TPo ../../../gcc/gcc/dwarf2out.c
[...]

The config-list.mk builds are right now only scheduled on gcc20 and
gcc76. Maybe I'd schedule them on gcc110 as well?

> By that list, did you really mean that you got even 4.4.5 to
> work on an unmodified config-list.mk?

No, I just haven't scheduled config-list.mk based builds (you know, I
right now have two different build backends, with possibly cbuild2
being integrated as a third one) on gcc110 at all.

> Perhaps you have local patches or did you call config-list.mk
> with some kind of options?  Maybe you didn't actually use
> config-list.mk?  Or just looked to see whether the first failure
> for each target was on a target-specific file or the (same)
> middle-end bits?  Ok, I'm out of guesses. :)

...and you just missed the most obvious one: It probably won't just
work at all ;-)

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
 Signature of:Arroganz verkürzt fruchtlose Gespräche.
 the second  :   -- Jan-Benedict Glaw


signature.asc
Description: Digital signature

Re: [PATCH, Pointer Bounds Checker 9/x] Cgraph extension

[Ilya Enkovich]

2014-07-24 17:41 GMT+04:00 Jan Hubicka :
>> > So the patch is introducing yet another notion of clone (in addition to 
>> > existing virtual clones
>> > and function versions used by ifun) and you add a new type of reference 
>> > (CHKP) to link the
>> > original and the clone.
>> >
>> > Why do you need to link things in 3 different ways? (i.e. 
>> > instrumented_version points to the
>> > same place as CHKP and as orig_decl, right?).
>>
>> CHKP reference is required to have reachability algorithms working
>> correctly and not removing required instrumented nodes.  References
>> are rebuilt time to time and instrumented_version is used to rebuild
>> CHKP reference.  orig_decl is required because original function node
>> may be removed as unreachable.
>>
>> >
>> > I would preffer if this can be put into the existing clone mechanizm. The 
>> > virtual clones can
>> > have quite generic transformations done on them and the do perform all the 
>> > necessary links
>> > back and forth.
>>
>> I suppose virtual clones are useful when we may delay their
>> materialization, i.e. for IPA passes. For checker we have
>> instrumentation almost immediately following clone creation.
>> Instrumentation is a GIMPLE pass and we have to materialize clones to
>> have bodies to instrument. After materialization there is no link to
>> original node anymore and it means we would still require all new
>> fields in cgraph_node structure.
>>
>> >
>> > I will look into the rest of changes, is there some overview?
>>
>> I have a short overview of how it works on a wiki page:
>> https://gcc.gnu.org/wiki/Intel%20MPX%20support%20in%20the%20GCC%20compiler#Instrumentation_clones
>
> Thanks, I will take a deeper look.  I am just somewhat concerned that you seem
> to be duplicating a lot of logic that is already present in the other clonning
> schemes we have (i.e. arranging sane partitining, keeping clones linked with
> their original etc).  We may want to generalize current mechanizm rather than
> implementing similar in parallel...

Thanks for looking into this! I looked into clones mechanism before
introducing instrumentation clones and did not see how I can re-use
it. Probably you may see if it can be easily adopted.

Thanks,
Ilya

>
> Sorry for ignoring the patches so long - I seem to have missed my CC in 
> original
> thread.  I would welcome if you CC hubi...@ucw.cz for cgraph/ipa related 
> patches.
>
> Honza
>

Re: [GSoC] generation of Gimple code from isl_ast_node_if

[Roman Gareev]

> I have no idea. Is the Gimple basic block of S_3 never set, or is it set and
> deleted on the way?

I think, that it is deleted on the way. I've found out, that the
Gimple basic block will be set, if we add the following code to the
generate_isl_schedule:

bb_schedule = isl_map_set_tuple_id (bb_schedule, isl_dim_in,
isl_id_for_pbb (scop, pbb));

where isl_id_for_pbb is

static isl_id *
isl_id_for_pbb (scop_p s, poly_bb_p pbb)
{
  char name[50];
  snprintf (name, sizeof (name), "S_%d", pbb_index (pbb));
  return isl_id_alloc (s->ctx, name, pbb);
}

> What code does S_3 correspond to?

If I'm not mistaken, it is corresponds to:

res_18 = Cross_BB_scalar_dependence.7[0];
phi_out_of_ssa.4[0] = res_18;

I used the following code from
https://gcc.gnu.org/onlinedocs/gccint/Basic-Blocks.html to dump basic
block of the Gimple basic block:

gimple_stmt_iterator si;

for (si = gsi_start_phis (bb); !gsi_end_p (si); gsi_next (&si))
  {
gimple phi = gsi_stmt (si);
print_gimple_stmt (dump_file, phi, 0, TDF_SLIM);
  }
for (si = gsi_start_bb (bb); !gsi_end_p (si); gsi_next (&si))
  {
gimple stmt = gsi_stmt (si);
print_gimple_stmt (dump_file, stmt, 0, TDF_SLIM);
  }

Could you please advise me possible functions from
graphite-sese-to-poly.c, which can delete this?

P.S.: Only S_3 has this problem in the example.

--
   Cheers, Roman Gareev.

Re: [GSoC] generation of Gimple code from isl_ast_node_if

[Tobias Grosser]

On 25/07/2014 13:20, Roman Gareev wrote:

I have no idea. Is the Gimple basic block of S_3 never set, or is it set and
deleted on the way?


I think, that it is deleted on the way. I've found out, that the
Gimple basic block will be set, if we add the following code to the
generate_isl_schedule:

bb_schedule = isl_map_set_tuple_id (bb_schedule, isl_dim_in,
isl_id_for_pbb (scop, pbb));


Is at this point the pbb of S_3 still valid? Does it point to valid data?


where isl_id_for_pbb is

static isl_id *
isl_id_for_pbb (scop_p s, poly_bb_p pbb)
{
   char name[50];
   snprintf (name, sizeof (name), "S_%d", pbb_index (pbb));
   return isl_id_alloc (s->ctx, name, pbb);
}


This is surprising. You previously said the pbb pointer is still valid, 
but only the pointer that within the pbb that points to the gimple bb is 
invalid. I don't really see why setting the isl_id again (pointing to 
the very same pbb) helps in preserving the data structures in pbb.



What code does S_3 correspond to?


If I'm not mistaken, it is corresponds to:

res_18 = Cross_BB_scalar_dependence.7[0];
phi_out_of_ssa.4[0] = res_18;

I used the following code from
https://gcc.gnu.org/onlinedocs/gccint/Basic-Blocks.html to dump basic
block of the Gimple basic block:

gimple_stmt_iterator si;

for (si = gsi_start_phis (bb); !gsi_end_p (si); gsi_next (&si))
   {
 gimple phi = gsi_stmt (si);
 print_gimple_stmt (dump_file, phi, 0, TDF_SLIM);
   }
for (si = gsi_start_bb (bb); !gsi_end_p (si); gsi_next (&si))
   {
 gimple stmt = gsi_stmt (si);
 print_gimple_stmt (dump_file, stmt, 0, TDF_SLIM);
   }

Could you please advise me possible functions from
graphite-sese-to-poly.c, which can delete this?


This is a hard guess. I would propose to debug this in gdb. Add a 
breakpoint at a location where pbb/isl_id are set, verify that they are 
correctly set and add a watchpoint on the pointer that is set to ZERO. 
This should make gdb stop exactly at the point where the information is 
lost.


Alternatively, you could also try to run this in valgrind.

Cheers,
Tobias

Re: Patch for constexpr variable templates

[Braden Obrzut]

On 07/24/2014 04:56 PM, Jason Merrill wrote:



+  /* Variable templates will need to have the class context.  */
+  if (VAR_P (value))
+DECL_CONTEXT (value) = current_class_type;


Why isn't this covered by grokvardecl?
Oops, as the changelog indicated, this was to satisfy the old version of 
variable_template_p which checked the scope.  I forgot to apply Gaby's 
second patch initially.  It's no longer needed so I've removed it.



+  else if (VAR_P (decl))
+{
+  if (!DECL_DECLARED_CONSTEXPR_P (decl))
+error ("template declaration of non-constexpr variable 
%qD", decl);

+}


As Ed and Andrew pointed out, non-constexpr variable templates are fine.

This patch only covers constexpr variable templates, so it makes sense 
to produce an error for now.  Otherwise more confusing linker errors 
will be thrown regarding duplicate or missing symbols.  I do not believe 
it would be too difficult to extend this patch to do non-constexpr 
variables since it looks like the issue is assigning names, but it's 
outside of the scope of what is required for concepts which is what I'm 
assigned to for GSoC.


Other than that, the other issues you mentioned should be fixed.

- Braden Obrzut

2014-07-25  Braden Obrzut  

* decl.c (grokvardecl): Handle specializations of variable templates.
(grokdeclarator): Handle variable template id expressions.
* decl2.c (check_member_template): Allow declaration of template member
variables.
* parser.c (cp_parser_postfix_expression): Resolve VAR_DECLs from
TEMPLATE_ID_EXPRs.
(cp_parser_template_id): Build a TEMPLATE_ID_EXPR for variable
templates.
* pt.c (register_specialization): Accept variable templates.
(determine_specialization): Accept variable templates.
(check_template_variable): Fixed wanted template header count and
change non static data member error to variable template warning.
(lookup_template_variable): New.
(do_decl_instantiation): Handle template variables.
(instantiate_decl): Handle template variables.
* semantics.c (finish_template_variable): New.

2014-07-25  Braden Obrzut  

* g++.dg/cpp1y/var-templ1.C: New.
* g++.dg/cpp1y/var-templ2.C: New.
* g++.dg/cpp1y/var-templ3.C: New.
* g++.dg/cpp1y/var-templ4.C: New.
* g++.dg/cpp1y/var-templ5.C: New.

2013-03-29  Gabriel Dos Reis  

* cp-tree.h (variable_template_p): Do not check scope.
* pt.c (check_template_variable): Fix thinko from previous change.
(push_template_decl_real): Fix formatting.


2013-03-29  Gabriel Dos Reis  

* cp-tree.h (variable_template_p): New.
* pt.c (check_template_variable): Accept variable temploids at
non-class scope.
(push_template_decl_real): The current instantiation of a template
can be a VAR_DECL.
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 4a5cb98..c6c 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -5027,6 +5027,17 @@ class_of_this_parm (const_tree fntype)
   return TREE_TYPE (type_of_this_parm (fntype));
 }
 
+/* True if T designates a variable template declaration.  */
+inline bool
+variable_template_p (tree t)
+{
+  if (TREE_CODE (t) != TEMPLATE_DECL)
+return false;
+  if (tree r = DECL_TEMPLATE_RESULT (t))
+return VAR_P (r);
+  return false;
+}
+
 /* A parameter list indicating for a function with no parameters,
e.g  "int f(void)".  */
 extern cp_parameter_declarator *no_parameters;
@@ -5554,6 +5565,7 @@ extern bool redeclare_class_template		(tree, tree);
 extern tree lookup_template_class		(tree, tree, tree, tree,
 		 int, tsubst_flags_t);
 extern tree lookup_template_function		(tree, tree);
+extern tree lookup_template_variable		(tree, tree);
 extern int uses_template_parms			(tree);
 extern int uses_template_parms_level		(tree, int);
 extern bool in_template_function		(void);
@@ -5816,6 +5828,7 @@ extern tree perform_koenig_lookup		(tree, vec *,
 		 tsubst_flags_t);
 extern tree finish_call_expr			(tree, vec **, bool,
 		 bool, tsubst_flags_t);
+extern tree finish_template_variable	(tree);
 extern tree finish_increment_expr		(tree, enum tree_code);
 extern tree finish_this_expr			(void);
 extern tree finish_pseudo_destructor_expr   (tree, tree, tree, location_t);
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index dae85c2..eea2775 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -80,8 +80,8 @@ static int ambi_op_p (enum tree_code);
 static int unary_op_p (enum tree_code);
 static void push_local_name (tree);
 static tree grok_reference_init (tree, tree, tree, int);
-static tree grokvardecl (tree, tree, const cp_decl_specifier_seq *,
-			 int, int, tree);
+static tree grokvardecl (tree, tree, tree, const cp_decl_specifier_seq *,
+			 int, int, int, tree);
 static int check_static_variable_definition (tree, tree);
 static void record_unknown_type (tree, const char *);
 static tree builtin_function_1 (tree, tree, bool);
@@ -7943,9 +7943,11 @@ set_linkage_for_static_data_

Re: Updated incremental hash patchkit

[Richard Biener]

On Fri, Jul 25, 2014 at 2:11 AM, Andi Kleen  wrote:
> This version addresses the review feedback. begin is gone now.
> add_flag is in the class.  The changes in tree.c are nearer
> the original code now. Some other minor cleanups.
>
> Passed bootstrap and test and x86_64-linux. Ok to commit
> now?

Ok.

Thanks,
Richard.

> Thanks,
> -Andi
>

Re: [PATCH] Support asan-fixed-shadow-offset in GCC

[Alexey Preobrazhensky]

Our x86_64 implementation it also checks whether frame pointer lies
within direct mapping zone (0x8800-c800), as
some frames are not in that zone and doesn't have shadow.

On Tue, Jul 22, 2014 at 2:43 PM, Andrey Ryabinin  wrote:
> On 07/22/14 14:30, Yury Gribov wrote:
 It is required for Kernel AddressSanitizer, as the shadow offset is
 not known at the compile time,
>>>
>>> To get shadow offset this patch uses function __asan_get_shadow_ptr.
>>> Wouldn't be more effective just to read variable instead of function call?
>>
>> Depends on how much logic you want to hide there. If it's just "return 
>> something" than sure
>> but if you need some synchronization or complex calculations, accessing 
>> global would not be enough.
>>
>
> This function just returns some global variable, and I don't think we will 
> need something more complex in future.
>
>> -Y
>>
>

Re: [PATCH 1/3]Improve induction variable elimination

[Richard Biener]

On Thu, Jul 17, 2014 at 11:07 AM, Bin Cheng  wrote:
> Hi,
> This is a series of three patches improving induction variable elimination.
> Currently GCC only eliminates iv for very specific case when the loop’s
> latch could run zero times, i.e., when may_be_zero field of loop niter
> information evaluates to true.  In fact, it’s so specific that
> iv_elimination_compare_lt rarely succeeds during either GCC bootstrap or
> spec2000/spec2006 compilation.  Though intrusive data shows these patches
> don’t help iv elimination that much for GCC bootstrap, they do capture
> 5%~15% more eliminations for compiling spec2000/2006.  Detailed numbers are
> like:
>   2k/int   2k/fp   2k6/int   2k6/fp
> improve ~9.6%  ~4.8%  ~5.5%~14.4%
>
> All patches pass bootstrap and regression test on x86_64/x86.  I will
> bootstrap and test them on aarch64/arm platforms too.
>
> The first patch turns to tree operand_equal_p to check the number of
> iterations in iv_elimination_lt.  Though I think this change isn’t necessary
> for current code, it’s needed if we further relax iv elimination for cases
> in which sign/unsigned conversion is involved.

As said elsewhere this bug should be fixed in tree-affine.c.  Do you have
a testcase?

Thanks,
Richard.

> Thanks,
> bin
>
> 2014-07-17  Bin Cheng  
>
> * tree-ssa-loop-ivopts.c (iv_elimination_compare_lt): Check number
> of iteration using tree comparison.

Re: [PATCH 2/3]Improve induction variable elimination

[Richard Biener]

On Thu, Jul 17, 2014 at 11:08 AM, Bin Cheng  wrote:
> Hi,
> As quoted from the function difference_cannot_overflow_p,
>
>   /* TODO: deeper inspection may be necessary to prove the equality.  */
>   switch (code)
> {
> case PLUS_EXPR:
>   return expr_equal_p (e1, offset) || expr_equal_p (e2, offset);
> case POINTER_PLUS_EXPR:
>   return expr_equal_p (e2, offset);
>
> default:
>   return false;
> }
>
> The overflow check can be improved by using deeper inspection to prove the
> equality.  This patch deals with that by making below two improvements:
>   a) Handles constant cases.
>   b) Uses affine expansion as deeper inspection to check the equality.
>
> As a result, functions strip_wrap_conserving_type_conversions and
> expr_equal_p can be removed now.  A test case is also added to illustrate iv
> elimination opportunity captured by this patch.
>
> Thanks,
> bin

You add special casing for constants but I don't see any testcases for that.
Specifically

+  /* No overflow if offset is zero.  */
+  if (offset == integer_zero_node)
 return true;

is a bogus check (use integer_zerop).  Apart from the special-casing of
constants the patch looks good to me.

Richard.

> 2014-07-17  Bin Cheng  
>
> * tree-ssa-loop-ivopts.c (ivopts_data): New field name_expansion.
> (tree_ssa_iv_optimize_init): Initialize name_expansion.
> (tree_ssa_iv_optimize_finalize): Free name_expansion.
> (strip_wrap_conserving_type_conversions, expr_equal_p): Delete.
> (difference_cannot_overflow_p): New parameter.  Handle constant
> cases.  Use affine expansion for equality check.
> (iv_elimination_compare_lt): Pass new argument.
>
> gcc/testsuite/ChangeLog
> 2014-07-17  Bin Cheng  
>
> * gcc.dg/tree-ssa/ivopts-lt-2.c: New test.

Avoid multiple entry SCC regions

[Jan Hubicka]

Hi,
this patch make SCC hashes stronger by using DFS to get entry point independent
order.  The DFS refactoring work is Richards, only hash_tree changes are mine
and I am responsible for all bugs :) Details are hopefully well documented in
hash_scc.

I tested the patch on Firefox and we manage to get rid of all the duplicates
within SCC regions that allows further simplification downstream on SCC
streaming and merging.

I am lto bootstrapping/regtesting x86_64-linux and intend to comming once it
passes.

Honza

Richard Biener 
Jan Hubicka  

* lto-streamer-out.c (struct sccs): Turn to ...
(class DFS): ... this one; refactor the DFS walk so it can
be re-done on per-SCC basis.
(DFS::DFS): New constructor.
(DFS::~DFS): New destructor.
(hash_tree): Add new MAP argument holding in-SCC hash values;
remove POINTER_TYPE hashing hack.
(scc_entry_compare): Rename to ...
(DFS::scc_entry_compare): ... this one.
(hash_scc): Rename to ...
(DFS::hash_scc): ... this one; pass output_block instead
of streamer_cache; work harder to get unique and stable SCC
hashes.
(DFS_write_tree): Rename to ...
(DFS::DFS_write_tree): ... this one; add SINGLE_P parameter.
(lto_output_tree): Update.

Index: lto-streamer-out.c
===
--- lto-streamer-out.c  (revision 212994)
+++ lto-streamer-out.c  (working copy)
@@ -439,36 +440,71 @@ lto_output_tree_1 (struct output_block *
 }
 }
 
-struct sccs
+class DFS
 {
-  unsigned int dfsnum;
-  unsigned int low;
+public:
+  DFS (struct output_block *ob, tree expr, bool ref_p, bool this_ref_p,
+   bool single_p);
+  ~DFS ();
+
+  struct scc_entry
+  {
+tree t;
+hashval_t hash;
+  };
+  vec sccstack;
+
+private:
+  struct sccs
+  {
+unsigned int dfsnum;
+unsigned int low;
+  };
+
+  static int scc_entry_compare (const void *, const void *);
+
+  void DFS_write_tree_body (struct output_block *ob,
+   tree expr, sccs *expr_state, bool ref_p,
+   bool single_p);
+
+  void DFS_write_tree (struct output_block *ob, sccs *from_state,
+  tree expr, bool ref_p, bool this_ref_p,
+  bool single_p);
+  hashval_t
+  hash_scc (struct output_block *ob, unsigned first, unsigned size);
+
+  unsigned int next_dfs_num;
+  struct pointer_map_t *sccstate;
+  struct obstack sccstate_obstack;
 };
 
-struct scc_entry
+DFS::DFS (struct output_block *ob, tree expr, bool ref_p, bool this_ref_p,
+ bool single_p)
 {
-  tree t;
-  hashval_t hash;
-};
-
-static unsigned int next_dfs_num;
-static vec sccstack;
-static struct pointer_map_t *sccstate;
-static struct obstack sccstate_obstack;
+  sccstack.create (0);
+  sccstate = pointer_map_create ();
+  gcc_obstack_init (&sccstate_obstack);
+  next_dfs_num = 1;
+  DFS_write_tree (ob, NULL, expr, ref_p, this_ref_p, single_p);
+}
 
-static void
-DFS_write_tree (struct output_block *ob, sccs *from_state,
-   tree expr, bool ref_p, bool this_ref_p);
+DFS::~DFS ()
+{
+  sccstack.release ();
+  pointer_map_destroy (sccstate);
+  obstack_free (&sccstate_obstack, NULL);
+}
 
 /* Handle the tree EXPR in the DFS walk with SCC state EXPR_STATE and
DFS recurse for all tree edges originating from it.  */
 
-static void
-DFS_write_tree_body (struct output_block *ob,
-tree expr, sccs *expr_state, bool ref_p)
+void
+DFS::DFS_write_tree_body (struct output_block *ob,
+ tree expr, sccs *expr_state, bool ref_p,
+ bool single_p)
 {
 #define DFS_follow_tree_edge(DEST) \
-  DFS_write_tree (ob, expr_state, DEST, ref_p, ref_p)
+  DFS_write_tree (ob, expr_state, DEST, ref_p, ref_p, single_p)
 
   enum tree_code code;
 
@@ -689,16 +725,25 @@ DFS_write_tree_body (struct output_block
 #undef DFS_follow_tree_edge
 }
 
-/* Return a hash value for the tree T.  */
+/* Return a hash value for the tree T.
+   CACHE holds hash values of trees outside current SCC.  MAP, if non-NULL,
+   may hold hash values if trees inside current SCC.  */
 
 static hashval_t
-hash_tree (struct streamer_tree_cache_d *cache, tree t)
+hash_tree (struct streamer_tree_cache_d *cache, hash_map 
*map, tree t)
 {
 #define visit(SIBLING) \
   do { \
 unsigned ix; \
-if (SIBLING && streamer_tree_cache_lookup (cache, SIBLING, &ix)) \
-  v = iterative_hash_hashval_t (streamer_tree_cache_get_hash (cache, ix), 
v); \
+if (!SIBLING) \
+  v = iterative_hash_hashval_t (0, v); \
+else if (streamer_tree_cache_lookup (cache, SIBLING, &ix)) \
+  v = iterative_hash_hashval_t (streamer_tree_cache_get_hash (cache, ix), \
+   v); \
+else if (map) \
+  v = iterative_hash_hashval_t (*map->get (SIBLING), v); \
+else \
+  v = iterative_hash_hashval_t (1, v); \
   } while (0)
 
   /* Hash 

Re: [PATCH 1/3]Improve induction variable elimination

[Bin.Cheng]

On Fri, Jul 25, 2014 at 1:27 PM, Richard Biener
 wrote:
> On Thu, Jul 17, 2014 at 11:07 AM, Bin Cheng  wrote:
>> Hi,
>> This is a series of three patches improving induction variable elimination.
>> Currently GCC only eliminates iv for very specific case when the loop's
>> latch could run zero times, i.e., when may_be_zero field of loop niter
>> information evaluates to true.  In fact, it's so specific that
>> iv_elimination_compare_lt rarely succeeds during either GCC bootstrap or
>> spec2000/spec2006 compilation.  Though intrusive data shows these patches
>> don't help iv elimination that much for GCC bootstrap, they do capture
>> 5%~15% more eliminations for compiling spec2000/2006.  Detailed numbers are
>> like:
>>   2k/int   2k/fp   2k6/int   2k6/fp
>> improve ~9.6%  ~4.8%  ~5.5%~14.4%
>>
>> All patches pass bootstrap and regression test on x86_64/x86.  I will
>> bootstrap and test them on aarch64/arm platforms too.
>>
>> The first patch turns to tree operand_equal_p to check the number of
>> iterations in iv_elimination_lt.  Though I think this change isn't necessary
>> for current code, it's needed if we further relax iv elimination for cases
>> in which sign/unsigned conversion is involved.
>
> As said elsewhere this bug should be fixed in tree-affine.c.  Do you have
> a testcase?
>
Sorry I don't have test case without patching GCC, I will revisit the
problem and try to understand whether it's necessary or in which part
it should be fixed.

Thanks,
bin

Re: [PATCH 2/3]Improve induction variable elimination

[Bin.Cheng]

On Fri, Jul 25, 2014 at 1:35 PM, Richard Biener
 wrote:
> On Thu, Jul 17, 2014 at 11:08 AM, Bin Cheng  wrote:
>> Hi,
>> As quoted from the function difference_cannot_overflow_p,
>>
>>   /* TODO: deeper inspection may be necessary to prove the equality.  */
>>   switch (code)
>> {
>> case PLUS_EXPR:
>>   return expr_equal_p (e1, offset) || expr_equal_p (e2, offset);
>> case POINTER_PLUS_EXPR:
>>   return expr_equal_p (e2, offset);
>>
>> default:
>>   return false;
>> }
>>
>> The overflow check can be improved by using deeper inspection to prove the
>> equality.  This patch deals with that by making below two improvements:
>>   a) Handles constant cases.
>>   b) Uses affine expansion as deeper inspection to check the equality.
>>
>> As a result, functions strip_wrap_conserving_type_conversions and
>> expr_equal_p can be removed now.  A test case is also added to illustrate iv
>> elimination opportunity captured by this patch.
>>
>> Thanks,
>> bin
>
> You add special casing for constants but I don't see any testcases for that.
> Specifically
>
> +  /* No overflow if offset is zero.  */
> +  if (offset == integer_zero_node)
>  return true;
>
> is a bogus check (use integer_zerop).  Apart from the special-casing of
Will be changed.

> constants the patch looks good to me.
>
Ah, Now I can see that handling of constants (here the zero offset
case) is to make the 3rd patch to work.  I should include this part of
code in the 3rd patch.  Also I will try to reduce testcase for other
non-zero constant scenarios

Thanks,
bin

Re: Patch for constexpr variable templates

[Ed Smith-Rowland]

How difficult would it be to make partial specializations work:

// Write n*pi once for every possible type
template
  constexpr Tp npi = N * Tp(3.1415926535897932385L);

// Partial specialization for int type.
template
  constexpr double npi = N * double(3.1415926535897932385L);

[jit] Add type-checking for API calls that expect numeric types

[David Malcolm]

Committed to branch dmalcolm/jit:

gcc/jit/
* TODO.rst (error-checking): Remove various items that either
already were implemented, or are implemented by this commit.
* internal-api.h (gcc::jit::recording::type::is_numeric): New.
* libgccjit.c (RETURN_NULL_IF_FAIL_NONNULL_NUMERIC_TYPE): New macro.
(gcc_jit_context_new_rvalue_from_int): Verify that numeric_type is
indeed numeric.
(gcc_jit_context_zero): Likewise.
(gcc_jit_context_one): Likewise.
(gcc_jit_context_new_rvalue_from_double): Likewise.
(gcc_jit_context_new_array_access): Likewise for type of "index".

gcc/testsuite/
* jit.dg/test-error-index-not-a-numeric-type.c: New test case.
* jit.dg/test-error-value-not-a-numeric-type.c: New test case.
---
 gcc/jit/ChangeLog.jit  | 13 +
 gcc/jit/TODO.rst   | 16 --
 gcc/jit/internal-api.h |  5 
 gcc/jit/libgccjit.c| 23 +++
 gcc/testsuite/ChangeLog.jit|  5 
 .../jit.dg/test-error-index-not-a-numeric-type.c   | 34 ++
 .../jit.dg/test-error-value-not-a-numeric-type.c   | 29 ++
 7 files changed, 104 insertions(+), 21 deletions(-)
 create mode 100644 gcc/testsuite/jit.dg/test-error-index-not-a-numeric-type.c
 create mode 100644 gcc/testsuite/jit.dg/test-error-value-not-a-numeric-type.c

diff --git a/gcc/jit/ChangeLog.jit b/gcc/jit/ChangeLog.jit
index 65fba51..3db15e8 100644
--- a/gcc/jit/ChangeLog.jit
+++ b/gcc/jit/ChangeLog.jit
@@ -1,3 +1,16 @@
+2014-07-25  David Malcolm  
+
+   * TODO.rst (error-checking): Remove various items that either
+   already were implemented, or are implemented by this commit.
+   * internal-api.h (gcc::jit::recording::type::is_numeric): New.
+   * libgccjit.c (RETURN_NULL_IF_FAIL_NONNULL_NUMERIC_TYPE): New macro.
+(gcc_jit_context_new_rvalue_from_int): Verify that numeric_type is
+   indeed numeric.
+   (gcc_jit_context_zero): Likewise.
+   (gcc_jit_context_one): Likewise.
+   (gcc_jit_context_new_rvalue_from_double): Likewise.
+   (gcc_jit_context_new_array_access): Likewise for type of "index".
+
 2014-07-14  David Malcolm  
 
* internal-api.c (gcc::jit::recording::context::new_array_type):
diff --git a/gcc/jit/TODO.rst b/gcc/jit/TODO.rst
index b2d8c04..caf78e3 100644
--- a/gcc/jit/TODO.rst
+++ b/gcc/jit/TODO.rst
@@ -75,20 +75,6 @@ Initial Release
 
 * error-checking:
 
-* gcc_jit_context_new_field: type must not be void
-
-* gcc_jit_context_new_param: type must not be void
-
-* gcc_jit_context_new_global: type must not be void
-
-* gcc_jit_context_new_rvalue_from_int: must be a numeric type
-
-* gcc_jit_context_zero: must be a numeric type
-
-* gcc_jit_context_one: must be a numeric type
-
-* gcc_jit_context_new_rvalue_from_double: must be a numeric type
-
 * gcc_jit_context_new_unary_op: various checks needed
 
 * gcc_jit_context_new_binary_op: various checks needed
@@ -101,8 +87,6 @@ Initial Release
 
 * gcc_jit_rvalue_access_field: must be field of correct struct
 
-* gcc_jit_function_new_local: type must not be void
-
 * gcc_jit_block_add_assignment_op: check the types
 
 * Currently each function has a single stmt_list, which is built in
diff --git a/gcc/jit/internal-api.h b/gcc/jit/internal-api.h
index 1612a22..331edd5 100644
--- a/gcc/jit/internal-api.h
+++ b/gcc/jit/internal-api.h
@@ -500,6 +500,11 @@ public:
   virtual type *is_pointer () = 0;
   virtual type *is_array () = 0;
 
+  bool is_numeric () const
+  {
+return is_int () || is_float () || is_bool ();
+  }
+
   playback::type *
   playback_type ()
   {
diff --git a/gcc/jit/libgccjit.c b/gcc/jit/libgccjit.c
index c9805de..bbc1941 100644
--- a/gcc/jit/libgccjit.c
+++ b/gcc/jit/libgccjit.c
@@ -671,13 +671,20 @@ gcc_jit_rvalue_get_type (gcc_jit_rvalue *rvalue)
   return static_cast  (rvalue->get_type ());
 }
 
+#define RETURN_NULL_IF_FAIL_NONNULL_NUMERIC_TYPE(CTXT, NUMERIC_TYPE) \
+  RETURN_NULL_IF_FAIL (NUMERIC_TYPE, CTXT, NULL, "NULL type"); \
+  RETURN_NULL_IF_FAIL_PRINTF1 (\
+NUMERIC_TYPE->is_numeric (), ctxt, NULL,   \
+"not a numeric type: %s",  \
+NUMERIC_TYPE->get_debug_string ());
+
 gcc_jit_rvalue *
 gcc_jit_context_new_rvalue_from_int (gcc_jit_context *ctxt,
 gcc_jit_type *numeric_type,
 int value)
 {
   RETURN_NULL_IF_FAIL (ctxt, NULL, NULL, "NULL context");
-  RETURN_NULL_IF_FAIL (numeric_type, ctxt, NULL, "NULL type");
+  RETURN_NULL_IF_FAIL_NONNULL_NUMERIC_TYPE (ctxt, numeric_type);
 
   return (gcc_jit_rvalue *)ctxt->new_rvalue_from_int (numeric_type, value);
 }
@@ -687,7 +694,7 @@ gcc_jit_context_zero (gcc_jit_context *ctxt,
   

Re: Avoid multiple entry SCC regions

[Andi Kleen]

Jan Hubicka  writes:
>
> I am lto bootstrapping/regtesting x86_64-linux and intend to comming once it
> passes.

You'll have to redo it with hstates, sorry, as it conflicts with my
patchkit which I checked in earlier.

-Andi

-- 
a...@linux.intel.com -- Speaking for myself only

Re: Avoid multiple entry SCC regions

[Jan Hubicka]

> Jan Hubicka  writes:
> >
> > I am lto bootstrapping/regtesting x86_64-linux and intend to comming once it
> > passes.
> 
> You'll have to redo it with hstates, sorry, as it conflicts with my
> patchkit which I checked in earlier.

Yep I noticed that earlier and I am testing updated patch.  I think your 
incremental
hashing should be also use within scc_hash calculation, but I will leave that 
for incremnetal
patch.

Honza

> 
> -Andi
> 
> -- 
> a...@linux.intel.com -- Speaking for myself only

Re: FWD: Re: OpenACC subarray specifications in the GCC Fortran front end

[Thomas Schwinge]

Hi Cesar!

On Thu, 24 Jul 2014 15:44:13 -0700, Cesar Philippidis  
wrote:
> On 07/24/2014 06:11 AM, Thomas Schwinge wrote:
> > I'd suggest to continue to handle all the data clauses [...]
> 
> I moved all of the data clause matching back to gfc_match_omp_clauses,
> and I guarded the copyin clause with the openacc flag.

Thanks!

> It looks like the
> private clause may also require a special memory mapping, so I left the
> openacc flag in place.

Where is that?  (I don't see it.)

> Is this patch OK to commit to gomp-4_0-branch?

Yes, though you may directly fold in the following patch to nuke the
unused OMP_LIST_COPY (or do that later).

--- gcc/fortran/dump-parse-tree.c
+++ gcc/fortran/dump-parse-tree.c
@@ -1257,7 +1257,6 @@ show_omp_clauses (gfc_omp_clauses *omp_clauses)
const char *type = NULL;
switch (list_type)
  {
- case OMP_LIST_COPY: type = "COPY"; break;
  case OMP_LIST_DEVICEPTR: type = "DEVICEPTR"; break;
  case OMP_LIST_USE_DEVICE: type = "USE_DEVICE"; break;
  case OMP_LIST_DEVICE_RESIDENT: type = "USE_DEVICE"; break;
--- gcc/fortran/gfortran.h
+++ gcc/fortran/gfortran.h
@@ -1157,9 +1157,8 @@ enum
   OMP_LIST_TO,
   OMP_LIST_FROM,
   OMP_LIST_REDUCTION,
-  OMP_LIST_COPY,
-  OMP_LIST_DATA_CLAUSE_FIRST = OMP_LIST_COPY,
   OMP_LIST_DEVICEPTR,
+  OMP_LIST_DATA_CLAUSE_FIRST = OMP_LIST_DEVICEPTR,
   OMP_LIST_DATA_CLAUSE_LAST = OMP_LIST_DEVICEPTR,
   OMP_LIST_DEVICE_RESIDENT,
   OMP_LIST_USE_DEVICE,


Grüße,
 Thomas


pgpp05bdfd2gj.pgp
Description: PGP signature

Re: C++ PATCH for c++/61687 (extra errors with -O2)

[Jason Merrill]

On 07/24/2014 07:36 PM, Jan Hubicka wrote:

ipa-deivrt has code to do the tracking for you. All is needed is to cal 
get_odr_type
for all polymorphic type that we care about.  build_type_inheritance_graph just
walks all virtual methods to register all polymorphic types that matters (i.e.
have methods associated with them) into the datastructure.  I think within C++
FE we can just reigster all polymoprhic types we produce.


Makes sense.


I see that during the reachability walk new types may be instantiated. This may
extend target lists earlier visited, I guess we need to add some way to make
to track this?


True.

And more problematic, doing this in a single TU isn't good enough; there 
are cases where LTO can devirtualize a call to a target that isn't 
declared in the TU where the call occurs.  That is,


foo.h:
struct A { virtual ~A() {} };
void g(A*);

bar.h:
#include "foo.h"
struct B: A { virtual void f(); };

one.C:
#include "foo.h"
void g(A* p) { delete p; }

two.C:
#include "bar.h"
int main() { g(new B); }

three.C:
#include "bar.h"
void B::f() {}

$ gcc -fpic -shared -fvisibility-inlines-hidden three.C -o libfoo.so
$ gcc -O2 -flto -fvisibility-inlines-hidden one.C two.C libfoo.so
/home/jason/gtt/foo/one.C:2: undefined reference to `B::~B()'

To deal with this I guess we can either keep -fuse-all-virtuals or not 
devirtualize in LTO to something that is hidden and not defined.  Thoughts?


commit ac04d4b08190593299c8c94431d5e43384514096
Author: Jason Merrill 
Date:   Fri Jul 25 09:15:02 2014 -0400

mark_virtual_overrides

diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index c318cad..75711a5 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -1272,10 +1272,6 @@ funsigned-char
 C ObjC C++ ObjC++ LTO Var(flag_signed_char, 0)
 Make \"char\" unsigned by default
 
-fuse-all-virtuals
-C++ ObjC++ Var(flag_use_all_virtuals) Init(1)
-Treat all virtual functions as odr-used
-
 fuse-cxa-atexit
 C++ ObjC++ Var(flag_use_cxa_atexit) Init(DEFAULT_USE_CXA_ATEXIT)
 Use __cxa_atexit to register destructors
diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 4d37c65..969e730 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -7364,6 +7364,8 @@ build_over_call (struct z_candidate *cand, int flags, tsubst_flags_t complain)
 ba_any, NULL, complain);
   gcc_assert (binfo && binfo != error_mark_node);
 
+  note_fn_called_virtually (fn);
+
   /* Warn about deprecated virtual functions now, since we're about
 	 to throw away the decl.  */
   if (TREE_DEPRECATED (fn))
diff --git a/gcc/cp/class.c b/gcc/cp/class.c
index 0f611e1..1401069 100644
--- a/gcc/cp/class.c
+++ b/gcc/cp/class.c
@@ -817,6 +817,9 @@ get_vtable_decl (tree type, int complete)
   decl = build_vtable (type, get_vtable_name (type), vtbl_type_node);
   CLASSTYPE_VTABLES (type) = decl;
 
+  /* Make the vtable visible to build_type_inheritance_graph.  */
+  varpool_node::get_create (decl);
+
   if (complete)
 {
   DECL_EXTERNAL (decl) = 1;
@@ -6408,7 +6411,7 @@ finish_struct_1 (tree t)
 	 in every translation unit where the class definition appears.  If
 	 we're devirtualizing, we can look into the vtable even if we
 	 aren't emitting it.  */
-  if (CLASSTYPE_KEY_METHOD (t) == NULL_TREE || flag_use_all_virtuals)
+  if (CLASSTYPE_KEY_METHOD (t) == NULL_TREE)
 	keyed_classes = tree_cons (NULL_TREE, t, keyed_classes);
 }
 
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 0c0d804..c9f248a 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -109,6 +109,7 @@ c-common.h, not after.
   BIND_EXPR_BODY_BLOCK (in BIND_EXPR)
   DECL_NON_TRIVIALLY_INITIALIZED_P (in VAR_DECL)
   CALL_EXPR_LIST_INIT_P (in CALL_EXPR, AGGR_INIT_EXPR)
+  FNDECL_CALLED_VIRTUALLY (in FUNCTION_DECL)
4: TREE_HAS_CONSTRUCTOR (in INDIRECT_REF, SAVE_EXPR, CONSTRUCTOR,
 	  or FIELD_DECL).
   IDENTIFIER_TYPENAME_P (in IDENTIFIER_NODE)
@@ -3222,6 +3223,11 @@ more_aggr_init_expr_args_p (const aggr_init_expr_arg_iterator *iter)
 #define FNDECL_USED_AUTO(NODE) \
   TREE_LANG_FLAG_2 (FUNCTION_DECL_CHECK (NODE))
 
+/* True if NODE was called through the vtable; used to avoid duplicates in
+   fns_called_virtually.  */
+#define FNDECL_CALLED_VIRTUALLY(NODE) \
+  TREE_LANG_FLAG_3 (FUNCTION_DECL_CHECK (NODE))
+
 /* Nonzero if NODE is a DECL which we know about but which has not
been explicitly declared, such as a built-in function or a friend
declared inside a class.  In the latter case DECL_HIDDEN_FRIEND_P
@@ -5381,6 +5387,7 @@ extern tree get_tls_wrapper_fn			(tree);
 extern void mark_needed(tree);
 extern bool decl_needed_p			(tree);
 extern void note_vague_linkage_fn		(tree);
+extern void note_fn_called_virtually		(tree);
 extern tree build_artificial_parm		(tree, tree);
 extern bool possibly_inlined_p			(tree);
 extern int parm_index   (tree);
diff --git a/gcc/cp/decl2.c b/gcc/cp/decl2.c
index 8fa3145..a448103 100644
--- a/gcc/cp/decl2.c
+++ b/gcc/cp/decl2.c
@@ -47,6 +47,8 @@ along with

Re: Implement N4051 - Allow typename in a template template parameter

[Jason Merrill]

OK, thanks!

Jason

Re: werror fallout for cross-builds (was: Re: [BUILDROBOT][PATCH] Fix mmix (unused variable))

[Hans-Peter Nilsson]

On Fri, 25 Jul 2014, Jan-Benedict Glaw wrote:
> On Thu, 2014-07-24 16:30:13 -0400, Hans-Peter Nilsson  
> wrote:
> > On Thu, 24 Jul 2014, Jan-Benedict Glaw wrote:
> > > On Tue, 2014-07-22 16:40:31 -0400, Hans-Peter Nilsson  
> > > wrote:
> > > > Jan-Benedict, which host gcc version do you use when getting
> > > > most targets to build with config-list.mk?  Maybe we can just
> > > > set the initial version to that instead of 4.4.4.
> > >
> > > darkeye   gcc (Debian 4.8.1-7) 4.8.1
> > > gccbuild  gcc (Debian 4.8.1-7) 4.8.1
> > > pluto gcc (Debian 4.9.1-1) 4.9.1
> > > gcc20 gcc (Debian 4.4.5-8) 4.4.5
> > > gcc76 gcc (Debian 4.4.5-8) 4.4.5
> > > gcc110gcc (GCC) 4.7.2 20121109 (Red Hat 4.7.2-8)
> > > gcc111gcc (GCC) 4.8.1
> > >   XL 12.1.0.0 (if I ever get that properly working...)

I think we have different definitions of "getting most targets
to build".  I guess a valid reply here would IMO have been an
empty list. :(  Does 4.9.1 work(*)?

> > On gcc110 which *has* gnat, I get:
> > /gcc/o/aarch64-elf/./mpfr -I/home/hp/gcc/gcc/mpfr -I/opt/cfarm/mpc/include  
> > -I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd 
> > -I../libdecnumber -I../../../gcc/gcc/../libbacktrace-o dwarf2out.o -MT 
> > dwarf2out.o -MMD -MP -MF ./.deps/dwarf2out.TPo ../../../gcc/gcc/dwarf2out.c
> [...]
>
> The config-list.mk builds are right now only scheduled on gcc20 and
> gcc76. Maybe I'd schedule them on gcc110 as well?

I wouldn't bother, as I found most fail with the errored-warning
I quoted, the rest on port warnings (c6x, mep, avr, bfin, so far)
I'm guessing you don't get very far on gcc20 or gcc76 on each
target.

I think there's a miscommunication here.  When you said you used
config-list.mk and by reporting target-specific build errors, I
misunderstood that as implying that most targets were then
building with no errors using config-list.mk.

> > Perhaps you have local patches or did you call config-list.mk
> > with some kind of options?  Maybe you didn't actually use
> > config-list.mk?  Or just looked to see whether the first failure
> > for each target was on a target-specific file or the (same)
> > middle-end bits?  Ok, I'm out of guesses. :)
>
> ...and you just missed the most obvious one: It probably won't just
> work at all ;-)

(Not really, that's reporting the first failure for a target
when being a target-specific error.)

Anyway, on to the point of this message: by the quoted list it
seems you have a local host called pluto using 4.9.1 as the host
gcc for some build; does config-list.mk work for that?

(* to wit, by "work" I mean "builds with no errors for at least
one target actually using config-list.mk".)

brgds, H-P

[PATCH] Make sra_modify_assign's stmt prameter gimple (as opposed to gimple *)

[Martin Jambor]

Hi,

parameter stmt of sra_modify_assign and sra_modify_constructor_assign
is currently gimple*, although there is no need for the extra level of
indirection and dereferencing.  Thus this patch removes quite few
stars and one ampersand.

Bootstrapped and tested on x86_64-linux, OK for trunk?

Thanks,

Martin


2014-07-25  Martin Jambor  

* tree-sra.c (sra_modify_constructor_assign): Change type of stmt
parameter to gimple.
(sra_modify_assign): Likewise.

diff --git a/gcc/tree-sra.c b/gcc/tree-sra.c
index 7fa6b4f..ba7d159 100644
--- a/gcc/tree-sra.c
+++ b/gcc/tree-sra.c
@@ -3043,9 +3043,9 @@ enum assignment_mod_result { SRA_AM_NONE,   /* 
nothing done for the stmt */
the same values as sra_modify_assign.  */
 
 static enum assignment_mod_result
-sra_modify_constructor_assign (gimple *stmt, gimple_stmt_iterator *gsi)
+sra_modify_constructor_assign (gimple stmt, gimple_stmt_iterator *gsi)
 {
-  tree lhs = gimple_assign_lhs (*stmt);
+  tree lhs = gimple_assign_lhs (stmt);
   struct access *acc;
   location_t loc;
 
@@ -3053,23 +3053,23 @@ sra_modify_constructor_assign (gimple *stmt, 
gimple_stmt_iterator *gsi)
   if (!acc)
 return SRA_AM_NONE;
 
-  if (gimple_clobber_p (*stmt))
+  if (gimple_clobber_p (stmt))
 {
   /* Remove clobbers of fully scalarized variables, otherwise
 do nothing.  */
   if (acc->grp_covered)
{
- unlink_stmt_vdef (*stmt);
+ unlink_stmt_vdef (stmt);
  gsi_remove (gsi, true);
- release_defs (*stmt);
+ release_defs (stmt);
  return SRA_AM_REMOVED;
}
   else
return SRA_AM_NONE;
 }
 
-  loc = gimple_location (*stmt);
-  if (vec_safe_length (CONSTRUCTOR_ELTS (gimple_assign_rhs1 (*stmt))) > 0)
+  loc = gimple_location (stmt);
+  if (vec_safe_length (CONSTRUCTOR_ELTS (gimple_assign_rhs1 (stmt))) > 0)
 {
   /* I have never seen this code path trigger but if it can happen the
 following should handle it gracefully.  */
@@ -3082,9 +3082,9 @@ sra_modify_constructor_assign (gimple *stmt, 
gimple_stmt_iterator *gsi)
   if (acc->grp_covered)
 {
   init_subtree_with_zero (acc, gsi, false, loc);
-  unlink_stmt_vdef (*stmt);
+  unlink_stmt_vdef (stmt);
   gsi_remove (gsi, true);
-  release_defs (*stmt);
+  release_defs (stmt);
   return SRA_AM_REMOVED;
 }
   else
@@ -3133,7 +3133,7 @@ contains_vce_or_bfcref_p (const_tree ref)
copying.  */
 
 static enum assignment_mod_result
-sra_modify_assign (gimple *stmt, gimple_stmt_iterator *gsi)
+sra_modify_assign (gimple stmt, gimple_stmt_iterator *gsi)
 {
   struct access *lacc, *racc;
   tree lhs, rhs;
@@ -3142,10 +3142,10 @@ sra_modify_assign (gimple *stmt, gimple_stmt_iterator 
*gsi)
   location_t loc;
   gimple_stmt_iterator orig_gsi = *gsi;
 
-  if (!gimple_assign_single_p (*stmt))
+  if (!gimple_assign_single_p (stmt))
 return SRA_AM_NONE;
-  lhs = gimple_assign_lhs (*stmt);
-  rhs = gimple_assign_rhs1 (*stmt);
+  lhs = gimple_assign_lhs (stmt);
+  rhs = gimple_assign_rhs1 (stmt);
 
   if (TREE_CODE (rhs) == CONSTRUCTOR)
 return sra_modify_constructor_assign (stmt, gsi);
@@ -3154,9 +3154,9 @@ sra_modify_assign (gimple *stmt, gimple_stmt_iterator 
*gsi)
   || TREE_CODE (rhs) == IMAGPART_EXPR || TREE_CODE (lhs) == IMAGPART_EXPR
   || TREE_CODE (rhs) == BIT_FIELD_REF || TREE_CODE (lhs) == BIT_FIELD_REF)
 {
-  modify_this_stmt = sra_modify_expr (gimple_assign_rhs1_ptr (*stmt),
+  modify_this_stmt = sra_modify_expr (gimple_assign_rhs1_ptr (stmt),
  gsi, false);
-  modify_this_stmt |= sra_modify_expr (gimple_assign_lhs_ptr (*stmt),
+  modify_this_stmt |= sra_modify_expr (gimple_assign_lhs_ptr (stmt),
   gsi, true);
   return modify_this_stmt ? SRA_AM_MODIFIED : SRA_AM_NONE;
 }
@@ -3166,11 +3166,11 @@ sra_modify_assign (gimple *stmt, gimple_stmt_iterator 
*gsi)
   if (!lacc && !racc)
 return SRA_AM_NONE;
 
-  loc = gimple_location (*stmt);
+  loc = gimple_location (stmt);
   if (lacc && lacc->grp_to_be_replaced)
 {
   lhs = get_access_replacement (lacc);
-  gimple_assign_set_lhs (*stmt, lhs);
+  gimple_assign_set_lhs (stmt, lhs);
   modify_this_stmt = true;
   if (lacc->grp_partial_lhs)
force_gimple_rhs = true;
@@ -3206,7 +3206,7 @@ sra_modify_assign (gimple *stmt, gimple_stmt_iterator 
*gsi)
  && !contains_bitfld_component_ref_p (lhs))
{
  lhs = build_ref_for_model (loc, lhs, 0, racc, gsi, false);
- gimple_assign_set_lhs (*stmt, lhs);
+ gimple_assign_set_lhs (stmt, lhs);
}
  else if (AGGREGATE_TYPE_P (TREE_TYPE (rhs))
   && !contains_vce_or_bfcref_p (rhs))
@@ -3238,7 +3238,7 @@ sra_modify_assign (gimple *stmt, gimple_stmt_iterator 
*gsi)
drhs = fold_build1_loc (loc, VIEW_CONVERT_EXPR,
   

Re: [GOMP4, RFC] OpenMP4 offload support for Intel PHI targets.

[Kirill Yukhin]

Hello,
Branch was rebased on trunk.

It contains fixes for several issues in the build system.
Now 'configure' can be called using relative path.

Also some options are now unnecessary, updated manual is posted
on wiki: https://gcc.gnu.org/wiki/Offloading in "How to try offloading enabled 
GCC".

--
Thanks, K

Re: Avoid multiple entry SCC regions

[Jan Hubicka]

> Jan Hubicka  writes:
> >
> > I am lto bootstrapping/regtesting x86_64-linux and intend to comming once it
> > passes.
> 
> You'll have to redo it with hstates, sorry, as it conflicts with my
> patchkit which I checked in earlier.
Hi,
this is vairant of patch I comitted.

Richard Biener 
Jan Hubicka  

* lto-streamer-out.c (struct sccs): Turn to ...
(class DFS): ... this one; refactor the DFS walk so it can
be re-done on per-SCC basis.
(DFS::DFS): New constructor.
(DFS::~DFS): New destructor.
(hash_tree): Add new MAP argument holding in-SCC hash values;
remove POINTER_TYPE hashing hack.
(scc_entry_compare): Rename to ...
(DFS::scc_entry_compare): ... this one.
(hash_scc): Rename to ...
(DFS::hash_scc): ... this one; pass output_block instead
of streamer_cache; work harder to get unique and stable SCC
hashes.
(DFS_write_tree): Rename to ...
(DFS::DFS_write_tree): ... this one; add SINGLE_P parameter.
(lto_output_tree): Update.

Index: lto-streamer-out.c
===
--- lto-streamer-out.c  (revision 213058)
+++ lto-streamer-out.c  (working copy)
@@ -440,36 +440,71 @@ lto_output_tree_1 (struct output_block *
 }
 }
 
-struct sccs
+class DFS
 {
-  unsigned int dfsnum;
-  unsigned int low;
+public:
+  DFS (struct output_block *ob, tree expr, bool ref_p, bool this_ref_p,
+   bool single_p);
+  ~DFS ();
+
+  struct scc_entry
+  {
+tree t;
+hashval_t hash;
+  };
+  vec sccstack;
+
+private:
+  struct sccs
+  {
+unsigned int dfsnum;
+unsigned int low;
+  };
+
+  static int scc_entry_compare (const void *, const void *);
+
+  void DFS_write_tree_body (struct output_block *ob,
+   tree expr, sccs *expr_state, bool ref_p,
+   bool single_p);
+
+  void DFS_write_tree (struct output_block *ob, sccs *from_state,
+  tree expr, bool ref_p, bool this_ref_p,
+  bool single_p);
+  hashval_t
+  hash_scc (struct output_block *ob, unsigned first, unsigned size);
+
+  unsigned int next_dfs_num;
+  struct pointer_map_t *sccstate;
+  struct obstack sccstate_obstack;
 };
 
-struct scc_entry
+DFS::DFS (struct output_block *ob, tree expr, bool ref_p, bool this_ref_p,
+ bool single_p)
 {
-  tree t;
-  hashval_t hash;
-};
+  sccstack.create (0);
+  sccstate = pointer_map_create ();
+  gcc_obstack_init (&sccstate_obstack);
+  next_dfs_num = 1;
+  DFS_write_tree (ob, NULL, expr, ref_p, this_ref_p, single_p);
+}
 
-static unsigned int next_dfs_num;
-static vec sccstack;
-static struct pointer_map_t *sccstate;
-static struct obstack sccstate_obstack;
-
-static void
-DFS_write_tree (struct output_block *ob, sccs *from_state,
-   tree expr, bool ref_p, bool this_ref_p);
+DFS::~DFS ()
+{
+  sccstack.release ();
+  pointer_map_destroy (sccstate);
+  obstack_free (&sccstate_obstack, NULL);
+}
 
 /* Handle the tree EXPR in the DFS walk with SCC state EXPR_STATE and
DFS recurse for all tree edges originating from it.  */
 
-static void
-DFS_write_tree_body (struct output_block *ob,
-tree expr, sccs *expr_state, bool ref_p)
+void
+DFS::DFS_write_tree_body (struct output_block *ob,
+ tree expr, sccs *expr_state, bool ref_p,
+ bool single_p)
 {
 #define DFS_follow_tree_edge(DEST) \
-  DFS_write_tree (ob, expr_state, DEST, ref_p, ref_p)
+  DFS_write_tree (ob, expr_state, DEST, ref_p, ref_p, single_p)
 
   enum tree_code code;
 
@@ -690,18 +725,26 @@ DFS_write_tree_body (struct output_block
 #undef DFS_follow_tree_edge
 }
 
-/* Return a hash value for the tree T.  */
+/* Return a hash value for the tree T.
+   CACHE holds hash values of trees outside current SCC.  MAP, if non-NULL,
+   may hold hash values if trees inside current SCC.  */
 
 static hashval_t
-hash_tree (struct streamer_tree_cache_d *cache, tree t)
+hash_tree (struct streamer_tree_cache_d *cache, hash_map 
*map, tree t)
 {
   inchash hstate;
 
 #define visit(SIBLING) \
   do { \
 unsigned ix; \
-if (SIBLING && streamer_tree_cache_lookup (cache, SIBLING, &ix)) \
+if (!SIBLING) \
+  hstate.add_int (0); \
+else if (streamer_tree_cache_lookup (cache, SIBLING, &ix)) \
   hstate.add_int (streamer_tree_cache_get_hash (cache, ix)); \
+else if (map) \
+  hstate.add_int (*map->get (SIBLING)); \
+else \
+  hstate.add_int (1); \
   } while (0)
 
   /* Hash TS_BASE.  */
@@ -905,23 +948,7 @@ hash_tree (struct streamer_tree_cache_d
 
   if (CODE_CONTAINS_STRUCT (code, TS_TYPED))
 {
-  if (POINTER_TYPE_P (t))
-   {
- /* For pointers factor in the pointed-to type recursively as
-we cannot recurse through only pointers.
-???  We can generalize this by keeping track of the
-in-SCC edges for each tree (or arbitraril

Re: Porting libsanitizer to Solaris

[Joseph S. Myers]

On Fri, 4 Jul 2014, Konstantin Serebryany wrote:

> BTW, I really want to change our current scheme of merging sanitizer
> sources to gcc --
> to use 'svn external' or some such instead of maintaining a copy.

I believe we should avoid all use of systems such as svn externals or git 
submodules, so that it is always the case that ordinary operations such as 
commits, branching, tagging etc. do serve to commit, branch, tag etc. the 
entire source tree in the GCC repository, when done by anyone with write 
access to it and without needing write access to any external repository.

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

Re: [PATCH, NLS] try to search relative dir

[Joseph S. Myers]

On Mon, 7 Jul 2014, Zhenqiang Chen wrote:

> The patch tries to search relative dir "../share/locale" from gcc.
> Although it can not cover all cases, I think it can cover most cases.

That's not how to use make_relative_prefix.  You want e.g. 
make_relative_prefix (argv[0], standard_bindir_prefix, LOCALEDIR).  And 
it's wrong to search the configured directory first; only the relocated 
directory should be used (see PR 17621, fixed in 2006).

Your patch only seems to address the "gcc" driver, not other programs that 
may also use translated messages.  The issue would appear to apply to all 
programs using gcc_init_libintl.  Now, programs such as cc1 aren't run 
from bindir but from libexecsubdir, so you'll need to look at 
GCC_EXEC_PREFIX there rather than using argv[0] and the corresponding 
configure-time bindir.  Look at what incpath.c does to construct a 
suitable argument to make_relative_prefix.

The relevant information for relocation will also need passing to cpplib 
so that its call to bindtextdomain also gets a relocated path.

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

Re: [PATCH] Make sra_modify_assign's stmt prameter gimple (as opposed to gimple *)

[Sebastian Pop]

On Fri, Jul 25, 2014 at 9:50 AM, Martin Jambor  wrote:
> Hi,
>
> parameter stmt of sra_modify_assign and sra_modify_constructor_assign
> is currently gimple*, although there is no need for the extra level of
> indirection and dereferencing.  Thus this patch removes quite few
> stars and one ampersand.

Looks good to me.
Can you please also remove the * from "gimple *stmt_ptr" in
sra_ipa_modify_assign?

Thanks,
Sebastian

>
> Bootstrapped and tested on x86_64-linux, OK for trunk?
>
> Thanks,
>
> Martin
>
>
> 2014-07-25  Martin Jambor  
>
> * tree-sra.c (sra_modify_constructor_assign): Change type of stmt
> parameter to gimple.
> (sra_modify_assign): Likewise.
>
> diff --git a/gcc/tree-sra.c b/gcc/tree-sra.c
> index 7fa6b4f..ba7d159 100644
> --- a/gcc/tree-sra.c
> +++ b/gcc/tree-sra.c
> @@ -3043,9 +3043,9 @@ enum assignment_mod_result { SRA_AM_NONE,   /* 
> nothing done for the stmt */
> the same values as sra_modify_assign.  */
>
>  static enum assignment_mod_result
> -sra_modify_constructor_assign (gimple *stmt, gimple_stmt_iterator *gsi)
> +sra_modify_constructor_assign (gimple stmt, gimple_stmt_iterator *gsi)
>  {
> -  tree lhs = gimple_assign_lhs (*stmt);
> +  tree lhs = gimple_assign_lhs (stmt);
>struct access *acc;
>location_t loc;
>
> @@ -3053,23 +3053,23 @@ sra_modify_constructor_assign (gimple *stmt, 
> gimple_stmt_iterator *gsi)
>if (!acc)
>  return SRA_AM_NONE;
>
> -  if (gimple_clobber_p (*stmt))
> +  if (gimple_clobber_p (stmt))
>  {
>/* Remove clobbers of fully scalarized variables, otherwise
>  do nothing.  */
>if (acc->grp_covered)
> {
> - unlink_stmt_vdef (*stmt);
> + unlink_stmt_vdef (stmt);
>   gsi_remove (gsi, true);
> - release_defs (*stmt);
> + release_defs (stmt);
>   return SRA_AM_REMOVED;
> }
>else
> return SRA_AM_NONE;
>  }
>
> -  loc = gimple_location (*stmt);
> -  if (vec_safe_length (CONSTRUCTOR_ELTS (gimple_assign_rhs1 (*stmt))) > 0)
> +  loc = gimple_location (stmt);
> +  if (vec_safe_length (CONSTRUCTOR_ELTS (gimple_assign_rhs1 (stmt))) > 0)
>  {
>/* I have never seen this code path trigger but if it can happen the
>  following should handle it gracefully.  */
> @@ -3082,9 +3082,9 @@ sra_modify_constructor_assign (gimple *stmt, 
> gimple_stmt_iterator *gsi)
>if (acc->grp_covered)
>  {
>init_subtree_with_zero (acc, gsi, false, loc);
> -  unlink_stmt_vdef (*stmt);
> +  unlink_stmt_vdef (stmt);
>gsi_remove (gsi, true);
> -  release_defs (*stmt);
> +  release_defs (stmt);
>return SRA_AM_REMOVED;
>  }
>else
> @@ -3133,7 +3133,7 @@ contains_vce_or_bfcref_p (const_tree ref)
> copying.  */
>
>  static enum assignment_mod_result
> -sra_modify_assign (gimple *stmt, gimple_stmt_iterator *gsi)
> +sra_modify_assign (gimple stmt, gimple_stmt_iterator *gsi)
>  {
>struct access *lacc, *racc;
>tree lhs, rhs;
> @@ -3142,10 +3142,10 @@ sra_modify_assign (gimple *stmt, gimple_stmt_iterator 
> *gsi)
>location_t loc;
>gimple_stmt_iterator orig_gsi = *gsi;
>
> -  if (!gimple_assign_single_p (*stmt))
> +  if (!gimple_assign_single_p (stmt))
>  return SRA_AM_NONE;
> -  lhs = gimple_assign_lhs (*stmt);
> -  rhs = gimple_assign_rhs1 (*stmt);
> +  lhs = gimple_assign_lhs (stmt);
> +  rhs = gimple_assign_rhs1 (stmt);
>
>if (TREE_CODE (rhs) == CONSTRUCTOR)
>  return sra_modify_constructor_assign (stmt, gsi);
> @@ -3154,9 +3154,9 @@ sra_modify_assign (gimple *stmt, gimple_stmt_iterator 
> *gsi)
>|| TREE_CODE (rhs) == IMAGPART_EXPR || TREE_CODE (lhs) == IMAGPART_EXPR
>|| TREE_CODE (rhs) == BIT_FIELD_REF || TREE_CODE (lhs) == 
> BIT_FIELD_REF)
>  {
> -  modify_this_stmt = sra_modify_expr (gimple_assign_rhs1_ptr (*stmt),
> +  modify_this_stmt = sra_modify_expr (gimple_assign_rhs1_ptr (stmt),
>   gsi, false);
> -  modify_this_stmt |= sra_modify_expr (gimple_assign_lhs_ptr (*stmt),
> +  modify_this_stmt |= sra_modify_expr (gimple_assign_lhs_ptr (stmt),
>gsi, true);
>return modify_this_stmt ? SRA_AM_MODIFIED : SRA_AM_NONE;
>  }
> @@ -3166,11 +3166,11 @@ sra_modify_assign (gimple *stmt, gimple_stmt_iterator 
> *gsi)
>if (!lacc && !racc)
>  return SRA_AM_NONE;
>
> -  loc = gimple_location (*stmt);
> +  loc = gimple_location (stmt);
>if (lacc && lacc->grp_to_be_replaced)
>  {
>lhs = get_access_replacement (lacc);
> -  gimple_assign_set_lhs (*stmt, lhs);
> +  gimple_assign_set_lhs (stmt, lhs);
>modify_this_stmt = true;
>if (lacc->grp_partial_lhs)
> force_gimple_rhs = true;
> @@ -3206,7 +3206,7 @@ sra_modify_assign (gimple *stmt, gimple_stmt_iterator 
> *gsi)
>   && !contains_bitfld_component_ref_p (lhs))
> {
>   lhs = build_ref_for_m

[Patch, Fortran] Fix integer kind returned by storage_size (was: Re: incorrect integer kind returned from call to storage_size() with gcc 4.9.0)

[Tobias Burnus]

Hi,

N.M. Maclaren wrote:

On Jul 25 2014, Rezny, Mike wrote:


I am seeing the following problems in using the Fortran intrinsic 
function, storage_size(), in gfortran version 4.9.0. 1: A calls to 
this function is returning a 64-bit integer instead of a default 
32-bit integer 2: the routine is not honouring the second parameter 
to the call which specifies the kind of the returned value. In all 
valid cases, the returned value is a 64-bit integer.


The key property is the KIND of the result - if THAT is not KIND(0),
then there is a bug.


I can confirm the problem. It only occurs when the compiler can simplify 
the intrinsic function call at compile time (what it usually can for 
storage_size). Thus, if one passes a polymorphic argument, the KIND 
value is properly handled. By the way, the used kind is "c_ptrdiff_t" 
from the intrinsic module ISO_C_Binding.


In case a work around is needed, use "int(storage_size(...), kind=...)". 
However, in case you pass the value on to some run-time library, you 
should consider using "integer(c_ptrdiff_t)" [TS 29113] or 
"integer(c_size_t)" [F2003] instead. In general, it makes sense to 
handle as large storage_sizes as the system permits. (ptrdiff_t is 
signed, which matches what Fortran uses as only signed integers are 
supported; size_t is unsigned but of the same storage size; as 
"c_size_t" is already in Fortran 2003 many more compilers support it 
than "c_ptrdiff_t".)



The problem is fixed by the attached patch. I will commit it as obvious 
(to the trunk, i.e. GCC 5 alias GCC 4.10 only) once building and 
regtesting has finished.


Thanks for reporting the bug – and sorry for the inconvenience.

Tobias
2014-07-25  Tobias Burnus  

	* simplify.c (gfc_simplify_storage_size): Use proper
	integer kind for the returned value.

2014-07-25  Tobias Burnus  

	* gfortran.dg/storage_size_5.f90: New.

diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c
index 60d8593..d4a67ad 100644
--- a/gcc/fortran/simplify.c
+++ b/gcc/fortran/simplify.c
@@ -5841,11 +5841,9 @@ gfc_simplify_storage_size (gfc_expr *x,
   if (k == -1)
 return &gfc_bad_expr;
 
-  result = gfc_get_constant_expr (BT_INTEGER, gfc_index_integer_kind,
-  &x->where);
+  result = gfc_get_constant_expr (BT_INTEGER, k, &x->where);
 
   mpz_set_si (result->value.integer, gfc_element_size (x));
-
   mpz_mul_ui (result->value.integer, result->value.integer, BITS_PER_UNIT);
 
   return range_check (result, "STORAGE_SIZE");
diff --git a/gcc/testsuite/gfortran.dg/storage_size_5.f90 b/gcc/testsuite/gfortran.dg/storage_size_5.f90
new file mode 100644
index 000..ae0f126
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/storage_size_5.f90
@@ -0,0 +1,44 @@
+! { dg-do compile }
+! { dg-options "-fdump-tree-original" }
+!
+subroutine test()
+  implicit none
+  integer :: i0, i1, i2, i3, i4
+  i0 = kind(STORAGE_SIZE(5))
+  i1 = kind(STORAGE_SIZE(5, kind=1))
+  i2 = kind(STORAGE_SIZE(5, kind=2))
+  i3 = kind(STORAGE_SIZE(5, kind=4))
+  i4 = kind(STORAGE_SIZE(5, kind=8))
+end subroutine test
+
+subroutine test2(x)
+  implicit none
+  class(*) :: x
+  integer :: j0, j1, j2, j3, j4
+  integer(1) :: k1
+  integer(2) :: k2
+  j0 = kind(STORAGE_SIZE(x))
+  j1 = kind(STORAGE_SIZE(x, kind=1))
+  j2 = kind(STORAGE_SIZE(x, kind=2))
+  j3 = kind(STORAGE_SIZE(x, kind=4))
+  j4 = kind(STORAGE_SIZE(x, kind=8))
+
+  k1 = STORAGE_SIZE(x, kind=1)
+  k2 = STORAGE_SIZE(x, kind=2)
+end subroutine test2
+
+! { dg-final { scan-tree-dump-times "i0 = 4;" 1 "original" } }
+! { dg-final { scan-tree-dump-times "i1 = 1;" 1 "original" } }
+! { dg-final { scan-tree-dump-times "i2 = 2;" 1 "original" } }
+! { dg-final { scan-tree-dump-times "i3 = 4;" 1 "original" } }
+! { dg-final { scan-tree-dump-times "i4 = 8;" 1 "original" } }
+! { dg-final { scan-tree-dump-times "j0 = 4;" 1 "original" } }
+
+! { dg-final { scan-tree-dump-times "j1 = 1;" 1 "original" } }
+! { dg-final { scan-tree-dump-times "j2 = 2;" 1 "original" } }
+! { dg-final { scan-tree-dump-times "j3 = 4;" 1 "original" } }
+! { dg-final { scan-tree-dump-times "j4 = 8;" 1 "original" } }
+
+! { dg-final { scan-tree-dump-times "k1 = \\(integer\\(kind=1\\)\\)" 1 "original" } }
+! { dg-final { scan-tree-dump-times "k2 = \\(integer\\(kind=2\\)\\)" 1 "original" } }
+! { dg-final { cleanup-tree-dump "original" } }

Re: [Patch, Fortran] Fix integer kind returned by storage_size

[Tobias Burnus]

Tobias Burnus wrote:
The problem is fixed by the attached patch. I will commit it as 
obvious (to the trunk, i.e. GCC 5 alias GCC 4.10 only) once building 
and regtesting has finished.


As I only saw later in Steve's email, it is a regression. Thus, I will 
also apply it to the GCC 4.9 branch (will be in GCC 4.9.2; Linux distros 
likely pick it up earlier).


The regression was caused by my commit r197159 for PRs 56650 and 36437, 
which added compile-time simplification for storage_size, c_sizeof and 
sizeof. (The latter are not affected as they are supposed to return a 
value of kind c_size_t and take no kind parameters.)


Tobias

Re: [PATCH, rs6000] Fix many powerpc*-linux ASAN test suite failures

[Peter Bergner]

On Wed, 2014-07-23 at 15:06 -0500, Peter Bergner wrote:
> On Wed, 2014-07-16 at 11:23 +0200, Jakub Jelinek wrote: 
> > On Wed, Jul 16, 2014 at 05:18:06AM -0400, David Edelsohn wrote:
> > > This seems weird. Why wasn't this file included before or whenever it
> > > was added for other *-linux targets?  This seems to define SPECs that
> > > should have been necessary before now.
> > 
> > All other Linux targets where asan is supported got the right definitions
> > from gnu-user.h, it was needed even on the older release branches.
> 
> Ok, I compiled a source file that #includes tm.h and looked at the -dD -E
> output to see what macros get defined with and without this change.
> There are a few macros the gnu-user.h defines that are identical to what
> some of the rs6000/sysv4.h or rs6000/linux{,64}.h header files define, so
> we could remove those.  There are some that are different too, so we'd
> need to keep those.  The following are the macros that are identical:

FYI, here is the mainline patch that removes the redundant macro defines
in rs6000/linux.h and rs6000/linux64.h.  This also passed bootstrap and
regtesting with no regressions.


Peter


* config.gcc (powerpc*-*-linux*): Include gnu-user.h in tm_file.
* config/rs6000/sysv4.h (CC!_SPEC): Undefine it before defining it.
* config/rs6000/linux.h (CPLUSPLUS_CPP_SPEC): Delete define.
(LINK_GCC_C_SEQUENCE_SPEC): Likewise.
(USE_LD_AS_NEEDED): Likewise.
(ASM_APP_ON): Likewise.
(ASM_APP_OFF): Likewise.
(TARGET_POSIX_IO): Likewise.
* config/rs6000/linux64.h (CPLUSPLUS_CPP_SPEC): Likewise.
(LINK_GCC_C_SEQUENCE_SPEC): Likewise.
(USE_LD_AS_NEEDED): Likewise.
(ASM_APP_ON): Likewise.
(ASM_APP_OFF): Likewise.
(TARGET_POSIX_IO): Likewise.

Index: gcc/config.gcc
===
--- gcc/config.gcc  (revision 212572)
+++ gcc/config.gcc  (working copy)
@@ -2243,7 +2243,7 @@ powerpc-*-rtems*)
tmake_file="${tmake_file} rs6000/t-fprules rs6000/t-rtems 
rs6000/t-ppccomm"
;;
 powerpc*-*-linux*)
-   tm_file="${tm_file} dbxelf.h elfos.h freebsd-spec.h rs6000/sysv4.h"
+   tm_file="${tm_file} dbxelf.h elfos.h gnu-user.h freebsd-spec.h 
rs6000/sysv4.h"
extra_options="${extra_options} rs6000/sysv4.opt"
tmake_file="rs6000/t-fprules rs6000/t-ppcos ${tmake_file} 
rs6000/t-ppccomm"
extra_objs="$extra_objs rs6000-linux.o"
Index: gcc/config/rs6000/sysv4.h
===
--- gcc/config/rs6000/sysv4.h   (revision 212572)
+++ gcc/config/rs6000/sysv4.h   (working copy)
@@ -539,6 +539,7 @@ ENDIAN_SELECT(" -mbig", " -mlittle", DEF
 #endif
 
 /* Pass -G xxx to the compiler.  */
+#undef CC1_SPEC
 #defineCC1_SPEC "%{G*} %(cc1_cpu)" \
 "%{meabi: %{!mcall-*: -mcall-sysv }} \
 %{!meabi: %{!mno-eabi: \
Index: gcc/config/rs6000/linux.h
===
--- gcc/config/rs6000/linux.h   (revision 212572)
+++ gcc/config/rs6000/linux.h   (working copy)
@@ -56,12 +56,6 @@
 #undef CPP_OS_DEFAULT_SPEC
 #define CPP_OS_DEFAULT_SPEC "%(cpp_os_linux)"
 
-/* The GNU C++ standard library currently requires _GNU_SOURCE being
-   defined on glibc-based systems. This temporary hack accomplishes this,
-   it should go away as soon as libstdc++-v3 has a real fix.  */
-#undef  CPLUSPLUS_CPP_SPEC
-#define CPLUSPLUS_CPP_SPEC "-D_GNU_SOURCE %(cpp)"
-
 #undef  LINK_SHLIB_SPEC
 #define LINK_SHLIB_SPEC "%{shared:-shared} %{!shared: %{static:-static}}"
 
@@ -98,22 +92,6 @@
   %{rdynamic:-export-dynamic} \
   -dynamic-linker " GNU_USER_DYNAMIC_LINKER "}}"
 
-#define LINK_GCC_C_SEQUENCE_SPEC \
-  "%{static:--start-group} %G %L %{static:--end-group}%{!static:%G}"
-
-/* Use --as-needed -lgcc_s for eh support.  */
-#ifdef HAVE_LD_AS_NEEDED
-#define USE_LD_AS_NEEDED 1
-#endif
-
-/* Override rs6000.h definition.  */
-#undef  ASM_APP_ON
-#define ASM_APP_ON "#APP\n"
-
-/* Override rs6000.h definition.  */
-#undef  ASM_APP_OFF
-#define ASM_APP_OFF "#NO_APP\n"
-
 /* For backward compatibility, we must continue to use the AIX
structure return convention.  */
 #undef  DRAFT_V4_STRUCT_RET
@@ -129,8 +107,6 @@
 #define RELOCATABLE_NEEDS_FIXUP \
   (rs6000_isa_flags & rs6000_isa_flags_explicit & OPTION_MASK_RELOCATABLE)
 
-#define TARGET_POSIX_IO
-
 #ifdef TARGET_LIBC_PROVIDES_SSP
 /* ppc32 glibc provides __stack_chk_guard in -0x7008(2).  */
 #define TARGET_THREAD_SSP_OFFSET   -0x7008
Index: gcc/config/rs6000/linux64.h
===
--- gcc/config/rs6000/linux64.h (revision 212572)
+++ gcc/config/rs6000/linux64.h (working copy)
@@ -343,12 +343,6 @@ extern int dot_symbols;
 #undef  CPP_OS_DEFAULT_SPEC
 #define CPP_OS_DEFAULT_SPEC "%(cpp_os_linux)"
 
-/* The GNU C++ standard library currently requires _GNU_SOURCE being
-   defined on glibc-based systems. T

[PATCH libstdc++ v3] - Add xmethods for std::vector and std::unique_ptr

[Siva Chandra]

The attached patch is identical to v2 except that I rebased it over
the current head.

To recollect, GDB now supports xmethods in its Python API:
https://sourceware.org/gdb/current/onlinedocs/gdb/Xmethods-In-Python.html

This feature will be available in GDB starting version 7.8 (which has
not yet been released, but has been branched). The attached patch adds
xmethods to the classes std::vector and std::unique_ptr. One can of
course add xmethods to many other classes, but I am viewing this as
the first patch in that series (though not a series yet) to get the
basic infrastructure for adding more xmethods in place.

Link to v1 posting: https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02339.html
Link to v2 posting: https://gcc.gnu.org/ml/gcc-patches/2014-07/msg2.html

ChangeLog

2014-07-25  Siva Chandra Reddy  

* python/libstdcxx/v6/xmethods.py: New file.
* testsuite/lib/gdb-test.exp (gdb_version_check_xmethods): New
function.
(gdb-test): New optional argument LOAD_XMETHODS.  Load xmethods
python script if LOAD_XMETHODS is true.
* testsuite/libstdc++-xmethods/unique_ptr.cc: New file.
* testsuite/libstdc++-xmethods/vector.cc: New file.
* testsuite/libstdc++-xmethods/xmethods.exp: New file.
diff --git a/libstdc++-v3/python/libstdcxx/v6/xmethods.py 
b/libstdc++-v3/python/libstdcxx/v6/xmethods.py
new file mode 100644
index 000..f20f411
--- /dev/null
+++ b/libstdc++-v3/python/libstdcxx/v6/xmethods.py
@@ -0,0 +1,103 @@
+# Xmethods for libstc++.
+
+# Copyright (C) 2014 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see .
+
+import gdb
+import gdb.xmethod
+import re
+
+matcher_name_prefix = 'libstdc++::'
+
+# Xmethods for std::vector
+
+class VectorSizeWorker(gdb.xmethod.XMethodWorker):
+def __init__(self):
+self.name = 'size'
+self.enabled = True
+
+def get_arg_types(self):
+return None
+
+def __call__(self, obj):
+return obj['_M_impl']['_M_finish'] - obj['_M_impl']['_M_start']
+
+class VectorSubscriptWorker(gdb.xmethod.XMethodWorker):
+def __init__(self):
+self.name = 'operator[]'
+self.enabled = True
+
+def get_arg_types(self):
+return gdb.lookup_type('std::size_t')
+
+def __call__(self, obj, subscript):
+return obj['_M_impl']['_M_start'][subscript]
+
+class VectorMethodsMatcher(gdb.xmethod.XMethodMatcher):
+def __init__(self):
+gdb.xmethod.XMethodMatcher.__init__(self,
+matcher_name_prefix + 'vector')
+self._subscript_worker = VectorSubscriptWorker()
+self._size_worker = VectorSizeWorker()
+self.methods = [self._subscript_worker, self._size_worker]
+
+def match(self, class_type, method_name):
+if not re.match('^std::vector<.*>$', class_type.tag):
+return None
+if method_name == 'operator[]' and self._subscript_worker.enabled:
+return self._subscript_worker
+elif method_name == 'size' and self._size_worker.enabled:
+return self._size_worker
+
+# Xmethods for std::unique_ptr
+
+class UniquePtrGetWorker(gdb.xmethod.XMethodWorker):
+def __init__(self):
+self.name = 'get'
+self.enabled = True
+
+def get_arg_types(self):
+return None
+
+def __call__(self, obj):
+return obj['_M_t']['_M_head_impl']
+
+class UniquePtrDerefWorker(UniquePtrGetWorker):
+def __init__(self):
+UniquePtrGetWorker.__init__(self)
+self.name = 'operator*'
+
+def __call__(self, obj):
+return UniquePtrGetWorker.__call__(self, obj).dereference()
+
+class UniquePtrMethodsMatcher(gdb.xmethod.XMethodMatcher):
+def __init__(self):
+gdb.xmethod.XMethodMatcher.__init__(self,
+matcher_name_prefix + 'unique_ptr')
+self._get_worker = UniquePtrGetWorker()
+self._deref_worker = UniquePtrDerefWorker()
+self.methods = [self._get_worker, self._deref_worker]
+
+def match(self, class_type, method_name):
+if not re.match('^std::unique_ptr<.*>$', class_type.tag):
+return None
+if method_name == 'operator*' and self._deref_worker.enabled:
+return self._deref_worker
+elif method_name == 'get' and self._get_worker.enabled:
+return self._get_work

Re: RFA: Add a common tls_referenced_p function

[Jeff Law]

On 07/24/14 09:44, Richard Sandiford wrote:

Three targets had the same for_each_rtx function to check for a TLS symbol.
This patch adds a generic version instead.

Some other targets have a variation that checks for target-specific
UNSPEC sequences too so I've left those alone.  They're all prefixed
by the target name so there's no name clash or ambiguity.

Tested on mips64-linux-gnu and via a cross-compiler for
powerpc64-linux-gnu and hppa64-hp-hpux11.23.  OK to install?

Thanks,
Richard


gcc/
* rtl.h (tls_referenced_p): Declare.
* rtlanal.c (tls_referenced_p_1, tls_referenced_p): New functions.
* config/mips/mips.c (mips_tls_symbol_ref_1): Delete.
(mips_cannot_force_const_mem): Use tls_referenced_p.
* config/pa/pa-protos.h (pa_tls_referenced_p): Delete.
* config/pa/pa.h (CONSTANT_ADDRESS_P): Use tls_referenced_p
instead of pa_tls_referenced_p.
* config/pa/pa.c (hppa_legitimize_address, pa_cannot_force_const_mem)
(pa_emit_move_sequence, pa_emit_move_sequence): Likewise.
(pa_legitimate_constant_p): Likewise.
(pa_tls_symbol_ref_1, pa_tls_referenced_p): Delete.
* config/rs6000/rs6000.c (rs6000_tls_referenced_p): Delete.
(rs6000_cannot_force_const_mem, rs6000_emit_move)
(rs6000_address_for_altivec): Use tls_referenced_p instead of
rs6000_tls_referenced_p.
(rs6000_tls_symbol_ref_1): Delete.

OK.
Jeff

Re: [PATCH] -fsanitize=alignment support

[Jason Merrill]

On 07/04/2014 04:47 PM, Jakub Jelinek wrote:

(ubsan_expand_null_ifn): ...take type from ckind argument's type rather 
than
first argument.


Why?  It looks like they have the same type with your patch, and then 
you need to convert ckind back to unsigned char.


Jason

Re: [texi2pod.pl] Handle command @t and embedded form @dfn{@sc{}}

[Joseph S. Myers]

On Wed, 9 Jul 2014, Mingjie Xing wrote:

> 2014-07-09  Mingjie Xing  
> 
> * texi2pod.pl (postprocess): Move command process for '@sc' to the
> front of '@dfn'.  Add a new command process for '@t{...}', just print
> the content.

OK.

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

Re: [patch] No allocation for empty unordered containers

[François Dumont]

Hi

I think I never get feedback regarding this patch proposal. Note 
that if accepted the doc will have to be updated regarding the default 
hint value.


Thanks


On 03/06/2014 22:44, François Dumont wrote:

Hi

Thanks to the single bucket introduced to make move semantic 
noexcept we can also avoid some over allocations. Here is a patch to 
avoid any allocation on default instantiation, on range constructor 
when range is empty and on construction from an initialization list 
when this list is empty too. I had to make all default hint value to 0 
so that if this value is used the rehash policy next bucket returns 1 
bucket.


I don't know if you had in mind to noexcept qualify the default 
constructor but it would mean to have a real default constructor and 
another to deal with the hint which wouldn't match the Standard so no 
noexcept qualification at the moment.


Tested under Linux x86_64.normal debug and profile modes.


2014-06-03  François Dumont 

* include/bits/hashtable.h: Make use of the internal single bucket to
limit allocation as long as container remains empty.
* include/bits/unordered_map.h: Set default bucket hint to 0 in
constructors to avoid allocation.
* include/bits/unordered_set.h: Likewise.
* include/debug/unordered_map: Likewise.
* include/debug/unordered_set: Likewise.
* include/profile/unordered_map: Likewise.
* include/profile/unordered_set: Likewise.
* src/c++11/hashtable_c++0x.cc (_Prime_rehash_policy::_M_next_bkt):
Returns 1 for hint 0.
* testsuite/23_containers/unordered_map/allocator/
empty_instantiation.cc:New.
* testsuite/23_containers/unordered_multimap/allocator/
empty_instantiation.cc:New.
* testsuite/23_containers/unordered_set/allocator/
empty_instantiation.cc: New.
* testsuite/23_containers/unordered_multiset/allocator/
empty_instantiation.cc: New.

Ok to commit ?

François




Index: include/bits/hashtable.h
===
--- include/bits/hashtable.h	(revision 211144)
+++ include/bits/hashtable.h	(working copy)
@@ -407,12 +407,12 @@
   // Use delegating constructors.
   explicit
   _Hashtable(const allocator_type& __a)
-  : _Hashtable(10, _H1(), _H2(), _Hash(), key_equal(),
+  : _Hashtable(0, _H1(), _H2(), _Hash(), key_equal(),
 		   __key_extract(), __a)
   { }
 
   explicit
-  _Hashtable(size_type __n = 10,
+  _Hashtable(size_type __n = 0,
 		 const _H1& __hf = _H1(),
 		 const key_equal& __eql = key_equal(),
 		 const allocator_type& __a = allocator_type())
@@ -792,14 +792,18 @@
 	   const _Equal& __eq, const _ExtractKey& __exk,
 	   const allocator_type& __a)
 : __hashtable_base(__exk, __h1, __h2, __h, __eq),
-  __map_base(),
-  __rehash_base(),
   __hashtable_alloc(__node_alloc_type(__a)),
+  _M_buckets(&_M_single_bucket),
+  _M_bucket_count(1),
   _M_element_count(0),
-  _M_rehash_policy()
+  _M_single_bucket(nullptr)
 {
-  _M_bucket_count = _M_rehash_policy._M_next_bkt(__bucket_hint);
-  _M_buckets = _M_allocate_buckets(_M_bucket_count);
+  auto __bkt_count = _M_rehash_policy._M_next_bkt(__bucket_hint);
+  if (_M_bucket_count != __bkt_count)
+	{
+	  _M_bucket_count = __bkt_count;
+	  _M_buckets = _M_allocate_buckets(_M_bucket_count);
+	}
 }
 
   template_M_deallocate_nodes(_M_begin());
-		_M_before_begin._M_nxt = nullptr;
 		_M_deallocate_buckets();
-		_M_buckets = nullptr;
+		__hashtable_base::operator=(__ht);
 		std::__alloc_on_copy(__this_alloc, __that_alloc);
-		__hashtable_base::operator=(__ht);
-		_M_bucket_count = __ht._M_bucket_count;
+		_M_buckets = &_M_single_bucket;
+		_M_bucket_count = 1;
+		_M_before_begin._M_nxt = nullptr;
 		_M_element_count = __ht._M_element_count;
 		_M_rehash_policy = __ht._M_rehash_policy;
+		_M_single_bucket = nullptr;
 		__try
 		  {
 		_M_assign(__ht,
@@ -946,8 +956,14 @@
   _M_assign(const _Hashtable& __ht, const _NodeGenerator& __node_gen)
   {
 	__bucket_type* __buckets = nullptr;
-	if (!_M_buckets)
-	  _M_buckets = __buckets = _M_allocate_buckets(_M_bucket_count);
+	if (_M_bucket_count != __ht._M_bucket_count)
+	  {
+	// Bucket deallocation useless because per design _M_buckets
+	// can only be pointing to _M_single_bucket.
+	//_M_deallocate_buckets();
+	_M_bucket_count = __ht._M_bucket_count;
+	_M_buckets = __buckets = _M_allocate_buckets(_M_bucket_count);
+	  }
 
 	__try
 	  {
@@ -1101,10 +1117,11 @@
   __rehash_base(__ht),
   __hashtable_alloc(
 	__node_alloc_traits::_S_select_on_copy(__ht._M_node_allocator())),
-  _M_buckets(),
-  _M_bucket_count(__ht._M_bucket_count),
+  _M_buckets(&_M_single_bucket),
+  _M_bucket_count(1),
   _M_element_count(__ht._M_element_count),
-  _M_rehash_policy(__ht._M_rehash_policy)
+  _M_rehash_policy(__ht._M_rehash_policy),
+  _M_single_bucket(nullptr)
 {

Re: Does anyone use Ada on Alpha?

[Paolo Bonzini]

Il 24/07/2014 19:32, Uros Bizjak ha scritto:
> Hello!
> 
>> Well, I was lucky enough to gain access to an alpha pca56 for a day (I say
>> lucky, this may not be repeatable!). However I was not able to build the Ada
>>
>> frontend, due (AFAICT) to the image being too big for relocations. 
>> (Moreover, my understanding is > that the default memory model for Alpha, is 
>> the largest memory model.) I used pristine 4.9.1
>> sources, host compiler
> 
> You will need attached patch.

Ok for mainline with a ChangeLog.  Why not. :)

Paolo

Re: [PATCH] gcc/toplev.c: Avoid to close 'asm_out_file' when it is 'stdout'

[Jeff Law]

On 07/23/14 16:17, Chen Gang wrote:

On 07/23/2014 11:44 AM, Jeff Law wrote:

On 07/21/14 09:47, Chen Gang wrote:

'asm_out_file' may be 'stdout', so need check this case before close it.
Or 'stdout' may be closed -- since need not open 'stdout', either need
not close it.

ChangLog:

* topleve.c (finalize): Avoid to close 'asm_out_file' when it is
'stdout'.

What exactly is the problem with closing stdout at this point?  In general, you 
need to state the problem you're trying to fix with your patch.



Excuse me, I only find it by reading source code, so for me, I didn't
meet the real problem for it, so at least, this patch is not urgent (
although I am not sure whether it is still valuable or not).
OK.  I suspected it might be the case that you just saw something odd 
and sent a patch to change it.


But that was just a suspicion -- there well could have been some path 
you found where GCC wanted to write to stdout after the point where we 
closed the output file.  That would clearly be a bug and warrant fixing 
immediately.


Either way it's important you tell us why you're making a change in a 
way which allows us to evaluate the importance of the change.  Otherwise 
we have to guess and we could easily guess wrong.


In this specific instance, I don't really see any value in avoiding the 
close of stdout.




At present, I am a newbie, and use 2 ways to learn gcc and binutils.

  - Cross compile the cross compiler with '-W' for linux kernel.
(If find issues, I shall try to fix them with related members).

  - Reading source code of gcc and binutils, if find some where can be
improved, and try to send patch for it.
And these are excellent ways to get started.  Another would be to build 
GCC with Clang/LLVM and see what warnings that generates and try to fix 
them.  Perusing the bug database (gcc.gnu.org/bugzilla) can sometimes 
result in identifying issues you can resolve.






By the way, is there a trivial patch mailing list of gcc? I guess most
of my patches belong to trivial.

No, all patches go to gcc-patches, even trivial ones.

Thanks,
jeff

Re: [PATCH] Fix -imacros (PR c/57653)

[Jeff Law]

On 07/23/14 11:49, Marek Polacek wrote:

On Thu, Jul 17, 2014 at 02:40:27AM -0600, Jeff Law wrote:

I was really hoping someone could add tests from the old (2004?) thread
between DJ and Per to ensure we weren't regressing any of those cases while
fixing 57653.  In fact, I think I'd pre-approved with those tests added ;-)


All I could find was a test (mentioned twice by DJ) that was crashing with
-imacros and an empty .h and .c file.  I added it in the following.
I'm keeping the test I already had in the previous patch, because it
tests something that is fixed with this patch.

Bootstrapped/regtested on x86_64-linux, applying to trunk.

2014-07-23  Marek Polacek  

PR c/57653
* c-opts.c (c_finish_options): If -imacros is in effect, return.

* c-c++-common/pr57653.c: New test.
* c-c++-common/pr57653.h: New file.
* c-c++-common/pr57653-2.c: New test.
* c-c++-common/pr57653-2.h: New file.

Perfect.  Thanks for picking up the ball on this one.


Jeff

Re: [libcpp PATCH] Fix up location of builtin macros (PR c/61861)

[Jeff Law]

On 07/23/14 07:15, Marek Polacek wrote:

Bultin macros like __FILE__, __DATE__, etc. had wrong locus - always
column 1.  This patch fixes it by giving those macros location
of the expansion point, i.e, the location, where builtin macro is used.
It now also does the correct thing if we do e.g.
#define F __FILE__.

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

2014-07-23  Marek Polacek  

PR c/61861
* macro.c (builtin_macro): Add location parameter.  Set
location of builtin macro to the expansion point.
(enter_macro_context): Pass location to builtin_macro.

* gcc.dg/pr61861.c: New test.

This is fine for the trunk.

Thanks,
jeff

Re: [PATCH] -fsanitize=alignment support

[Jakub Jelinek]

On Fri, Jul 25, 2014 at 04:41:08PM -0400, Jason Merrill wrote:
> On 07/04/2014 04:47 PM, Jakub Jelinek wrote:
> > (ubsan_expand_null_ifn): ...take type from ckind argument's type rather 
> > than
> > first argument.
> 
> Why?  It looks like they have the same type with your patch, and then you
> need to convert ckind back to unsigned char.

Because right now (almost?) all type conversions are useless, therefore
the middle-end happily replaces e.g.
// _11 has void * type
_12 = (int *) _11;
UBSAN_NULL (_12, ...);
with
UBSAN_NULL (_11, ...);
and the type will be lost there.  If the type is put on a constant (it is
the same thing as e.g. MEM_REF puts the pointer type on the offset
constant), then nothing will change it.

Jakub

Re: [PATCH][sched-deps] Generalise usage of macro fusion to work on any two insns

[Jeff Law]

On 07/24/14 03:11, Kyrill Tkachov wrote:

Ping.
https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00958.html

Kyrill

On 14/07/14 11:01, Kyrill Tkachov wrote:

On 11/07/14 14:20, Alexander Monakov wrote:

On Fri, 11 Jul 2014, Kyrill Tkachov wrote:

On 10/07/14 22:53, Maxim Kuvyrkov wrote:

The patch looks good to me, but some cleanup suggestions below.

Thanks, here's an updated patch.
How's this?

You need to remove 'if (targetm. ...) SCHED_GROUP_P (insn) = 1;' from
the
first if branch, keeping only one SCHED_GROUP_P assignment at the end
of the
function.

Alexander

Thanks for the pointer, I had hurried a bit.
Here is the updated patch.

Kyrill

2014-07-14  Ramana Radhakrishnan 
  Kyrylo Tkachov  

  * sched-deps.c (try_group_insn): Generalise macro fusion hook usage
  to any two insns.  Update comment.  Rename to
sched_macro_fuse_insns.
  (sched_analyze_insn): Update use of try_group_insn to
  sched_macro_fuse_insns.
  * config/i386/i386.c (ix86_macro_fusion_pair_p): Reject 2nd
arguments
  that are not conditional jumps.

This is fine.  Thanks for your patience.

jeff

Re: Patch for constexpr variable templates

[Jason Merrill]

On 07/25/2014 07:43 AM, Braden Obrzut wrote:

This patch only covers constexpr variable templates, so it makes sense
to produce an error for now.


Fair enough, but in that case let's use 'sorry' rather then 'error' to 
be clear that it's a missing feature.


I ran the testsuite with your patch applied and got a bunch of failures. 
 For instance,


+FAIL: g++.old-deja/g++.other/anon2.C  -std=c++11 (internal compiler error)

is crashing here:


+ || TREE_CODE (orig_declarator) == TEMPLATE_ID_EXPR))


because orig_declarator is null.  Please fix this and the other failures.


+ "Variable templates only available with "


Diagnostics aren't capitalized.


  gcc_assert (decl == error_mark_node
+ || variable_template_p (tmpl)
  || !(DECL_CONSTRUCTOR_P (decl)


Indentation mismatch.


   DECL_EXTERNAL (d) = 0;

-  /* Enter the scope of D so that access-checking works correctly.  */
-  push_nested_class (DECL_CONTEXT (d));
+ /* Enter the scope of D so that access-checking works correctly.  */
+ bool enter_context = DECL_CLASS_SCOPE_P (d);


Indentation mismatch.

Jason

Re: [PATCH][RFC] Fix part of -ftrapv (PR52478)

[Jeff Law]

On 07/24/14 03:35, Richard Biener wrote:


The following fixes one of the most annoying parts of non-working -ftrapv,
namely that we only support >= word_mode trappings (quite annoying on
64bit archs where 'int' is not handled).  At least on x86_64 libgcc
has all the libfuncs available for SImode so the following patch
arranges for them to be used.  RFC because I don't know whether
they are there by accident... (and thus the patch adds a requirement
that is not met by other targets - but a link error is better than
-ftrapv failure?)

The testcase relies on fork() to be able to capture both inline
and out-of-line trapv sequences.  dg-require-fork is unused but
present, so I use it.  I suppose we can restrict the testcase
to a few targets manually as well - not sure, any preferences?

At least the obvious testcase from PR52478 now works (until
you hit constant folding ... see PR61893 I just opened).

Bootstrap and regtest running on x86_64-unknown-linux-gnu, ok
for trunk?

Thanks,
Richard.


2014-07-24  Richard Biener  

PR middle-end/52478
* optabs.c (gen_int_libfunc): For -ftrapv libfuncs make
sure to register SImode ones, not only >= word_mode ones.
* expr.c (expand_expr_real_2): When expanding -ftrapv
binops do not use OPTAB_LIB_WIDEN.

* gcc.dg/torture/ftrapv-1.c: New testcase.
I'm certainly comfortable requiring more bits in libgcc (which are often 
going to be there anyway) to get -ftrapv to work.


I'd be a little worried the testcase won't work on simulated targets. 
Perhaps limit it to native only?  I'd consider this is relatively minor 
issue and not enough to hold up the patch.


jeff

Re: [PATCH] -fsanitize=alignment support

[Jason Merrill]

On 07/25/2014 05:21 PM, Jakub Jelinek wrote:

On Fri, Jul 25, 2014 at 04:41:08PM -0400, Jason Merrill wrote:

On 07/04/2014 04:47 PM, Jakub Jelinek wrote:

(ubsan_expand_null_ifn): ...take type from ckind argument's type rather 
than
first argument.


Why?  It looks like they have the same type with your patch, and then you
need to convert ckind back to unsigned char.


Because right now (almost?) all type conversions are useless, therefore
the middle-end happily replaces e.g.
// _11 has void * type
_12 = (int *) _11;
UBSAN_NULL (_12, ...);
with
UBSAN_NULL (_11, ...);
and the type will be lost there.  If the type is put on a constant (it is
the same thing as e.g. MEM_REF puts the pointer type on the offset
constant), then nothing will change it.


Makes sense, but please add a comment about it.  OK with that change.

Jason

Re: [PATCH, 1 of 5], Add suport for PowerPC IEEE 128-bit floating point

[Joseph S. Myers]

On Tue, 15 Jul 2014, Michael Meissner wrote:

> This patch is the machine independent patch for libgcc to add IEEE 128-bit
> floating point to the PowerPC.
> 
> This patch allows the PowerPC port to override the TFtype in quad.h to allow 
> it
> to use __float128 instead of attribute ((TF)).  On most of the PowerPC 
> systems,
> TFmode by default is the IBM extended double format.
> 
> 2014-07-15  Michael Meissner  
> 
>   * soft-fp/quad.h (TFtype): Allow TFmode to be overridden by the
>   machine dependent files.

soft-fp patches need to go in glibc first, with libgcc's soft-fp copy then 
being updated from glibc.

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

Re: FDO and source changes

[Jeff Law]

On 07/23/14 15:52, Xinliang David Li wrote:

Index: ChangeLog
===
--- ChangeLog   (revision 212682)
+++ ChangeLog   (working copy)
@@ -1,3 +1,10 @@
+2014-07-16  Xinliang David Li
+
+   * params.def: New parameter.
+   * coverage.c (get_coverage_counts): Check new flag.
+   (coverage_compute_profile_id): Check new flag.
+   (coverage_begin_function): Check new flag.
+
  2014-07-16  Dodji Seketeli

Support location tracking for built-in macro tokens
Index: testsuite/ChangeLog
===
--- testsuite/ChangeLog (revision 212682)
+++ testsuite/ChangeLog (working copy)
@@ -1,3 +1,11 @@
+2014-07-16  Xinliang David Li
+
+   * g++.dg/tree-prof/tree-prof.exp: Define macros.
+   * g++.dg/tree-prof/reorder_class1.h: New file.
+   * g++.dg/tree-prof/reorder_class2.h: New file.
+   * g++.dg/tree-prof/reorder.C: New test.
+   * g++.dg/tree-prof/morefunc.C: New test.
+
Basically OK.  You need to document the new option in doc/invoke.texi. 
Consider it pre-approved with that addition (please post the final 
version for archival purposes).


Jeff

Re: [PATCH][doc] Document clrsb optab and fix some inconsistencies

[Jeff Law]

On 07/23/14 02:54, Kyrill Tkachov wrote:


2014-07-16  Kyrylo Tkachov  
  James Greenhalgh  

   * doc/md.texi (clrsb): Document.
   (clz): Change reference to x into operand 1.
   (ctz): Likewise.
   (popcount): Likewise.
   (parity): Likewise.
The second version seems better to me as well.  Particularly if I try 
and ignore that I'm already familiar with a redundant sign bit by way of 
hacking combine through the years which uses that terminology IIRC.


Ok for the trunk.  Thanks,

jeff

Re: [PATCH, 2 of 5], Add suport for PowerPC IEEE 128-bit floating point

[Joseph S. Myers]

On Tue, 15 Jul 2014, Michael Meissner wrote:

> These patches are the PowerPC specific patches to add IEEE 128-bit support to
> libgcc.  These patches need to be co-ordinated with the glibc support that
> provides the software floating point emulation.  The compiler patches need to
> be installed before these patches can be installed.
> 
> 2014-07-15  Michael Meissner  
> 
>   * config.host (powerpc64*-*-linux*): Add t-float128 to PowerPC
>   64-bit linux builds.

Testing for powerpc64*-*-linux* is not appropriate - remember that you can 
build for powerpc-linux-gnu --enable-targets=all and get 64-bit multilibs, 
and those should get exactly the same configuration as for a 64-bit 
multilib for powerpc64*-*-linux*.  Of course 32-bit multilibs should also 
get identical libgcc contents in both configurations (as far as I can 
tell, your intent does not include supporting the new type for 32-bit at 
present).

Various targets use tests of ${host_address} in config.host to condition 
aspects of the configuration on whether *the particular multilib being 
built* is 32-bit or 64-bit.  That's what you need to do here as well if 
you don't want both 32-bit and 64-bit to get the new functions.

>   * config/rs6000/sfp-machine.h (_FP_W_TYPE_SIZE): On 64-bit
>   systems, use 64-bit types instead of 32-bit types.
>   (_FP_W_TYPE): Likewise.
>   (_FP_WS_TYPE): Likewise.
>   (_FP_I_TYPE): Likewise.
>   (_FP_MUL_MEAT_Q): Likewise.
>   (_FP_DIV_MEAT_Q): Likewise.
>   (_FP_NANFRAC_Q): Likewise.
>   (TItype): Define 128-bit integer types on 64-bit systems.
>   (UTItype): Likewise.

This appears to be missing the integration with hardware exceptions and 
rounding modes that I noted in 
 should be 
included.

Also:

* There is no need for __sqrtkf2.  The __sqrt*2 functions in soft-fp never 
get used for anything; GCC will never generate calls to them.

* It seems to me there are some problems in the conversion from __float128 
to IBM long double.  If the high part of the result is Inf, you set low = 
high, but the low part of an infinity in IBM long double must be +/-0, not 
another infinity.  And when you do the subtraction to compute the low part 
of the result you seem to be missing the renormalization that I noted in 
 would be needed.  I 
also don't understand what the sign bit manipulation is for; the low part 
(before renormalization) should be the result of the subtraction (whose 
sign may or may not be that of the high part), without any such 
manipulation.

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

Re: [PATCH][optabs.c] Fix PR 61713: ICE when expanding single-threaded version of atomic_test_and_set

[Jeff Law]

On 07/23/14 02:53, Kyrill Tkachov wrote:

Darn, had forgotten to attach the patch...


On 16/07/14 12:30, Kyrill Tkachov wrote:

Hi all,

This fixes the PR mentioned in the subject. When expanding
atomic_test_and_set we try the corresponding sync optabs and if none
exist, like for pre-SMP ARM architectures (-march=armv6 and earlier) the
code in optabs.c reverts to a single-threaded implementation that just
does a load and store.

However, if the result of the operation is to be ignored the code in
builtins.c follows the convention that the target RTX is set to
const0_rtx to signify that the result is ignored and the expand
functions in optabs.c are supposed to check for that and act
appropriately.

The code in the single-threaded codepath in expand_atomic_test_and_set
in optabs.c didn't perform this check and instead tried to emit a move
to a const0_rtx which ICEs further down the line.

This patch fixes that by checking if the result is ignored, and if it is
omits the load.
I wouldn't dare to remove the load in normal atomic handling code due to
all the memory ordering subtleties, but this code path occurs only when
we have a trivially single-threaded bare-metal target and the compiler
assumes no races anyway and no dodgy context switches and tries to
implement this with a ldrb+strb, so I think removing the ldrb is valid.

Bootstrapped on arm, aarch64 and x86 and tested as well.

Ok for trunk?
This appears on 4.9 as well, I'll test it on that branch as well

2014-07-16  Kyrylo Tkachov  

  PR target/61713
  * gcc/optabs.c (expand_atomic_test_and_set): Do not try to emit
  move to subtarget in serial version if result is ignored.

OK.
jeff

Re: RFA: Tweak RA cost calculation for -O0

[Jeff Law]

On 07/19/14 14:05, Richard Sandiford wrote:

IRA (like the old allocators) calculates a "best" class and an "alternative"
class for each allocno.  The best class is the one with the lowest cost while
the alternative class is the biggest class whose cost is smaller than the
cost of spilling.  When optimising we adjust the costs so that the best
class is preferred, but when not optimisting we effectively use the
alternative class:

   if (optimize && ALLOCNO_CLASS (a) != pref[i])
{
  n = ira_class_hard_regs_num[aclass];
  ALLOCNO_HARD_REG_COSTS (a)
= reg_costs = ira_allocate_cost_vector (aclass);
  for (j = n - 1; j >= 0; j--)
{
  hard_regno = ira_class_hard_regs[aclass][j];
  if (TEST_HARD_REG_BIT (reg_class_contents[pref[i]], hard_regno))
reg_costs[j] = ALLOCNO_CLASS_COST (a);
  else
{
  rclass = REGNO_REG_CLASS (hard_regno);
  num = cost_classes_ptr->index[rclass];
  if (num < 0)
{
  num = cost_classes_ptr->hard_regno_index[hard_regno];
  ira_assert (num >= 0);
}
  reg_costs[j] = COSTS (costs, i)->cost[num];
}
}
}

In some cases the alternative class can be significantly more costly
than the preferred class.  If reg_alloc_order lists a member of the
alternative class that isn't in the best class, then for -O0 we'll tend
to use it even if many members of the best class are still free.

Obviously we don't want to spend too much on RA at -O0.  But with the
code above disabled, I think we should use the best class as the allocno
class if it isn't likely to be spilled.  The patch below does this.

One case where this occurs is on MIPS with:

   (set (reg:DI y) (sign_extend:SI (reg:SI x)))
   ...(reg:DI y)...

where y is used in a context that requires a GPR and where the sign
extension is done by:

(define_insn_and_split "extendsidi2"
   [(set (match_operand:DI 0 "register_operand" "=d,l,d")
 (sign_extend:DI (match_operand:SI 1 "nonimmediate_operand" "0,0,m")))]
   "TARGET_64BIT"
   "@
#
#
lw\t%0,%1"
   "&& reload_completed && register_operand (operands[1], VOIDmode)"
   [(const_int 0)]
{
   emit_note (NOTE_INSN_DELETED);
   DONE;
}
   [(set_attr "move_type" "move,move,load")
(set_attr "mode" "DI")])

("l" is the LO register.)  Because a "d" register would satisfy both
the definition and use of "y", it is the best class and has a cost of 0.
But the costs are deliberately set up so that using "l" is cheaper
than memory (which might not be true on all processors, but that's
a question of -mtune-specific costs).  So the alternative class is
GR_AND_MD?_REGS.  The problem is that the LO register comes first
in the allocation order:

#define REG_ALLOC_ORDER \
{ /* Accumulator registers.  When GPRs and accumulators have equal  \
  cost, we generally prefer to use accumulators.  For example,  \
  a division of multiplication result is better allocated to LO,\
  so that we put the MFLO at the point of use instead of at the \
  point of definition.  It's also needed if we're to take advantage \
  of the extra accumulators available with -mdspr2.  In some cases, \
  it can also help to reduce register pressure.  */ \
   64, 65,176,177,178,179,180,181,  \

So we end up picking LO even though it is significantly more costly
than GPRs in this case (but still less costly than memory, again
according to the chosen cost model).  This is the cause of a regression
in gcc.target/mips/branch-7.c after:

2014-06-24  Catherine Moore  
Sandra Loosemore  

* config/mips/mips.c (mips_order_regs_for_local_alloc): Delete.
* config/mips/mips.h (ADJUST_REG_ALLOC_ORDER): Delete.
* config/mips/mips-protos.h (mips_order_regs_for_local_alloc): Delete.

But I think it's a general problem.  I tried the patch on CSiBE for:

   MIPS -mips64r2 -mabi=32 -mips16
   MIPS -mips64r2 -mabi=32
   MIPS -mips64r2 -mabi=n32
   MIPS -mips64r2 -mabi=64
   MIPS -mips3 -mabi=64
   x86_64 -m32
   x86_64

all at -O0, and it was a size win in all cases.  The biggest win was for
MIPS -mips64r2 -mabi=32 (which isn't affected by the sign_extend case above,
since the pattern is restricted to 64-bit targets).  The saving there was 10%.
The saving for x86_64 -m32 was just 0.05%, but the saving for x86_64 was a
more worthwhile 0.5%.

Tested on mips64-linux-gnu and x86_64-linux-gnu.  It fixes the
gcc.target/mips/branch-7.c regression for MIPS.  OK to install?

Thanks,
Richard


gcc/
* ira-costs.c (find_costs_and_classes): For -O0, use the best class
as the allocation class if it isn't likely to be spilled.
Seems reasonable.  Please keep an eye out for fallou

[COMMIT] Add a .gitattributes file for use with git-merge-changelog

[Samuel Bronson]

Individual users will still have to:

 1. Install git-merge-changelog

 2. Set up the merge driver in their git config

See gnulib's lib/git-merge-changelog.c [1] for details.

For example, I:

 1. Patched Debian's gnulib package to build git-merge-changelog, and
sent the patch to the Debian maintainer, who then proceeded to not
only accept my patch but even write a *manpage* for
git-merge-changelog! (Let's hear it for Ian Beckwith.)

So now, I can install it simply by running "apt-get install
git-merge-changelog".  (Except, of course, that I already have it
installed from when I was testing my patch.)

 2. Did step (2) from .gitattributes

With this patch applied and the above two steps done by whatever means
you deem best, you can say goodbye to merge conflicts in ChangeLog
files -- at least *IF* people stop renaming the danged things, anyway.

If you don't do step 2, you will continue to suffer from ChangeLog
merge conflicts exactly as before, whether or not you did step 1.

If you do step 2 but not step 1, git will likely start complaining
that it can't find any "git-merge-changelog" to run.

[1]: 
http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/git-merge-changelog.c

[Note: The docs for git-merge-changelog (the comments at the top) say
that you need a .gitattributes in every directory.  The docs are wrong.
Ignore the docs.  Well, not the whole docs; just that part.

You really only need one at the top level, since .gitattributes uses
the same pattern matching rules as .gitignore, which match files in
any subdirectory unless you prefix the pattern with a "/", as
explained in the gitignore(5) manpage.]
---
 .gitattributes | 20 
 ChangeLog  |  4 
 2 files changed, 24 insertions(+)
 create mode 100644 .gitattributes

diff --git a/.gitattributes b/.gitattributes
new file mode 100644
index 000..06d51d2
--- /dev/null
+++ b/.gitattributes
@@ -0,0 +1,20 @@
+# -*- conf -*-
+
+## Set merge driver for ChangeLog files 
+# See gnulib's lib/git-merge-changelog.c (or git-merge-changelog(1))
+# for per-user setup instructions.
+#
+# The short version of this (optional) procedure is:
+# 
+# (1) Install git-merge-changelog (this is the tricky part!)
+#
+# (2) Add something like the following to your ~/.gitconfig:
+#
+# [merge "merge-changelog"]
+# name = GNU-style ChangeLog merge driver
+# driver = git-merge-changelog %O %A %B
+#
+# (3) Enjoy mostly effortless ChangeLog merges, at least until the
+# file gets renamed again ...
+
+ChangeLog   merge=merge-changelog
diff --git a/ChangeLog b/ChangeLog
index 16047d3..5c8fe15 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2014-07-25  Samuel Bronson  
+
+   * .gitattributes: New file for use with git-merge-changelog.
+
 2014-07-21  Joel Sherrill  
 
Disable gdb for or1k*-*-* until supported
-- 
2.0.1

Re: FDO and source changes

[Xinliang David Li]

Ok. The internal benchmark testing also shows no change in behavior.

David

On Fri, Jul 25, 2014 at 2:55 PM, Jeff Law  wrote:
> On 07/23/14 15:52, Xinliang David Li wrote:
>>
>> Index: ChangeLog
>> ===
>> --- ChangeLog   (revision 212682)
>> +++ ChangeLog   (working copy)
>> @@ -1,3 +1,10 @@
>> +2014-07-16  Xinliang David Li
>> +
>> +   * params.def: New parameter.
>> +   * coverage.c (get_coverage_counts): Check new flag.
>> +   (coverage_compute_profile_id): Check new flag.
>> +   (coverage_begin_function): Check new flag.
>> +
>>   2014-07-16  Dodji Seketeli
>>
>> Support location tracking for built-in macro tokens
>> Index: testsuite/ChangeLog
>> ===
>> --- testsuite/ChangeLog (revision 212682)
>> +++ testsuite/ChangeLog (working copy)
>> @@ -1,3 +1,11 @@
>> +2014-07-16  Xinliang David Li
>> +
>> +   * g++.dg/tree-prof/tree-prof.exp: Define macros.
>> +   * g++.dg/tree-prof/reorder_class1.h: New file.
>> +   * g++.dg/tree-prof/reorder_class2.h: New file.
>> +   * g++.dg/tree-prof/reorder.C: New test.
>> +   * g++.dg/tree-prof/morefunc.C: New test.
>> +
>
> Basically OK.  You need to document the new option in doc/invoke.texi.
> Consider it pre-approved with that addition (please post the final version
> for archival purposes).
>
> Jeff

[Patch, Fortran] PRs 61881/61888 - Fix issues with SIZEOF, CLASS(*) and assumed-rank

[Tobias Burnus]

The patch has been motivated by the needs for implementing the openacc 
module. In particular, it does:


- Fix passing intrinsic types to CLASS(*) [F2003]
- Fix STORAGE_SIZE for polymorphic arrays [F2003]
- Permit the vendor intrinsic SIZEOF also for TYPE(*) if and only if an 
array descriptor has been used [extend GNU extension]

- Fix SIZEOF with assumed-rank [fix GNU extension]
- Document that SIZEOF's result are not well defined for noncontiguous 
arrays. [fix GNU extension]


Build and regtested on x86-64-gnu-linux.
OK for the trunk?

Tobias
2014-07-26  Tobias Burnus  

	* check.c (gfc_check_sizeof): Permit for assumed type if and
	only if it has an array descriptor.
	* intrinsic.c (do_ts29113_check): Permit SIZEOF.
	(add_functions): SIZEOF is an Inquiry function.
	* intrinsic.texi (SIZEOF): Add note that only contiguous
	arrays are permitted.
	* trans-expr.c (gfc_conv_intrinsic_to_class): Handle assumed
	rank.
	* trans-intrinsic.c (gfc_conv_intrinsic_sizeof): Handle
	assumed type + array descriptor, CLASS and assumed rank.
	(gfc_conv_intrinsic_storage_size): Handle class arrays.

2014-07-26  Tobias Burnus  

	* gfortran.dg/sizeof_2.f90: Change dg-error.
	* gfortran.dg/sizeof_4.f90: New.
	* gfortran.dg/storage_size_1.f08: Correct expected
	value.

diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index eff2c4c..ff7e53d 100644
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -3902,7 +3902,12 @@ gfc_check_sizeof (gfc_expr *arg)
   return false;
 }
 
-  if (arg->ts.type == BT_ASSUMED)
+  // TYPE(*) is acceptable if and only if it uses an array descriptor.
+  if (arg->ts.type == BT_ASSUMED
+  && (arg->symtree->n.sym->as == NULL
+	  || (arg->symtree->n.sym->as->type != AS_ASSUMED_SHAPE
+	  && arg->symtree->n.sym->as->type != AS_DEFERRED
+	  && arg->symtree->n.sym->as->type != AS_ASSUMED_RANK)))
 {
   gfc_error ("'%s' argument of '%s' intrinsic at %L shall not be TYPE(*)",
 		 gfc_current_intrinsic_arg[0]->name, gfc_current_intrinsic,
diff --git a/gcc/fortran/intrinsic.c b/gcc/fortran/intrinsic.c
index d681d70..1ad1e69 100644
--- a/gcc/fortran/intrinsic.c
+++ b/gcc/fortran/intrinsic.c
@@ -204,6 +204,7 @@ do_ts29113_check (gfc_intrinsic_sym *specific, gfc_actual_arglist *arg)
 	   && specific->id != GFC_ISYM_RANK
 	   && specific->id != GFC_ISYM_SHAPE
 	   && specific->id != GFC_ISYM_SIZE
+	   && specific->id != GFC_ISYM_SIZEOF
 	   && specific->id != GFC_ISYM_UBOUND
 	   && specific->id != GFC_ISYM_C_LOC)
 	{
@@ -2765,8 +2766,9 @@ add_functions (void)
 	 ar, BT_REAL, dr, REQUIRED, dm, BT_INTEGER, ii, OPTIONAL);
   make_from_module();
 
-  add_sym_1 ("sizeof", GFC_ISYM_SIZEOF, CLASS_IMPURE, ACTUAL_NO, BT_INTEGER, ii,
-	 GFC_STD_GNU, gfc_check_sizeof, gfc_simplify_sizeof, NULL,
+  add_sym_1 ("sizeof", GFC_ISYM_SIZEOF, CLASS_INQUIRY, ACTUAL_NO,
+	 BT_INTEGER, ii, GFC_STD_GNU,
+	 gfc_check_sizeof, gfc_simplify_sizeof, NULL,
 	 x, BT_UNKNOWN, 0, REQUIRED);
 
   make_generic ("sizeof", GFC_ISYM_SIZEOF, GFC_STD_GNU);
diff --git a/gcc/fortran/intrinsic.texi b/gcc/fortran/intrinsic.texi
index 152b46c..6c4cb09 100644
--- a/gcc/fortran/intrinsic.texi
+++ b/gcc/fortran/intrinsic.texi
@@ -12205,7 +12205,9 @@ to is returned.  If the argument is of a derived type with @code{POINTER}
 or @code{ALLOCATABLE} components, the return value does not account for
 the sizes of the data pointed to by these components. If the argument is
 polymorphic, the size according to the declared type is returned. The argument
-may not be a procedure or procedure pointer.
+may not be a procedure or procedure pointer. Note that the code assumes for
+arrays that those are contiguous; for contiguous arrays, it returns the
+storage or an array element multiplicated by the size of the array.
 
 @item @emph{Example}:
 @smallexample
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 81f2137..02cec97 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -564,7 +564,7 @@ gfc_conv_intrinsic_to_class (gfc_se *parmse, gfc_expr *e,
   var = gfc_create_var (tmp, "class");
 
   /* Set the vptr.  */
-  ctree =  gfc_class_vptr_get (var);
+  ctree = gfc_class_vptr_get (var);
 
   vtab = gfc_find_vtab (&e->ts);
   gcc_assert (vtab);
@@ -573,7 +573,7 @@ gfc_conv_intrinsic_to_class (gfc_se *parmse, gfc_expr *e,
 		  fold_convert (TREE_TYPE (ctree), tmp));
 
   /* Now set the data field.  */
-  ctree =  gfc_class_data_get (var);
+  ctree = gfc_class_data_get (var);
   if (parmse->ss && parmse->ss->info->useflags)
 {
   /* For an array reference in an elemental procedure call we need
@@ -589,7 +589,16 @@ gfc_conv_intrinsic_to_class (gfc_se *parmse, gfc_expr *e,
 	{
 	  parmse->ss = NULL;
 	  gfc_conv_expr_reference (parmse, e);
-	  tmp = fold_convert (TREE_TYPE (ctree), parmse->expr);
+	  if (class_ts.u.derived->components->as
+	  && class_ts.u.derived->components->as->type == AS_ASSUMED_RANK)
+	{
+	  tmp = gfc_conv_scalar_to_

Re: [PATCH] gcc/toplev.c: Avoid to close 'asm_out_file' when it is 'stdout'

[Chen Gang]

On 07/26/2014 05:12 AM, Jeff Law wrote:
> On 07/23/14 16:17, Chen Gang wrote:
>> On 07/23/2014 11:44 AM, Jeff Law wrote:
>>> On 07/21/14 09:47, Chen Gang wrote:
 'asm_out_file' may be 'stdout', so need check this case before close
 it.
 Or 'stdout' may be closed -- since need not open 'stdout', either need
 not close it.

 ChangLog:

 * topleve.c (finalize): Avoid to close 'asm_out_file' when it is
 'stdout'.
>>> What exactly is the problem with closing stdout at this point?  In
>>> general, you need to state the problem you're trying to fix with your
>>> patch.
>>>
>>
>> Excuse me, I only find it by reading source code, so for me, I didn't
>> meet the real problem for it, so at least, this patch is not urgent (
>> although I am not sure whether it is still valuable or not).
> OK.  I suspected it might be the case that you just saw something odd
> and sent a patch to change it.
> 
> But that was just a suspicion -- there well could have been some path
> you found where GCC wanted to write to stdout after the point where we
> closed the output file.  That would clearly be a bug and warrant fixing
> immediately.
> 

In source root directory:
  "grep -rn asm_out_file * | grep stdout"
  "grep -rn asm_out_file * | grep fclose"
  "grep -rn asm_out_file * | grep NULL".

We can know about stdout may be used (e.g. the related parameter is '-')
in init_asm_output() in "gcc/toplev.c". And only one place to close it
in finalize() in "gcc/toplev.c".

But really, it is only by reading source code, no any real test for it,
so yeah, we can say it is only a suspicion.

> Either way it's important you tell us why you're making a change in a
> way which allows us to evaluate the importance of the change.  Otherwise
> we have to guess and we could easily guess wrong.
> 
> In this specific instance, I don't really see any value in avoiding the
> close of stdout.
> 

I don't see either, so at least, it is not urgent.

But if it was really a bug, for me, we have to fix it, when we have time.

>>
>> At present, I am a newbie, and use 2 ways to learn gcc and binutils.
>>
>>   - Cross compile the cross compiler with '-W' for linux kernel.
>> (If find issues, I shall try to fix them with related members).
>>
>>   - Reading source code of gcc and binutils, if find some where can be
>> improved, and try to send patch for it.
> And these are excellent ways to get started.  Another would be to build
> GCC with Clang/LLVM and see what warnings that generates and try to fix
> them.  Perusing the bug database (gcc.gnu.org/bugzilla) can sometimes
> result in identifying issues you can resolve.
> 

Thank you for your ideas and suggestions, Clang/LLVM and bugzilla are
really two important and valuable places.

But excuse me, I have no enough time resources on it. I have started
Linux kernel and qemu/kvm/xen in my free time, and now, I am starting
gcc/binutils in my free time, too.

 - "cross compiling the cross-compiler for linux kernel, and let each
   architectures in kernel pass allmodconfig" is an efficient way to me
   for both learning gcc/binutils and linux kernel.

 - Reading source code are always necessary in any cases (it is my main
   learning way for qemu/kvm/xen).

Clang/LLVM and bugzilla are really very important, so I shall try them
in the future (I guess, may be next year -- 2015).

>> By the way, is there a trivial patch mailing list of gcc? I guess most
>> of my patches belong to trivial.
> No, all patches go to gcc-patches, even trivial ones.
> 

OK, thanks. And I shall continue in gcc-patches.

And excuse me, next, most of my trivial patches maybe bother many other
members in gcc-patches mailing list.


Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

[PATCH] gcc/config/nios2/nios2.c: Let custom_builtin_name[*] always be zero terminated string

[Chen Gang]

The related strncpy() for custom_builtin_name[*] may set 5 none-zero
characters, which cause custom_builtin_name[*] none-zero terminated.
But error() assumes custom_builtin_name[*] is always zero terminated.

So add additional '\0' byte for custom_builtin_name[*].

ChangeLog:

* config/nios2/nios2.c (custom_builtin_name): Let it always be
zero terminated string.

Signed-off-by: Chen Gang 
---
 gcc/config/nios2/nios2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/nios2/nios2.c b/gcc/config/nios2/nios2.c
index a4e60c6..e4e005b 100644
--- a/gcc/config/nios2/nios2.c
+++ b/gcc/config/nios2/nios2.c
@@ -2510,7 +2510,7 @@ nios2_expand_fpu_builtin (tree exp, unsigned int code, 
rtx target)
total of (3 + 1) * (1 + 3 + 9) == 52 custom builtin functions.
 */
 #define NUM_CUSTOM_BUILTINS ((3 + 1) * (1 + 3 + 9))
-static char custom_builtin_name[NUM_CUSTOM_BUILTINS][5];
+static char custom_builtin_name[NUM_CUSTOM_BUILTINS][6];
 
 static void
 nios2_init_custom_builtins (int start_code)
-- 
1.9.2.459.g68773ac

[PATCH] gcc/config/nios2/nios2.c: Let custom_builtin_name[*] always be zero terminated string

[Chen Gang]

The related strncpy() for custom_builtin_name[*] may set 5 none-zero
characters, which may cause custom_builtin_name[*] is none-zero
terminated.

So add additional '\0' byte for custom_builtin_name[*].

ChangeLog:

* config/nios2/nios2.c (custom_builtin_name): Let it always be
zero terminated string.

Signed-off-by: Chen Gang 
---
 gcc/config/nios2/nios2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/nios2/nios2.c b/gcc/config/nios2/nios2.c
index a4e60c6..e4e005b 100644
--- a/gcc/config/nios2/nios2.c
+++ b/gcc/config/nios2/nios2.c
@@ -2510,7 +2510,7 @@ nios2_expand_fpu_builtin (tree exp, unsigned int code, 
rtx target)
total of (3 + 1) * (1 + 3 + 9) == 52 custom builtin functions.
 */
 #define NUM_CUSTOM_BUILTINS ((3 + 1) * (1 + 3 + 9))
-static char custom_builtin_name[NUM_CUSTOM_BUILTINS][5];
+static char custom_builtin_name[NUM_CUSTOM_BUILTINS][6];
 
 static void
 nios2_init_custom_builtins (int start_code)
-- 
1.9.2.459.g68773ac

Re: [PATCH v3 3/3] Port libstdc++ pretty-printers to Python 2 + Python 3

[Samuel Bronson]

Tom Tromey  writes:

>> "Samuel" == Samuel Bronson  writes:
>
> Samuel> +# FIXME: The handling of e.g. std::basic_string (at least on char)
> Samuel> +# probably needs updating to work with Python 3's new string rules.
> Samuel> +#
> Samuel> +# In particular, Python 3 has a separate type (called byte) for
> Samuel> +# bytestrings, and a special b"" syntax for the byte literals; the 
> old
> Samuel> +# str() type has been redefined to always store Unicode text.
> Samuel> +#
> Samuel> +# We probably can't do much about this until GDB get their act
> Samuel> +# together: 
>
> I don't think this comment is applicable.
> The libstdc++ pretty-printers use gdb.Value.lazy_string, not the
> built-in Python types.

Hmm, doesn't that just make it a timebomb -- a value that will explode
if, at some point in the future, someone tries to treat it as a string?

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!

Re: [PATCH] gcc/config/nios2/nios2.c: Let custom_builtin_name[*] always be zero terminated string

[Chung-Lin Tang]

On 14/7/26 11:28 AM, Chen Gang wrote:
> The related strncpy() for custom_builtin_name[*] may set 5 none-zero
> characters, which may cause custom_builtin_name[*] is none-zero
> terminated.
> 
> So add additional '\0' byte for custom_builtin_name[*].

Where did you see this? Supposedly the snprintf of the custom function
type string should at most be of 'xnxx' format; 4 characters at most,
not 5.  Do you have a test case where the behavior you described appears?

Thanks,
Chung-Lin

> ChangeLog:
> 
>   * config/nios2/nios2.c (custom_builtin_name): Let it always be
>   zero terminated string.
> 
> Signed-off-by: Chen Gang 
> ---
>  gcc/config/nios2/nios2.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/gcc/config/nios2/nios2.c b/gcc/config/nios2/nios2.c
> index a4e60c6..e4e005b 100644
> --- a/gcc/config/nios2/nios2.c
> +++ b/gcc/config/nios2/nios2.c
> @@ -2510,7 +2510,7 @@ nios2_expand_fpu_builtin (tree exp, unsigned int code, 
> rtx target)
> total of (3 + 1) * (1 + 3 + 9) == 52 custom builtin functions.
>  */
>  #define NUM_CUSTOM_BUILTINS ((3 + 1) * (1 + 3 + 9))
> -static char custom_builtin_name[NUM_CUSTOM_BUILTINS][5];
> +static char custom_builtin_name[NUM_CUSTOM_BUILTINS][6];
>  
>  static void
>  nios2_init_custom_builtins (int start_code)
>