[PR c++/58072][C++11]

[Ed Smith-Rowland]

This was a bug concerning reporting of compiler errors involving 
user-defined literals.

The error messages would appear with token names 'CPP_STRING_USERDEF', etc.
This is very cryptic for the user.

This patch just catches user-defined literal tokens in 
c-family/c-common.c/c_parse_error() and inserts useful phrases in the 
error messages.


Built and tested on x86-64-linux.

OK?

Ed


gcc/c-family:

2013-08-04  Ed Smith-Rowland  <3dw...@verizon.net>

PR c++/58072
* c-common.c (c_parse_error): Catch user-defined literal tokens and
provide useful error strings.


gcc/testsuite:

PR c++/58072
* g++.dg/cpp0x/pr58072.C: New.
Index: c-family/c-common.c
===
--- c-family/c-common.c (revision 201466)
+++ c-family/c-common.c (working copy)
@@ -9352,6 +9352,18 @@
   free (message);
   message = NULL;
 }
+  else if (token_type == CPP_CHAR_USERDEF
+  || token_type == CPP_WCHAR_USERDEF
+  || token_type == CPP_CHAR16_USERDEF
+  || token_type == CPP_CHAR32_USERDEF)
+message = catenate_messages (gmsgid,
+" before user-defined character literal");
+  else if (token_type == CPP_STRING_USERDEF
+  || token_type == CPP_WSTRING_USERDEF
+  || token_type == CPP_STRING16_USERDEF
+  || token_type == CPP_STRING32_USERDEF
+  || token_type == CPP_UTF8STRING_USERDEF)
+message = catenate_messages (gmsgid, " before user-defined string 
literal");
   else if (token_type == CPP_STRING
   || token_type == CPP_WSTRING
   || token_type == CPP_STRING16
Index: testsuite/g++.dg/cpp0x/pr58072.C
===
--- testsuite/g++.dg/cpp0x/pr58072.C(revision 0)
+++ testsuite/g++.dg/cpp0x/pr58072.C(working copy)
@@ -0,0 +1,18 @@
+// { dg-do compile }
+// { dg-options "-std=c++11" }
+
+// PR c++/58072
+
+extern 'c'void*blah(void*); // { dg-error "expected unqualified-id before 
user-defined character literal" }
+extern L'c'void*Lblah(void*); // { dg-error "expected unqualified-id before 
user-defined character literal" }
+extern u'c'void*ublah(void*); // { dg-error "expected unqualified-id before 
user-defined character literal" }
+extern U'c'void*Ublah(void*); // { dg-error "expected unqualified-id before 
user-defined character literal" }
+
+extern "c"void*strblah(void*); // { dg-error "expected unqualified-id before 
user-defined string literal" }
+extern L"c"void*Lstrblah(void*); // { dg-error "expected unqualified-id before 
user-defined string literal" }
+extern u"c"void*ustrblah(void*); // { dg-error "expected unqualified-id before 
user-defined string literal" }
+extern U"c"void*Ustrblah(void*); // { dg-error "expected unqualified-id before 
user-defined string literal" }
+extern u8"c"void*u8strblah(void*); // { dg-error "expected unqualified-id 
before user-defined string literal" }
+
+extern 123void*ULLblah(void*); // { dg-error "expected unqualified-id before 
numeric constant" }
+extern 123.456void*Ldblblah(void*); // { dg-error "expected unqualified-id 
before numeric constant" }

[wwwdocs] Buildstat update for 4.8

[Tom G. Christensen]

Latest results for gcc 4.8.x.

-tgc

Testresults for 4.8.1
  arm-unknown-linux-gnueabi
  hppa2.0w-hp-hpux11.11
  hppa64-hp-hpux11.11
  i386-pc-solaris2.9 (2)
  i686-pc-linux-gnu
  mips-unknown-linux-gnu
  mipsel-unknown-linux-gnu
  powerpc-apple-darwin8.11.0
  powerpc-unknown-linux-gnu
  powerpc64-unknown-linux-gnu
  sparc-sun-solaris2.9
  sparc-unknown-linux-gnu
  x86_64-apple-darwin13.0.0


Testresults for 4.8.0
  hppa1.1-hp-hpux10.20
  i386-pc-solaris2.9

Index: buildstat.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/buildstat.html,v
retrieving revision 1.3
diff -u -r1.3 buildstat.html
--- buildstat.html  12 May 2013 20:47:31 -  1.3
+++ buildstat.html  4 Aug 2013 08:31:10 -
@@ -26,11 +26,20 @@
 arm-unknown-linux-gnueabi
  
 Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2013-06/msg01612.html";>4.8.1,
 http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg02658.html";>4.8.0
 
 
 
 
+hppa1.1-hp-hpux10.20
+ 
+Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2013-05/msg02368.html";>4.8.0
+
+
+
+
 hppa2.0w-hp-hpux11.00
  
 Test results:
@@ -42,6 +51,7 @@
 hppa2.0w-hp-hpux11.11
  
 Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2013-07/msg01045.html";>4.8.1,
 http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg02538.html";>4.8.0
 
 
@@ -58,6 +68,7 @@
 hppa64-hp-hpux11.11
  
 Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2013-07/msg01207.html";>4.8.1,
 http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg02679.html";>4.8.0
 
 
@@ -74,6 +85,9 @@
 i386-pc-solaris2.9
  
 Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2013-08/msg00230.html";>4.8.1,
+http://gcc.gnu.org/ml/gcc-testresults/2013-06/msg00416.html";>4.8.1,
+http://gcc.gnu.org/ml/gcc-testresults/2013-06/msg00415.html";>4.8.0,
 http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg02715.html";>4.8.0
 
 
@@ -98,14 +112,24 @@
 i686-pc-linux-gnu
  
 Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2013-07/msg02349.html";>4.8.1,
 http://gcc.gnu.org/ml/gcc-testresults/2013-04/msg03091.html";>4.8.0
 
 
 
 
+mips-unknown-linux-gnu
+ 
+Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2013-06/msg02891.html";>4.8.1
+
+
+
+
 mipsel-unknown-linux-gnu
  
 Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2013-06/msg01568.html";>4.8.1,
 http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg02562.html";>4.8.0
 
 
@@ -114,6 +138,7 @@
 powerpc-apple-darwin8.11.0
  
 Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2013-06/msg00237.html";>4.8.1,
 http://gcc.gnu.org/ml/gcc-testresults/2013-04/msg01012.html";>4.8.0
 
 
@@ -138,14 +163,24 @@
 powerpc-unknown-linux-gnu
  
 Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2013-06/msg01486.html";>4.8.1,
 http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg02452.html";>4.8.0
 
 
 
 
+powerpc64-unknown-linux-gnu
+ 
+Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2013-05/msg03088.html";>4.8.1
+
+
+
+
 sparc-sun-solaris2.9
  
 Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2013-08/msg00243.html";>4.8.1,
 http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg02774.html";>4.8.0,
 http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg02717.html";>4.8.0
 
@@ -171,6 +206,7 @@
 sparc-unknown-linux-gnu
  
 Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2013-06/msg02503.html";>4.8.1,
 http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg02660.html";>4.8.0
 
 
@@ -200,6 +236,14 @@
 
 
 
+x86_64-apple-darwin13.0.0
+ 
+Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2013-07/msg00520.html";>4.8.1
+
+
+
+
 x86_64-unknown-linux-gnu
  
 Test results:

[wwwdocs] Buildstat update for 4.7

[Tom G. Christensen]

Latest results for gcc 4.7.x.

-tgc

Testresults for 4.7.3
  i386-pc-solaris2.8 (2)
  i386-pc-solaris2.9 (2)
  i386-pc-solaris2.11
  sparc-sun-solaris2.8 (2)
  sparc-sun-solaris2.9

Index: buildstat.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/buildstat.html,v
retrieving revision 1.9
diff -u -r1.9 buildstat.html
--- buildstat.html  12 May 2013 23:17:35 -  1.9
+++ buildstat.html  4 Aug 2013 08:40:47 -
@@ -106,6 +106,8 @@
 i386-pc-solaris2.8
  
 Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2013-08/msg00255.html";>4.7.3,
+http://gcc.gnu.org/ml/gcc-testresults/2013-08/msg00254.html";>4.7.3,
 http://gcc.gnu.org/ml/gcc-testresults/2013-05/msg00269.html";>4.7.3,
 http://gcc.gnu.org/ml/gcc-testresults/2012-11/msg01980.html";>4.7.2,
 http://gcc.gnu.org/ml/gcc-testresults/2012-06/msg02064.html";>4.7.1,
@@ -120,6 +122,8 @@
 i386-pc-solaris2.9
  
 Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2013-08/msg00227.html";>4.7.3,
+http://gcc.gnu.org/ml/gcc-testresults/2013-08/msg00226.html";>4.7.3,
 http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02618.html";>4.7.0
 
 
@@ -138,6 +142,7 @@
 i386-pc-solaris2.11
  
 Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2013-05/msg02140.html";>4.7.3,
 http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02519.html";>4.7.0
 
 
@@ -203,6 +208,8 @@
 sparc-sun-solaris2.8
  
 Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2013-08/msg00238.html";>4.7.3,
+http://gcc.gnu.org/ml/gcc-testresults/2013-08/msg00237.html";>4.7.3,
 http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02928.html";>4.7.0,
 http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02621.html";>4.7.0
 
@@ -212,6 +219,7 @@
 sparc-sun-solaris2.9
  
 Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2013-08/msg00242.html";>4.7.3,
 http://gcc.gnu.org/ml/gcc-testresults/2013-05/msg00265.html";>4.7.3,
 http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02620.html";>4.7.0
 

[wwwdocs] Buildstat update for 4.6

[Tom G. Christensen]

Latest results for gcc 4.6.x.

-tgc

Testresults for 4.6.4
  i386-pc-solaris2.8 (2)
  i386-pc-solaris2.9 (2)
  sparc-sun-solaris2.8 (2)
  sparc-sun-solaris2.9

Index: buildstat.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.6/buildstat.html,v
retrieving revision 1.14
diff -u -r1.14 buildstat.html
--- buildstat.html  12 May 2013 19:14:52 -  1.14
+++ buildstat.html  4 Aug 2013 08:39:28 -
@@ -113,6 +113,8 @@
 i386-pc-solaris2.8
  
 Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2013-08/msg00253.html";>4.6.4,
+http://gcc.gnu.org/ml/gcc-testresults/2013-08/msg00252.html";>4.6.4,
 http://gcc.gnu.org/ml/gcc-testresults/2013-05/msg00268.html";>4.6.4,
 http://gcc.gnu.org/ml/gcc-testresults/2012-04/msg02817.html";>4.6.3,
 http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02401.html";>4.6.3,
@@ -133,6 +135,8 @@
 i386-pc-solaris2.9
  
 Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2013-08/msg00225.html";>4.6.4,
+http://gcc.gnu.org/ml/gcc-testresults/2013-08/msg00224.html";>4.6.4,
 http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg02831.html";>4.6.0,
 http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg02718.html";>4.6.0,
 http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg02708.html";>4.6.0
@@ -285,6 +289,8 @@
 sparc-sun-solaris2.8
  
 Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2013-08/msg00236.html";>4.6.4,
+http://gcc.gnu.org/ml/gcc-testresults/2013-08/msg00235.html";>4.6.4,
 http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg01811.html";>4.6.3,
 http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg00337.html";>4.6.3,
 http://gcc.gnu.org/ml/gcc-testresults/2011-11/msg01044.html";>4.6.2,
@@ -303,6 +309,7 @@
 sparc-sun-solaris2.9
  
 Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2013-08/msg00241.html";>4.6.4,
 http://gcc.gnu.org/ml/gcc-testresults/2013-05/msg00264.html";>4.6.4,
 http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg02934.html";>4.6.0,
 http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg02724.html";>4.6.0,

Re: New option to do fine grain control [on|off] of micro-arch specific features : -mtune-ctrl=....

[Richard Biener]

Xinliang David Li  wrote:
>Hi, GCC/i386 currently has about 73 boolean parameters/knobs (defined
>in ix86_tune_features[], indexed by ix86_tune_indices) to perform
>micro-arch specific performance tuning. However such settings are hard
>coded (fixed with a given -mtune setting) and is very hard to do
>performance experiment.
>
>The attached patch fixes the problem. The patch introduces a new
>option -mtune-ctrl=. Its parameter is a comma separated list of
>feature names to turn on associated features. Feature name can be
>prefixed by ^ to do the opposite. For instance,
>
>  -mtune-ctrl=prologue_using_move,epilogue_using_move,^pad_returns
>
>tells the compiler to use move instructions in prologue/epilogue
>(instead of push/pop), and *not* pad return instructions.
>
>To facilitate the change, the feature tuning enums defined in i386.h
>are moved to a new file x86-tune.def and this file can be used to
>generate both the enums and names of the features.
>
>
>Ok for trunk?
>

The patch fails to add documentation. 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?

Richard.
>thanks,
>
>David
>
>2013-08-03  Xinliang David Li  
>
>* config/i386/i386.opt: New option -mtune-ctrl=.
>* config/i386/x86-tune.def: New file.
>* config/i386/i386.h: include x86-tune.def.
>* config/i386/i386.c (ix86_option_override_internal):
>Parsing -mtune-ctrl= option and set tune features.

Re: [PATCH] PR32219, weak hidden reference segfault [PING^2]

[Chung-Lin Tang]

On 13/7/15 1:43 AM, Diego Novillo wrote:
> Could you please repost the patch with its description?  This thread
> is sufficiently old and noisy that I'm not even sure what the patch
> does nor why.

Taking the same example in my first post:

extern void weakfun() __attribute__((weak,visibility("hidden")));
void foo ()
{
  if (weakfun) weakfun();
}

Under -O1 -m32 -fPIC, the address load and test will look like:

(insn 5 2 6 2 (set (reg/f:SI 60)
   (plus:SI (reg:SI 3 bx)
  (const:SI (unspec:SI [
(symbol_ref/i:SI ("f") [flags 0x43]  )
] UNSPEC_GOTOFF {*leasi}
 (expr_list:REG_EQUAL (symbol_ref/i:SI ("f") )
(nil)))

(insn 6 5 7 2 (set (reg:CCZ 17 flags)
(compare:CCZ (reg/f:SI 60)
(const_int 0 [0]))) p.c:8 3 {*cmpsi_ccno_1}
 (nil))

(jump_insn 7 6 8 2 ...


Under -fPIC, the code in rtlanal.c:nonzero_address_p() does not properly
recognize the "PIC-reg + " form of load as a weak symbol; it
returns 'true' immediately after seeing the pic-reg indexing, and does
not test the wrapped symbol for DECL_WEAK.

My patch slightly modifies the test to look into the wrapped symbol when
seeing a "PIC-reg + " form, which I believe has become
the idiomatic form in GCC for such PIC addresses. Richard Sandiford's
concerns were that, UNSPEC really is unspecified, and this might be
overassuming its semantics, plus some targets may not be really
following the idiomatic use.

My final take at the time was, for targets that do follow the common
PIC-reg+const-unspec form, this patch solves the problem, while for
other targets, nothing is changed.

I have re-tested the patch on i686-linux, with clean results. Please see
if this patch can be accepted into trunk (patch attached again for
convenience).

Thanks,
Chung-Lin

2013-08-04  Chung-Lin Tang  

PR target/32219
* rtlanal.c (nonzero_address_p): Robustify checking by look
recursively into PIC constant offsets and (CONST (UNSPEC ...))
expressions.

Index: rtlanal.c
===
--- rtlanal.c   (revision 201473)
+++ rtlanal.c   (working copy)
@@ -393,7 +393,15 @@ nonzero_address_p (const_rtx x)
   /* Handle PIC references.  */
   if (XEXP (x, 0) == pic_offset_table_rtx
   && CONSTANT_P (XEXP (x, 1)))
-   return true;
+   {
+ rtx offset = XEXP (x, 1);
+ if (GET_CODE (offset) == CONST
+ && GET_CODE (XEXP (offset, 0)) == UNSPEC
+ && GET_CODE (XVECEXP (XEXP (offset, 0), 0, 0)) == SYMBOL_REF)
+   return nonzero_address_p (XVECEXP (XEXP (offset, 0), 0, 0));
+
+ return true;
+   }
   return false;
 
 case PRE_MODIFY:
Index: testsuite/gcc.dg/torture/pr32219.c
===
--- testsuite/gcc.dg/torture/pr32219.c  (revision 0)
+++ testsuite/gcc.dg/torture/pr32219.c  (revision 0)
@@ -0,0 +1,12 @@
+/* PR target/32219 */
+/* { dg-do run } */
+/* { dg-require-visibility "" } */
+/* { dg-options "-fPIC" { target fpic } } */
+
+extern void f() __attribute__((weak,visibility("hidden")));
+int main()
+{
+  if (f)
+f();
+  return 0;
+}

Re: New option to do fine grain control [on|off] of micro-arch specific features : -mtune-ctrl=....

[Andi Kleen]

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.

> 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?

-Andi

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

Re: [PR c++/58072][C++11]

[Jason Merrill]

OK.

Jason

Re: New option to do fine grain control [on|off] of micro-arch specific features : -mtune-ctrl=....

[Xinliang David Li]

On Sun, Aug 4, 2013 at 4:40 AM, Richard Biener
 wrote:
> Xinliang David Li  wrote:
>>Hi, GCC/i386 currently has about 73 boolean parameters/knobs (defined
>>in ix86_tune_features[], indexed by ix86_tune_indices) to perform
>>micro-arch specific performance tuning. However such settings are hard
>>coded (fixed with a given -mtune setting) and is very hard to do
>>performance experiment.
>>
>>The attached patch fixes the problem. The patch introduces a new
>>option -mtune-ctrl=. Its parameter is a comma separated list of
>>feature names to turn on associated features. Feature name can be
>>prefixed by ^ to do the opposite. For instance,
>>
>>  -mtune-ctrl=prologue_using_move,epilogue_using_move,^pad_returns
>>
>>tells the compiler to use move instructions in prologue/epilogue
>>(instead of push/pop), and *not* pad return instructions.
>>
>>To facilitate the change, the feature tuning enums defined in i386.h
>>are moved to a new file x86-tune.def and this file can be used to
>>generate both the enums and names of the features.
>>
>>
>>Ok for trunk?
>>
>
> The patch fails to add documentation. 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?
>

This option is intended to be used by developers -- otherwise we will
have to document all possible feature knobs. I saw a couple of
existing options in i386.opt marked as 'Undocumented' -- is this mark
used for case like this?   Since this option is for experimental
purpose, user certainly can shoot their foot with it :)

If there is support of target specific --params which takes strings as
args, it might be a better choice to use that.

thanks,

David

> Richard.
>>thanks,
>>
>>David
>>
>>2013-08-03  Xinliang David Li  
>>
>>* config/i386/i386.opt: New option -mtune-ctrl=.
>>* config/i386/x86-tune.def: New file.
>>* config/i386/i386.h: include x86-tune.def.
>>* config/i386/i386.c (ix86_option_override_internal):
>>Parsing -mtune-ctrl= option and set tune features.
>
>

Re: [PATCH] PR32219, weak hidden reference segfault [PING^2]

[Bernhard Reutner-Fischer]

On 4 August 2013 17:14:36 Chung-Lin Tang  wrote:

On 13/7/15 1:43 AM, Diego Novillo wrote:
> Could you please repost the patch with its description?  This thread
> is sufficiently old and noisy that I'm not even sure what the patch
> does nor why.

Taking the same example in my first post:

extern void weakfun() __attribute__((weak,visibility("hidden")));
void foo ()
{
  if (weakfun) weakfun();
}

Under -O1 -m32 -fPIC, the address load and test will look like:

(insn 5 2 6 2 (set (reg/f:SI 60)
   (plus:SI (reg:SI 3 bx)
  (const:SI (unspec:SI [
(symbol_ref/i:SI ("f") [flags 0x43]  )
] UNSPEC_GOTOFF {*leasi}
 (expr_list:REG_EQUAL (symbol_ref/i:SI ("f") )
(nil)))

(insn 6 5 7 2 (set (reg:CCZ 17 flags)
(compare:CCZ (reg/f:SI 60)
(const_int 0 [0]))) p.c:8 3 {*cmpsi_ccno_1}
 (nil))

(jump_insn 7 6 8 2 ...


Under -fPIC, the code in rtlanal.c:nonzero_address_p() does not properly
recognize the "PIC-reg + " form of load as a weak symbol; it
returns 'true' immediately after seeing the pic-reg indexing, and does
not test the wrapped symbol for DECL_WEAK.

My patch slightly modifies the test to look into the wrapped symbol when
seeing a "PIC-reg + " form, which I believe has become
the idiomatic form in GCC for such PIC addresses. Richard Sandiford's
concerns were that, UNSPEC really is unspecified, and this might be
overassuming its semantics, plus some targets may not be really
following the idiomatic use.

My final take at the time was, for targets that do follow the common
PIC-reg+const-unspec form, this patch solves the problem, while for
other targets, nothing is changed.

I have re-tested the patch on i686-linux, with clean results. Please see
if this patch can be accepted into trunk (patch attached again for
convenience).

Thanks,
Chung-Lin

2013-08-04  Chung-Lin Tang  

PR target/32219
* rtlanal.c (nonzero_address_p): Robustify checking by look
recursively into PIC constant offsets and (CONST (UNSPEC ...))
expressions.

An alternative was to change default_binds_local_1() to reorder the weak 
check, worked at least for me, back then:

http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00665.html
But without the comment or at least a comment that explains it more 
accurately...


Whatever works to get this fixed :)
Thanks


Sent with AquaMail for Android
http://www.aqua-mail.com

Cleanup pretty printers [1/n]

[Gabriel Dos Reis]

This patch replaces uses of pp_string on operators and punctuators with
specialized pretty printing functions.

Tested on an x86_64-suse-linux.  Applied to trunk.

-- Gaby

2013-08-03  Gabriel Dos Reis  

* pretty-print.h (pp_bar_bar): New.
(pp_ampersand_ampersand): Likewise.
(pp_less_equal): Likewise.
(pp_greater_equal): Likewise.
* gimple-pretty-print.c (dump_ternary_rhs): Use specialized pretty
printer functions instead of pp_string or operators and punctuators.
(dump_gimple_call): Likewise.
(dump_gimple_omp_for): Likewise.
(dump_gimple_transaction): Likewise.
(dump_gimple_phi): Likewise.
(pp_gimple_stmt_1): Likewise.
* sched-vis.c (print_insn): Likewise.
* tree-mudflap.c (mf_varname_tree): Likewise.
* tree-pretty-print.c (dump_block_node): Likewise.
(dump_generic_node): Likewise.

c-family/ 
* c-ada-spec.c (pp_ada_tree_identifier): Use specialized pretty
printer functions instead of pp_string or operators and punctuators.
(dump_generic_ada_node): Likewise.
* c-pretty-print.c (pp_c_type_specifier): Likewise.
(pp_c_relational_expression): Likewise.
(pp_c_logical_or_expression): Likewise.

cp/
* error.c (dump_type_prefix): Use specialized pretty printer
functions instead of pp_string or operators and punctuators.
(dump_decl): Likewise.
(dump_expr): Likewise.

Index: c-family/c-ada-spec.c
===
--- c-family/c-ada-spec.c   (revision 201473)
+++ c-family/c-ada-spec.c   (working copy)
@@ -1266,7 +1266,7 @@
 {
   pp_string (buffer, "Class_");
   pp_string (buffer, s);
-  pp_string (buffer, ".");
+  pp_dot (buffer);
 }
 
 }
@@ -1626,7 +1626,7 @@
   if (xloc.file)
 {
   pp_string (buffer, xloc.file);
-  pp_string (buffer, ":");
+  pp_colon (buffer);
   pp_decimal_int (buffer, xloc.line);
 }
 }
@@ -1886,14 +1886,14 @@
  bool first = true;
  spc += INDENT_INCR;
  newline_and_indent (buffer, spc - 1);
- pp_string (buffer, "(");
+ pp_left_paren (buffer);
  for (; value; value = TREE_CHAIN (value))
{
  if (first)
first = false;
  else
{
- pp_string (buffer, ",");
+ pp_comma (buffer);
  newline_and_indent (buffer, spc);
}
 
@@ -1907,7 +1907,7 @@
  dump_generic_ada_node
(buffer, DECL_NAME (type) ? type : TYPE_NAME (node), type,
 cpp_check, spc, 0, true);
- pp_string (buffer, ")");
+ pp_right_paren (buffer);
}
  else
{
@@ -2032,7 +2032,7 @@
pp_string (buffer, "pragma Convention (C, ");
dump_generic_ada_node
  (buffer, type, 0, cpp_check, spc, false, true);
-   pp_string (buffer, ")");
+   pp_right_paren (buffer);
  }
}
   else
Index: c-family/c-pretty-print.c
===
--- c-family/c-pretty-print.c   (revision 201473)
+++ c-family/c-pretty-print.c   (working copy)
@@ -370,7 +370,7 @@
  pp_c_type_specifier (pp, t);
  if (TYPE_PRECISION (t) != prec)
{
- pp_string (pp, ":");
+ pp_colon (pp);
  pp_decimal_int (pp, prec);
}
}
@@ -393,7 +393,7 @@
  gcc_unreachable ();
}
  pp_decimal_int (pp, prec);
- pp_string (pp, ">");
+ pp_greater (pp);
}
}
   break;
@@ -1920,9 +1920,9 @@
   else if (code == GT_EXPR)
pp_greater (pp);
   else if (code == LE_EXPR)
-   pp_string (pp, "<=");
+   pp_less_equal (pp);
   else if (code == GE_EXPR)
-   pp_string (pp, ">=");
+   pp_greater_equal (pp);
   pp_c_whitespace (pp);
   pp_c_shift_expression (pp, TREE_OPERAND (e, 1));
   break;
@@ -2032,7 +2032,7 @@
 {
   pp_c_logical_and_expression (pp, TREE_OPERAND (e, 0));
   pp_c_whitespace (pp);
-  pp_string (pp, "&&");
+  pp_ampersand_ampersand (pp);
   pp_c_whitespace (pp);
   pp_c_inclusive_or_expression (pp, TREE_OPERAND (e, 1));
 }
@@ -2052,7 +2052,7 @@
 {
   pp_c_logical_or_expression (pp, TREE_OPERAND (e, 0));
   pp_c_whitespace (pp);
-  pp_string (pp, "||");
+  pp_bar_bar (pp);
   pp_c_whitespace (pp);
   pp_c_logical_and_expression (pp, TREE_OPERAND (e, 1));
 }
Index: cp/error.c
===
--- 

Re: vector conditional expression with scalar arguments

[Gerald Pfeifer]

On Sat, 13 Jul 2013, Marc Glisse wrote:

2013-07-14  Marc Glisse  

gcc/cp/
* call.c (build_conditional_expr_1): Handle the case with 1 vector
and 2 scalars. Call save_expr before building a vector.
* typeck.c (cp_build_binary_op): Check complain before complaining.


Shouldn't this be documented somewhere (gcc/doc/*.texi and our 
web based release notes)?


Gerald

Re: New branch: ubsan

[Gerald Pfeifer]

On Fri, 5 Jul 2013, Marek Polacek wrote:
> I've created a new branch, called ubsan for work being done for
> Undefined Behavior Sanitizer.  

Mind documenting this in http://gcc.gnu.org/svn.html?  Let me
know if you need help (http://gcc.gnu.org/projects/web.html has
some background).

Gerald

Re: msp430 port

[Gerald Pfeifer]

On Tue, 23 Jul 2013, DJ Delorie wrote:
> Ok, I think I covered everything...

...except one comma. ;-)

> Index: gcc/doc/contrib.texi
> ===
> -Nick Clifton for arm, mcore, fr30, v850, m32r, rx work,
> +Nick Clifton for arm, mcore, fr30, v850, m32r, msp430 rx work,
   ^^^

Gerald

Re: [wwwdocs] Buildstat update for 4.6

[Gerald Pfeifer]

On Sun, 4 Aug 2013, Tom G. Christensen wrote:
> Testresults for 4.6.4
>   i386-pc-solaris2.8 (2)
>   i386-pc-solaris2.9 (2)
>   sparc-sun-solaris2.8 (2)
>   sparc-sun-solaris2.9

Thanks, applied.

Gerald

[C++ Patch] PR 58080

[Paolo Carlini]

Hi,

another case of "Error reporting routines re-entered", due to the 
pedwarns in c-common.c:pointer_int_sum. Usual solution, propagate complain.


Note: I can't just pass the complain of type tsubst_flags_t to 
pointer_int_sum, because it can be, and it is for the testcase, 
tf_none|tf_decltype, I really have to check for tf_warning_or_error. 
Tested x86_64-linux.


Thanks,
Paolo.

/
/c-family
2013-08-05  Paolo Carlini  

PR c++/58080
* c-common.c (pointer_int_sum): Add bool parameter.
* c-common.h (pointer_int_sum): Adjust declaration.

/cp
2013-08-05  Paolo Carlini  

PR c++/58080
* typeck.c (cp_pointer_int_sum): Add tsubst_flags_t parameter.
(cp_build_binary_op): Adjust.

/testsuite
2013-08-05  Paolo Carlini  

PR c++/58080
* g++.dg/cpp0x/pr58080.C: New.
Index: c-family/c-common.c
===
--- c-family/c-common.c (revision 201473)
+++ c-family/c-common.c (working copy)
@@ -4284,7 +4284,7 @@ shorten_compare (tree *op0_ptr, tree *op1_ptr, tre
 
 tree
 pointer_int_sum (location_t loc, enum tree_code resultcode,
-tree ptrop, tree intop)
+tree ptrop, tree intop, bool complain)
 {
   tree size_exp, ret;
 
@@ -4293,14 +4293,20 @@ pointer_int_sum (location_t loc, enum tree_code re
 
   if (TREE_CODE (TREE_TYPE (result_type)) == VOID_TYPE)
 {
-  pedwarn (loc, OPT_Wpointer_arith,
-  "pointer of type % used in arithmetic");
+  if (complain && warn_pointer_arith)
+   pedwarn (loc, OPT_Wpointer_arith,
+"pointer of type % used in arithmetic");
+  else if (!complain)
+   return error_mark_node;
   size_exp = integer_one_node;
 }
   else if (TREE_CODE (TREE_TYPE (result_type)) == FUNCTION_TYPE)
 {
-  pedwarn (loc, OPT_Wpointer_arith,
-  "pointer to a function used in arithmetic");
+  if (complain && warn_pointer_arith)
+   pedwarn (loc, OPT_Wpointer_arith,
+"pointer to a function used in arithmetic");
+  else if (!complain)
+   return error_mark_node;
   size_exp = integer_one_node;
 }
   else
Index: c-family/c-common.h
===
--- c-family/c-common.h (revision 201473)
+++ c-family/c-common.h (working copy)
@@ -790,7 +790,8 @@ extern tree shorten_binary_op (tree result_type, t
and, if so, perhaps change them both back to their original type.  */
 extern tree shorten_compare (tree *, tree *, tree *, enum tree_code *);
 
-extern tree pointer_int_sum (location_t, enum tree_code, tree, tree);
+extern tree pointer_int_sum (location_t, enum tree_code, tree, tree,
+bool = true);
 
 /* Add qualifiers to a type, in the fashion for C.  */
 extern tree c_build_qualified_type (tree, int);
Index: cp/typeck.c
===
--- cp/typeck.c (revision 201473)
+++ cp/typeck.c (working copy)
@@ -43,7 +43,7 @@ static tree pfn_from_ptrmemfunc (tree);
 static tree delta_from_ptrmemfunc (tree);
 static tree convert_for_assignment (tree, tree, impl_conv_rhs, tree, int,
tsubst_flags_t, int);
-static tree cp_pointer_int_sum (enum tree_code, tree, tree);
+static tree cp_pointer_int_sum (enum tree_code, tree, tree, tsubst_flags_t);
 static tree rationalize_conditional_expr (enum tree_code, tree, 
  tsubst_flags_t);
 static int comp_ptr_ttypes_real (tree, tree, int);
@@ -4064,7 +4064,8 @@ cp_build_binary_op (location_t location,
}
  return cp_pointer_int_sum (code,
 ptr_operand, 
-int_operand);
+int_operand,
+complain);
}
   common = 1;
   break;
@@ -4894,7 +4895,8 @@ build_x_vec_perm_expr (location_t loc,
of pointer PTROP and integer INTOP.  */
 
 static tree
-cp_pointer_int_sum (enum tree_code resultcode, tree ptrop, tree intop)
+cp_pointer_int_sum (enum tree_code resultcode, tree ptrop, tree intop,
+   tsubst_flags_t complain)
 {
   tree res_type = TREE_TYPE (ptrop);
 
@@ -4906,7 +4908,8 @@ static tree
   complete_type (TREE_TYPE (res_type));
 
   return pointer_int_sum (input_location, resultcode, ptrop,
- fold_if_not_in_template (intop));
+ fold_if_not_in_template (intop),
+ complain & tf_warning_or_error);
 }
 
 /* Return a tree for the difference of pointers OP0 and OP1.
Index: testsuite/g++.dg/cpp0x/pr58080.C
===
--- testsuite/g++.dg/cpp0x/pr58080.C(revision 0)
+++ testsuite/g++.dg/cpp0x/pr58080.C(working copy)
@@ -0,0 +1,14 @@
+// PR c++/58080
+// { dg-do compile { target c++11 } }
+
+t

Re: [Patch, Fortran, OOP] PR 57306: ICE on valid with class pointer initialization

[Tobias Burnus]

Janus Weil wrote:

ping!


Sorry, I currently have only a shaky internet connection and also no 
access to my development system.


Looking at gfc_class_initializer, I have the impression that it does not 
handle initialization of unlimited polymorphic variables/components. I 
don't know whether initialization is permitted, but my feeling is that 
the following should work:


type t
  class(*), pointer :: x
end type t
type(t), target :: y
integer,target :: z
type(t) :: x = t(y)
type(t) :: x = t(z)
class(*), pointer :: a => y

And I have the feeling that it is not correctly treated - but I might be 
wrong. (Note to the example above: I believe "t(y)" is a valid structure 
constructor, which is not yet supported. But again, I might be wrong 
about either.)



Regarding the example: Does it now work when the target and the pointer 
are in the same scoping unit? Or does one still need to place the 
targets into the module?



2013/7/30 Janus Weil :

The attached update fixes it, and thus should hopefully be
regression-free. It also renames 'gfc_class_null_initializer' to
'gfc_class_initializer', since it now also does other initializations
beside EXPR_NULL.

Will do another regtest to make sure it's clean.

No failures observed. As a test case I'm using now Tobias' extended
version (attached). New ChangeLog below.


Well, the test case does not check whether it works. You either need to 
check the dump - or you need to use dg-do run.


Tobias



2013-07-30  Janus Weil  

 PR fortran/57306
 * class.c (gfc_class_null_initializer): Rename to
 'gfc_class_initializer'. Treat non-NULL init-exprs.
 * gfortran.h (gfc_class_null_initializer): Update prototype.
 * trans-decl.c (gfc_get_symbol_decl): Treat class pointers.
 * trans-expr.c (gfc_conv_initializer): Ditto.
 (gfc_trans_subcomponent_assign): Renamed gfc_class_null_initializer.

2013-07-30  Janus Weil  

 PR fortran/57306
 * gfortran.dg/pointer_init_8.f90: New.

Re: [Patch, Fortran, OOP] PR 57306: ICE on valid with class pointer initialization

[Janus Weil]

Hi Tobias,

> Sorry, I currently have only a shaky internet connection and also no access
> to my development system.

sounds like holidays :)


> Looking at gfc_class_initializer, I have the impression that it does not
> handle initialization of unlimited polymorphic variables/components. I don't
> know whether initialization is permitted, but my feeling is that the
> following should work:
>
> type t
>   class(*), pointer :: x
> end type t
> type(t), target :: y
> integer,target :: z
> type(t) :: x = t(y)
> type(t) :: x = t(z)
> class(*), pointer :: a => y
>
> And I have the feeling that it is not correctly treated - but I might be
> wrong. (Note to the example above: I believe "t(y)" is a valid structure
> constructor, which is not yet supported. But again, I might be wrong about
> either.)

Your example yields (with and without the current patch):

tobias2.f90:7.17:

type(t) :: x = t(y)
 1
Error: Can't convert TYPE(t) to CLASS(*) at (1)
tobias2.f90:8.17:

type(t) :: x = t(z)
 1
Error: Can't convert INTEGER(4) to CLASS(*) at (1)


In fact the patch does not really handle unlimited polymorphics. I
suspect several fixes might be needed to get your test case running.
Is it ok to do this in a follow-up patch?


> Regarding the example: Does it now work when the target and the pointer are
> in the same scoping unit? Or does one still need to place the targets into
> the module?

Well, they will work as soon as PR 55207 is fixed (there is a working
patch already, which hopefully can be committed soon).



>>> No failures observed. As a test case I'm using now Tobias' extended
>>> version (attached). New ChangeLog below.
>
> Well, the test case does not check whether it works. You either need to
> check the dump - or you need to use dg-do run.

Good point. The intention was to use dg-do run, of course.


Anyway, thanks for the review. Is it ok to commit the patch as is and
defer the treatment of unlimited polymorphics into a follow-up patch?

Cheers,
Janus



>>> 2013-07-30  Janus Weil  
>>>
>>>  PR fortran/57306
>>>  * class.c (gfc_class_null_initializer): Rename to
>>>  'gfc_class_initializer'. Treat non-NULL init-exprs.
>>>  * gfortran.h (gfc_class_null_initializer): Update prototype.
>>>  * trans-decl.c (gfc_get_symbol_decl): Treat class pointers.
>>>  * trans-expr.c (gfc_conv_initializer): Ditto.
>>>  (gfc_trans_subcomponent_assign): Renamed gfc_class_null_initializer.
>>>
>>> 2013-07-30  Janus Weil  
>>>
>>>  PR fortran/57306
>>>  * gfortran.dg/pointer_init_8.f90: New.
>
>

Re: [C++14/lambda] Experimental polymorphic lambda patches

[Adam Butcher]

Hi Paolo,

On 03.08.2013 19:38, Paolo Carlini wrote:

.. I don't know if at this Stage we are paying attention to these
minor details, but at least Patch 1 and 3 appear to have some 
overlong

lines.

The patch set referenced by your mail has been superseded (see [1] and 
[2]).  I think most of the overlong lines were review queries or partial 
implementation which have now gone away.  I will ensure prior to 
submitting a final set that changelogs are done and that, to the best of 
my knowledge, the code style guidelines are followed.


For future, is there a convention for the mail 'Subject' that I should 
use to make it clear that I'm requesting feedback rather than expecting 
to get the patch committed as is?  "RFC" rather than "PATCH" perhaps?  I 
have simply been omitting changelogs in the commit logs for "non-final" 
patches.


Cheers,
Adam

[1] http://gcc.gnu.org/ml/gcc-patches/2013-07/threads.html#00755
[2] http://gcc.gnu.org/ml/gcc-patches/2013-08/threads.html#00130

Re: [C++14/lambda] Experimental polymorphic lambda patches

[Paolo Carlini]

On 08/05/2013 12:52 AM, Adam Butcher wrote:

Hi Paolo,

On 03.08.2013 19:38, Paolo Carlini wrote:

.. I don't know if at this Stage we are paying attention to these
minor details, but at least Patch 1 and 3 appear to have some overlong
lines.

The patch set referenced by your mail has been superseded (see [1] and 
[2]).  I think most of the overlong lines were review queries or 
partial implementation which have now gone away.  I will ensure prior 
to submitting a final set that changelogs are done and that, to the 
best of my knowledge, the code style guidelines are followed.

Ah good, thanks!

Paolo.

Re: [PATCH 2/4] [lambda] Support implicit conversion of a stateless generic lambda to a function pointer.

[Adam Butcher]

Hi Jason,

On 03.08.2013 17:18, Jason Merrill wrote:

On 08/01/2013 08:25 AM, Adam Butcher wrote:

+= DECL_TEMPLATE_INFO (callop)
+&& DECL_TEMPLATE_RESULT (DECL_TI_TEMPLATE (callop)) == callop;


An expression broken across lines should be parenthesized.

And let's move the building of 'call' for the non-template case up to
be with the template case.


Done.


Otherwise, looks good!

Cheers.  What should I do about the symtab nullptr issue? 
(http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00043.html)  Should I 
leave the workaround in my patch set as a standalone commit to be 
remedied later or should I try to squash it?  Or is the hack appropriate 
for some reason?


It occurs when  is included (I'm assuming it will with other 
code too) when a generic lambda is defined (whether using 'auto' params 
or an explicit template param list).  The following program is minimal 
and sufficient (with regard to the lambda expression) to cause it.  I've 
deliberately used a capturing explicit lambda template below to remove 
the possibility that the conversion op or implicit template code has 
anything to do with it.


   #include 

   int main()
   {
 int i;
 [i]  (T) {};
   }

It does not matter whether the lambda is declared within a function or 
referenced by an initializer at namespace scope.  The backtrace looks 
like this (when the nullptr checks are removed of course):


  0xaeea1f crash_signal
../../gcc/toplev.c:334
  0xcdff04 tree_check
../../gcc/tree.h:3899
  0xcdff04 decl_assembler_name_hash(tree_node const*)
../../gcc/tree.c:602
  0x8068cf insert_to_assembler_name_hash
../../gcc/symtab.c:130
  0x806d91 symtab_initialize_asm_name_hash()
../../gcc/symtab.c:361
  0x806db8 symtab_node_for_asm(tree_node const*)
../../gcc/symtab.c:374
  0x810670 handle_alias_pairs
../../gcc/cgraphunit.c:1014
  0x81443c finalize_compilation_unit()
../../gcc/cgraphunit.c:2104
  0x62b7ce cp_write_global_declarations()
../../gcc/cp/decl2.c:4357

It occurs because at

  symtab.c:117   tree name = DECL_ASSEMBLER_NAME (node->symbol.decl);

'name' ends up being 0.  GDB gives the following for 
debug_tree(node->symbol.decl) which may give you a clue:


 >
type_0 type_6 QI
size 
unit size 
align 8 symtab 0 alias set -1 canonical type 0x74f46bd0 
method basetype 
arg-types 0x74f46b28>
chain 0x74f46738 T>
chain 0x76716bd0 void>
static external autoinline decl_3 decl_5 QI file bug.cpp line 6 col 
22 align 16 context  initial 


arguments type 0x74f469d8 __lambda0>

readonly unsigned type_6 DI
size 
unit size 
align 64 symtab 0 alias set -1 canonical type 
0x74f46c78>
readonly used unsigned DI file bug.cpp line 6 col 22 size 
 unit size 
align 64 context  
arg-type 
chain 

VOID file bug.cpp line 6 col 21
align 8 context 
   >>
result 0x74f467e0 auto>

ignored VOID file bug.cpp line 6 col 22
align 8 context >
full-name "main()::"
not-really-extern template-info 0x74f41c00
struct-function 0x752cfbe0>

Do you know what could be causing this?  Presumably something that's 
generated in the non-template lambda case needs to be removed in the 
template case (or something new added)?  It is strange that it occurs 
only when  (or presumably some other headers) are included.  
With the two early outs for nullptrs in symtab.c the resulting programs 
behave as expected, I'm just not happy with that solution.


Cheers,
Adam

Re: [PATCH 1/2] make the c++ pretty printer inherit from the C one instead of include it

[Trevor Saunders]

On Wed, Jul 31, 2013 at 10:02:29PM -0500, Gabriel Dos Reis wrote:
>   * declare the "pointer to function fields" as virtual functions --
> that is what I meant
> with the (necessarily poor) emulation through the casts.

I guess you'll work on this later in the patch series you're sending,
but its worth noting making pretty_print_info::format_decoder a virtual
function is non-trivial, it turns out to be important that some
consumers can leave it null instead of making it  what is currently
default_tree_printer.  This is because gcov and maybe other things link
against diagnostic.c and pretty-print.c but not all the tree stuff that
would be required for default_tree_printer.

Trev

>   * override those that needed to be overridden  in cxx_pretty_printer.
>   * adjust the macros.
>   * Have the associated constructors do the right thing.
> 
> 
> 
> -- Gaby

Re: [PATCH 1/2] make the c++ pretty printer inherit from the C one instead of include it

[Gabriel Dos Reis]

On Sun, Aug 4, 2013 at 8:37 PM, Trevor Saunders  wrote:
> On Wed, Jul 31, 2013 at 10:02:29PM -0500, Gabriel Dos Reis wrote:
>>   * declare the "pointer to function fields" as virtual functions --
>> that is what I meant
>> with the (necessarily poor) emulation through the casts.
>
> I guess you'll work on this later in the patch series you're sending,
> but its worth noting making pretty_print_info::format_decoder a virtual
> function is non-trivial, it turns out to be important that some
> consumers can leave it null instead of making it  what is currently
> default_tree_printer.  This is because gcov and maybe other things link
> against diagnostic.c and pretty-print.c but not all the tree stuff that
> would be required for default_tree_printer.

Trev --

Thanks for the piece of info.

Writing OO programming in C is not  fun at all; and undoing
OO C programs is even less fun.

I originally expected clients to derive from the pretty printers and add
their own behavior.  But, it turns out that since OO programming in C
isn't fun, things have grown barnacles and entangled in ways I did not
intend or anticipate.  Hopefully, now that we have a better abstraction tool,
we can express the intent much more directly.

I will send in a patch that adds the inheritance chain from pretty_printer
to cxx_pretty_printer.  Unfortunately, it does not add the virtual functions.
This is because I want to handle 'constructors' in a separate patch.

-- Gaby

Re: New parameters to control stringop expansion libcall strategy

[Xinliang David Li]

The attached is a new patch implementing the stringop inline strategy
control using two new -m options:

-mmemcpy-strategy=
-mmemset-strategy=

See changes in doc/invoke.texi for description of the new options. Example:
  
-mmemcpy-strategy=rep_8byte:64:unaligned,unrolled_loop:2048:unaligned,libcall:-1:unaligned

tells compiler to inline memcpy using rep_8byte when the size is no
larger than 64 byte, using unrolled_loop when size is no larger than
2048, and for size > 2048, using library call. In all cases,
destination alignment adjustment is not done.

Tested on x86-64/linux. Ok for trunk?

thanks,

David

2013-08-02  Xinliang David Li  

* config/i386/stringop.def: New file.
* config/i386/stringop.opt: New file.
* config/i386/i386-opts.h: Include stringopt.def.
* config/i386/i386.opt: Include stringopt.opt.
* config/i386/i386.c (ix86_option_override_internal):
Override default size based stringop inline strategies
with options.
* config/i386/i386.c (ix86_parse_stringop_strategy_string):
New function.

2013-08-04  Xinliang David Li  

* testsuite/gcc.target/i386/memcpy-strategy-1.c: New test.
* testsuite/gcc.target/i386/memcpy-strategy-2.c: Ditto.
* testsuite/gcc.target/i386/memset-strategy-1.c: Ditto.
* testsuite/gcc.target/i386/memcpy-strategy-3.c: Ditto.




On Fri, Aug 2, 2013 at 9:21 PM, Xinliang David Li  wrote:
> On x86_64, when the expected size of memcpy/memset is known (e.g, with
> FDO), libcall strategy is used with the size is > 8192. This value is
> hard coded, which makes it hard to do performance tuning. This patch
> adds two new parameters to do that. Potential usage includes
> per-application libcall strategy min-size tuning based on summary data
> with FDO (e.g, instruction workset size).
>
> Bootstrap and tested on x86_64/linux. Ok for trunk?
>
> thanks,
>
> David
>
>
> 2013-08-02  Xinliang David Li  
>
> * params.def: New parameters.
> * config/i386/i386.c (ix86_option_override_internal):
> Override default libcall size limit with parameters.
Index: config/i386/stringop.def
===
--- config/i386/stringop.def(revision 0)
+++ config/i386/stringop.def(revision 0)
@@ -0,0 +1,42 @@
+/* Definitions for option handling for IA-32.
+   Copyright (C) 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.
+
+Under Section 7 of GPL version 3, you are granted additional
+permissions described in the GCC Runtime Library Exception, version
+3.1, as published by the Free Software Foundation.
+
+You should have received a copy of the GNU General Public License and
+a copy of the GCC Runtime Library Exception along with this program;
+see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+.  */
+
+DEF_ENUM
+DEF_ALG (no_stringop, no_stringop)
+DEF_ENUM
+DEF_ALG (libcall, libcall)
+DEF_ENUM
+DEF_ALG (rep_prefix_1_byte, rep_byte)
+DEF_ENUM
+DEF_ALG (rep_prefix_4_byte, rep_4byte)
+DEF_ENUM
+DEF_ALG (rep_prefix_8_byte, rep_8byte)
+DEF_ENUM
+DEF_ALG (loop_1_byte, byte_loop)
+DEF_ENUM
+DEF_ALG (loop, loop)
+DEF_ENUM
+DEF_ALG (unrolled_loop, unrolled_loop)
+DEF_ENUM
+DEF_ALG (vector_loop, vector_loop)
Index: config/i386/i386.opt
===
--- config/i386/i386.opt(revision 201458)
+++ config/i386/i386.opt(working copy)
@@ -316,6 +316,14 @@ mstack-arg-probe
 Target Report Mask(STACK_PROBE) Save
 Enable stack probing
 
+mmemcpy-strategy=
+Target RejectNegative Joined Var(ix86_tune_memcpy_strategy)
+Specify memcpy expansion strategy when expected size is known
+
+mmemset-strategy=
+Target RejectNegative Joined Var(ix86_tune_memset_strategy)
+Specify memset expansion strategy when expected size is known
+
 mstringop-strategy=
 Target RejectNegative Joined Enum(stringop_alg) Var(ix86_stringop_alg) 
Init(no_stringop)
 Chose strategy to generate stringop using
Index: config/i386/stringop.opt
===
--- config/i386/stringop.opt(revision 0)
+++ config/i386/stringop.opt(revision 0)
@@ -0,0 +1,36 @@
+/* Definitions for option handling for IA-32.
+   Copyright (C) 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; e

Clean up pretty printers [3/n]

[Gabriel Dos Reis]

This patchlet makes the asan module stop using a global pretty printer.
As a result, the code is cleaner that way -- and this is in preparation
of having pretty printers initialize themselves through constructors.

-- Gaby

2013-08-05  Gabriel Dos Reis  

* asan.c (asan_pp): Remove.
(asan_pp_initialized): Likewise.
(asan_pp_initialize): Likewise.
(asan_pp_string): Take a pretty_printer parameter.  Adjust callers.
(asan_emit_stack_protection): Tidy.  Use local pretty printer.
(asan_add_global): Likewise.

Index: asan.c
===
--- asan.c  (revision 201479)
+++ asan.c  (working copy)
@@ -842,25 +842,12 @@
   initialize_sanitizer_builtins ();
 }
 
-/* Asan pretty-printer, used for buidling of the description STRING_CSTs.  */
-static pretty_printer asan_pp;
-static bool asan_pp_initialized;
+/* Create ADDR_EXPR of STRING_CST with the PP pretty printer text.  */
 
-/* Initialize asan_pp.  */
-
-static void
-asan_pp_initialize (void)
-{
-  pp_construct (&asan_pp, /* prefix */NULL, /* line-width */0);
-  asan_pp_initialized = true;
-}
-
-/* Create ADDR_EXPR of STRING_CST with asan_pp text.  */
-
 static tree
-asan_pp_string (void)
+asan_pp_string (pretty_printer *pp)
 {
-  const char *buf = pp_formatted_text (&asan_pp);
+  const char *buf = pp_formatted_text (pp);
   size_t len = strlen (buf);
   tree ret = build_string (len + 1, buf);
   TREE_TYPE (ret)
@@ -950,9 +937,9 @@
 asan_init_shadow_ptr_types ();
 
   /* First of all, prepare the description string.  */
-  if (!asan_pp_initialized)
-asan_pp_initialize ();
-
+  pretty_printer asan_pp;
+  pp_construct (&asan_pp, /* prefix */NULL, /* line-width */0);
+  
   pp_clear_output_area (&asan_pp);
   if (DECL_NAME (current_function_decl))
 pp_tree_identifier (&asan_pp, DECL_NAME (current_function_decl));
@@ -978,7 +965,7 @@
pp_string (&asan_pp, "9 ");
   pp_space (&asan_pp);
 }
-  str_cst = asan_pp_string ();
+  str_cst = asan_pp_string (&asan_pp);
 
   /* Emit the prologue sequence.  */
   base = expand_binop (Pmode, add_optab, base, GEN_INT (base_offset),
@@ -1976,8 +1963,8 @@
   tree str_cst, refdecl = decl;
   vec *vinner = NULL;
 
-  if (!asan_pp_initialized)
-asan_pp_initialize ();
+  pretty_printer asan_pp;
+  pp_construct (&asan_pp, /* prefix */NULL, /* line-width */0);
 
   pp_clear_output_area (&asan_pp);
   if (DECL_NAME (decl))
@@ -1988,7 +1975,7 @@
   pp_left_paren (&asan_pp);
   pp_string (&asan_pp, main_input_filename);
   pp_right_paren (&asan_pp);
-  str_cst = asan_pp_string ();
+  str_cst = asan_pp_string (&asan_pp);
 
   if (asan_needs_local_alias (decl))
 {

Re: New branch: ubsan

[Marek Polacek]

On Sun, Aug 04, 2013 at 06:55:13PM +0200, Gerald Pfeifer wrote:
> On Fri, 5 Jul 2013, Marek Polacek wrote:
> > I've created a new branch, called ubsan for work being done for
> > Undefined Behavior Sanitizer.  
> 
> Mind documenting this in http://gcc.gnu.org/svn.html?  Let me
> know if you need help (http://gcc.gnu.org/projects/web.html has
> some background).

Sure, does this patch look ok?

--- www/htdocs/svn.html.mp  2013-08-05 07:55:08.698293912 +0200
+++ www/htdocs/svn.html 2013-08-05 08:02:14.963046024 +0200
@@ -346,6 +346,14 @@ the command svn log --stop-on-copy
   and will be merged with mainline from time to time.  Patches will be
   marked with the tag [sso] in the subject line.
   
+  ubsan
+  This branch contains the Undefined Behavior Sanitizer (ubsan).  Ubsan is
+  an undefined behavior detector for the C family of languages.  The branch is
+  maintained by Marek Polacek
+  < mailto:pola...@redhat.com";>pola...@redhat.com>
+  and will be merged with mainline from time to time.  Patches will be
+  marked with the tag [ubsan] in the subject line.
+
 
 
 Architecture-specific

Marek

Clean up pretty printers [4/n]

[Gabriel Dos Reis]

This patchlet has print_c_tree use non-static local variable for its
pretty-printer object.  The code is much simpler that way.
(A follow up will add destructor so we stop leaking storage.)

Tested on an x86_64-suse-linux.  Applied to trunk.

-- Gaby


2013-08-05  Gabriel Dos Reis  

* c-pretty-print.c (print_c_tree): Simplify.  Use non-static local
c_pretty_printer variable.

Index: c-family/c-pretty-print.c
===
--- c-family/c-pretty-print.c   (revision 201479)
+++ c-family/c-pretty-print.c   (working copy)
@@ -2359,22 +2359,13 @@
 void
 print_c_tree (FILE *file, tree t)
 {
-  static c_pretty_printer pp_rec;
-  static bool initialized = 0;
-  c_pretty_printer *pp = &pp_rec;
-
-  if (!initialized)
-{
-  initialized = 1;
-  pp_construct (pp, NULL, 0);
-  pp_c_pretty_printer_init (pp);
-  pp_needs_newline (pp) = true;
-}
-  pp->buffer->stream = file;
-
-  pp_statement (pp, t);
-
-  pp_newline_and_flush (pp);
+  c_pretty_printer pp;
+  pp_construct (&pp, NULL, 0);
+  pp_c_pretty_printer_init (&pp);
+  pp_needs_newline (&pp) = true;
+  pp.buffer->stream = file;
+  pp_statement (&pp, t);
+  pp_newline_and_flush (&pp);
 }
 
 /* Print the tree T in full, on stderr.  */