Re: [wwwdocs] Add link to @gnutools on Twitter

[Gerald Pfeifer]

> Does this also deserve a news post? I certainly found it to be
> interesting news!

Sure.  Want to add one, David?

Based on another suggestion by David I also added a link to the
gnutools account on Google+.  Patch below, gcc.gnu.org updated.

Gerald

Index: style.mhtml
===
RCS file: /cvs/gcc/wwwdocs/htdocs/style.mhtml,v
retrieving revision 1.120
diff -r1.120 style.mhtml
164a165,170
>   
>   https://plus.google.com/108467477471815191158";>
>height="24" width="24" align="middle" alt="gnutools on Google+"
>   style="border:0px" />  gnutools
>   

Re: [PATCH 08/11] Example of converting global state to per-pass state

[David Malcolm]

On Thu, 2013-08-01 at 10:58 -1000, Richard Henderson wrote:
[...]
> Ok.
Thanks; committed to svn trunk as r201681 (having rebootstrap and
tested).

Re: [PATCH 07/11] Introduce virtual functions in testsuite/gcc.dg/plugin/one_time_plugin.c

[David Malcolm]

On Thu, 2013-08-01 at 10:48 -1000, Richard Henderson wrote:
[...]
> Ok.

Thanks; committed to trunk as r201680 (having rebootstrapped and tested)

Re: [PATCH 2/3] Support using 'auto' in a function parameter list to introduce an implicit template parameter.

[Adam Butcher]

On 12.08.2013 17:00, Jason Merrill wrote:

On 08/11/2013 03:49 PM, Adam Butcher wrote:
+#define fully_implicit_template 
scope_chain->x_fully_implicit_template


Why did you choose to add this to saved_scope rather than cp_parser?
It seems like state that could be local to the parser rather than
shared with the rest of the compiler.

Currently it is the implicit function template code in pt.c that 
updates this; specifically add_implicit_template_parms and 
finish_fully_implicit_template.


It is queried by the parser (both in parser.c and lambda.c) to decide 
whether a new [implicit] template parameter list as been started and to 
decide how to finish up.


I had a look into this; it should be possible to move these out of pt.c 
and into parser.c (or some new file generic-parms.c, implicit-pt.c or 
some such) and possibly add a plain global counter for this state, 
rather than attribute it to each scope.



+tree type_uses_auto (tree type)
+tree type_uses_auto_or_concept (tree type)


Function name at the beginning of the line.


Fixed.

Adam

Committed: Fix stray PIPELINE_H in gcc/config/i386/t-i386

[David Malcolm]

In r201505 I added a reference to $(PIPELINE_H) to
gcc/config/i386/t-i386.
This was a holdover from before this was renamed to "pass_manager", and
should have read $(PASS_MANAGER_H) - I missed this when renaming.

Successfully bootstrapped; I've committed the fix to trunk as being
obvious (as r201679).

(thanks to Tom Tromey for spotting it).

>From a70a3f2f4cfd2f77754a61627e04074cdab4c7a2 Mon Sep 17 00:00:00 2001
From: David Malcolm 
Date: Wed, 7 Aug 2013 15:38:56 -0400
Subject: [PATCH 1/9] Rename stray PIPELINE_H to PASS_MANAGER_H

gcc/
	* config/i386/t-i386 (i386.o): Rename stray PIPELINE_H to
	PASS_MANAGER_H
---
 gcc/config/i386/t-i386 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/i386/t-i386 b/gcc/config/i386/t-i386
index f10d570..07624cc 100644
--- a/gcc/config/i386/t-i386
+++ b/gcc/config/i386/t-i386
@@ -24,7 +24,7 @@ i386.o: $(CONFIG_H) $(SYSTEM_H) coretypes.h dumpfile.h $(TM_H) \
   $(GGC_H) $(TARGET_H) $(TARGET_DEF_H) langhooks.h $(CGRAPH_H) \
   $(TREE_GIMPLE_H) $(DWARF2_H) $(DF_H) tm-constrs.h $(PARAMS_H) \
   i386-builtin-types.inc debug.h dwarf2out.h sbitmap.h $(FIBHEAP_H) \
-  $(OPTS_H) $(DIAGNOSTIC_H) $(COMMON_TARGET_H) $(CONTEXT_H) $(PIPELINE_H)
+  $(OPTS_H) $(DIAGNOSTIC_H) $(COMMON_TARGET_H) $(CONTEXT_H) $(PASS_MANAGER_H)
 
 i386-c.o: $(srcdir)/config/i386/i386-c.c \
   $(srcdir)/config/i386/i386-protos.h $(CONFIG_H) $(SYSTEM_H) coretypes.h \
-- 
1.7.11.7

Re: [PATCH 1/3] Support lambda templates.

[Adam Butcher]

On 12.08.2013 16:47, Jason Merrill wrote:

On 08/11/2013 03:49 PM, Adam Butcher wrote:

+  if (cxx_dialect < cxx1y || flag_iso)
+   cp_parser_error (parser,
+"lambda templates are only available with "
+"-std=gnu++1y");


Normally we only use flag_iso to disable extensions that can change
the meaning of conforming code, which I don't think is the case here.
For pure extensions, we prefer to use a pedwarn.



Okay.  Though I'm not sure how to implement exactly what we discussed
before with pedwarn.  Namely:

On 07.08.2013 16:59, Jason Merrill wrote:

On 08/07/2013 03:52 AM, Adam Butcher wrote:
I'm not sure which dialect guards to put these features behind 
though.

Strictly:

  a) Generic lambdas created fully implicitly via 'auto params' 
should be
 accepted with -std=c++1y and -std=gnu++1y since it is actually 
spec'd by

 the draft.

  b) Generic lambdas created with an explicit template parameter 
list should be

 accepted with -std=gnu++1y only.

  c) Generalized implicit function templates should be accepted by 
-std=gnu++1y

 only.


This makes sense to me.  Or perhaps add (c) to the concepts lite
flag, when there is one.



Presumably with pedwarn it would need to be relaxed to simply
   "accepted with -std=c++1y or -std=gnu++1y"
for all?  flag_iso was the only thing I could find to discriminate 
between gnu++1y

and c++1y?


+ if (!DECL_TEMPLATE_INFO (decl) || DECL_TEMPLATE_RESULT
+ (DECL_TI_TEMPLATE (decl)) != decl)


This needs reformatting so that the arguments to a macro aren't to
the left of the macro name.


Done.

Adam

[patch, mips] Fix for loongson prefetching and -mabi=32

[Steve Ellcey]

Someone using buildroot reported a problem to me that I tracked down to
compiling a routine containing __builtin_prefetch with '-march=loongson
-mabi=32'.  When doing this the prefetch instruction on loongson generates
'ld' instead of 'lw' and then tries to put it into a delay slot.  This
causes the assembler to generate a warning both because 'ld' in 32 bit
mode is a macro and GCC put out a '.set nomacro' and because it tries to
put the two instructions generated by the macro into a delay slot.  My fix
is to generate 'lw' in 32 bit mode on loongson, then it doesn't generate a
macro and the instruction that is generated can go into a delay slot.

OK for checkin?


2013-08-12  Steve Ellcey  

* config/mips/mips.md (prefetch): Use lw instead of ld on
loongson in 32bit mode.


diff --git a/gcc/config/mips/mips.md b/gcc/config/mips/mips.md
index 397c40a..ad03040 100644
--- a/gcc/config/mips/mips.md
+++ b/gcc/config/mips/mips.md
@@ -6674,7 +6674,10 @@
 {
   if (TARGET_LOONGSON_2EF || TARGET_LOONGSON_3A)
 /* Loongson 2[ef] and Loongson 3a use load to $0 to perform prefetching.  
*/
-return "ld\t$0,%a0";
+if (TARGET_64BIT)
+  return "ld\t$0,%a0";
+else
+  return "lw\t$0,%a0";
   operands[1] = mips_prefetch_cookie (operands[1], operands[2]);
   return "pref\t%1,%a0";
 }

[PATCH, committed] pt.c: Grammar fix in comments ("it's" to "its").

[Adam Butcher]

From: abutcher 

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@201674 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/cp/ChangeLog | 4 
 gcc/cp/pt.c  | 6 +++---
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/gcc/cp/ChangeLog b/gcc/cp/ChangeLog
index a7462af..6dd0cd8 100644
--- a/gcc/cp/ChangeLog
+++ b/gcc/cp/ChangeLog
@@ -1,3 +1,7 @@
+2013-08-13  Adam Butcher  
+
+   * pt.c: Grammar fix in comments ("it's" to "its").
+
 2013-08-12  Paolo Carlini  
 
* decl.c (warn_extern_redeclared_static, duplicate_decls,
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index d03c1cf..85224fc 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -1986,7 +1986,7 @@ determine_specialization (tree template_id,
  tree decl_arg_types;
 
  /* This is an ordinary member function.  However, since
-we're here, we can assume it's enclosing class is a
+we're here, we can assume its enclosing class is a
 template class.  For example,
 
   template  struct S { void f(); };
@@ -4337,7 +4337,7 @@ check_default_tmpl_args (tree decl, tree parms, bool 
is_primary,
  || DECL_INITIALIZED_IN_CLASS_P (decl)))
 /* We already checked these parameters when the template was
declared, so there's no need to do it again now.  This function
-   was defined in class scope, but we're processing it's body now
+   was defined in class scope, but we're processing its body now
that the class is complete.  */
 return true;
 
@@ -7555,7 +7555,7 @@ lookup_template_class_1 (tree d1, tree arglist, tree 
in_decl, tree context,
the one of #0.
 
When we encounter #1, we want to store the partial instantiation
-   of M (template S::M) in it's CLASSTYPE_TI_TEMPLATE.
+   of M (template S::M) in its CLASSTYPE_TI_TEMPLATE.
 
For all cases other than this "explicit specialization of member of a
class template", we just want to store the most general template into
-- 
1.8.3

[PATCH, committed] MAINTAINERS (Write After Approval): Add myself.

[Adam Butcher]

From: abutcher 

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@201673 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 ChangeLog   | 4 
 MAINTAINERS | 1 +
 2 files changed, 5 insertions(+)

diff --git a/ChangeLog b/ChangeLog
index a35d04a..8f29bc9 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2013-08-13  Adam Butcher  
+
+   * MAINTAINERS (Write After Approval): Add myself.
+
 2013-08-12  Caroline Tice  
 
* MAINTAINERS: Add myself as libvtv maintainer. Correct my email
diff --git a/MAINTAINERS b/MAINTAINERS
index ad418b1..ef6ab87 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -337,6 +337,7 @@ Dave Brolley
brol...@redhat.com
 Julian Brown   jul...@codesourcery.com
 Christian Bruelchristian.br...@st.com
 Kevin Buettner kev...@redhat.com
+Adam Butcher   a...@jessamine.co.uk
 Andrew Cagney  cag...@redhat.com
 Daniel Carrera dcarr...@gmail.com
 Stephane Carrezstcar...@nerim.fr
-- 
1.8.3

[google] add a new parameter to control icall promotion strategy

[Xinliang David Li]

The attached patch defines a new parameter to decide if icall
promotion (LIPO) is using a new hotness based heuristic or not.   (See
Honza's speculative call support patch for reference).


David
Index: params.def
===
--- params.def  (revision 201420)
+++ params.def  (working copy)
@@ -903,6 +903,13 @@ DEFPARAM (PARAM_ALWAYS_INLINE_ICALL_TARG
  "force inline indirect call target when promoted",
   0, 0, 0)
 
+/* Do not check the icall target count distribution, but use
+   hotness info to decide if promotion should be done.  */
+DEFPARAM (PARAM_ICALL_USE_HOTNESS_HEUR,
+ "icall-use-hotness-heur",
+ "use hotness based heuristics to match inliner",
+  0, 0, 0)
+
 /* Force the compiler to be in LIPO mode even there is no
  profile data available. -fripa is also needed. */
 DEFPARAM (PARAM_FORCE_LIPO_MODE, 
Index: value-prof.c
===
--- value-prof.c(revision 201419)
+++ value-prof.c(working copy)
@@ -1558,6 +1558,7 @@ gimple_ic_transform_mult_targ (gimple st
   gimple modify1, modify2;
   struct cgraph_node *direct_call1 = 0, *direct_call2 = 0;
   int perc_threshold, count_threshold, always_inline;
+  int use_hotness_heur = false;
   location_t locus;
 
   val1 = histogram->hvalue.counters [1];
@@ -1576,9 +1577,18 @@ gimple_ic_transform_mult_targ (gimple st
   perc_threshold = PARAM_VALUE (PARAM_ICALL_PROMOTE_PERCENT_THRESHOLD);
   count_threshold = PARAM_VALUE (PARAM_ICALL_PROMOTE_COUNT_THRESHOLD);
   always_inline = PARAM_VALUE (PARAM_ALWAYS_INLINE_ICALL_TARGET);
+  use_hotness_heur = PARAM_VALUE (PARAM_ICALL_USE_HOTNESS_HEUR);
 
-  if (100 * count1 < all * perc_threshold || count1 < count_threshold)
-return false;
+  if (!use_hotness_heur)
+{
+  if (100 * count1 < all * perc_threshold || count1 < count_threshold)
+return false;
+}
+  else
+{
+  if (!maybe_hot_count_p (cfun, count1))
+return false;
+}
 
   if (check_ic_counter (stmt, &count1, &count2, all))
 return false;
@@ -1597,9 +1607,17 @@ gimple_ic_transform_mult_targ (gimple st
 
   direct_call1 = find_func_by_global_id (val1, flag_auto_profile);
 
-  if (val2 && (100 * count2 >= all * perc_threshold)
-  && count2 > count_threshold)
-direct_call2 = find_func_by_global_id (val2, flag_auto_profile);
+  if (!use_hotness_heur)
+{
+  if (val2 && (100 * count2 >= all * perc_threshold)
+  && count2 > count_threshold)
+direct_call2 = find_func_by_global_id (val2, flag_auto_profile);
+}
+  else
+{
+  if (maybe_hot_count_p (cfun, count2))
+direct_call2 = find_func_by_global_id (val2, flag_auto_profile);
+}
 
   locus = (stmt != NULL) ? gimple_location (stmt)
   : DECL_SOURCE_LOCATION (current_function_decl);

[C++ testcase, committed] PR 57416

[Paolo Carlini]

Hi,

tested x86_64-linux, committed to mainline.

Thanks,
Paolo.

///
2013-08-12  Paolo Carlini  

PR c++/57416
* g++.dg/cpp0x/pr57416.C: New.
Index: g++.dg/cpp0x/pr57416.C
===
--- g++.dg/cpp0x/pr57416.C  (revision 0)
+++ g++.dg/cpp0x/pr57416.C  (working copy)
@@ -0,0 +1,45 @@
+// PR c++/57416
+// { dg-do compile { target c++11 } }
+
+struct Nothing
+{
+};
+
+template 
+void func3 (PARENTDATA & p_parent_data)
+{
+  struct Data
+  {
+PARENTDATA & parent_data = p_parent_data;  // { dg-error "parameter" }
+  } data;
+}
+
+template 
+void func2 (PARENTDATA & p_parent_data)
+{
+  struct Data
+  {
+PARENTDATA & parent_data = p_parent_data;  // { dg-error "parameter" }
+  } data;
+
+  data.parent_data.x = 5;
+  func3(data);
+}
+
+template 
+void func1 (PARENTDATA & p_parent_data)
+{
+  struct Data
+  {
+PARENTDATA & parent_data = p_parent_data;  // { dg-error "parameter" }
+int x = 1;
+  } data;
+
+  func2(data);
+}
+
+int main()
+{
+  Nothing nothing;
+  func1(nothing);
+}

Re: [C++ PATCH] Grammar fix in pt.c comments.

[Adam Butcher]

On 12.08.2013 22:03, Jason Merrill wrote:

On 08/12/2013 04:52 PM, Adam Butcher wrote:
Yes, I must confess up until now I hadn't considered it.  I've just 
been
submitting patches from a clone of http://gcc.gnu.org/git/gcc.git. 
Are

you happy to approve this?


Yes.


Cheers.  Submitted.


If so I'll set up a sourceware account at
http://sourceware.org/cgi-bin/pdw/ps_form.cgi and switch to working 
with

a git-svn clone of the main repo using svn+ssh.


git svn clone takes forever on the gcc repo; much better to connect
git-svn to your existing repository.

http://gcc.gnu.org/wiki/GitMirror#Commit_upstream_.28git-svn.29

I was intending to git-svn fetch only 'trunk' from a few thousand 
revisions back from HEAD, not the whole repo (my response did not make 
this clear).  I had not seen that wiki page before though.  Useful.


Thanks,
Adam

Re: [C++ PATCH] Grammar fix in pt.c comments.

[Jason Merrill]

On 08/12/2013 04:52 PM, Adam Butcher wrote:

Yes, I must confess up until now I hadn't considered it.  I've just been
submitting patches from a clone of http://gcc.gnu.org/git/gcc.git. Are
you happy to approve this?


Yes.


If so I'll set up a sourceware account at
http://sourceware.org/cgi-bin/pdw/ps_form.cgi and switch to working with
a git-svn clone of the main repo using svn+ssh.


git svn clone takes forever on the gcc repo; much better to connect 
git-svn to your existing repository.


http://gcc.gnu.org/wiki/GitMirror#Commit_upstream_.28git-svn.29

Jason

Re: [C++ Patch] Use inform more

[Jason Merrill]

OK.

Jason

Re: [C++ PATCH] Grammar fix in pt.c comments.

[Adam Butcher]

On 12.08.2013 16:33, Jason Merrill wrote:

On 08/12/2013 09:06 AM, Dodji Seketeli wrote:
FWIW, this change seems to fall under the obvious rule and thus, 
ought

to be committed.


Agreed.  But I don't see Adam's name in MAINTAINERS; do you still
need to get set up for write after approval?

Yes, I must confess up until now I hadn't considered it.  I've just 
been submitting patches from a clone of http://gcc.gnu.org/git/gcc.git.  
Are you happy to approve this?  If so I'll set up a sourceware account 
at http://sourceware.org/cgi-bin/pdw/ps_form.cgi and switch to working 
with a git-svn clone of the main repo using svn+ssh.


Cheers,
Adam

Re: [PATCH, vtv update] Fix /tmp directory issues in libvtv

[Mike Stump]

On Aug 10, 2013, at 4:08 PM, Caroline Tice  wrote:
> OK, I have removed the attempt to use $HOME for the logs;

I've reviewed the code and don't see anything I don't like anymore, thanks for 
the work.

Re: RFC - Refactor tree.h

[Mike Stump]

On Aug 11, 2013, at 1:00 AM, Richard Biener  wrote:
> Fact is that we need to separate internal details of tree.h into sth 
> shareable from exactly two places.  Tree-core.h and tree.h are both 'tree.h' 
> in some way. Call it tree-internal.h or tree1.h.

1 is also a bad category; internal or core is better.

[patch, google] Update powerpc64le xfails file.

[Brooks Moses]

One of the Fortran failures in the powerpc64le xfail file I committed
to the Google 4.8 branch last week is no longer failing.  This patch
removes it from the xfails file.

Committed as obvious.

- Brooks


2013-08-12_xfail-fixup.diff
Description: Binary data

Re: [PATCH] Update MAINTAINERS file

[Marek Polacek]

On Mon, Aug 12, 2013 at 12:53:56PM -0700, Caroline Tice wrote:
> Ping?  Is this one of those I can commit without waiting for approval?

Yes.

Marek

Re: [PATCH/Merge Request] Vtable Verification feature.

[Caroline Tice]

On Thu, Aug 8, 2013 at 9:34 AM, Caroline Tice  wrote:
> On Thu, Aug 8, 2013 at 3:27 AM, Rainer Orth  
> wrote:
>> Caroline,
>>
>
>> As an aside, I had a very quick look at libvtv to determine what's
>> required for a port to a non-Linux platform.  It would be good if the
>> requirements (currently, ELF, dl_iterate_phdr, __fortify_fail, certainly
>> several more) could be documented to ease porters' task.
>>
>
>
> I will be working on some documentation for this.
>
>> Thanks.
>>
>> Rainer
>>

I have finished my first pass at the porting documentation.  It is now
available on the vtable verification feature web site:
http://gcc.gnu.org/wiki/vtv

I've never attempted to write porting documentation before, so I'm
hoping that what I wrote is what was needed.  If I missed anything
important, please let me know.

-- Caroline Tice
cmt...@google.com

Re: [PATCH] Update MAINTAINERS file

[Caroline Tice]

Ping?  Is this one of those I can commit without waiting for approval?

-- Caroline Tice
cmt...@google.com


On Sat, Aug 10, 2013 at 1:16 PM, Caroline Tice  wrote:
> I would like to make the following changes to the MAINTAINERS file.
> May I commit this?
>
> -- Caroline Tice
> cmt...@google.com
>
>
> 2013-08-10  Caroline Tice  
>
> * MAINTAINERS: Add myself as libvtv maintainer. Correct my email
> address in the Write After Approval section.

[wwwdocs] mirrors.html -- add link to releases.html

[Gerald Pfeifer]

Looking to simplify our navigation bar, I realised that our
mirrors page fails to link to our releases page.

Applied.

Gerald

Index: mirrors.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/mirrors.html,v
retrieving revision 1.220
diff -u -3 -p -r1.220 mirrors.html
--- mirrors.html30 Mar 2013 20:37:12 -  1.220
+++ mirrors.html12 Aug 2013 19:51:32 -
@@ -8,7 +8,7 @@
 
 GCC mirror sites
 
-Our releases are available on the
+Our releases are available on the
 http://www.gnu.org/prep/ftp.html";>GNU FTP server and its
 mirrors.  The following sites mirror the gcc.gnu.org FTP site
 (Phoenix, Arizona, USA) directly:

Re: [RFC] Bare bones of virtual call tracking

[Xinliang David Li]

It might be more flexible to represent the analysis results as a
type/inheritance graph -- i.e. explicitly introduce inheritance edge
class to capture the interitence relationship (offset, etc) between
two class nodes. The 'method' should probably be augmented to include
vtable slot index info. Inherited (not overridden) methods do not need
to represented in the derived type node etc.

thanks,

David

On Mon, Aug 12, 2013 at 5:16 AM, Jan Hubicka  wrote:
> Hi,
> this patch represents bare bones of what I hope to give me possible targets
> of a virtual call.
>
> I basically added One Definition Rule based hash that unify all types that
> are same in C++ sense (with LTO many of those are still not merged - I hope
> that with few dumps I can improve the merging, too). So every type used in
> virtual method declaration gets assigned odr_type entry.
>
> Then I use BINFO_BASE_BINFOS to walk direct bases and produce a type 
> inheritance
> graph linking type with its bases but also with its derived types.
>
> So I get:
>
> jan@linux-9ure:~/trunk/build/gcc> ./xgcc -B ./ -O2 devirt-1.C
>
>  type 0: struct A
>  defined at: devirt-1.C:7
>  methods:
>virtual int A::foo(int)/0
>  derived types:
>type 1: struct C
>defined at: devirt-1.C:20
>base odr type ids:  0
>methods:
>  virtual int C::foo(int)/2
>
>type 2: struct B
>defined at: devirt-1.C:14
>base odr type ids:  0
>methods:
>  virtual int B::foo(int)/1
>
> I think in future I can also use this for LTO merging (i.e. merge binfos of 
> all
> types equivalent by ODR) and perhaps canonical types can be refined to honor
> ODR when there is no non-ODR language type of same layout.
>
> Now for single inheritance, I think my work is easy:
>
> I have token and type of the virtual call taken from OBJ_TYPE_REF.  I think
> I can just walk my inheritance graph now and on each entry look for method
> with given token (I can take it from virtual table, or I can actually
> use DECL_VINFO and complette my current partial tracking of them) and put
> them into set.  Those should be all possible virtual call targets (defined
> in current unit) of the call.
>
> With multiple inheritance I need to adjust offsets.  I assume for every type,
> I can simply walk binfos, look for mathing type of the call and look for 
> method
> at given token within the binfo.  This will be quadratic.
>
> Other otion would be to track the offsets in my base to derived type link. But
> I do not know how to obtain it, since BINFO_BASE_BINFOS do not track them.
> Shall I look for TYPE_FIELDs instead?
> Does this approach seem to make sense?
>
> Honza
>
> Index: Makefile.in
> ===
> --- Makefile.in (revision 201654)
> +++ Makefile.in (working copy)
> @@ -1275,6 +1275,7 @@
> init-regs.o \
> internal-fn.o \
> ipa-cp.o \
> +   ipa-devirt.o \
> ipa-split.o \
> ipa-inline.o \
> ipa-inline-analysis.o \
> @@ -2945,6 +2946,10 @@
> $(TREE_PASS_H) $(GIMPLE_H) $(TARGET_H) $(GGC_H) pointer-set.h \
> $(IPA_UTILS_H) tree-inline.h $(HASH_TABLE_H) profile.h $(PARAMS_H) \
> $(LTO_STREAMER_H) $(DATA_STREAMER_H)
> +ipa-devirt.o : ipa-devirt.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) 
> $(CGRAPH_H) \
> +   $(TREE_PASS_H) $(GIMPLE_H) $(TARGET_H) $(GGC_H) pointer-set.h \
> +   $(IPA_UTILS_H) tree-inline.h $(HASH_TABLE_H) profile.h $(PARAMS_H) \
> +   $(LTO_STREAMER_H) $(DATA_STREAMER_H)
>  ipa-prop.o : ipa-prop.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \
> langhooks.h $(GGC_H) $(TARGET_H) $(CGRAPH_H) $(IPA_PROP_H) 
> $(DIAGNOSTIC_H) \
> $(TREE_FLOW_H) $(TM_H) $(TREE_PASS_H) $(FLAGS_H) $(TREE_H) \
> Index: ipa-devirt.c
> ===
> --- ipa-devirt.c(revision 0)
> +++ ipa-devirt.c(working copy)
> @@ -0,0 +1,267 @@
> +/* Basic IPA optimizations and utilities.
> +   Copyright (C) 2003-2013 Free Software Foundation, Inc.
> +
> +This file is part of GCC.
> +
> +GCC is free software; you can redistribute it and/or modify it under
> +the terms of the GNU General Public License as published by the Free
> +Software Foundation; either version 3, or (at your option) any later
> +version.
> +
> +GCC 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 GCC; see the file COPYING3.  If not see
> +.  */
> +
> +#include "config.h"
> +#include "system.h"
> +#include "coretypes.h"
> +#include "tm.h"
> +#include "cgraph.h"
> +#include "tree-pass.h"
> +#include "gimple.h"
> +#include "ggc.h"
> +#include "flags.h"
> +#include "pointer-set.h"
> +#include "target.h"
> +#include "tree-iterator.h"
> +#include "pointer-set.h"

Re: [PATCH] x86-64 gcc generate wrong assembly instruction movabs for intel syntax

[Uros Bizjak]

On Mon, Aug 12, 2013 at 11:04 AM, Anna Tikhonova
 wrote:
> Also, there should be an issue with -masm=intel for sse3_monitor. Please see
> attached patch.

We can just use "monitor" with implicit operands here, like in
attached patch. It should handle 32bit, 64bit and x32 targets with ATT
and Intel syntax.

Uros.
Index: i386.c
===
--- i386.c  (revision 201667)
+++ i386.c  (working copy)
@@ -4170,24 +4170,19 @@
   ix86_gen_leave = gen_leave_rex64;
   if (Pmode == DImode)
{
- ix86_gen_monitor = gen_sse3_monitor64_di;
  ix86_gen_tls_global_dynamic_64 = gen_tls_global_dynamic_64_di;
  ix86_gen_tls_local_dynamic_base_64
= gen_tls_local_dynamic_base_64_di;
}
   else
{
- ix86_gen_monitor = gen_sse3_monitor64_si;
  ix86_gen_tls_global_dynamic_64 = gen_tls_global_dynamic_64_si;
  ix86_gen_tls_local_dynamic_base_64
= gen_tls_local_dynamic_base_64_si;
}
 }
   else
-{
-  ix86_gen_leave = gen_leave;
-  ix86_gen_monitor = gen_sse3_monitor;
-}
+ix86_gen_leave = gen_leave;
 
   if (Pmode == DImode)
 {
@@ -4199,6 +4194,7 @@
   ix86_gen_allocate_stack_worker = gen_allocate_stack_worker_probe_di;
   ix86_gen_adjust_stack_and_probe = gen_adjust_stack_and_probedi;
   ix86_gen_probe_stack_range = gen_probe_stack_rangedi;
+  ix86_gen_monitor = gen_sse3_monitor_di;
 }
   else
 {
@@ -4210,6 +4206,7 @@
   ix86_gen_allocate_stack_worker = gen_allocate_stack_worker_probe_si;
   ix86_gen_adjust_stack_and_probe = gen_adjust_stack_and_probesi;
   ix86_gen_probe_stack_range = gen_probe_stack_rangesi;
+  ix86_gen_monitor = gen_sse3_monitor_si;
 }
 
 #ifdef USE_IX86_CLD
Index: sse.md
===
--- sse.md  (revision 201667)
+++ sse.md  (working copy)
@@ -7781,21 +7781,12 @@
   "mwait"
   [(set_attr "length" "3")])
 
-(define_insn "sse3_monitor"
-  [(unspec_volatile [(match_operand:SI 0 "register_operand" "a")
-(match_operand:SI 1 "register_operand" "c")
-(match_operand:SI 2 "register_operand" "d")]
-   UNSPECV_MONITOR)]
-  "TARGET_SSE3 && !TARGET_64BIT"
-  "monitor\t%0, %1, %2"
-  [(set_attr "length" "3")])
-
-(define_insn "sse3_monitor64_"
+(define_insn "sse3_monitor_"
   [(unspec_volatile [(match_operand:P 0 "register_operand" "a")
 (match_operand:SI 1 "register_operand" "c")
 (match_operand:SI 2 "register_operand" "d")]
UNSPECV_MONITOR)]
-  "TARGET_SSE3 && TARGET_64BIT"
+  "TARGET_SSE3"
 ;; 64bit version is "monitor %rax,%rcx,%rdx". But only lower 32bits in
 ;; RCX and RDX are used.  Since 32bit register operands are implicitly
 ;; zero extended to 64bit, we only need to set up 32bit registers.

Re: [RFC] Bare bones of virtual call tracking

[Jan Hubicka]

Hi,
I guess I understand you now about the offsets.  I do not need to update token,
right?  Here is updated and somewhat more complette patch (now I can get list
of possible targets and use it to prune the callgraph)
I also added sanity check that ipa-cp devirtualization actually picks one
of targets from my list.

Honza

Index: ipa-devirt.c
===
--- ipa-devirt.c(revision 0)
+++ ipa-devirt.c(revision 0)
@@ -0,0 +1,359 @@
+/* Basic IPA optimizations and utilities.
+   Copyright (C) 2003-2013 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 3, or (at your option) any later
+version.
+
+GCC 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 GCC; see the file COPYING3.  If not see
+.  */
+
+#include "config.h"
+#include "system.h"
+#include "coretypes.h"
+#include "tm.h"
+#include "cgraph.h"
+#include "tree-pass.h"
+#include "gimple.h"
+#include "ggc.h"
+#include "flags.h"
+#include "pointer-set.h"
+#include "target.h"
+#include "tree-iterator.h"
+#include "pointer-set.h"
+#include "hash-table.h"
+#include "params.h"
+#include "tree-pretty-print.h"
+#include "diagnostic.h"
+
+struct odr_type_d
+{
+  int id;
+  vec types;
+  pointer_set_t *types_set;
+  vec bases;
+  vec derived_types;
+  vec methods;
+};
+
+typedef odr_type_d *odr_type;
+
+/* One Definition Rule hashtable helpers.  */
+
+struct odr_hasher 
+{
+  typedef odr_type_d value_type;
+  typedef odr_type_d compare_type;
+  static inline hashval_t hash (const value_type *);
+  static inline bool equal (const value_type *, const compare_type *);
+  static inline void remove (value_type *);
+};
+
+/* Return the computed hashcode for ODR_TYPE.  */
+
+inline hashval_t
+odr_hasher::hash (const value_type *odr_type)
+{
+  hashval_t hash = 0;
+  tree t = odr_type->types[0];
+  while (t)
+{
+  gcc_assert (TREE_CODE (t) != TYPE_DECL);
+
+  /* Hash the names.  */
+  if (TREE_CODE (t) == IDENTIFIER_NODE)
+   hash = iterative_hash_hashval_t (hash, htab_hash_pointer (t));
+  else if (DECL_P (t))
+{
+ gcc_checking_assert (TREE_CODE (DECL_NAME (t)) == IDENTIFIER_NODE);
+ hash = iterative_hash_hashval_t (hash, htab_hash_pointer (DECL_NAME 
(t)));
+ t = DECL_CONTEXT (t);
+}
+
+  /* Look into type names.  */
+  else if (TYPE_P (t))
+   {
+ t = TYPE_MAIN_VARIANT (t);
+
+ /* Anonymous namespaces must be unique.  */
+ if (TYPE_STUB_DECL (t) && !!TREE_PUBLIC (TYPE_STUB_DECL (t)))
+   return iterative_hash_hashval_t (hash, htab_hash_pointer 
(TYPE_STUB_DECL (t)));
+ /* Skip internal types.  */
+ gcc_assert (TYPE_NAME (t));
+ if (TYPE_NAME (t))
+   {
+ gcc_assert (TREE_CODE (DECL_NAME (TYPE_NAME (t))) == 
IDENTIFIER_NODE);
+ hash = iterative_hash_hashval_t (hash, htab_hash_pointer 
(DECL_NAME (TYPE_NAME (t;
+   }
+ t = TYPE_CONTEXT (t);
+   }
+}
+  return hash;
+}
+
+/* Compare types operations T1 and T2 and return true if they are
+   equivalent.  */
+
+inline bool
+odr_hasher::equal (const value_type *t1, const compare_type *t2)
+{
+  bool same;
+  if (t1->types[0] == t2->types[0])
+return true;
+  same = types_same_for_odr (t1->types[0], t2->types[0]);
+#if 0
+  if (!same
+  && odr_hasher::hash (t1) == odr_hasher::hash (t2))
+{
+  TREE_NO_WARNING (t2->types[0]) = 1;
+  if (TYPE_CANONICAL (t1->types[0]) == TYPE_CANONICAL (t2->types[0]))
+   fprintf (stderr, "Mismatch\n");
+  else
+   fprintf (stderr, "Canonical Mismatch\n");
+  debug_tree (t1->types[0]);
+  debug_tree (t2->types[0]);
+}
+#endif
+  return same;
+}
+
+/* Free a phi operation structure VP.  */
+
+inline void
+odr_hasher::remove (value_type *v)
+{
+  v->types.release ();
+  v->bases.release ();
+  v->methods.release ();
+  free (v);
+}
+
+/* ODR type hash.  */
+typedef hash_table  odr_hash_type;
+odr_hash_type odr_hash;
+vec  odr_types;
+
+/* Get ODR type hash entry for TYPE.  */
+odr_type
+get_odr_type (tree type)
+{
+  odr_type_d key;
+  odr_type_d **slot;
+  odr_type val;
+  hashval_t hash;
+
+  type = TYPE_MAIN_VARIANT (type);
+  key.types = vNULL;
+  key.types.safe_push (type);
+  hash = odr_hasher::hash (&key);
+  slot = odr_hash.find_slot_with_hash (&key, hash, INSERT);
+  if (*slot)
+{
+  val = *slot;
+  key.types.release ();
+  if (!pointer_set_insert (val->types_set, type))
+   {
+ gcc_assert (in_lto_

[C++ Patch] Use inform more

[Paolo Carlini]

Hi,

today I wanted to add a testcase and noticed again that in quite a few 
cases we still use a second error call for the "previous 
declaration"-type message. Thus the below, consisting mostly of 
testsuite adjustments, the code changes themselves should be largely 
obvious.


Tested x86_64-linux.

Thanks!
Paolo.

///
2013-08-12  Paolo Carlini  

* config/i386/i386.c (ix86_function_versions): Use error + inform.

/cp
2013-08-12  Paolo Carlini  

* decl.c (warn_extern_redeclared_static, duplicate_decls,
check_elaborated_type_specifier): Use error + inform.
* friend.c (make_friend_class): Likewise.
* semantics.c (finish_id_expression): Likewise.

/testsuite
2013-08-12  Paolo Carlini  

* g++.dg/cpp0x/constexpr-function2.C: Adjust for error -> inform
changes.
* g++.dg/cpp0x/constexpr-neg1.C: Likewise.
* g++.dg/cpp0x/defaulted2.C: Likewise.
* g++.dg/cpp0x/defaulted31.C: Likewise.
* g++.dg/cpp0x/error6.C: Likewise.
* g++.dg/cpp0x/gen-attrs-32.C: Likewise.
* g++.dg/cpp0x/override2.C: Likewise.
* g++.dg/cpp0x/parse1.C: Likewise.
* g++.dg/cpp0x/scoped_enum.C: Likewise.
* g++.dg/cpp0x/temp_default4.C: Likewise.
* g++.dg/ext/attrib32.C: Likewise.
* g++.dg/ext/gnu-inline-global-reject.C: Likewise.
* g++.dg/ext/mv13.C: Likewise.
* g++.dg/ext/mv7.C: Likewise.
* g++.dg/ext/mv9.C: Likewise.
* g++.dg/ext/pr57362.C: Likewise.
* g++.dg/ext/typeof10.C: Likewise.
* g++.dg/lookup/anon6.C: Likewise.
* g++.dg/lookup/crash6.C: Likewise.
* g++.dg/lookup/name-clash5.C: Likewise.
* g++.dg/lookup/name-clash6.C: Likewise.
* g++.dg/other/anon4.C: Likewise.
* g++.dg/other/error15.C: Likewise.
* g++.dg/other/error8.C: Likewise.
* g++.dg/other/redecl2.C: Likewise.
* g++.dg/parse/crash16.C: Likewise.
* g++.dg/parse/crash21.C: Likewise.
* g++.dg/parse/crash38.C: Likewise.
* g++.dg/parse/redef2.C: Likewise.
* g++.dg/parse/struct-as-enum1.C: Likewise.
* g++.dg/template/crash39.C: Likewise.
* g++.dg/template/redecl3.C: Likewise.
* g++.dg/tls/diag-3.C: Likewise.
* g++.dg/warn/Wredundant-decls-spec.C: Likewise.
* g++.old-deja/g++.benjamin/typedef01.C: Likewise.
* g++.old-deja/g++.benjamin/warn02.C: Likewise.
* g++.old-deja/g++.brendan/crash16.C: Likewise.
* g++.old-deja/g++.brendan/crash18.C: Likewise.
* g++.old-deja/g++.brendan/err-msg4.C: Likewise.
* g++.old-deja/g++.brendan/redecl1.C: Likewise.
* g++.old-deja/g++.brendan/static3.C: Likewise.
* g++.old-deja/g++.bugs/900127_02.C: Likewise.
* g++.old-deja/g++.jason/binding.C: Likewise.
* g++.old-deja/g++.jason/crash4.C: Likewise.
* g++.old-deja/g++.jason/crash7.C: Likewise.
* g++.old-deja/g++.jason/lineno.C: Likewise.
* g++.old-deja/g++.jason/scoping7.C: Likewise.
* g++.old-deja/g++.mike/misc3.C: Likewise.
* g++.old-deja/g++.mike/net44.C: Likewise.
* g++.old-deja/g++.mike/ns3.C: Likewise.
* g++.old-deja/g++.ns/alias4.C: Likewise.
* g++.old-deja/g++.ns/ns11.C: Likewise.
* g++.old-deja/g++.other/crash23.C: Likewise.
* g++.old-deja/g++.other/decl8.C: Likewise.
* g++.old-deja/g++.other/linkage3.C: Likewise.
* g++.old-deja/g++.other/typeck1.C: Likewise.
* g++.old-deja/g++.other/typedef5.C: Likewise.
* g++.old-deja/g++.pt/explicit34.C: Likewise.
* g++.old-deja/g++.pt/friend36.C: Likewise.
* obj-c++.dg/method-8.mm: Likewise.
* obj-c++.dg/tls/diag-3.mm: Likewise.
Index: config/i386/i386.c
===
--- config/i386/i386.c  (revision 201661)
+++ config/i386/i386.c  (working copy)
@@ -29870,8 +29870,8 @@ ix86_function_versions (tree fn1, tree fn2)
  error_at (DECL_SOURCE_LOCATION (fn2),
"missing % attribute for multi-versioned %D",
fn2);
- error_at (DECL_SOURCE_LOCATION (fn1),
-   "previous declaration of %D", fn1);
+ inform (DECL_SOURCE_LOCATION (fn1),
+ "previous declaration of %D", fn1);
  /* Prevent diagnosing of the same error multiple times.  */
  DECL_ATTRIBUTES (fn2)
= tree_cons (get_identifier ("target"),
Index: cp/decl.c
===
--- cp/decl.c   (revision 201661)
+++ cp/decl.c   (working copy)
@@ -1146,8 +1146,9 @@ warn_extern_redeclared_static (tree newdecl, tree
   && DECL_ARTIFICIAL (olddecl))
 return;
 
-  permerror (input_location, "%qD was declared % and later 
%", newdecl);
-  permerror (input_location, "previous declaration of %q+D", olddecl);
+  if (permerror (input_location,
+ 

RE: [PATCH] Fix for PR c/57490

[Iyer, Balaji V]

> -Original Message-
> From: Rainer Orth [mailto:r...@cebitec.uni-bielefeld.de]
> Sent: Friday, August 09, 2013 7:54 AM
> To: Iyer, Balaji V
> Cc: Jakub Jelinek; gcc-patches@gcc.gnu.org; Marek Polacek
> (pola...@redhat.com)
> Subject: Re: [PATCH] Fix for PR c/57490
> 
> Rainer Orth  writes:
> 
> > Rainer Orth  writes:
> >
> >> "Iyer, Balaji V"  writes:
> >>
>  -Original Message-
>  From: Jakub Jelinek [mailto:ja...@redhat.com]
>  Sent: Monday, July 01, 2013 1:09 PM
>  To: Iyer, Balaji V
>  Cc: gcc-patches@gcc.gnu.org; Rainer Orth
>  Subject: Re: [PATCH] Fix for PR c/57490
> 
>  On Mon, Jul 01, 2013 at 05:02:57PM +, Iyer, Balaji V wrote:
>  > OK. The fixed patch is attached. Here are the ChangeLog entries:
>  >
>  > gcc/cp/ChangeLog
>  > 2013-07-01  Balaji V. Iyer  
>  >
> 
>  Still
>   PR c/57490
>  hasn't been added to cp/ChangeLog and c/ChangeLog entries.
>  > --- /dev/null
>  > +++ b/gcc/testsuite/c-c++-common/cilk-plus/AN/pr57490.c
>  > @@ -0,0 +1,25 @@
> 
> >>>
> >>> Fixed as you suggested. Here is the fixed Changelogs and patch is 
> >>> attached.
> >>>
> >>> gcc/cp/ChangeLog
> >>> 2013-07-01  Balaji V. Iyer  
> >>>
> >>> PR c/57490
> >>> * cp-array-notation.c (cp_expand_cond_array_notations): Added a
> >>> check for truth values.
> >>> (expand_array_notation_exprs): Added truth values case.  Removed 
> >>> an
> >>> unwanted else.  Added for-loop to walk through subtrees in default
> >>> case.
> >>>
> >>> gcc/c/ChangeLog
> >>> 2013-07-01  Balaji V. Iyer  
> >>>
> >>> PR c/57490
> >>> * c-array-notation.c (fix_conditional_array_notations_1): Added a
> >>> check for truth values.
> >>> (expand_array_notation_exprs): Added truth values case.  Removed 
> >>> an
> >>> unwanted else.  Added for-loop to walk through subtrees in default
> >>> case.
> >>>
> >>>
> >>> gcc/testsuite/ChangeLog
> >>> 2013-07-01  Balaji V. Iyer  
> >>>
> >>> PR c/57490
> >>> * c-c++-common/cilk-plus/AN/pr57490.c: New test.
> >>
> >> I've just tested this patch on i386-pc-solaris2.10:
> >>
> >> The c-c++-common/cilk-plus/AN/an-if.c test still FAILs for C++:
> >>
> >> FAIL: c-c++-common/cilk-plus/AN/an-if.c  -fcilkplus (internal
> >> compiler error)
> >> FAIL: c-c++-common/cilk-plus/AN/an-if.c  -fcilkplus (test for excess
> >> errors)
> [...]
> > This is still unfixed almost three weeks later.  Balaji, could you
> > please have a look?
> 
> This bug is now unfixed for two months, and no reaction whatsoever on the
> report.  This is getting annoying since it generates large amount of testsuite
> noise.
> 
> Please fix ASAP!
> 

Hi Rainer,

   First off, my sincerest apologies for letting this bug slip the cracks. I am 
attaching a patch that seem to work fine with the .i file that you have 
submitted in bugzilla for both C and C++. Please let me know if this fix works 
for you and if it is OK for trunk.

Here are the Changelog entries:
gcc/c/ChangeLog
2013-08-12  Balaji V. Iyer  

PR c/57490
* c-array-notation.c (fix_conditional_array_notations_1): Added a
check for truth values.
(expand_array_notation_exprs): Added truth values case.  Removed an
unwanted else.  Added for-loop to walk through subtrees in default
case.

gcc/cp/ChangeLog
2013-08-12  Balaji V. Iyer  

PR c/57490
* cp-array-notation.c (cp_expand_cond_array_notations): Added a
check for truth values.
(expand_array_notation_exprs): Added truth values case.  Removed an
unwanted else.  Added for-loop to walk through subtrees in default
case.
* typeck.c (cp_build_binary_op): Inherited the type of the array
notation for built-in array notation functions.

gcc/testsuite/ChangeLog
2013-07-01  Balaji V. Iyer  

PR c/57490
* c-c++-common/cilk-plus/AN/pr57490.c: New test.


Yours sincerely,

Balaji V. Iyer.


>   Rainer
> 
> --
> -
> Rainer Orth, Center for Biotechnology, Bielefeld University
diff --git a/gcc/c/c-array-notation.c b/gcc/c/c-array-notation.c
index 7788f7b..5747bcb 100644
--- a/gcc/c/c-array-notation.c
+++ b/gcc/c/c-array-notation.c
@@ -906,6 +906,8 @@ fix_conditional_array_notations_1 (tree stmt)
 cond = COND_EXPR_COND (stmt);
   else if (TREE_CODE (stmt) == SWITCH_EXPR)
 cond = SWITCH_COND (stmt);
+  else if (truth_value_p (TREE_CODE (stmt)))
+cond = TREE_OPERAND (stmt, 0);
   else
 /* Otherwise dont even touch the statement.  */
 return stmt;
@@ -1232,6 +1234,12 @@ expand_array_notation_exprs (tree t)
 case BIND_EXPR:
   t = expand_array_notation_exprs (BIND_EXPR_BODY (t));
   return t;
+case TRUTH_ORIF_EXPR:
+case TRUTH_ANDIF_EXPR:
+case TRUTH_OR_EXPR:
+case TRUTH_AND_EXPR:
+case TRUTH_XOR_EXPR:

Re: [PATCH, vtv update] Fix /tmp directory issues in libvtv

[Caroline Tice]

On Mon, Aug 12, 2013 at 4:15 AM, Florian Weimer  wrote:
> On 08/12/2013 12:39 AM, Caroline Tice wrote:
>>
>> On Sun, Aug 11, 2013 at 1:04 PM, Florian Weimer 
>> wrote:
>>>
>>> On 08/11/2013 01:08 AM, Caroline Tice wrote:


 OK, I have removed the attempt to use $HOME for the logs; they will
 now either go into the directory specified by the environment variable
 VTV_LOGS_DIR, or they will go into the current directory.  I also
 added code to use secure_getenv, rather than getenv, if it is
 available.  Is this patch ok to commit?
>>>
>>>
>>>
>>> +  logs_prefix = secure_getenv ("VTV_LOGS_DIR");
>>> +  if (!logs_prefix || strlen (logs_prefix) == 0)
>>> +logs_prefix = (char *) ".";
>>>
>>> Hmm. If you fall back to the current directory, using secure_getenv
>>> doesn't
>>> have the intended security effect.  I wonder if we can simply label this
>>> functionality as unsafe for SUID/SGID programs, like we (hopefully) do
>>> for
>>> profiling.
>>>
>>
>> I am unclear how to do this?  Could you elaborate please?
>
>
> I think it boils whether vtv is a debugging feature (like mudflap or
> profiling), or supposed to be active in production code (like the stack
> protector).  If the latter, we have to go to greater lengths in restricting
> the logging feature when running SUID/SGID.
>

The feature is supposed to be active in production code (like the
stack protector).

> Looks like we lost the Cc: to gcc-patches.  Not sure if this is intentional.
> Feel free to add it again.

Done.

-- Caroline Tice
cmt...@google.com

>
>
> --
> Florian Weimer / Red Hat Product Security Team

Re: -mtune-ctrl=.... support, round-2

[Xinliang David Li]

Fixed some formatting issues and typos. There are no regressions with
the attached patch. Ok for trunk?

thanks,

David

On Wed, Aug 7, 2013 at 10:12 PM, Xinliang David Li  wrote:
> Hi, the attached is a follow up patch. The patch includes the following 
> changes:
>
> 1. new option -mno-default -- suggested by H.J. It can be combined
> with -mtune-ctrl= to clear the default settings.
> 2. new option -mdump-tune-features -- this option can be used to dump
> all feature names and their default settings.
> 3. Added documentation to the 3 new options
>
> 4. Move the contents of inital_x86_tune_features into x86-tune.def to
> make sure they are always in sync
> 5. Some refactoring and handle the the tune features properly during
> target option restore.
>
> 2013-08-07  Xinliang David Li  
>
> * config/i386/i386.h: Adjust macro definition.
> * config/i386/i386.opt: Define two new options.
> * config/i386/x86-tune.def: Add arch selector field in macros.
> * config/i386/i386.h: include x86-tune.def.
> * config/i386/i386.c (ix86_option_override_internal):
> Refactor the code.
> (parse_mtune_ctrl_str): New function.
> (set_ix86_tune_features): New function.
> (ix86_function_specific_restore): Call the new helper function.
>
> Ok for trunk after testing?
>
> thanks,
>
> David
>
>
> On Wed, Aug 7, 2013 at 5:22 PM, Xinliang David Li  wrote:
>> On Wed, Aug 7, 2013 at 4:54 PM, Joseph S. Myers  
>> wrote:
>>> On Sun, 4 Aug 2013, Andi Kleen wrote:
>>>
 Richard Biener  writes:
 >
 > The patch fails to add documentation.

 That seems like a feature, it's likely not useful for the general
 public. More for specialized tools that automatically search
 for the best tuning.
>>>
>>> If such a tool is not part of GCC itself, then it is a user of GCC and
>>> documentation should be provided for those writing such a tool.
>>>
>>> Options should be undocumented in very limited cases such as multiple
>>> variant spellings where only one should be used but others are accepted
>>> because they were historically, or whether the user interface to an option
>>> is separate from the internal option passed to cc1 (the documentation is
>>> of options as passed to the driver, but the .opt file may describe options
>>> passed to cc1 as a result of other options being passed to the driver), or
>>> the option really is only for use within the build of GCC itself.
>>> Otherwise, the strong presumption is that all options should be
>>> documented, with appropriate caveats as applicable about the cases where
>>> an option is useful.
>>>
>>
>> Fair enough. I will add the documentation in a followup patch which
>> also implements H.J's proposal -mno-default and cleans up the initial
>> tuning array to be always in sync with new enums.
>>
>>
 > And I am nervous about testing
 > coverage - is this considered a development option only or are random
 > combinations expected to work in all situations? I expect not, thus
 > this looks like a dangerous option?

 When it's undocumented it doesn't need to work in every situation?
>>>
>>> No input files and command-line arguments whatsoever to the driver should
>>> result in ICEs, including undocumented options.
>>
>> True -- if ICEs are found, we should fix them.
>>
>> thanks,
>>
>> David
>>
>>>
>>> --
>>> Joseph S. Myers
>>> jos...@codesourcery.com
Index: config/i386/i386.c
===
--- config/i386/i386.c  (revision 201645)
+++ config/i386/i386.c  (working copy)
@@ -1938,7 +1938,7 @@ const struct processor_costs *ix86_cost
 
 const char* ix86_tune_feature_names[X86_TUNE_LAST] = {
 #undef DEF_TUNE
-#define DEF_TUNE(tune, name) name,
+#define DEF_TUNE(tune, name, selector) name,
 #include "x86-tune.def"
 #undef DEF_TUNE
 };
@@ -1949,281 +1949,10 @@ unsigned char ix86_tune_features[X86_TUN
 /* Feature tests against the various tunings used to create ix86_tune_features
based on the processor mask.  */
 static unsigned int initial_ix86_tune_features[X86_TUNE_LAST] = {
-  /* X86_TUNE_USE_LEAVE: Leave does not affect Nocona SPEC2000 results
- negatively, so enabling for Generic64 seems like good code size
- tradeoff.  We can't enable it for 32bit generic because it does not
- work well with PPro base chips.  */
-  m_386 | m_CORE_ALL | m_K6_GEODE | m_AMD_MULTIPLE | m_GENERIC64,
-
-  /* X86_TUNE_PUSH_MEMORY */
-  m_386 | m_P4_NOCONA | m_CORE_ALL | m_K6_GEODE | m_AMD_MULTIPLE | m_GENERIC,
-
-  /* X86_TUNE_ZERO_EXTEND_WITH_AND */
-  m_486 | m_PENT,
-
-  /* X86_TUNE_UNROLL_STRLEN */
-  m_486 | m_PENT | m_PPRO | m_ATOM | m_SLM | m_CORE_ALL | m_K6 | 
m_AMD_MULTIPLE | m_GENERIC,
-
-  /* X86_TUNE_BRANCH_PREDICTION_HINTS: Branch hints were put in P4 based
- on simulation result. But after P4 was made, no performance benefit
- was observed with branch hints.  It also increases the code size.
- As a result, icc never ge

Re: [PATCH 2/3] Support using 'auto' in a function parameter list to introduce an implicit template parameter.

[Jason Merrill]

On 08/11/2013 03:49 PM, Adam Butcher wrote:

+ if (!(cxx_dialect >= cxx1y && (!flag_iso || lambda_p)))


Again, better to use a pedwarn.


+#define fully_implicit_template scope_chain->x_fully_implicit_template


Why did you choose to add this to saved_scope rather than cp_parser?  It 
seems like state that could be local to the parser rather than shared 
with the rest of the compiler.



+tree type_uses_auto (tree type)
+tree type_uses_auto_or_concept (tree type)


Function name at the beginning of the line.

Jason

Re: Cost model for indirect call speculation

[David Malcolm]

On Mon, 2013-08-12 at 01:11 +0200, Jan Hubicka wrote:
> Hi,
> this patch adds simple cost model into indirect call speculation.

[...]

> Index: cgraph.c
[...]
> *** cgraph_resolve_speculation (struct cgrap
> !   fprintf (dump_file, "Speculative indirect call %s/%i => %s/%i has 
> "
> !"turned out to have contradicitng known target ",
typo, fwiw  ^

Re: [RFC] Bare bones of virtual call tracking

[Jan Hubicka]

> > On 08/12/2013 08:16 AM, Jan Hubicka wrote:
> > >With multiple inheritance I need to adjust offsets.
> > 
> > It's not clear to me that you need to worry about that in your
> > search. A call through a particular vptr can only call overrides
> > that go into a vtable that vptr can point to, and you can look up
> > any thunk adjustments from the vtable.
> 
> What I think I need to worry about is the case, where I have
> type A with a virtual method FOO.  I have call of FOO.
> Now I have type B that inherits A with non-zero offset and overwrites
> method FOO to FOO2.  
> 
> Now call to FOO can be either FOO or FOO2, since someone can make
> object of type B and cast it back to A. 
> How can look it up in B's representation?
> > 
> > >+  /* First skip wrappers that C++ FE puts randomly into types.  */
> > >+  while (TREE_CODE (t) == TYPE_DECL
> > >+   && DECL_ORIGINAL_TYPE (t))
> > 
> > How can you get a decl in your types array?
> 
> Hmm, I am not sure if I can ;) I just copied the ODR code from tree.c.

OK, I don't visit TYPE_DECLs, at least for Mozilla's javascript shell.  I will
remove the code and keep sanity check.  Perhaps it can be dropped from tree.c'
ODR handling too, then.
> 
> One thing I noticed is that I get multiple instances of same type in my
> hash in LTO. It seems to be because TYPE_CANONICAL differs.  I wonder
> what of LTO type merging of TYPE_CANONICAl can mismatch with C++ style
> ODR.

And this was a stupid bug.  Always initialize your initial hash value 
when you hash everything incrementally ;))

Honza
> 
> Honza
> > 
> > Jason

[PING] [PATCH 0/6] Contributing new target port: Andes 'nds32'.

[Chung-Ju Wu]

Hi, GCC Global Maintainers,

The Andes nds32 port has been accepted by GCC SC [1]
and the initial patch is posted on [2] but still needs
global maintainer's approval.

Here are some up-to-date status of nds32 port with current trunk:
 a) Using a native compiler from current GCC trunk (20130811, Rev.201651),
the nds32 port can be built cleanly with --enable-werror-always option.
 b) New testing results have been published on [3]:

Since it has been two weeks and there is no further comment
for nds32 initial patch, could any global maintainer approve it
so that I may commit the patches into trunk?

We and Andes Technology Corporation really appreciate it. :) 


Best regards,
jasonwucj

[1] http://gcc.gnu.org/ml/gcc/2013-07/msg00232.html

[2] http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01144.html

[3] http://gcc.gnu.org/ml/gcc-testresults/2013-08/msg01142.html
http://gcc.gnu.org/ml/gcc-testresults/2013-08/msg01143.html
http://gcc.gnu.org/ml/gcc-testresults/2013-08/msg01144.html
http://gcc.gnu.org/ml/gcc-testresults/2013-08/msg01145.html

RE: [PATCH][4.8 backport] Fix PR57735

[Kyrylo Tkachov]

> > Ping?
> >
> 
> Ping^2
> 

Ping^3
http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00929.html

>  Thanks,
>  Kyrill
> >
> > > -Original Message-
> > > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> > > ow...@gcc.gnu.org] On Behalf Of Kyrylo Tkachov
> > > Sent: 23 July 2013 10:09
> > > To: 'Richard Sandiford'
> > > Cc: gcc-patches; mi...@it.uu.se; 'Richard Biener'
> > > Subject: RE: [PATCH][4.8 backport] Fix PR57735
> > >
> > > Hi Richard,
> > >
> > > > Richard Sandiford  writes:
> > > > > "Kyrylo Tkachov"  writes:
> > > > >> Hi all,
> > > > >>
> > > > >> The fix for PR57735 is in current trunk (for a different issue I
> > > > think), just
> > > > >> needs a backport to 4.8.
> > > > >> It is r198462 by Richard Sandiford:
> > > > >>
> > > > >> 2013-04-30 Richard Sandiford 
> > > > >>
> > > > >>  * explow.c (plus_constant): Pass "mode" to
> > > immed_double_int_const.
> > > > >>  Use gen_int_mode rather than GEN_INT.
> > > > >>
> > > > >> Ok to backport to the 4.8 branch?
> > > > >
> > > > > Sorry for dropping the ball.  It's already been approved for 4.8,
> > > > > and I think I even remembered to test it ready for commit.  I
> just
> > > > > never actually hit commit afterwards :-(
> > > >
> > > > *sigh*.  Scratch that.  I'd confused it with:
> > > >
> > > > 2013-05-22  Richard Sandiford  
> > > >
> > > > * recog.c (offsettable_address_addr_space_p): Fix calculation
> of
> > > > address mode.  Move pointer mode initialization to the same
> place.
> > > >
> > > > which I _did_ apply to 4.8.  Sorry about the confusion instead...
> > >
> > > It's ok, didn't have time to act on the confusion anyway :)
> > >
> > > So is the proposed one ok to backport? I've bootstrapped it on
> > > arm-none-linux-gnueabihf and tested on arm-none-eabi with qemu.
> > >
> > >
> > > Thanks,
> > > Kyrill
> > >
> > >
> > >
> > >
> >
> >
> >
> >

Re: [RFC] Bare bones of virtual call tracking

[Jan Hubicka]

> On 08/12/2013 08:16 AM, Jan Hubicka wrote:
> >With multiple inheritance I need to adjust offsets.
> 
> It's not clear to me that you need to worry about that in your
> search. A call through a particular vptr can only call overrides
> that go into a vtable that vptr can point to, and you can look up
> any thunk adjustments from the vtable.

What I think I need to worry about is the case, where I have
type A with a virtual method FOO.  I have call of FOO.
Now I have type B that inherits A with non-zero offset and overwrites
method FOO to FOO2.  

Now call to FOO can be either FOO or FOO2, since someone can make
object of type B and cast it back to A. 
How can look it up in B's representation?
> 
> >+  /* First skip wrappers that C++ FE puts randomly into types.  */
> >+  while (TREE_CODE (t) == TYPE_DECL
> >+ && DECL_ORIGINAL_TYPE (t))
> 
> How can you get a decl in your types array?

Hmm, I am not sure if I can ;) I just copied the ODR code from tree.c.
Basically I start with RECORD_TYPE or so, look for TYPE_NAME that gives
me a type decl whose name is identifier. I hash it and recursively look
for context.  I am not 100% sure what I can find in the contextes.
For sure there can be namespaces.

One thing I noticed is that I get multiple instances of same type in my
hash in LTO. It seems to be because TYPE_CANONICAL differs.  I wonder
what of LTO type merging of TYPE_CANONICAl can mismatch with C++ style
ODR.

Honza
> 
> Jason

Re: Fwd: [x86, PATCH] More effecient code for short unsigned conversion to float-point.

[Uros Bizjak]

On Mon, Aug 12, 2013 at 2:31 PM, Kirill Yukhin  wrote:
>
> part of the thread was accidentally removed from gcc-patches.
>
> I've comitted Yuri's patch into ML: 
> http://gcc.gnu.org/ml/gcc-cvs/2013-08/msg00272.html
>
> As far as discussion was out of ML - feel free to object.

I have changed X87MODEF mode iterator to MODEF, since SSE_FLOAT_MODE_P
is always false for XFmode.

2013-08-12  Uros Bizjak  

* config/i386/i386.md (floatunssi2 expand): Use MODEF mode
iterator instead of X87MODEF.

Tested on x86_64-pc-linux-gnu {,-m32}, will be committed to mainline SVN.

Uros.

Index: i386.md
===
--- i386.md (revision 201665)
+++ i386.md (working copy)
@@ -5037,15 +5037,15 @@
&& reload_completed"
   [(set (match_dup 0) (float:X87MODEF (match_dup 1)))])

-(define_expand "floatuns2"
-  [(set (match_operand:X87MODEF 0 "register_operand")
-   (unsigned_float:X87MODEF
+(define_expand "floatuns2"
+  [(set (match_operand:MODEF 0 "register_operand")
+   (unsigned_float:MODEF
  (match_operand:SWI12 1 "nonimmediate_operand")))]
   "!TARGET_64BIT
-   && SSE_FLOAT_MODE_P (mode) && TARGET_SSE_MATH"
+   && SSE_FLOAT_MODE_P (mode) && TARGET_SSE_MATH"
 {
   operands[1] = convert_to_mode (SImode, operands[1], 1);
-  emit_insn (gen_floatsi2 (operands[0], operands[1]));
+  emit_insn (gen_floatsi2 (operands[0], operands[1]));
   DONE;
 })

Re: [PATCH] Possible fix for PR57717 (PowerPC E500v2)

[David Edelsohn]

* config/rs6000/rs6000.c (rs6000_legitimize_reload_address): Don't
perform invalid legitimization on greater-than-word-size modes for
TARGET_E500_DOUBLE.

Disabling greater-than-word-size for E500v2 instead of continually
updating the enumeration seems reasonable.

Thanks, David

Re: [AArch64] Fix name of macros called in the vdup_lane Neon intrinsics

[James Greenhalgh]

On Mon, Aug 12, 2013 at 01:58:34PM +0100, James Greenhalgh wrote:
> 
> Ugh. Typos in arm_neon.h macro names mean that scalar intrinsics end
> up calling macros which don't exist.
> 
> So wherever I have written vget_laneq I should have written
> vgetq_lane.

As this patch is obvious, fixes a silly bug, and there were no
objections I've committed it as revision 201666.

Thanks,
James

> ---
> gcc/
> 
>   * config/aarch64/arm_none.h
>   (vdup_lane_<8,16,32,64>): Fix macro call.

> diff --git a/gcc/config/aarch64/arm_neon.h b/gcc/config/aarch64/arm_neon.h
> index 73a5400..4a480fb 100644
> --- a/gcc/config/aarch64/arm_neon.h
> +++ b/gcc/config/aarch64/arm_neon.h
> @@ -19780,49 +19780,49 @@ vcvtpq_u64_f64 (float64x2_t __a)
>  __extension__ static __inline int8x1_t __attribute__ ((__always_inline__))
>  vdupb_lane_s8 (int8x16_t a, int const b)
>  {
> -  return __aarch64_vget_laneq_s8 (a, b);
> +  return __aarch64_vgetq_lane_s8 (a, b);
>  }
>  
>  __extension__ static __inline uint8x1_t __attribute__ ((__always_inline__))
>  vdupb_lane_u8 (uint8x16_t a, int const b)
>  {
> -  return __aarch64_vget_laneq_u8 (a, b);
> +  return __aarch64_vgetq_lane_u8 (a, b);
>  }
>  
>  __extension__ static __inline int16x1_t __attribute__ ((__always_inline__))
>  vduph_lane_s16 (int16x8_t a, int const b)
>  {
> -  return __aarch64_vget_laneq_s16 (a, b);
> +  return __aarch64_vgetq_lane_s16 (a, b);
>  }
>  
>  __extension__ static __inline uint16x1_t __attribute__ ((__always_inline__))
>  vduph_lane_u16 (uint16x8_t a, int const b)
>  {
> -  return __aarch64_vget_laneq_u16 (a, b);
> +  return __aarch64_vgetq_lane_u16 (a, b);
>  }
>  
>  __extension__ static __inline int32x1_t __attribute__ ((__always_inline__))
>  vdups_lane_s32 (int32x4_t a, int const b)
>  {
> -  return __aarch64_vget_laneq_s32 (a, b);
> +  return __aarch64_vgetq_lane_s32 (a, b);
>  }
>  
>  __extension__ static __inline uint32x1_t __attribute__ ((__always_inline__))
>  vdups_lane_u32 (uint32x4_t a, int const b)
>  {
> -  return __aarch64_vget_laneq_u32 (a, b);
> +  return __aarch64_vgetq_lane_u32 (a, b);
>  }
>  
>  __extension__ static __inline int64x1_t __attribute__ ((__always_inline__))
>  vdupd_lane_s64 (int64x2_t a, int const b)
>  {
> -  return __aarch64_vget_laneq_s64 (a, b);
> +  return __aarch64_vgetq_lane_s64 (a, b);
>  }
>  
>  __extension__ static __inline uint64x1_t __attribute__ ((__always_inline__))
>  vdupd_lane_u64 (uint64x2_t a, int const b)
>  {
> -  return __aarch64_vget_laneq_s64 (a, b);
> +  return __aarch64_vgetq_lane_u64 (a, b);
>  }
>  
>  /* vld1 */

Re: Cost model for indirect call speculation

[Andi Kleen]

Xinliang David Li  writes:

> I like the approach in general -- in the past, indirect call promotion
> and function inlining heuristics are disconnected -- which can lead to
> either missing promotions or useless ones.  This approach solves the
> problem.
>
> On Sun, Aug 11, 2013 at 4:11 PM, Jan Hubicka  wrote:
>> Hi,
>> this patch adds simple cost model into indirect call speculation.  First we 
>> do not
>> turn calls into speculative calls when it seems bad idea (i.e. call is cold)
>> and during inlining we remove speculations that do not seem benefical.
>> On modern chip speculative call sequence without inlining is not really going
>> to fare better than indirect call because of indirect call predictor.
>> So we keep them only if the call was inlined or if the callee is turned to 
>> clone
>> or CONST/PURE flags are propagated to them.
>>
>> We may want to add target hook specifying if target support indirect call 
>> predictor,
>> but I am not sure how important this is in practice.
>
> It might be also useful to introduce a parameter to control the
> behavior so that people can do better experiment. The capability of
> indirect branch predictions varies a lot depending on the target.

With autofdo I guess it would be best to sample for branch
mispredictions using the PMU and use that as guideline.

The branch can be always looked up in the LBR

(e.g. On Intel using BR_MISP_RETIRED.ALL_BRANCHES_PS or using 
BR_MISP_EXEC.TAKEN_INDIRECT_JUMP_NON_CALL_RET [unfortunately speculative
and non precise] or on Atom BR_MISSP_TYPE_RETIRED.IND/IND_CALL)

This will always give you the best information.

-Andi

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

Re: [PATCH 1/3] Support lambda templates.

[Jason Merrill]

On 08/11/2013 03:49 PM, Adam Butcher wrote:

+  if (cxx_dialect < cxx1y || flag_iso)
+   cp_parser_error (parser,
+"lambda templates are only available with "
+"-std=gnu++1y");


Normally we only use flag_iso to disable extensions that can change the 
meaning of conforming code, which I don't think is the case here.  For 
pure extensions, we prefer to use a pedwarn.



+ if (!DECL_TEMPLATE_INFO (decl) || DECL_TEMPLATE_RESULT
+ (DECL_TI_TEMPLATE (decl)) != decl)


This needs reformatting so that the arguments to a macro aren't to the 
left of the macro name.


Jason

Re: [C++ PATCH] Grammar fix in pt.c comments.

[Jason Merrill]

On 08/12/2013 09:06 AM, Dodji Seketeli wrote:

FWIW, this change seems to fall under the obvious rule and thus, ought
to be committed.


Agreed.  But I don't see Adam's name in MAINTAINERS; do you still need 
to get set up for write after approval?


Jason

Re: [RFC] Bare bones of virtual call tracking

[Jason Merrill]

On 08/12/2013 08:16 AM, Jan Hubicka wrote:

With multiple inheritance I need to adjust offsets.


It's not clear to me that you need to worry about that in your search. 
A call through a particular vptr can only call overrides that go into a 
vtable that vptr can point to, and you can look up any thunk adjustments 
from the vtable.



+  /* First skip wrappers that C++ FE puts randomly into types.  */
+  while (TREE_CODE (t) == TYPE_DECL
+&& DECL_ORIGINAL_TYPE (t))


How can you get a decl in your types array?

Jason

Commit: M32R: Fix config problem building m32r-linux toolchains

[Nick Clifton]

Hi Guys,

  I am applying the patch below to fix a small problem building
  m32r-linux toolchains - the glibc-c.o object file was not being built
  because the definition of tmake_file in M32R section of config.gcc was
  not allowing for the inclusion of t-glibc.

Cheers
  Nick

gcc/ChangeLog
2013-08-12  Nick Clifton  

* config.gcc (m32r-linux): Allow for tmake_file not being empty.

Index: gcc/config.gcc
===
--- gcc/config.gcc  (revision 201658)
+++ gcc/config.gcc  (working copy)
@@ -1705,8 +1705,7 @@
;;
 m32r-*-linux*)
tm_file="dbxelf.h elfos.h gnu-user.h linux.h glibc-stdint.h ${tm_file} 
m32r/linux.h"
-   # We override the tmake_file for linux -- why?
-   tmake_file="m32r/t-linux t-slibgcc"
+   tmake_file="${tmake_file} m32r/t-linux t-slibgcc"
gnu_ld=yes
if test x$enable_threads = xyes; then
thread_file='posix'
@@ -1714,8 +1713,7 @@
;;
 m32rle-*-linux*)
tm_file="dbxelf.h elfos.h gnu-user.h linux.h glibc-stdint.h 
m32r/little.h ${tm_file} m32r/linux.h"
-   # We override the tmake_file for linux -- why?
-   tmake_file="m32r/t-linux t-slibgcc"
+   tmake_file="${tmake_file} m32r/t-linux t-slibgcc"
gnu_ld=yes
if test x$enable_threads = xyes; then
thread_file='posix'

Re: [PATCH] x86-64 gcc generate wrong assembly instruction movabs for intel syntax

[Perez Read]

On Mon, Aug 12, 2013 at 9:51 PM, Uros Bizjak  wrote:
> On Mon, Aug 12, 2013 at 3:39 PM, Perez Read  wrote:
>
>> movabs is incorrectly translated into "mov [rax], -1", and causes
>> compile error "Error: ambiguous operand size for `mov' ".
>> It should be "mov QWORD PTR [rax], -1"
>>
>> Bootstrap passed. Regression tested on x86_64-unknown-linux-gnu (pc).
>>
>> 2013-08-10  Perez Read 
>>
>> * config/i386/i386.md (*movabs_1) :  Add  PTR 
>> before
>> operand 0 for intel asm alternative.
>>
>> * testsuite/gcc.target/i386/movabs-1.c : New test.
>
> You should mention PR number in the ChangeLog.
>
> Looks OK, but I think that for consistency this decoration should also
> be added to *movabs_2 pattern.
>
> Uros.

 Hello,

 After the test, I think we can skip this pattern.
 Because the operand 0 must be the register, the assembler will
 determine the size automatically.
>>>
>>> As said, I don't want two similar patterns with a different asm
>>> template in i386.md. So, if decorating movabs_2 works OK, I
>>> propose to change both patterns with your change.
>>>
>>> Uros.
>>
>> There are new patch and changelog. Add " PTR" to both patterns.
>> Bootstrap passed,  Regression tested on x86_64-unknown-linux-gnu (pc).
>>
>> 2013-08-10  Perez Read 
>>
>>  PR target/58132
>>
>>  * config/i386/i386.md (*movabs_1) :  Add  PTR before
>>  operand 0 for intel asm alternative.
>>
>>  * testsuite/gcc.target/i386/movabs-1.c : New test.
>>
>> 2013-08-12  Perez Read 
>>
>>  PR target/58132
>>
>>  * config/i386/i386.md (*movabs_2) :  Add  PTR before
>>  operand 1 for intel asm alternative.
>
> Just merge these two ChangeLog entries.
>
> OK with this change.
>
> BTW: Do you have SVN committ access? Otherwise, I will take care to
> merge your change.
>
> Uros.

Ok, and I add a space before second " PTR", which corrects
the coding style.
I don't have SVN committ access, so thanks for helping me.

2013-08-12  Perez Read 

 PR target/58132
 * config/i386/i386.md (*movabs_1) :  Add  PTR before
 operand 0 for intel asm alternative.
 (*movabs_2): Ditto for operand 1.

 * testsuite/gcc.target/i386/movabs-1.c : New test.


Thanks,
Perez


movabs.patch
Description: Binary data

[PATCH] Possible fix for PR57717 (PowerPC E500v2)

[Julian Brown]

Hi,

At present, mainline fails to build a PowerPC E500v2 cross-compiler for
me because of the bug described in PR57717. The attached patch is a
possible fix for that, although I have been struggling to obtain good
evidence that it is correct due to lack of a working current baseline.

Without the patch, the partially-built compiler ICEs during a
cross-build trying to reload a TImode load instruction: I think this is
because the RTL generated by the clause modified by the attached patch
in rs6000_legitimize_reload_address is not valid for TARGET_E500_DOUBLE.
Simply disallowing all greater-than UNITS_PER_WORD-sized modes seems to
suffice to fix this.

I have tested on current mainline with the candidate patch in
http://gcc.gnu.org/bugzilla//show_bug.cgi?id=57717#c3 and compared the
results with my patch: this gives the same results. I configured with:

[...] --enable-e500_double --with-long-double-128 --with-cpu=8548
--disable-decimal-float --disable-libvtv

with a target of powerpc-linux-gnuspe (this is with our internal build
tools, which unfortunately I can't share), and tested on real hardware.0
(The last two options given are just working around build errors.) The
other test cases in PR57717 appear to work correctly with my patch too.

Unfortunately results show significant degradation relative to r189800
(before the patch identified in PR57717 was applied), though I believe
this to be due to a cause other than my patch (there seems to be some
kind of stack corruption in execute tests -- I've not yet tracked this
down). Also -- possibly related -- I had to add a hack to
rs6000_dwarf_register_span to get through the build, i.e.:

@@ -28940,6 +28940,9 @@ rs6000_dwarf_register_span (rtx reg)
   unsigned regno = REGNO (reg);
   enum machine_mode mode = GET_MODE (reg);
 
+  /* FIXME: This function causes an ICE when emitting Dwarf.  */
+  return NULL_RTX;
+
   if (TARGET_SPE
   && regno < 32
   && (SPE_VECTOR_MODE (GET_MODE (reg))

I am not proposing that particular patch for committing, of course.

OK to commit, or any comments? If anyone's in a position to do some
further testing on the patch, I'd be grateful for that!

Thanks,

Julian

ChangeLog

gcc/
* config/rs6000/rs6000.c (rs6000_legitimize_reload_address): Don't
perform invalid legitimization on greater-than-word-size modes for
TARGET_E500_DOUBLE.
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c	(revision 201609)
+++ gcc/config/rs6000/rs6000.c	(working copy)
@@ -6930,9 +6930,7 @@ rs6000_legitimize_reload_address (rtx x,
   && GET_CODE (XEXP (x, 1)) == CONST_INT
   && reg_offset_p
   && !SPE_VECTOR_MODE (mode)
-  && !(TARGET_E500_DOUBLE && (mode == DFmode || mode == TFmode
-  || mode == DDmode || mode == TDmode
-  || mode == DImode))
+  && !(TARGET_E500_DOUBLE && GET_MODE_SIZE (mode) > UNITS_PER_WORD)
   && (!VECTOR_MODE_P (mode) || VECTOR_MEM_NONE_P (mode)))
 {
   HOST_WIDE_INT val = INTVAL (XEXP (x, 1));

Re: [PATCH] Convert more passes to new dump framework

[Teresa Johnson]

On Tue, Aug 6, 2013 at 10:23 PM, Teresa Johnson  wrote:
> On Tue, Aug 6, 2013 at 9:29 AM, Teresa Johnson  wrote:
>> On Tue, Aug 6, 2013 at 9:01 AM, Martin Jambor  wrote:
>>> Hi,
>>>
>>> On Tue, Aug 06, 2013 at 07:14:42AM -0700, Teresa Johnson wrote:
 On Tue, Aug 6, 2013 at 5:37 AM, Martin Jambor  wrote:
 > On Mon, Aug 05, 2013 at 10:37:00PM -0700, Teresa Johnson wrote:
 >> This patch ports messages to the new dump framework,
 >
 > It would be great this new framework was documented somewhere.  I lost
 > track of what was agreed it would be and from the uses in the
 > vectorizer I was never quite sure how to utilize it in other passes.

 Cc'ing Sharad who implemented this - Sharad, is this documented on a
 wiki or elsewhere?
>>>
>>> Thanks
>>>

 >
 > I'd also like to point out two other minor things inline:
 >
 > [...]
 >
 >> 2013-08-06  Teresa Johnson  
 >> Dehao Chen  
 >>
 >> * dumpfile.c (dump_loc): Add column number to output, make 
 >> newlines
 >> consistent.
 >> * dumpfile.h (OPTGROUP_OTHER): Add and enable under 
 >> OPTGROUP_ALL.
 >> * ipa-inline-transform.c (clone_inlined_nodes):
 >> (cgraph_node_opt_info): New function.
 >> (cgraph_node_call_chain): Ditto.
 >> (dump_inline_decision): Ditto.
 >> (inline_call): Invoke dump_inline_decision.
 >> * doc/invoke.texi: Document optall -fopt-info flag.
 >> * profile.c (read_profile_edge_counts): Use new dump framework.
 >> (compute_branch_probabilities): Ditto.
 >> * passes.c (pass_manager::register_one_dump_file): Use 
 >> OPTGROUP_OTHER
 >> when pass not in any opt group.
 >> * value-prof.c (check_counter): Use new dump framework.
 >> (find_func_by_funcdef_no): Ditto.
 >> (check_ic_target): Ditto.
 >> * coverage.c (get_coverage_counts): Ditto.
 >> (coverage_init): Setup new dump framework.
 >> * ipa-inline.c (inline_small_functions): Set is_in_ipa_inline.
 >> * ipa-inline.h (is_in_ipa_inline): Declare.
 >>
 >> * testsuite/gcc.dg/pr40209.c: Use -fopt-info.
 >> * testsuite/gcc.dg/pr26570.c: Ditto.
 >> * testsuite/gcc.dg/pr32773.c: Ditto.
 >> * testsuite/g++.dg/tree-ssa/dom-invalid.C (struct C): Ditto.
 >>
 >
 > [...]
 >
 >> Index: ipa-inline-transform.c
 >> ===
 >> --- ipa-inline-transform.c  (revision 201461)
 >> +++ ipa-inline-transform.c  (working copy)
 >> @@ -192,6 +192,108 @@ clone_inlined_nodes (struct cgraph_edge *e, bool d
 >>  }
 >>
 >>
 >> +#define MAX_INT_LENGTH 20
 >> +
 >> +/* Return NODE's name and profile count, if available.  */
 >> +
 >> +static const char *
 >> +cgraph_node_opt_info (struct cgraph_node *node)
 >> +{
 >> +  char *buf;
 >> +  size_t buf_size;
 >> +  const char *bfd_name = lang_hooks.dwarf_name (node->symbol.decl, 0);
 >> +
 >> +  if (!bfd_name)
 >> +bfd_name = "unknown";
 >> +
 >> +  buf_size = strlen (bfd_name) + 1;
 >> +  if (profile_info)
 >> +buf_size += (MAX_INT_LENGTH + 3);
 >> +
 >> +  buf = (char *) xmalloc (buf_size);
 >> +
 >> +  strcpy (buf, bfd_name);
 >> +
 >> +  if (profile_info)
 >> +sprintf (buf, "%s ("HOST_WIDEST_INT_PRINT_DEC")", buf, 
 >> node->count);
 >> +  return buf;
 >> +}
 >
 > I'm not sure if output of this function is aimed only at the user or
 > if it is supposed to be used by gcc developers as well.  If the
 > latter, an incredibly useful thing is to also dump node->symbol.order
 > too.  We usually dump it after "/" sign separating it from node name.
 > It is invaluable when examining decisions in C++ code where you can
 > have lots of clones of a node (and also because existing dumps print
 > it, it is easy to combine them).

 The output is useful for both power users doing performance tuning of
 their application, and by gcc developers. Adding the id is not so
 useful for the former, but I agree that it is very useful for compiler
 developers. In fact, in the google branch version we emit more verbose
 information (the lipo module id and the funcdef_no) to help uniquely
 identify the routines and to aid in post-processing by humans and
 tools. So it is probably useful to add something similar here too. Is
 the node->symbol.order more or less unique than the funcdef_no? I see
 that you added a patch a few months ago to print the
 node->symbol.order in the function header, and it also has the
 advantage as you note of matching up with existing ipa dumps.
>>>
>>> node->symbol.order is unique and 

Re: [PATCH] x86-64 gcc generate wrong assembly instruction movabs for intel syntax

[Perez Read]

On Mon, Aug 12, 2013 at 5:26 PM, Uros Bizjak  wrote:
> On Mon, Aug 12, 2013 at 11:24 AM, Perez Read  wrote:
>
 movabs is incorrectly translated into "mov [rax], -1", and causes
 compile error "Error: ambiguous operand size for `mov' ".
 It should be "mov QWORD PTR [rax], -1"

 Bootstrap passed. Regression tested on x86_64-unknown-linux-gnu (pc).

 2013-08-10  Perez Read 

 * config/i386/i386.md (*movabs_1) :  Add  PTR before
 operand 0 for intel asm alternative.

 * testsuite/gcc.target/i386/movabs-1.c : New test.
>>>
>>> You should mention PR number in the ChangeLog.
>>>
>>> Looks OK, but I think that for consistency this decoration should also
>>> be added to *movabs_2 pattern.
>>>
>>> Uros.
>>
>> Hello,
>>
>> After the test, I think we can skip this pattern.
>> Because the operand 0 must be the register, the assembler will
>> determine the size automatically.
>
> As said, I don't want two similar patterns with a different asm
> template in i386.md. So, if decorating movabs_2 works OK, I
> propose to change both patterns with your change.
>
> Uros.

Sorry for forgetting to Cc the mailing list.

There are new patch and changelog. Add " PTR" to both patterns.
Bootstrap passed,  Regression tested on x86_64-unknown-linux-gnu (pc).

2013-08-10  Perez Read 

 PR target/58132

 * config/i386/i386.md (*movabs_1) :  Add  PTR before
 operand 0 for intel asm alternative.

 * testsuite/gcc.target/i386/movabs-1.c : New test.

2013-08-12  Perez Read 

 PR target/58132

 * config/i386/i386.md (*movabs_2) :  Add  PTR before
 operand 1 for intel asm alternative.


Thanks,
Perez


movabs.patch
Description: Binary data

Re: [RFC Patch, Aarch64] : Macros for profile code generation to enable gprof support

[Matthew Gretton-Dann]

Marcus,

On 9 August 2013 18:17, Marcus Shawcroft  wrote:
> On 03/08/13 19:01, Venkataramanan Kumar wrote:
>
>
>> 2013-08-02  Venkataramanan Kumar  
>>
>>   * config/aarch64/aarch64.h (MCOUNT_NAME): Define.
>> (NO_PROFILE_COUNTERS): Likewise.
>> (PROFILE_HOOK): Likewise.
>> (FUNCTION_PROFILER): Likewise.
>>  *  config/aarch64/aarch64.c (aarch64_function_profiler): Remove.
>> .
>>
>> regards,
>> Venkat.
>>
>
> Hi Venkat,
>
> Looking at the various other ports it looks that the majority choose to use
> FUNCTION_PROFILER_HOOK rather than PROFILE_HOOK.
>
> Using PROFILE_HOOK to inject a regular call to to _mcount() means that all
> arguments passed in registers in every function will be spilled and reloaded
> because the _mcount call will kill the caller save registers.
>
> Using the FUNCTION_PROFILER_HOOK and taking care not to kill the caller save
> registers would be less invasive.  The LR argument to _mcount would need to
> be passed in a temporary register, say x9 and _mcount would also need to
> ensure caller save registers are saved and restored.
>
> The latter seems to be a better option to me, is there compelling reason to
> choose PROFILE_HOOK over FUNCTION_PROFILER_HOOK ??

(I think you mean FUNCTION_PROFILER rather than FUNCTION_PROFILER_HOOK
in all the above.)

Using either PROFILE_HOOK or FUNCTION_PROFILER results in a call chain
that looks like the following (assuming the C Library is glibc):

 Function -> _mcount -> _mcount_internal.

Where _mcount_internal is the C function that does the real work and
is provided in glibc.  Importantly this means that _mcount_internal
follows the normal ABI - so we have to save the caller saved registers
somewhere.

Using FUNCTION_PROFILER requires us to write assembler which saves and
restores all caller saved registers every time it is called, and
requires (as you say) a special ABI.  This means _mcount ends up being
a piece of assembly that saves all caller-saved registers (i.e.
parameter-passing & temporary registers) and then makes the call to
_mcount internal before restoring everything on _mcount's return.

Using PROFILE_HOOK will cause the compiler to do all the heavy
lifting, and it will do the minimum required (for example with a
function with one parameter it will only save and restore x0).
_mcount in this case can be a simple function that sets up some
parameters and calls _mcount_internal (or even _mcount could just
alias _mcount_internal).

As to which of PROFILE_HOOK or FUNCTION_PROFILER are "the right way"
(TM) - I don't know - the documentation isn't very clear at all.
PROFILE_HOOK was introduced to support profiling for AIX 4.3.
http://gcc.gnu.org/ml/gcc-patches/2000-12/msg00580.html is the initial
patch, with a reworked patch here:
http://gcc.gnu.org/ml/gcc-patches/2001-02/msg00112.html. The final
commit happening on 2001-02-05.  The patch was introduced because it
was impossible to make FUNCTION_PROFILER work for AIX 4.3 and so a new
hook that worked earlier in the compiler was needed.  There doesn't
seem to have been a discussion about preferring one form over the
other.

In conclusion - I prefer the PROFILE_HOOK method because it makes the
compiler do all the work, and results in less impact on stack usage
and performance.  FUNCTION_PROFILER may impact the code generated by
the compiler less and produce a smaller overall image - but I'm not
sure that's more beneficial.

Thanks,

Matt


-- 
Matthew Gretton-Dann
Linaro Toolchain Working Group
matthew.gretton-d...@linaro.org

Re: [C++ PATCH] Grammar fix in pt.c comments.

[Dodji Seketeli]

Thank you for this patch, Adam.

Adam Butcher  a écrit:

>   * pt.c: Grammar fix in comments ("it's" to "its").

FWIW, this change seems to fall under the obvious rule and thus, ought
to be committed.

>
> ---
>  gcc/cp/pt.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
> index ce899ef..78b7a97 100644
> --- a/gcc/cp/pt.c
> +++ b/gcc/cp/pt.c
> @@ -1986,7 +1986,7 @@ determine_specialization (tree template_id,
> tree decl_arg_types;
>  
> /* This is an ordinary member function.  However, since
> -  we're here, we can assume it's enclosing class is a
> +  we're here, we can assume its enclosing class is a
>template class.  For example,
>  
>  template  struct S { void f(); };
> @@ -4337,7 +4337,7 @@ check_default_tmpl_args (tree decl, tree parms, bool 
> is_primary,
> || DECL_INITIALIZED_IN_CLASS_P (decl)))
>  /* We already checked these parameters when the template was
> declared, so there's no need to do it again now.  This function
> -   was defined in class scope, but we're processing it's body now
> +   was defined in class scope, but we're processing its body now
> that the class is complete.  */
>  return true;
>  
> @@ -7555,7 +7555,7 @@ lookup_template_class_1 (tree d1, tree arglist, tree 
> in_decl, tree context,
>   the one of #0.
>  
>   When we encounter #1, we want to store the partial instantiation
> - of M (template S::M) in it's CLASSTYPE_TI_TEMPLATE.
> + of M (template S::M) in its CLASSTYPE_TI_TEMPLATE.
>  
>   For all cases other than this "explicit specialization of member of a
>   class template", we just want to store the most general template into

-- 
Dodji

[AArch64] Fix name of macros called in the vdup_lane Neon intrinsics

[James Greenhalgh]

Ugh. Typos in arm_neon.h macro names mean that scalar intrinsics end
up calling macros which don't exist.

So wherever I have written vget_laneq I should have written
vgetq_lane.

This gets fixed by:
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00535.html
which I was testing at the same time.

But, yuck that shouldn't have happened.

Tested on aarch64-none-elf with no regressions.

OK?

Thanks,
James

---
gcc/

* config/aarch64/arm_none.h
(vdup_lane_<8,16,32,64>): Fix macro call.diff --git a/gcc/config/aarch64/arm_neon.h b/gcc/config/aarch64/arm_neon.h
index 73a5400..4a480fb 100644
--- a/gcc/config/aarch64/arm_neon.h
+++ b/gcc/config/aarch64/arm_neon.h
@@ -19780,49 +19780,49 @@ vcvtpq_u64_f64 (float64x2_t __a)
 __extension__ static __inline int8x1_t __attribute__ ((__always_inline__))
 vdupb_lane_s8 (int8x16_t a, int const b)
 {
-  return __aarch64_vget_laneq_s8 (a, b);
+  return __aarch64_vgetq_lane_s8 (a, b);
 }
 
 __extension__ static __inline uint8x1_t __attribute__ ((__always_inline__))
 vdupb_lane_u8 (uint8x16_t a, int const b)
 {
-  return __aarch64_vget_laneq_u8 (a, b);
+  return __aarch64_vgetq_lane_u8 (a, b);
 }
 
 __extension__ static __inline int16x1_t __attribute__ ((__always_inline__))
 vduph_lane_s16 (int16x8_t a, int const b)
 {
-  return __aarch64_vget_laneq_s16 (a, b);
+  return __aarch64_vgetq_lane_s16 (a, b);
 }
 
 __extension__ static __inline uint16x1_t __attribute__ ((__always_inline__))
 vduph_lane_u16 (uint16x8_t a, int const b)
 {
-  return __aarch64_vget_laneq_u16 (a, b);
+  return __aarch64_vgetq_lane_u16 (a, b);
 }
 
 __extension__ static __inline int32x1_t __attribute__ ((__always_inline__))
 vdups_lane_s32 (int32x4_t a, int const b)
 {
-  return __aarch64_vget_laneq_s32 (a, b);
+  return __aarch64_vgetq_lane_s32 (a, b);
 }
 
 __extension__ static __inline uint32x1_t __attribute__ ((__always_inline__))
 vdups_lane_u32 (uint32x4_t a, int const b)
 {
-  return __aarch64_vget_laneq_u32 (a, b);
+  return __aarch64_vgetq_lane_u32 (a, b);
 }
 
 __extension__ static __inline int64x1_t __attribute__ ((__always_inline__))
 vdupd_lane_s64 (int64x2_t a, int const b)
 {
-  return __aarch64_vget_laneq_s64 (a, b);
+  return __aarch64_vgetq_lane_s64 (a, b);
 }
 
 __extension__ static __inline uint64x1_t __attribute__ ((__always_inline__))
 vdupd_lane_u64 (uint64x2_t a, int const b)
 {
-  return __aarch64_vget_laneq_s64 (a, b);
+  return __aarch64_vgetq_lane_u64 (a, b);
 }
 
 /* vld1 */

Re: Fwd: [x86, PATCH] More effecient code for short unsigned conversion to float-point.

[Kirill Yukhin]

On 12 Aug 16:12, Yuri Rumyantsev wrote:

Hello,
part of the thread was accidentally removed from gcc-patches.

I've comitted Yuri's patch into ML: 
http://gcc.gnu.org/ml/gcc-cvs/2013-08/msg00272.html

As far as discussion was out of ML - feel free to object.

Thanks, K

> -- Forwarded message --
> From: Uros Bizjak 
> Date: 2013/8/7
> Subject: Re: [x86, PATCH] More effecient code for short unsigned
> conversion to float-point.
> To: Yuri Rumyantsev 
> 
> 
> Ah, OK, I see where I did a thinko.
> 
> The patch looks OK, then.
> 
> Uros.
> 

Re: [PATCH, PR 57748] Set mode of structures with zero sized arrays to be BLK

[David Abdurachmanov]

Hi,

Ping. Any news of the following patch being included into the trunk?

Thanks,
david

On Aug 2, 2013, at 1:45 PM, Martin Jambor wrote:

> Hi,
> 
> while compute_record_mode in stor-layout.c makes sure it assigns BLK
> mode to structs with flexible arrays, it has no such provisions for
> zero length arrays
> (http://gcc.gnu.org/onlinedocs/gcc-4.8.1/gcc/Zero-Length.html).  I
> think that in order to avoid problems and surprises like PR 57748
> (where this triggered code that was intended for small structures that
> fit into a scalar mode and ICEd), we should assign both variable array
> possibilities the same mode.
> 
> Bootstrapped and tested on x86_64-linux without any problems.  OK for
> trunk and the 4.8 branch?  (I'm not sure about the 4.7, this PR does
> not happen there despite the wrong mode so I'd ignore it for now.)
> 
> Thanks,
> 
> Martin
> 
> 
> 2013-08-01  Martin Jambor  
> 
>   PR middle-end/57748
>   * stor-layout.c (compute_record_mode): Treat zero-sized array fields
>   like incomplete types.
> 
> testsuite/
>   * gcc.dg/torture/pr57748.c: New test.
> 
> 
> *** /tmp/lV6Ba8_stor-layout.c Thu Aug  1 16:28:25 2013
> --- gcc/stor-layout.c Thu Aug  1 15:36:18 2013
> *** compute_record_mode (tree type)
> *** 1604,1610 
>  && integer_zerop (TYPE_SIZE (TREE_TYPE (field)
> || ! host_integerp (bit_position (field), 1)
> || DECL_SIZE (field) == 0
> !   || ! host_integerp (DECL_SIZE (field), 1))
>   return;
> 
>/* If this field is the whole struct, remember its mode so
> --- 1604,1612 
>  && integer_zerop (TYPE_SIZE (TREE_TYPE (field)
> || ! host_integerp (bit_position (field), 1)
> || DECL_SIZE (field) == 0
> !   || ! host_integerp (DECL_SIZE (field), 1)
> !   || (TREE_CODE (TREE_TYPE (field)) == ARRAY_TYPE
> !   && tree_low_cst (DECL_SIZE (field), 1) == 0))
>   return;
> 
>/* If this field is the whole struct, remember its mode so
> *** /dev/null Tue Jun  4 12:34:56 2013
> --- gcc/testsuite/gcc.dg/torture/pr57748.cThu Aug  1 15:42:14 2013
> ***
> *** 0 
> --- 1,45 
> + /* PR middle-end/57748 */
> + /* { dg-do run } */
> + 
> + #include 
> + 
> + extern void abort (void);
> + 
> + typedef long long V
> +   __attribute__ ((vector_size (2 * sizeof (long long)), may_alias));
> + 
> + typedef struct S { V a; V b[0]; } P __attribute__((aligned (1)));
> + 
> + struct __attribute__((packed)) T { char c; P s; };
> + 
> + void __attribute__((noinline, noclone))
> + check (struct T *t)
> + {
> +   if (t->s.b[0][0] != 3 || t->s.b[0][1] != 4)
> + abort ();
> + }
> + 
> + int __attribute__((noinline, noclone))
> + get_i (void)
> + {
> +   return 0;
> + }
> + 
> + void __attribute__((noinline, noclone))
> + foo (P *p)
> + {
> +   V a = { 3, 4 };
> +   int i = get_i();
> +   p->b[i] = a;
> + }
> + 
> + int
> + main ()
> + {
> +   struct T *t = (struct T *) malloc (128);
> + 
> +   foo (&t->s);
> +   check (t);
> + 
> +   return 0;
> + }

Re: [PATCH, PR 57748] Set mode of structures with zero sized arrays to be BLK

[David Abdurachmanov]

Hi,

Ping. Any news of the following patch being included into the trunk?

Thanks,
david

On Aug 2, 2013, at 1:45 PM, Martin Jambor wrote:

> Hi,
> 
> while compute_record_mode in stor-layout.c makes sure it assigns BLK
> mode to structs with flexible arrays, it has no such provisions for
> zero length arrays
> (http://gcc.gnu.org/onlinedocs/gcc-4.8.1/gcc/Zero-Length.html).  I
> think that in order to avoid problems and surprises like PR 57748
> (where this triggered code that was intended for small structures that
> fit into a scalar mode and ICEd), we should assign both variable array
> possibilities the same mode.
> 
> Bootstrapped and tested on x86_64-linux without any problems.  OK for
> trunk and the 4.8 branch?  (I'm not sure about the 4.7, this PR does
> not happen there despite the wrong mode so I'd ignore it for now.)
> 
> Thanks,
> 
> Martin
> 
> 
> 2013-08-01  Martin Jambor  
> 
>   PR middle-end/57748
>   * stor-layout.c (compute_record_mode): Treat zero-sized array fields
>   like incomplete types.
> 
> testsuite/
>   * gcc.dg/torture/pr57748.c: New test.
> 
> 
> *** /tmp/lV6Ba8_stor-layout.c Thu Aug  1 16:28:25 2013
> --- gcc/stor-layout.c Thu Aug  1 15:36:18 2013
> *** compute_record_mode (tree type)
> *** 1604,1610 
>  && integer_zerop (TYPE_SIZE (TREE_TYPE (field)
> || ! host_integerp (bit_position (field), 1)
> || DECL_SIZE (field) == 0
> !   || ! host_integerp (DECL_SIZE (field), 1))
>   return;
> 
>/* If this field is the whole struct, remember its mode so
> --- 1604,1612 
>  && integer_zerop (TYPE_SIZE (TREE_TYPE (field)
> || ! host_integerp (bit_position (field), 1)
> || DECL_SIZE (field) == 0
> !   || ! host_integerp (DECL_SIZE (field), 1)
> !   || (TREE_CODE (TREE_TYPE (field)) == ARRAY_TYPE
> !   && tree_low_cst (DECL_SIZE (field), 1) == 0))
>   return;
> 
>/* If this field is the whole struct, remember its mode so
> *** /dev/null Tue Jun  4 12:34:56 2013
> --- gcc/testsuite/gcc.dg/torture/pr57748.cThu Aug  1 15:42:14 2013
> ***
> *** 0 
> --- 1,45 
> + /* PR middle-end/57748 */
> + /* { dg-do run } */
> + 
> + #include 
> + 
> + extern void abort (void);
> + 
> + typedef long long V
> +   __attribute__ ((vector_size (2 * sizeof (long long)), may_alias));
> + 
> + typedef struct S { V a; V b[0]; } P __attribute__((aligned (1)));
> + 
> + struct __attribute__((packed)) T { char c; P s; };
> + 
> + void __attribute__((noinline, noclone))
> + check (struct T *t)
> + {
> +   if (t->s.b[0][0] != 3 || t->s.b[0][1] != 4)
> + abort ();
> + }
> + 
> + int __attribute__((noinline, noclone))
> + get_i (void)
> + {
> +   return 0;
> + }
> + 
> + void __attribute__((noinline, noclone))
> + foo (P *p)
> + {
> +   V a = { 3, 4 };
> +   int i = get_i();
> +   p->b[i] = a;
> + }
> + 
> + int
> + main ()
> + {
> +   struct T *t = (struct T *) malloc (128);
> + 
> +   foo (&t->s);
> +   check (t);
> + 
> +   return 0;
> + }

Re: RFA: AVR: Support building AVR Linux targets

[Denis Chertykov]

2013/8/12 Nick Clifton :
> Hi Dennis, Hi Anatoly, Hi Eric,
>
>   I have run into a small problem building GCC for an AVR Linux target -
>   glibc-c.o is not being built.  It turns out that the section handling
>   "avr-*-*" in the config.gcc file is redefining tmake_file without
>   allowing for the fact that t-glibc has already been added to it.
>
>   The patch below is the obvious fix for this problem, but I have not
>   committed it because it occurred to me that there might be some AVR
>   specific reason for not including t-glibc.

I can't remember such reasons.

>  So - is the patch OK, or
>   is there some other way of fixing the problem ?
>
> Cheers
>   Nick
>
> gcc/ChangeLog
> 2013-08-12  Nick Clifton  
>
> * config.gcc (avr-*-*): Allow for tmake_file not being empty.
>
> Index: gcc/config.gcc

Please Apply.

Denis.

[RFC] Bare bones of virtual call tracking

[Jan Hubicka]

Hi,
this patch represents bare bones of what I hope to give me possible targets
of a virtual call.

I basically added One Definition Rule based hash that unify all types that
are same in C++ sense (with LTO many of those are still not merged - I hope
that with few dumps I can improve the merging, too). So every type used in
virtual method declaration gets assigned odr_type entry.

Then I use BINFO_BASE_BINFOS to walk direct bases and produce a type inheritance
graph linking type with its bases but also with its derived types.

So I get:

jan@linux-9ure:~/trunk/build/gcc> ./xgcc -B ./ -O2 devirt-1.C

 type 0: struct A
 defined at: devirt-1.C:7
 methods:
   virtual int A::foo(int)/0
 derived types:
   type 1: struct C
   defined at: devirt-1.C:20
   base odr type ids:  0
   methods:
 virtual int C::foo(int)/2

   type 2: struct B
   defined at: devirt-1.C:14
   base odr type ids:  0
   methods:
 virtual int B::foo(int)/1

I think in future I can also use this for LTO merging (i.e. merge binfos of all
types equivalent by ODR) and perhaps canonical types can be refined to honor
ODR when there is no non-ODR language type of same layout.

Now for single inheritance, I think my work is easy:

I have token and type of the virtual call taken from OBJ_TYPE_REF.  I think
I can just walk my inheritance graph now and on each entry look for method
with given token (I can take it from virtual table, or I can actually
use DECL_VINFO and complette my current partial tracking of them) and put
them into set.  Those should be all possible virtual call targets (defined
in current unit) of the call.

With multiple inheritance I need to adjust offsets.  I assume for every type,
I can simply walk binfos, look for mathing type of the call and look for method
at given token within the binfo.  This will be quadratic.

Other otion would be to track the offsets in my base to derived type link. But
I do not know how to obtain it, since BINFO_BASE_BINFOS do not track them.
Shall I look for TYPE_FIELDs instead? 
Does this approach seem to make sense?

Honza

Index: Makefile.in
===
--- Makefile.in (revision 201654)
+++ Makefile.in (working copy)
@@ -1275,6 +1275,7 @@
init-regs.o \
internal-fn.o \
ipa-cp.o \
+   ipa-devirt.o \
ipa-split.o \
ipa-inline.o \
ipa-inline-analysis.o \
@@ -2945,6 +2946,10 @@
$(TREE_PASS_H) $(GIMPLE_H) $(TARGET_H) $(GGC_H) pointer-set.h \
$(IPA_UTILS_H) tree-inline.h $(HASH_TABLE_H) profile.h $(PARAMS_H) \
$(LTO_STREAMER_H) $(DATA_STREAMER_H)
+ipa-devirt.o : ipa-devirt.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) 
$(CGRAPH_H) \
+   $(TREE_PASS_H) $(GIMPLE_H) $(TARGET_H) $(GGC_H) pointer-set.h \
+   $(IPA_UTILS_H) tree-inline.h $(HASH_TABLE_H) profile.h $(PARAMS_H) \
+   $(LTO_STREAMER_H) $(DATA_STREAMER_H)
 ipa-prop.o : ipa-prop.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \
langhooks.h $(GGC_H) $(TARGET_H) $(CGRAPH_H) $(IPA_PROP_H) $(DIAGNOSTIC_H) \
$(TREE_FLOW_H) $(TM_H) $(TREE_PASS_H) $(FLAGS_H) $(TREE_H) \
Index: ipa-devirt.c
===
--- ipa-devirt.c(revision 0)
+++ ipa-devirt.c(working copy)
@@ -0,0 +1,267 @@
+/* Basic IPA optimizations and utilities.
+   Copyright (C) 2003-2013 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 3, or (at your option) any later
+version.
+
+GCC 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 GCC; see the file COPYING3.  If not see
+.  */
+
+#include "config.h"
+#include "system.h"
+#include "coretypes.h"
+#include "tm.h"
+#include "cgraph.h"
+#include "tree-pass.h"
+#include "gimple.h"
+#include "ggc.h"
+#include "flags.h"
+#include "pointer-set.h"
+#include "target.h"
+#include "tree-iterator.h"
+#include "pointer-set.h"
+#include "hash-table.h"
+#include "params.h"
+#include "tree-pretty-print.h"
+
+struct odr_type_d
+{
+  int id;
+  vec types;
+  pointer_set_t *types_set;
+  vec bases;
+  vec derived_types;
+  vec methods;
+};
+
+typedef odr_type_d *odr_type;
+
+/* One Definition Rule hashtable helpers.  */
+
+struct odr_hasher 
+{
+  typedef odr_type_d value_type;
+  typedef odr_type_d compare_type;
+  static inline hashval_t hash (const value_type *);
+  static inline bool equal (const value_type *, const compare_type *);
+  static inline void remove (value_type *);
+};
+
+/* Return the computed hashcode for ODR_TYPE.  */
+
+inline hashval_t
+odr_hasher::hash (const value_type *odr_type)
+{
+  h

RFA: AVR: Support building AVR Linux targets

[Nick Clifton]

Hi Dennis, Hi Anatoly, Hi Eric,

  I have run into a small problem building GCC for an AVR Linux target -
  glibc-c.o is not being built.  It turns out that the section handling
  "avr-*-*" in the config.gcc file is redefining tmake_file without
  allowing for the fact that t-glibc has already been added to it.

  The patch below is the obvious fix for this problem, but I have not
  committed it because it occurred to me that there might be some AVR
  specific reason for not including t-glibc.  So - is the patch OK, or
  is there some other way of fixing the problem ?

Cheers
  Nick

gcc/ChangeLog
2013-08-12  Nick Clifton  

* config.gcc (avr-*-*): Allow for tmake_file not being empty.

Index: gcc/config.gcc
===
--- gcc/config.gcc  (revision 201658)
+++ gcc/config.gcc  (working copy)
@@ -1001,7 +1001,7 @@
tm_file="${tm_file} ${cpu_type}/avrlibc.h"
tm_defines="${tm_defines} WITH_AVRLIBC"
fi
-   tmake_file="avr/t-avr avr/t-multilib"
+   tmake_file="${tmake_file} avr/t-avr avr/t-multilib"
use_gcc_stdint=wrap
extra_gcc_objs="driver-avr.o avr-devices.o"
extra_objs="avr-devices.o avr-log.o"

  

Backport from trune:

[Andrew Haley]

I think this one is obvious/trivial, but I'll ask anyway.

OK?

Andrew.


2013-08-12  Andrew Haley  

Backport from mainline:
* 2013-07-11  Andreas Schwab  

* config/aarch64/aarch64-linux.h (CPP_SPEC): Define.

Index: gcc/config/aarch64/aarch64-linux.h
===
--- gcc/config/aarch64/aarch64-linux.h  (revision 201661)
+++ gcc/config/aarch64/aarch64-linux.h  (working copy)
@@ -23,6 +23,8 @@

 #define GLIBC_DYNAMIC_LINKER "/lib/ld-linux-aarch64.so.1"

+#define CPP_SPEC "%{pthread:-D_REENTRANT}"
+
 #define LINUX_TARGET_LINK_SPEC  "%{h*} \
%{static:-Bstatic}  \
%{shared:-shared}   \

Re: [PATCH] x86-64 gcc generate wrong assembly instruction movabs for intel syntax

[Uros Bizjak]

On Mon, Aug 12, 2013 at 11:24 AM, Perez Read  wrote:

>>> movabs is incorrectly translated into "mov [rax], -1", and causes
>>> compile error "Error: ambiguous operand size for `mov' ".
>>> It should be "mov QWORD PTR [rax], -1"
>>>
>>> Bootstrap passed. Regression tested on x86_64-unknown-linux-gnu (pc).
>>>
>>> 2013-08-10  Perez Read 
>>>
>>> * config/i386/i386.md (*movabs_1) :  Add  PTR before
>>> operand 0 for intel asm alternative.
>>>
>>> * testsuite/gcc.target/i386/movabs-1.c : New test.
>>
>> You should mention PR number in the ChangeLog.
>>
>> Looks OK, but I think that for consistency this decoration should also
>> be added to *movabs_2 pattern.
>>
>> Uros.
>
> Hello,
>
> After the test, I think we can skip this pattern.
> Because the operand 0 must be the register, the assembler will
> determine the size automatically.

As said, I don't want two similar patterns with a different asm
template in i386.md. So, if decorating movabs_2 works OK, I
propose to change both patterns with your change.

Uros.

Re: [PATCH] x86-64 gcc generate wrong assembly instruction movabs for intel syntax

[Perez Read]

On Mon, Aug 12, 2013 at 2:52 PM, Uros Bizjak  wrote:
> Hello!
>
>> movabs is incorrectly translated into "mov [rax], -1", and causes
>> compile error "Error: ambiguous operand size for `mov' ".
>> It should be "mov QWORD PTR [rax], -1"
>>
>> Bootstrap passed. Regression tested on x86_64-unknown-linux-gnu (pc).
>>
>> 2013-08-10  Perez Read 
>>
>> * config/i386/i386.md (*movabs_1) :  Add  PTR before
>> operand 0 for intel asm alternative.
>>
>> * testsuite/gcc.target/i386/movabs-1.c : New test.
>
> You should mention PR number in the ChangeLog.
>
> Looks OK, but I think that for consistency this decoration should also
> be added to *movabs_2 pattern.
>
> Uros.

Hello,

After the test, I think we can skip this pattern.
Because the operand 0 must be the register, the assembler will
determine the size automatically.

Perez

Fixed ChangeLog
2013-08-10  Perez Read 

 PR target/58132
 * config/i386/i386.md (*movabs_1) :  Add  PTR before
 operand 0 for intel asm alternative.

 * testsuite/gcc.target/i386/movabs-1.c : New test.

Re: [wwwdocs] Add link to @gnutools on Twitter

[James Greenhalgh]

On Mon, Aug 12, 2013 at 01:20:03AM +0100, Gerald Pfeifer wrote:
> David suggested adding this link, and I think it fits nicely.

Does this also deserve a news post? I certainly found it to be
interesting news!

James

Re: [PATCH] Fix PR57980

[Marek Polacek]

On Fri, Aug 09, 2013 at 08:40:00PM +0200, Richard Biener wrote:
> Marek Polacek  wrote:
> >In this PR the problem was that when dealing with the gimple assign in
> >the tailcall optimization, we, when the rhs operand is of a vector
> >type, need to create -1 also of a vector type, but build_int_cst
> >doesn't create vectors (ICEs).  Instead, we should use
> >build_minus_one_cst
> >because that can create even the VECTOR_TYPE constant (and, it can
> >create even REAL_TYPE/COMPLEX_TYPE), as suggested by Marc.
> >
> >Regtested/bootstrapped on x86_64-linux, ok for trunk and 4.8?
> 
> Ok. Double-check that this function exists on the branch please.

It does not :(.  So not backporting to 4.8...

Marek

Re: [PATCH v2 00/18] resurrect automatic dependencies

[Tom Tromey]

> "Tom" == Tom Tromey  writes:

Tom> This is a refresh of my series to resurrect automatic dependency
Tom> tracking.

Ping.

Tom