Re: Go patch committed: Update libgo to 1.1.1

[Uros Bizjak]

On Wed, Jul 24, 2013 at 12:23 AM, Ian Lance Taylor  wrote:
> On Mon, Jul 22, 2013 at 6:38 AM, Uros Bizjak  wrote:
>>
>>> I have committed a large patch to update libgo to the library that was
>>> part of the Go 1.1.1 release.  As usual, I'm not including the entire
>>> patch in this e-mail message, because it is too large.  I'm only
>>> including the changes to the files that are partially gccgo-specific.
>>> Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
>>> Committed to mainline and 4.8 branch.
>>
>> I have hit following build failure on non-USING_SPLIT_STACK target
>> (alpha-linux-gnu):
>
> Thanks.  Fixed like so.  Committed to mainline and 4.8 branch.

 Thanks, with your patch, I was able to compile libgo without problems.
 The testsuite run exposes a timeout in net/http, I am looking into it.
>>
>> I have also managed to trigger the timeout on x86_64-pc-linux-gnu.
>>
>> The test was re-run with GOTESTFLAGS=--keep. When running the
>> resulting a.out with "strace -f -o strace-x86_64 ./a.out" from the
>> saved test directory, the test behaved in the same way as on alpha -
>> it hever finished. I have attached the resulting trace (the test was
>> killed with ctrl-c after some time).
>
> Thanks.  The problematic test is TestLinuxSendfile in
> libgo/net/http/fs_test.go.  That test binary invokes itself using
> strace.  In the trace here, that strace fails:
>
> 8511  ptrace(PTRACE_TRACEME, 0, 0, 0)   = -1 EPERM (Operation not permitted)
> 8511  write(2, "strace: test_ptrace_setoptions_f"..., 96) = 96
>
> The strace is supposed to start up a little server, and the test
> binary tries to connect to that server.  Since the server hasn't
> started, the test times out.
>
> The strace invocation is
>
> strace -f -q -e trace=sendfile,sendfile64 ./a.out
> -test.run=TestLinuxSendfileChild
>
> Any idea why that would fail?

Manual invocation of this command tells us the reason. On alpha, it says:

$ strace -f -e trace=sendfile64 ./a.out
strace: invalid system call 'sendfile64'

> The Alpha stack trace you send also indicates a failure in this test.
> It could be for the same reason; hard to say.  The Alpha strace output
> you send doesn't tell me much, since it wasn't done with -f.

I have resent you the strace. The important part is:

7407  write(2, "strace: invalid system call 'sen"..., 41 
7405  <... sigreturn resumed> ) = -1
7407  <... write resumed> ) = 41
7405  osf_sigprocmask(SIG_BLOCK, [] 
7407  exit_group(1) = ?
7405  <... osf_sigprocmask resumed> )   = 0 (old mask [])
7405  connect(7, {sa_family=AF_INET, sin_port=htons(32998),
sin_addr=inet_addr("127.0.0.1")}, 16) = 0
7407  +++ exited with 1 +++

The child exited with error, but this is not handled in the test, and
the test waits for dead process indefinitely.

I think that the test should detect, if test system supports
sendfile64 and perhaps also handle invocation failure from the child
process.

Thanks,
Uros.

Re: [C, C++] Implement -Wstatic-local

[Florian Weimer]

On 07/24/2013 03:24 AM, Gabriel Dos Reis wrote:


Do you envision this to be useful for C++ too?



There are many bits here.  'const' in C++ does not necessary prevent
race conditions with the variable's type has to run non-atomic constructors,
or if the object has data members declared mutable, etc.


I think the warning will mean the same thing for PODs without mutable 
fields as in C.  It's true that a const object is not necessarily 
physically const (i.e., in .rodata or .data.rel.ro), but I don't think 
this is a problem.


My main concern here is C, but I think it's useful to have parity 
between the two front ends if possible.



I think the C++ ABI mandates that the implementation adds implicit locks
to enforce orderly initialization


Yes, that's how we implement it.

--
Florian Weimer / Red Hat Product Security Team

[arm-embedded] Patch to define multilibs for arm embedded-4_8-branch

[Terry Guo]

Hi Joey,

This patch is to define multilibs for recently created embedded-4_8-branch.
Is it OK to commit?

BR,
Terry

2013-07-24  Terry Guo  

* configure.ac (with_multilib_list): Export its value.
* Makefile.in (with_multilib_list): Import it from configure files.
* configure: Regenerated.
* config/arm/t-mlibs: New files to define multilibs.
* config.gcc: Use above multilib fragment.Index: gcc/config.gcc
===
--- gcc/config.gcc  (revision 201200)
+++ gcc/config.gcc  (working copy)
@@ -917,7 +917,7 @@
case ${target} in
arm*-*-eabi*)
  tm_file="$tm_file newlib-stdint.h"
- tmake_file="${tmake_file} arm/t-bpabi"
+ tmake_file="${tmake_file} arm/t-bpabi arm/t-mlibs"
  use_gcc_stdint=wrap
  ;;
arm*-*-rtems*)
Index: gcc/ChangeLog.arm
===
--- gcc/ChangeLog.arm   (revision 0)
+++ gcc/ChangeLog.arm   (working copy)
@@ -0,0 +1,7 @@
+2013-07-24  Terry Guo  
+
+   * configure.ac (with_multilib_list): Export its value.
+   * Makefile.in (with_multilib_list): Import it from configure files.
+   * configure: Regenerated.
+   * config/arm/t-mlibs: New files to define multilibs.
+   * config.gcc: Use above multilib fragment.
Index: gcc/configure
===
--- gcc/configure   (revision 201200)
+++ gcc/configure   (working copy)
@@ -753,6 +753,7 @@
 LN_S
 AWK
 SET_MAKE
+with_multilib_list
 REPORT_BUGS_TEXI
 REPORT_BUGS_TO
 PKGVERSION
@@ -1660,7 +1661,7 @@
   --with-specs=SPECS  add SPECS to driver command-line processing
   --with-pkgversion=PKG   Use PKG in the version string in place of "GCC"
   --with-bugurl=URL   Direct users to URL to report a bug
-  --with-multilib-listselect multilibs (SH and x86-64 only)
+  --with-multilib-listselect multilibs (ARM, SH and x86-64 only)
   --with-gnu-ld   assume the C compiler uses GNU ld default=no
   --with-libiconv-prefix[=DIR]  search for libiconv in DIR/include and DIR/lib
   --without-libiconv-prefix don't search for libiconv in includedir and 
libdir
@@ -7397,6 +7398,7 @@
 fi
 
 
+
 # -
 # Checks for other programs
 # -
@@ -17828,7 +17830,7 @@
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 17831 "configure"
+#line 17833 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -17934,7 +17936,7 @@
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 17937 "configure"
+#line 17939 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
Index: gcc/configure.ac
===
--- gcc/configure.ac(revision 201200)
+++ gcc/configure.ac(working copy)
@@ -839,9 +839,10 @@
 [enable_languages=c])
 
 AC_ARG_WITH(multilib-list,
-[AS_HELP_STRING([--with-multilib-list], [select multilibs (SH and x86-64 
only)])],
+[AS_HELP_STRING([--with-multilib-list], [select multilibs (ARM, SH and x86-64 
only)])],
 :,
 with_multilib_list=default)
+AC_SUBST(with_multilib_list)
 
 # -
 # Checks for other programs
Index: gcc/config/arm/t-mlibs
===
--- gcc/config/arm/t-mlibs  (revision 0)
+++ gcc/config/arm/t-mlibs  (working copy)
@@ -0,0 +1,85 @@
+# A set of predefined MULTILIB which can be used for different ARM targets.
+# Via the configure option --with-multilib-list, user can customize the
+# final MULTILIB implementation.
+
+comma := ,
+space :=
+space +=
+
+MULTILIB_OPTIONS   = mthumb/marm
+MULTILIB_DIRNAMES  = thumb arm
+MULTILIB_OPTIONS  += march=armv6s-m/march=armv7-m/march=armv7e-m/march=armv7
+MULTILIB_DIRNAMES += armv6-m armv7-m armv7e-m armv7-ar
+MULTILIB_OPTIONS  += mfloat-abi=softfp/mfloat-abi=hard
+MULTILIB_DIRNAMES += softfp fpu
+MULTILIB_OPTIONS  += mfpu=fpv4-sp-d16/mfpu=vfpv3-d16
+MULTILIB_DIRNAMES += fpv4-sp-d16 vfpv3-d16
+
+MULTILIB_MATCHES   = march?armv6s-m=mcpu?cortex-m0
+MULTILIB_MATCHES  += march?armv6s-m=mcpu?cortex-m0plus
+MULTILIB_MATCHES  += march?armv6s-m=mcpu?cortex-m1
+MULTILIB_MATCHES  += march?armv6s-m=march?armv6-m
+MULTILIB_MATCHES  += march?armv7-m=mcpu?cortex-m3
+MULTILIB_MATCHES  += march?armv7e-m=mcpu?cortex-m4
+MULTILIB_MATCHES  += march?armv7=march?armv7-r
+MULTILIB_MATCHES  += march?armv7=march?armv7-a
+MULTILIB_MATCHES  += march?armv7=mcpu?cortex-r4
+MULTILIB_MATCHES  += march?armv7=mcpu?cortex-r4f
+MULTILIB_MATCHES  += march?armv7=mcpu?cortex-r5
+MULTILIB_MATCHES  += march?armv7=mcpu?cortex-a5
+MULTILIB_MATCHES  += march?armv7=mcpu?cortex-a7
+MULTILIB_MATCHES  += march?armv7=mcpu?cortex-a8
+MULTILIB_MATCHES  += march?armv7=mcpu?cortex-a9
+MULTILIB_MATCHES  += march?a

Re: [PATCH, ARM/Thumb1] Adjust rtx cost to prevent expanding MULT into shift/add instructions

[Richard Earnshaw]

On 24/07/13 03:36, Terry Guo wrote:

Hi there,

This patch intends to update thumb1_size_rtx_costs function to correctly
handle those RTXs defined by RTL expansion pass. Thus the GIMPLE
multiplication will be expanded to single mul instruction instead of a bunch
of shift/add/sub instructions which are in fact more expensive.

Tested with GCC regression test on QEMU ARM926, no regression. Is it OK to
trunk and 4.8 branch?

BR,
Terry


gcc/ChangeLog:
2013-07-24  Terry Guo  

 * config/arm/arm.c (thumb1_size_rtx_costs): Assign proper cost for
 shift_add/shift_sub0/shift_sub1 RTXs.

gcc/testsuite/ChangeLog:
2013-07-24  Terry Guo  

 * gcc.target/arm/thumb1-Os-mult.c: New test case.




OK.

I'll note for the record, though, that that function needs a major 
rewrite...


R.

[PATCH] S/390: libitm: Use .machine to enable the HTM instructions in the assembler

[Andreas Krebbel]

Hi,

the hardware transactional execution instructions in libitm are only
enabled if actually supported by the assembler.  So the option which
enables the instructions in the assembler should only be set if we are
already in a code path where we know the assembler can do it.

With the attached patch the ".machine" pseudo is used to enable the
full instruction set.

Bye,

-Andreas-


2013-07-24  Andreas Krebbel  

* config/s390/target.h (htm_begin, htm_commit, htm_abort)
(htm_transaction_active): Enable zEC12 instructions in the
assembler.
* configure.tgt: Remove -Wa,-march=zEC12 from XCFLAGS.

---
 libitm/config/s390/target.h |4 
 libitm/configure.tgt|2 !!
 2 files changed, 4 insertions(+), 2 modifications(!)

Index: libitm/config/s390/target.h
===
*** libitm/config/s390/target.h.orig
--- libitm/config/s390/target.h
*** htm_init ()
*** 85,90 
--- 85,91 
  static inline uint32_t
  htm_begin ()
  {
+   __asm volatile (".machine \"all\"  \n\t");
return __builtin_tbegin_nofloat (NULL);
  }
  
*** htm_begin_success (uint32_t begin_ret)
*** 97,108 
--- 98,111 
  static inline void
  htm_commit ()
  {
+   __asm volatile (".machine \"all\"  \n\t");
__builtin_tend ();
  }
  
  static inline void
  htm_abort ()
  {
+   __asm volatile (".machine \"all\"  \n\t");
__builtin_tabort (_HTM_FIRST_USER_ABORT_CODE);
  }
  
*** htm_abort_should_retry (uint32_t begin_r
*** 115,120 
--- 118,124 
  static inline bool
  htm_transaction_active ()
  {
+   __asm volatile (".machine \"all\"  \n\t");
return __builtin_tx_nesting_depth() != 0;
  }
  
Index: libitm/configure.tgt
===
*** libitm/configure.tgt.orig
--- libitm/configure.tgt
*** case "${target_cpu}" in
*** 109,115 
ARCH=x86
;;
s390|s390x)
!   XCFLAGS="${XCFLAGS} -mzarch -mhtm -Wa,-march=zEC12"
ARCH=s390
;;
  
--- 109,115 
ARCH=x86
;;
s390|s390x)
!   XCFLAGS="${XCFLAGS} -mzarch -mhtm"
ARCH=s390
;;
  

Re: [v3] libstdc++/57920

[Paolo Carlini]

Hi,

On 07/23/2013 12:45 PM, Chung-Ju Wu wrote:

2013/7/23 Paolo Carlini :

... in the future, when we manage to actually avoid including  from
 I think we can avoid including it from  if we play a bit
with void*. Should be safe aliasing-wise. Something like the below,
completely untested.

I tested it on my target.  At least the elf toolchain can be
successfully built with such changes.
Thanks for testing! I guess we can as well do this now that we are still 
in Stage 1. Also, take the chance to avoid a couple of unnecessary 
reinterpret_casts. Like in the below, which I'm going to apply if 
testing on x86_64-linux goes well.


Paolo.

///
2013-07-24  Paolo Carlini  

* include/bits/random.h (random_device): Avoid using the FILE type.
* include/std/random: Do not include .
* src/c++11/random.cc: Include it here.
(random_device::_M_init, random_device::_M_fini,
random_device::_M_getval): Cast back and forth void* and FILE*.
Index: include/bits/random.h
===
--- include/bits/random.h   (revision 201200)
+++ include/bits/random.h   (working copy)
@@ -1638,10 +1638,10 @@
 
 union
 {
-FILE*_M_file;
-mt19937  _M_mt;
+  void*  _M_file;
+  mt19937_M_mt;
+};
   };
-  };
 
   /* @} */ // group random_generators
 
Index: include/std/random
===
--- include/std/random  (revision 201200)
+++ include/std/random  (working copy)
@@ -36,7 +36,6 @@
 #else
 
 #include 
-#include  // For FILE
 #include 
 #include 
 #include 
Index: src/c++11/random.cc
===
--- src/c++11/random.cc (revision 201202)
+++ src/c++11/random.cc (working copy)
@@ -30,13 +30,14 @@
 # include 
 #endif
 
+#include 
+
 #ifdef _GLIBCXX_HAVE_UNISTD_H
 # include 
 #endif
 
 namespace std _GLIBCXX_VISIBILITY(default)
 {
-
   namespace
   {
 static unsigned long
@@ -72,7 +73,6 @@
 #endif
   }
 
-
   void
   random_device::_M_init(const std::string& token)
   {
@@ -102,8 +102,8 @@
   std::__throw_runtime_error(__N("random_device::"
 "random_device(const std::string&)"));
 
-_M_file = std::fopen(fname, "rb");
-if (! _M_file)
+_M_file = static_cast(std::fopen(fname, "rb"));
+if (!_M_file)
   goto fail;
   }
 
@@ -117,23 +117,24 @@
   random_device::_M_fini()
   {
 if (_M_file)
-  std::fclose(_M_file);
+  std::fclose(static_cast(_M_file));
   }
 
   random_device::result_type
   random_device::_M_getval()
   {
 #if (defined __i386__ || defined __x86_64__) && defined _GLIBCXX_X86_RDRAND
-if (! _M_file)
+if (!_M_file)
   return __x86_rdrand();
 #endif
 
 result_type __ret;
 #ifdef _GLIBCXX_HAVE_UNISTD_H
-read(fileno(_M_file), reinterpret_cast(&__ret), 
sizeof(result_type));
+read(fileno(static_cast(_M_file)),
+static_cast(&__ret), sizeof(result_type));
 #else
-std::fread(reinterpret_cast(&__ret), sizeof(result_type),
-  1, _M_file);
+std::fread(static_cast(&__ret), sizeof(result_type),
+  1, static_cast(_M_file));
 #endif
 return __ret;
   }

Re: [Patch] Reimplment regex matcher using DFS

[Paolo Carlini]

On 07/23/2013 05:31 PM, Tim Shen wrote:

Revised version, with _M_dfs_* moved to the class definition, PR
testcases, and some comments on _M_dfs().
I nobody has further comments, I think this is Ok to go in now. Let's 
make sure we don't forget the various comments about optimization, 
pre-scanning, etc!


Then we should also add something (by hand, unfortunately, as I 
explained) to the audit trails of those bugs, because we want the 
original submitters to double check the fixes with their own code, get 
as much feedback as possible while we commit these improvements.


Paolo.

Re: Go patch committed: Update libgo to 1.1.1

[Uros Bizjak]

On Wed, Jul 24, 2013 at 9:09 AM, Uros Bizjak  wrote:

>>> The test was re-run with GOTESTFLAGS=--keep. When running the
>>> resulting a.out with "strace -f -o strace-x86_64 ./a.out" from the
>>> saved test directory, the test behaved in the same way as on alpha -
>>> it hever finished. I have attached the resulting trace (the test was
>>> killed with ctrl-c after some time).
>>
>> Thanks.  The problematic test is TestLinuxSendfile in
>> libgo/net/http/fs_test.go.  That test binary invokes itself using
>> strace.  In the trace here, that strace fails:
>>
>> 8511  ptrace(PTRACE_TRACEME, 0, 0, 0)   = -1 EPERM (Operation not permitted)
>> 8511  write(2, "strace: test_ptrace_setoptions_f"..., 96) = 96
>>
>> The strace is supposed to start up a little server, and the test
>> binary tries to connect to that server.  Since the server hasn't
>> started, the test times out.
>>
>> The strace invocation is
>>
>> strace -f -q -e trace=sendfile,sendfile64 ./a.out
>> -test.run=TestLinuxSendfileChild
>>
>> Any idea why that would fail?

It looks you can't trace a traced process:

$ strace -f strace ./a.out

[pid 17864] ptrace(PTRACE_TRACEME, 0, 0, 0) = -1 EPERM (Operation not permitted)
[pid 17864] write(2, "strace: test_ptrace_setoptions_f"..., 93strace:
test_ptrace_setoptions_for_all: PTRACE_TRACEME doesn't work: Operation
not permitted
) = 93
[pid 17864] exit_group(1)   = ?
[pid 17864] +++ exited with 1 +++

> Manual invocation of this command tells us the reason. On alpha, it says:
>
> $ strace -f -e trace=sendfile64 ./a.out
> strace: invalid system call 'sendfile64'
>
>> The Alpha stack trace you send also indicates a failure in this test.
>> It could be for the same reason; hard to say.  The Alpha strace output
>> you send doesn't tell me much, since it wasn't done with -f.
>
> I have resent you the strace. The important part is:
>
> 7407  write(2, "strace: invalid system call 'sen"..., 41 
> 7405  <... sigreturn resumed> ) = -1
> 7407  <... write resumed> ) = 41
> 7405  osf_sigprocmask(SIG_BLOCK, [] 
> 7407  exit_group(1) = ?
> 7405  <... osf_sigprocmask resumed> )   = 0 (old mask [])
> 7405  connect(7, {sa_family=AF_INET, sin_port=htons(32998),
> sin_addr=inet_addr("127.0.0.1")}, 16) = 0
> 7407  +++ exited with 1 +++
>
> The child exited with error, but this is not handled in the test, and
> the test waits for dead process indefinitely.
>
> I think that the test should detect, if test system supports
> sendfile64 and perhaps also handle invocation failure from the child
> process.

Attached patch fixes failures on alpha. However, the patch doesn't
detect the failure from strace invocation, so the testcase could still
wait for the dead child process.

The patch was tested on x86_64-linux-gnu and alpha-linux-gnu.

Uros.
Index: go/net/http/fs_test.go
===
--- go/net/http/fs_test.go  (revision 201182)
+++ go/net/http/fs_test.go  (working copy)
@@ -696,8 +696,13 @@
}
defer ln.Close()
 
+   trace := "trace=sendfile"
+   if runtime.GOARCH != "alpha" {
+   trace = trace + ",sendfile64"
+   }
+
var buf bytes.Buffer
-   child := exec.Command("strace", "-f", "-q", "-e", 
"trace=sendfile,sendfile64", os.Args[0], "-test.run=TestLinuxSendfileChild")
+   child := exec.Command("strace", "-f", "-q", "-e", trace, os.Args[0], 
"-test.run=TestLinuxSendfileChild")
child.ExtraFiles = append(child.ExtraFiles, lnf)
child.Env = append([]string{"GO_WANT_HELPER_PROCESS=1"}, 
os.Environ()...)
child.Stdout = &buf

RE: [PING] Two patches pending

[Bin Cheng]

Ping this patch:

> > [PATCH ARM]Extend thumb1_reorg to save more comparison instructions
> > http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01057.html

Thanks.
bin

> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Saturday, July 20, 2013 1:34 AM
> To: Bin Cheng
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PING] Two patches pending
> 
> On 07/09/2013 01:53 AM, Bin Cheng wrote:
> > Hi,
> >
> > FW: [PATCH GCC]Relax the probability condition in CE pass when
> > optimizing for code size
> > http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00969.html
> This is OK.
> 
> >
> > [PATCH ARM]Extend thumb1_reorg to save more comparison instructions
> > http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01057.html
> Ping Richard Earnshaw, Nick and Ramana privately -- one of them should be
able
> to handle it.  I don't think Paul Brook is active anymore.
> 
> jeff
> 

RE: [PATCH GCC/ARM]Disable "-fira-hoist-pressure" on Thumb2

[Bin Cheng]

ping.

Thanks.
bin

> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org]
On
> Behalf Of Bin Cheng
> Sent: Tuesday, July 09, 2013 4:08 PM
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH GCC/ARM]Disable "-fira-hoist-pressure" on Thumb2
> 
> Hi,
> For now the option "-fira-hoist-pressure" is enabled for all targets, but
I
> monitored performance regression with Os on thumb2 for some cases.
> Considering that optimization has small improvement on thumb2 for code
size,
> here comes this patch disabling it on Thumb2 and modifying the
corresponding
> test cases.
> 
> Tested on arm-none-eabi/M3, is it OK?
> 
> Thanks.
> bin
> 
> 2013-04-25  Bin Cheng  
> 
>   * common.opt (flag_ira_hoist_pressure): Initialize to 2.
>   * doc/invoke.texi (-fira-hoist-pressure): Disabled by default
>   on Thumb2 instruction set.
>   * config/arm/arm.c (arm_option_override): Disable option
>   -fira-hoist-pressure on Thumb2 by default.
> 
> 2013-04-25  Bin Cheng  
> 
>   * gcc.dg/hoist-register-pressure-1.c: Add -fira-hoist-pressure
option.
>   * gcc.dg/hoist-register-pressure-2.c: Ditto.
>   * gcc.dg/hoist-register-pressure-3.c: Ditto.

Re: Go patch committed: Update libgo to 1.1.1

[Rainer Orth]

Ian Lance Taylor  writes:

> On Thu, Jul 18, 2013 at 6:59 AM, Rainer Orth
>  wrote:
>> Ian Lance Taylor  writes:
>>
>>> I have committed a large patch to update libgo to the library that was
>>> part of the Go 1.1.1 release.  As usual, I'm not including the entire
>>> patch in this e-mail message, because it is too large.  I'm only
>>> including the changes to the files that are partially gccgo-specific.
>>> Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
>>> Committed to mainline and 4.8 branch.
>>
>> This broke the Solaris build:
>>
>> /vol/gcc/src/hg/trunk/local/libgo/go/log/syslog/syslog_libc.go:18:25: error: 
>> use of undefined type 'serverConn'
>>  func unixSyslog() (conn serverConn, err error) {
>>  ^
>> make[6]: *** [log/syslog.lo] Error 1
>>
>> Didn't make much progress on this one.
>
> The interface I put in a while back for Solaris support got taken out
> from the master library, and I missed it.  This patch restores it.
> Committed to mainline and 4.8 branch.  I've also sent a patch to the
> master library to restore the interface.

Thanks, that allowed libgo.so to build on Solaris 10/x86.
Unfortunately, all tests FAIL like this:

Undefined   first referenced
 symbol in file
runtime_unminit 
/var/gcc/regression/trunk/10-gcc/build/i386-pc-solaris2.10/amd64/libgo/.libs/libgo.so
runtime_minit   
/var/gcc/regression/trunk/10-gcc/build/i386-pc-solaris2.10/amd64/libgo/.libs/libgo.so
runtime_mpreinit
/var/gcc/regression/trunk/10-gcc/build/i386-pc-solaris2.10/amd64/libgo/.libs/libgo.so
ld: fatal: symbol referencing errors. No output written to a.out
collect2: error: ld returned 1 exit status
FAIL: bufio

I've fixed this by also adding the definitions of those three functions
to runtime/thread-sema.c, although there might be a better way to handle
this:

diff --git a/libgo/runtime/thread-sema.c b/libgo/runtime/thread-sema.c
--- a/libgo/runtime/thread-sema.c
+++ b/libgo/runtime/thread-sema.c
@@ -146,3 +146,48 @@ runtime_goenvs (void)
 {
   runtime_goenvs_unix ();
 }
+
+// Called to initialize a new m (including the bootstrap m).
+// Called on the parent thread (main thread in case of bootstrap), can allocate memory.
+void
+runtime_mpreinit(M *mp)
+{
+	mp->gsignal = runtime_malg(32*1024, &mp->gsignalstack, &mp->gsignalstacksize);	// OS X wants >=8K, Linux >=2K
+}
+
+// Called to initialize a new m (including the bootstrap m).
+// Called on the new thread, can not allocate memory.
+void
+runtime_minit(void)
+{
+	M* m;
+	sigset_t sigs;
+
+	// Initialize signal handling.
+	m = runtime_m();
+	runtime_signalstack(m->gsignalstack, m->gsignalstacksize);
+	if (sigemptyset(&sigs) != 0)
+		runtime_throw("sigemptyset");
+	sigprocmask(SIG_SETMASK, &sigs, nil);
+}
+
+// Called from dropm to undo the effect of an minit.
+void
+runtime_unminit(void)
+{
+	runtime_signalstack(nil, 0);
+}
+
+void
+runtime_signalstack(byte *p, int32 n)
+{
+	stack_t st;
+
+	st.ss_sp = p;
+	st.ss_size = n;
+	st.ss_flags = 0;
+	if(p == nil)
+		st.ss_flags = SS_DISABLE;
+	if(sigaltstack(&st, nil) < 0)
+		*(int *)0xf1 = 0xf1;
+}

With that change, we're almost back to normal for Solaris testresults:

@@ -498,47 +516,63 @@
 
 
 Running target unix
+FAIL: net
+FAIL: runtime
 
=== libgo Summary for unix ===
 
-# of expected passes   131
+# of expected passes   120
+# of unexpected failures   2
 
 Running target unix/-m64
+FAIL: net
 FAIL: os
-FAIL: net/http
+FAIL: runtime
 FAIL: net/http/cgi
 
=== libgo Summary for unix/-m64 ===
 
-# of expected passes   128
-# of unexpected failures   3
+# of expected passes   118
+# of unexpected failures   4

The new failures are:

--- FAIL: TestReadUnixgramWithUnnamedSocket (0.00 seconds)
:0: neighbor address is @
--- FAIL: TestReadUnixgramWithZeroBytesBuffer (0.00 seconds)
:0: neighbor address is @
--- FAIL: TestUnixConnLocalAndRemoteNames (0.01 seconds)
:0: got &net.UnixAddr{Name:"@", Net:"unix"}, expected 
&net.UnixAddr{Name:"", Net:"unix"}
unix_test.go:159: Listener.Accept failed: use of closed network 
connection
--- FAIL: TestUnixgramConnLocalAndRemoteNames (0.00 seconds)
:0: got &net.UnixAddr{Name:"@", Net:"unixgram"}, expected 
&net.UnixAddr{Name:"", Net:"unixgram"}
FAIL
FAIL: net

32-bit runtime:

runtime: memory allocated by OS (0xbd60) not in usable range 
[0xdde0,0x5de0)
runtime: out of memory: cannot allocate 2097152-byte block (536870912 in use)
fatal error: out of memory

goroutine 61 [running]:

:0

:0

:0

:0

:0
runtime_test.testConcurrentReadsAfterGrowth

/var/gcc/regression/trunk/10-gcc/build/i386-pc-solaris2.10/libgo/gotest29011/test/map_test.go:261

/var/gcc/regression/trunk/10-gcc/build/i386-pc-solaris2.10/libgo/gotest29011/test/map_test.go:261

:0

 

RFA: Fix rtl-optimization/57968

[Joern Rennecke]

The problem is fixed by simply moving the code that skips insns that don't
set a part of the return value below the code that checks if the insn needs
a non-MODE_EXIT mode setting.

bootstrapped/regtested on i686-pc-linux-gnu


2013-07-24  Joern Rennecke  

PR rtl-optimization/57968
* mode-switching.c (create_pre_exit): Allow instructions that
don't set a return register to need a non-exit mode.

Index: mode-switching.c
===
--- mode-switching.c(revision 201202)
+++ mode-switching.c(working copy)
@@ -330,12 +330,10 @@ create_pre_exit (int n_entities, int *en
break;
  }
if (!targetm.calls.function_value_regno_p (copy_start))
- {
-   last_insn = return_copy;
-   continue;
- }
-   copy_num
- = hard_regno_nregs[copy_start][GET_MODE (copy_reg)];
+ copy_num = 0;
+   else
+ copy_num
+   = hard_regno_nregs[copy_start][GET_MODE (copy_reg)];
 
/* If the return register is not likely spilled, - as is
   the case for floating point on SH4 - then it might
@@ -372,6 +370,11 @@ create_pre_exit (int n_entities, int *en
  forced_late_switch = 1;
break;
  }
+   if (copy_num == 0)
+ {
+   last_insn = return_copy;
+   continue;
+ }
 
if (copy_start >= ret_start
&& copy_start + copy_num <= ret_end)

Re: [PATCH, PowerPC] Fix unaligned Altivec load/stores in LE mode

[David Edelsohn]

On Tue, Jul 23, 2013 at 11:19 PM, Bill Schmidt
 wrote:
> In order to use vperm for aligning loads and stores in little endian
> mode, we need to reverse the order of the input operands and use lvsl
> instead of lvsr.  This corrects 32 regressions in the test suite when
> run in LE mode.
>
> Bootstrapped and tested on powerpc64-unknown-linux-gnu in BE mode with
> no new regressions.  Is this ok for trunk?
>
> Patch by Anton Blanchard.
>
> Thanks,
> Bill
>
>
> 2013-07-23  Bill Schmidt  
> Anton Blanchard 
>
> * vector.md (vec_realign_load_): Reorder input operands to
> vperm for little endian.
> * rs6000.c (rs6000_expand_builtin): Use lvsr instead of lvsl to
> create the control mask for a vperm for little endian.

Okay.

Thanks, David

Re: Go patch committed: Update libgo to 1.1.1

[Ian Lance Taylor]

On Wed, Jul 24, 2013 at 2:24 AM, Uros Bizjak  wrote:
> On Wed, Jul 24, 2013 at 9:09 AM, Uros Bizjak  wrote:
>
 The test was re-run with GOTESTFLAGS=--keep. When running the
 resulting a.out with "strace -f -o strace-x86_64 ./a.out" from the
 saved test directory, the test behaved in the same way as on alpha -
 it hever finished. I have attached the resulting trace (the test was
 killed with ctrl-c after some time).
>>>
>>> Thanks.  The problematic test is TestLinuxSendfile in
>>> libgo/net/http/fs_test.go.  That test binary invokes itself using
>>> strace.  In the trace here, that strace fails:
>>>
>>> 8511  ptrace(PTRACE_TRACEME, 0, 0, 0)   = -1 EPERM (Operation not permitted)
>>> 8511  write(2, "strace: test_ptrace_setoptions_f"..., 96) = 96
>>>
>>> The strace is supposed to start up a little server, and the test
>>> binary tries to connect to that server.  Since the server hasn't
>>> started, the test times out.
>>>
>>> The strace invocation is
>>>
>>> strace -f -q -e trace=sendfile,sendfile64 ./a.out
>>> -test.run=TestLinuxSendfileChild
>>>
>>> Any idea why that would fail?
>
> It looks you can't trace a traced process:
>
> $ strace -f strace ./a.out
>
> [pid 17864] ptrace(PTRACE_TRACEME, 0, 0, 0) = -1 EPERM (Operation not 
> permitted)
> [pid 17864] write(2, "strace: test_ptrace_setoptions_f"..., 93strace:
> test_ptrace_setoptions_for_all: PTRACE_TRACEME doesn't work: Operation
> not permitted
> ) = 93
> [pid 17864] exit_group(1)   = ?
> [pid 17864] +++ exited with 1 +++
>
>> Manual invocation of this command tells us the reason. On alpha, it says:
>>
>> $ strace -f -e trace=sendfile64 ./a.out
>> strace: invalid system call 'sendfile64'
>>
>>> The Alpha stack trace you send also indicates a failure in this test.
>>> It could be for the same reason; hard to say.  The Alpha strace output
>>> you send doesn't tell me much, since it wasn't done with -f.
>>
>> I have resent you the strace. The important part is:
>>
>> 7407  write(2, "strace: invalid system call 'sen"..., 41 
>> 7405  <... sigreturn resumed> ) = -1
>> 7407  <... write resumed> ) = 41
>> 7405  osf_sigprocmask(SIG_BLOCK, [] 
>> 7407  exit_group(1) = ?
>> 7405  <... osf_sigprocmask resumed> )   = 0 (old mask [])
>> 7405  connect(7, {sa_family=AF_INET, sin_port=htons(32998),
>> sin_addr=inet_addr("127.0.0.1")}, 16) = 0
>> 7407  +++ exited with 1 +++
>>
>> The child exited with error, but this is not handled in the test, and
>> the test waits for dead process indefinitely.
>>
>> I think that the test should detect, if test system supports
>> sendfile64 and perhaps also handle invocation failure from the child
>> process.
>
> Attached patch fixes failures on alpha. However, the patch doesn't
> detect the failure from strace invocation, so the testcase could still
> wait for the dead child process.
>
> The patch was tested on x86_64-linux-gnu and alpha-linux-gnu.

Thanks a lot.  Committed to mainline and 4.8 branch.

I looked at the kernel sources, and there does seem to be a sendfile64
system call on alpha (system call 239).  I wonder how strace decides
which system calls are supported.

Ian

Re: Go patch committed: Update libgo to 1.1.1

[Ian Lance Taylor]

On Wed, Jul 24, 2013 at 4:49 AM, Rainer Orth
 wrote:
> Ian Lance Taylor  writes:
>
>> On Thu, Jul 18, 2013 at 6:59 AM, Rainer Orth
>>  wrote:
>>> Ian Lance Taylor  writes:
>>>
 I have committed a large patch to update libgo to the library that was
 part of the Go 1.1.1 release.  As usual, I'm not including the entire
 patch in this e-mail message, because it is too large.  I'm only
 including the changes to the files that are partially gccgo-specific.
 Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
 Committed to mainline and 4.8 branch.
>>>
>>> This broke the Solaris build:
>>>
>>> /vol/gcc/src/hg/trunk/local/libgo/go/log/syslog/syslog_libc.go:18:25: 
>>> error: use of undefined type 'serverConn'
>>>  func unixSyslog() (conn serverConn, err error) {
>>>  ^
>>> make[6]: *** [log/syslog.lo] Error 1
>>>
>>> Didn't make much progress on this one.
>>
>> The interface I put in a while back for Solaris support got taken out
>> from the master library, and I missed it.  This patch restores it.
>> Committed to mainline and 4.8 branch.  I've also sent a patch to the
>> master library to restore the interface.
>
> Thanks, that allowed libgo.so to build on Solaris 10/x86.
> Unfortunately, all tests FAIL like this:
>
> Undefined   first referenced
>  symbol in file
> runtime_unminit 
> /var/gcc/regression/trunk/10-gcc/build/i386-pc-solaris2.10/amd64/libgo/.libs/libgo.so
> runtime_minit   
> /var/gcc/regression/trunk/10-gcc/build/i386-pc-solaris2.10/amd64/libgo/.libs/libgo.so
> runtime_mpreinit
> /var/gcc/regression/trunk/10-gcc/build/i386-pc-solaris2.10/amd64/libgo/.libs/libgo.so
> ld: fatal: symbol referencing errors. No output written to a.out
> collect2: error: ld returned 1 exit status
> FAIL: bufio
>
> I've fixed this by also adding the definitions of those three functions
> to runtime/thread-sema.c, although there might be a better way to handle
> this:

Sorry, that was really sloppy of me.  I just moved those functions to
runtime.c instead.  I committed this patch to mainline and 4.8 branch.

Ian


foo.patch
Description: Binary data

[www] Mention avx512 and mpx branches

[Kirill Yukhin]

Hi,
Patch adds mention of avx512 and mpx branches in svn.html.

Ok to install?

Index: htdocs/svn.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/svn.html,v
retrieving revision 1.185
diff -p -r1.185 svn.html
*** htdocs/svn.html 27 May 2013 10:54:12 -  1.185
--- htdocs/svn.html 24 Jul 2013 14:04:55 -
*** the command svn log --stop-on-copy
*** 352,357 
--- 352,374 

  

+   avx512
+   The goal of this branch is to implement Intel AVX-512 and SHA
+   Programming Reference
+   (http://download-software.intel.com/sites/default/files/319433-015.pdf";>link).
+   The branch is maintained by Yukhin Kirill kirill.yuk...@intel.com>.
+   Patches should be marked with the tag [AVX512] in the
subject
+   line.
+
+   mpx
+   The goal of this branch is to support Intel MPX technology
+   (http://download-software.intel.com/sites/default/files/319433-015.pdf";>link).
+   The branch is maintained by
+   Ilya Enkovich ilya.enkov...@intel.com>
+   Patches should be marked with the tag [MPX] in the subject
+   line.
+
st/cli-be
The goal of the branch is to develop a back-end producing CLI
binaries,
compliant with ECMA-335 specification.

Thanks, K

Re: [Patch] Reimplment regex matcher using DFS

[Tim Shen]

On Wed, Jul 24, 2013 at 5:18 PM, Paolo Carlini  wrote:
> Then we should also add something (by hand, unfortunately, as I explained)
> to the audit trails of those bugs, because we want the original submitters
> to double check the fixes with their own code, get as much feedback as
> possible while we commit these improvements.

Committed.

Should I register a new bugzilla account to comment on these two
bugs(53622 and 57173), or any other one will do this?


-- 
Tim Shen

[PATCH] ppc-vector-memcpy.c

[David Edelsohn]

gcc.target/ppc-vector-memcpy.c testcase currently fails and has been
failing since early in the GCC 4.6 development cycle.  A change by
Eric Botcazou in April 2008 to the handling of constants reduced the
extra alignment of initializers matching the alignment of the
variable.

The testcases originally was written by Geoff Keating and I do not
know exactly what features he was trying to test -- if he only was
testing Altivec used for block move or also Altivec used for aligned
initializers.

The appended patch changes the testcase to match the name of the file:
test that aligned memcpy uses VMX.

Any contrary opinion about this change?

Thanks, David

* gcc.target/powerpc/ppc-vector-memcpy.c: Test use of VMX for memcpy
not initializers.

Index: ppc-vector-memcpy.c
===
--- ppc-vector-memcpy.c (revision 201200)
+++ ppc-vector-memcpy.c (working copy)
@@ -3,8 +3,13 @@
 /* { dg-options "-O -maltivec -mno-vsx" } */
 /* { dg-final { scan-assembler "lvx" } } */

+#include 
+
 void foo(void)
 {
-  int x[8] __attribute__((aligned(128))) = { 1, 1, 1, 1, 1, 1, 1, 1 };
-  bar (x);
+  extern int x[8] __attribute__((aligned(128)));
+  int y[8] __attribute__((aligned(128)));
+  memcpy (y, x, sizeof (x));
+  bar (y);
 }

[PATCH 1/2] Introduce context class

[David Malcolm]

gcc/

Introduce context class.

* Makefile.in (CONTEXT_H): New.
(OBJS): Add context.o.
(toplev.o): Add CONTEXT_H to dependencies.
(context.o): New.

* toplev.c (general_init): Create the singleton gcc::context
instance.

* context.c: New.

* context.h: New.
---
 gcc/Makefile.in |  6 +-
 gcc/context.c   | 27 +++
 gcc/context.h   | 42 ++
 gcc/toplev.c|  5 +
 4 files changed, 79 insertions(+), 1 deletion(-)
 create mode 100644 gcc/context.c
 create mode 100644 gcc/context.h

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 966c38a..fb0cb4b 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -986,6 +986,7 @@ PLUGIN_H = plugin.h $(GCC_PLUGIN_H)
 PLUGIN_VERSION_H = plugin-version.h configargs.h
 LIBFUNCS_H = libfuncs.h $(HASHTAB_H)
 GRAPHITE_HTAB_H = graphite-htab.h graphite-clast-to-gimple.h $(HASH_TABLE_H)
+CONTEXT_H = context.h
 
 #
 # Now figure out from those variables how to compile and link.
@@ -1200,6 +1201,7 @@ OBJS = \
combine.o \
combine-stack-adj.o \
compare-elim.o \
+   context.o \
convert.o \
coverage.o \
cppbuiltin.o \
@@ -2729,7 +2731,7 @@ toplev.o : toplev.c $(CONFIG_H) $(SYSTEM_H) coretypes.h 
$(TM_H) $(TREE_H) \
$(OPTS_H) params.def tree-mudflap.h $(TREE_PASS_H) $(GIMPLE_H) \
tree-ssa-alias.h $(PLUGIN_H) realmpfr.h tree-diagnostic.h \
$(TREE_PRETTY_PRINT_H) opts-diagnostic.h $(COMMON_TARGET_H) \
-   tsan.h diagnostic-color.h
+   tsan.h diagnostic-color.h $(CONTEXT_H)
 
 hwint.o : hwint.c $(CONFIG_H) $(SYSTEM_H) $(DIAGNOSTIC_CORE_H)
 
@@ -3487,6 +3489,8 @@ $(out_object_file): $(out_file) $(CONFIG_H) coretypes.h 
$(TM_H) $(TREE_H) \
regrename.h
$(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) \
$(out_file) $(OUTPUT_OPTION)
+context.o: context.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(GGC_H) \
+   $(CONTEXT_H)
 
 $(common_out_object_file): $(common_out_file) $(CONFIG_H) $(SYSTEM_H) \
 coretypes.h $(COMMON_TARGET_H) $(COMMON_TARGET_DEF_H) $(PARAMS_H) \
diff --git a/gcc/context.c b/gcc/context.c
new file mode 100644
index 000..76e0dde
--- /dev/null
+++ b/gcc/context.c
@@ -0,0 +1,27 @@
+/* context.c - Holder for global state
+   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.
+
+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 "ggc.h"
+#include "context.h"
+
+/* The singleton holder of global state: */
+gcc::context *g;
diff --git a/gcc/context.h b/gcc/context.h
new file mode 100644
index 000..3caf02f
--- /dev/null
+++ b/gcc/context.h
@@ -0,0 +1,42 @@
+/* context.h - Holder for global state
+   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.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+.  */
+
+#ifndef GCC_CONTEXT_H
+#define GCC_CONTEXT_H
+
+namespace gcc {
+
+/* GCC's internal state can be divided into zero or more
+   "parallel universe" of state; an instance of this class is one such
+   context of state.  */
+class context
+{
+public:
+
+  /* Currently empty.  */
+
+}; // class context
+
+} // namespace gcc
+
+/* The global singleton context aka "g".
+   (the name is chosen to be easy to type in a debugger).  */
+extern gcc::context *g;
+
+#endif /* ! GCC_CONTEXT_H */
diff --git a/gcc/toplev.c b/gcc/toplev.c
index a2ee491..de28a2d 100644
--- a/gcc/toplev.c
+++ b/gcc/toplev.c
@@ -75,6 +75,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "tree-ssa-alias.h"
 #include "plugin.h"
 #include "diagnostic-color.h"
+#include "context.h"
 
 #if defined(DBX_DEBUGGING_INFO) || defined(XCOFF_DEBUGGING_INFO)
 #include "dbxout.h"
@@ -1156,6 +1157,10 @@ general_init (const char *argv0)
   /* This must be d

[PATCH 0/2] Introduce context and pipeline classes

[David Malcolm]

The following pair of patches is aimed at eliminating global variables
from gcc's internals, as per my Cauldron talk on state-removal [1]

Patch 1 introduces a gcc::context class, along with a singleton
instance.  The name of the instance is chosen so as to be easy to
type in the debugger:

   gcc::context *g;

[FWIW you can see an example of a debugging session in:
  http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01028.html ]

My aim is that this pointer will eventually be the only global
variable in GCC - so you can think of "g" as standing for either
"the global", "gcc" or "gnu" as you prefer :)   If we want to support
embedding gcc as a shared library, in that configuration "g" would
become a thread-local variable.

In patch 1, the context class is merely an empty stub.

Patch 2 introduces a gcc::pipeline class and moves various non-GTY
globals relating to pass management into it.  The gcc::context gains its
first field: a pointer to the gcc::pipeline instance, and
init_optimization_passes becomes the ctor for gcc::pipeline, so that as
much as possible can be private.

I've successfully bootstrapped the *combination* of patches on
x86_64-unknown-linux-gnu: all testcases show the same results as an
unpatched build (relative to r201148); I've split them up conceptually
in the hope of making review easier.

OK for trunk?

[I have a series of followup patches which move the passes themselves
into this system, integrating it all with ggc and pch, so that pass
instances can own GC references, at which point *lots* of modularization
of globals becomes possible.  However I'm still tracking down the last
few testsuite failures with that part - I'll post those patches when
I've got it fully working]

Thanks
Dave

[1] 
http://gcc.gnu.org/wiki/cauldron2013?action=AttachFile&do=view&target=removing-global-state-from-gcc.txt
(the class was named "universe" in my Cauldron talk, but I now
prefer "gcc::context").

David Malcolm (2):
  Introduce context class
  Introduce beginnings of a pipeline class.

 gcc/Makefile.in  | 19 +++---
 gcc/cgraphunit.c | 22 +++-
 gcc/context.c| 33 ++
 gcc/context.h| 51 +++
 gcc/lto-cgraph.c |  7 ++--
 gcc/lto/Make-lang.in |  3 +-
 gcc/lto/lto.c|  4 ++-
 gcc/passes.c | 97 +++-
 gcc/pipeline.h   | 89 +++
 gcc/statistics.c |  7 ++--
 gcc/toplev.c |  7 +++-
 gcc/tree-pass.h  | 29 
 12 files changed, 288 insertions(+), 80 deletions(-)
 create mode 100644 gcc/context.c
 create mode 100644 gcc/context.h
 create mode 100644 gcc/pipeline.h

-- 
1.7.11.7

[PATCH 2/2] Introduce beginnings of a pipeline class.

[David Malcolm]

gcc/
* Makefile.in (PIPELINE_H): New.
(lto-cgraph.o): Depend on CONTEXT_H and PIPELINE_H.
(passes.o): Likewise.
(statistics.o): Likewise.
(cgraphunit.o): Likewise.
(context.o): Depend on PIPELINE_H.

* pipeline.h: New.

* cgraphunit.c (cgraph_add_new_function): Update for moves
of globals to fields of pipeline.
(analyze_function): Likewise.
(expand_function): Likewise.
(ipa_passes): Likewise.
(compile): Likewise.

* context.c (context::context): New.
* context.h  (context::context): New.
(context::get_passes): New.
(context::passes_): New.

* lto-cgraph.c (input_node): Update for moves of globals to
fields of pipeline.

* passes.c (all_passes): Remove, in favor of a field of the
same name within the new class pipeline.
(all_small_ipa_passes): Likewise.
(all_lowering_passes): Likewise.
(all_regular_ipa_passes): Likewise.
(all_late_ipa_passes): Likewise.
(all_lto_gen_passes): Likewise.
(passes_by_id): Likewise.
(passes_by_id_size): Likewise.
(gcc_pass_lists): Remove, in favor of "pass_lists" field within
the new class pipeline.
(set_pass_for_id): Convert to...
(pipeline::set_pass_for_id): ...method.
(get_pass_for_id): Convert to...
(pipeline::get_pass_for_id): ...method.
(register_one_dump_file): Move body of implementation into...
(pipeline::register_one_dump_file): ...here.
(register_dump_files_1): Convert to...
(pipeline::register_dump_files_1): ...method.
(register_dump_files): Convert to...
(pipeline::register_dump_files): ...method.
(create_pass_tab): Update for moves of globals to fields of
pipeline.
(dump_passes): Move body of implementation into...
(pipeline::dump_passes): ...here.
(register_pass): Move body of implementation into...
(pipeline::register_pass): ...here.
(init_optimization_passes): Convert into...
(pipeline::pipeline): ...constructor for new pipeline class, and
initialize the pass_lists array.
(check_profile_consistency): Update for moves of globals to
fields of pipeline.
(dump_profile_report): Move body of implementation into...
(pipeline::dump_profile_report): ...here.
(ipa_write_summaries_1): Update for moves of pass lists from
being globals to fields of pipeline.
(ipa_write_optimization_summaries): Likewise.
(ipa_read_summaries):  Likewise.
(ipa_read_optimization_summaries): Likewise.
(execute_all_ipa_stmt_fixups): Likewise.

* statistics.c (statistics_fini): Update for moves of globals to
fields of pipeline.

* toplev.c (general_init): Replace call to
init_optimization_passes with construction of the pipeline
instance.

* tree-pass.h (all_passes): Remove, in favor of a field of the
same name within the new class pipeline.
(all_small_ipa_passes): Likewise.
(all_lowering_passes): Likewise.
(all_regular_ipa_passes): Likewise.
(all_lto_gen_passes): Likewise.
(all_late_ipa_passes): Likewise.
(passes_by_id): Likewise.
(passes_by_id_size): Likewise.
(gcc_pass_lists): Remove, in favor of "pass_lists" field within
the new class pipeline.
(get_pass_for_id): Remove.

gcc/lto/

* Make-lang.in (lto/lto.o:): Depend on CONTEXT_H and
PIPELINE_H.

* lto.c (do_whole_program_analysis): Update for move of
all_regular_ipa_passes from a global to a field of class
pipeline.
---
 gcc/Makefile.in  | 15 +---
 gcc/cgraphunit.c | 22 +++-
 gcc/context.c|  6 
 gcc/context.h| 11 +-
 gcc/lto-cgraph.c |  7 ++--
 gcc/lto/Make-lang.in |  3 +-
 gcc/lto/lto.c|  4 ++-
 gcc/passes.c | 97 +++-
 gcc/pipeline.h   | 89 +++
 gcc/statistics.c |  7 ++--
 gcc/toplev.c |  4 +--
 gcc/tree-pass.h  | 29 
 12 files changed, 212 insertions(+), 82 deletions(-)
 create mode 100644 gcc/pipeline.h

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index fb0cb4b..0b28c2d 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -987,6 +987,7 @@ PLUGIN_VERSION_H = plugin-version.h configargs.h
 LIBFUNCS_H = libfuncs.h $(HASHTAB_H)
 GRAPHITE_HTAB_H = graphite-htab.h graphite-clast-to-gimple.h $(HASH_TABLE_H)
 CONTEXT_H = context.h
+PIPELINE_H = pipeline.h
 
 #
 # Now figure out from those variables how to compile and link.
@@ -2183,7 +2184,8 @@ lto-cgraph.o: lto-cgraph.c $(CONFIG_H) $(SYSTEM_H) 
coretypes.h   \
$(HASHTAB_H) langhooks.h $(BASIC_BLOCK_H) \
$(TREE_FLOW_H) $(CGRAPH_H) $(FUNCTION_H) $(GGC_H) $(DIAGNOS

Re: [Patch] Reimplment regex matcher using DFS

[Paolo Carlini]

On 07/24/2013 04:50 PM, Tim Shen wrote:

On Wed, Jul 24, 2013 at 5:18 PM, Paolo Carlini  wrote:

Then we should also add something (by hand, unfortunately, as I explained)
to the audit trails of those bugs, because we want the original submitters
to double check the fixes with their own code, get as much feedback as
possible while we commit these improvements.

Committed.

Should I register a new bugzilla account to comment on these two
bugs(53622 and 57173), or any other one will do this?
What do you mean by "any other one"? Another Bugzilla account, not a new 
one, or another person, somebody else? Normally, whoever commits a patch 
also adds comments to the corresponding bug. If you don't have a 
Bugzilla account you should.


Paolo.

Re: [Patch] Reimplment regex matcher using DFS

[Jonathan Wakely]

On 24 July 2013 15:50, Tim Shen wrote:
>
> Committed.

Thanks!

> Should I register a new bugzilla account to comment on these two
> bugs(53622 and 57173), or any other one will do this?

I've added a comment to the bugs.

With svn commit rights you should be able to receive email at @gcc.gnu.org and if you use that address to create a bugzilla
account then you'll be able to update the status of Bugzilla entries.

[PATCH, i386, MPX] Support of Intel MPX ISA

[Ilya Enkovich]

Hi,

Here is a patch which adds support for new instructions from Intel
Memory Protection Extensions (MPX) ISA [1]

This patch introduces bound type, modes, registers and all MPX instructions.

Control transfer instructions are modified to support 'bnd' prefix
used by Intel MPX.

Bootstrap and checked on x86_64-linux. There is one issue [2] with
length attribute computation which leads to several fails in make
check. Currently I assume it is not a bug in this patch. But in case
it is a patch problem I have a version which uses temp attribute for
length computation as a workaround (resulting in clean make check).

Does it look good for trunk?

Thanks,
Ilya

[1] http://download-software.intel.com/sites/default/files/319433-015.pdf
[2] http://gcc.gnu.org/ml/gcc/2013-07/msg00311.html

-
2013-07-23  Ilya Enkovich  

* mode-classes.def (MODE_BOUND): New.
* tree.def (BOUND_TYPE): New.
* genmodes.c (complete_mode): Support MODE_BOUND.
(BOUND_MODE): New.
(make_bound_mode): New.
* machmode.h (BOUND_MODE_P): New.
* stor-layout.c (mode_for_bound): New.
(int_mode_for_mode): Support MODE_BOUND.
(layout_type): Support BOUND_TYPE.
* tree-pretty-print.c (dump_generic_node): Support BOUND_TYPE.
* tree.c (build_int_cst_wide): Support BOUND_TYPE.
(type_contains_placeholder_1): Likewise.
* tree.h (BOUND_TYPE_P): New.
* varasm.c (output_constant): Support BOUND_TYPE.
* config/i386/constraints.md (B): New.
* config/i386/i386-modes.def (BND32): New.
(BND64): New.
* config/i386/i386-protos.h (ix86_bnd_prefixed_insn_p): New.
* config/i386/i386.c (regclass_map): Add bound registers.
(dbx_register_map): Likewise.
(dbx64_register_map): Likewise.
(svr4_dbx_register_map): Likewise.
(ix86_code_end): Add MPX bnd prefix.
(output_set_got): Likewise.
(ix86_output_call_insn): Likewise.
(get_some_local_dynamic_name): Add '!' (MPX bnd) print prefix support.
(ix86_print_operand_punct_valid_p): Likewise.
(ix86_print_operand_address): Support UNSPEC_BNDMK_ADDR and
UNSPEC_BNDMK_ADDR.
(ix86_class_likely_spilled_p): Add bound regs support.
(ix86_hard_regno_mode_ok): Likewise.
(x86_order_regs_for_local_alloc): Likewise.
(ix86_bnd_prefixed_insn_p): New.
* config/i386/i386.h (FIRST_PSEUDO_REGISTER): Fix to new value.
(FIXED_REGISTERS): Add bound registers.
(CALL_USED_REGISTERS): Likewise.
(REG_ALLOC_ORDER): Likewise.
(HARD_REGNO_NREGS): Likewise.
(VALID_BND_REG_MODE): New.
(FIRST_BND_REG): New.
(LAST_BND_REG): New.
(reg_class): Add BND_REGS.
(REG_CLASS_NAMES): Likewise.
(REG_CLASS_CONTENTS): Likewise.
(BND_REGNO_P): New.
(ANY_BND_REG_P): New.
(BNDmode): New.
(HI_REGISTER_NAMES): Add bound registers.
* config/i386/i386.md (UNSPEC_BNDMK): New.
(UNSPEC_BNDMK_ADDR): New.
(UNSPEC_BNDSTX): New.
(UNSPEC_BNDLDX): New.
(UNSPEC_BNDLDX_ADDR): New.
(UNSPEC_BNDCL): New.
(UNSPEC_BNDCU): New.
(UNSPEC_BNDCN): New.
(UNSPEC_MPX_FENCE): New.
(BND0_REG): New.
(BND1_REG): New.
(type): Add mpxmov, mpxmk, mpxchk, mpxld, mpxst.
(length_immediate): Likewise.
(prefix_0f): Likewise.
(memory): Likewise.
(prefix_rep): Check for bnd prefix.
(BND): New.
(bnd_ptr): New.
(BNDCHECK): New.
(bndcheck): New.
(*jcc_1): Add MPX bnd prefix and fix length.
(*jcc_2): Likewise.
(jump): Likewise.
(simple_return_internal): Likewise.
(simple_return_pop_internal): Likewise.
(*indirect_jump): Add MPX bnd prefix.
(*tablejump_1): Likewise.
(simple_return_internal_long): Likewise.
(simple_return_indirect_internal): Likewise.
(_mk): New.
(*_mk): New.
(mov): New.
(*mov_internal_mpx): New.
(_): New.
(*_): New.
(_ldx): New.
(*_ldx): New.
(_stx): New.
(*_stx): New.
* config/i386/predicates.md (lea_address_operand) Rename to...
(address_no_seg_operand): ... this.
(address_mpx_no_base_operand): New.
(address_mpx_no_index_operand): New.
(bnd_mem_operator): New.


mpx-isa.patch
Description: Binary data

Re: [PATCH 3/4] Introduce NEXT_PASS_NUM macro

[Martin Jambor]

Hi,

On Tue, Jul 23, 2013 at 11:43:04AM -0400, David Malcolm wrote:
> On Tue, 2013-07-23 at 16:46 +0200, Martin Jambor wrote:
> > Hi,
> > 
> > On Mon, Jul 22, 2013 at 03:22:33PM -0400, David Malcolm wrote:
> > > On Mon, 2013-07-22 at 20:25 +0200, Martin Jambor wrote:
> > > > On Wed, Jul 17, 2013 at 09:18:22PM -0400, David Malcolm wrote:
> > > > > gcc/
> > > > > 
> > > > >   Explicitly number the instances of passes within passes.def.
> > > > > 
> > > > >   This is needed by a subsequent patch so that we can create
> > > > >   fields within the pipeline class for each pass instance (to help
> > > > >   locate pass instances when debugging).
> > > > > 
> > > > 
> > > > I don't really understand what you want to achieve.  Are you sure the
> > > > benefits are worth the work necessary to implement the processing of
> > > > passes.def.in?  Especially given that we already initialize
> > > > static_pass_number at run time and copy stuff around in
> > > > make_pass_instance when it is already set.  I assume this would
> > > > somehow allow us to directly dump data of say forwprop3 as apposed to
> > > > forwprop2 to but that would require constant awareness of the sequence
> > > > number of the currently running pass, which I think is also unpleasant
> > > > and error-prone.
> > > > 
> > > > I mean, you may have perfectly legitimate reasons for doing this, I'm
> > > > just wondering whether we are perhaps over-engineering this a bit.
> > > 
> > > The main goal here is part of eliminating global variables from gcc [1],
> > > to be able to create:
> > > 
> > > class pipeline
> > > {
> > >   /* omitting various other fields for clarity */
> > > 
> > >   opt_pass *pass_warn_unused_result;
> > >   opt_pass *pass_diagnose_omp_blocks;
> > >   opt_pass *pass_diagnose_tm_blocks;
> > >   opt_pass *pass_mudflap_1;
> > >   opt_pass *pass_lower_omp;
> > >   opt_pass *pass_lower_cf;
> > >   opt_pass *pass_lower_tm;
> > >   opt_pass *pass_refactor_eh;
> > >   opt_pass *pass_lower_eh;
> > >   opt_pass *pass_build_cfg;
> > >   opt_pass *pass_warn_function_return;
> > >   opt_pass *pass_expand_omp;
> > >   opt_pass *pass_build_cgraph_edges;
> > >   opt_pass *pass_ipa_free_lang_data;
> > >   opt_pass *pass_ipa_function_and_variable_visibility;
> > >   opt_pass *pass_early_local_passes;
> > >   opt_pass *pass_fixup_cfg;
> > >   opt_pass *pass_init_datastructures;
> > >   /* etc */
> > >   opt_pass *pass_clean_state;
> > > };
> > > 
> > > without having to list all of the pass kinds again, thus reusing the
> > > pass description from passes.def.  Without the numbering, I couldn't see
> > > a good way to avoid duplicate field names in the class.  So the
> > > numbering gives us uniqueness of field names in that class (and also
> > > makes debugging slightly easier, but that's a minor side-benefit).
> > > 
> > 
> > I really think the easier debugging benefit is really very small, if
> > any.  Is there another one?  Otherwise, I wouldn't bother with
> > explicit static fields for each pass but just have a linked list of
> > them.  If we ever make the pass manager to really be a manager of some
> > sort, this will happen anyway.
> > 
> > And as far as gdb is concerned, I'd rather avoid typing:
> > 
> > p 
> > current_context->pipeline_for_Ox_except_Og->my_great_pass_with_long_name_number_2->my_array[1]->stuff
> > p 
> > current_context->pipeline_for_Ox_except_Og->my_great_pass_with_long_name_number_2->my_array[2]->stuff
> > p 
> > current_context->pipeline_for_Ox_except_Og->my_great_pass_with_long_name_number_2->my_array[3]->stuff
> 
> Thanks - yes - I completely agree, having spent a lot of time in gdb
> with this lately :)
> 
> Note that there is only one "pipeline" per context, and I've kept the
> existing pass struct names (meaning "pass_vrp" rather than "vrp").
> 
> BTW, you mentioned dumping in an earlier post, sorry for not clarifying
> that aspect.  I haven't changed how dumping works, and I've taken some
> care to ensure that the numbering of the pass instances isn't disturbed
> (an earlier version of my patches broke that, leading to some of the
> test suite failing).   So whatever static_pass_number the 2nd instance
> of vrp ended up with before, it will continue to end up with after my
> patches.
> 
> > and instead do
> > 
> > set $d = (my_great_pass_class *) current_context->current_pass
> > p $d->my_array[1]->stuff
> > p $d->my_array[2]->stuff
> > p $d->my_array[3]->stuff
> > 
> > Or am I missing something?  Otherwise I'd just say don't bother with awk.
> 
> To give you a flavor of what I'm aiming at, here's a transcript from gdb
> on a build with some further patches, with some comments added inline:
> 
> The global "current context" variable is simply "g", for ease of typing
> - and my hope is that eventually this will be the *only* global variable
> [1]:
> 
> (gdb) p g
> $1 = (gcc::context *) 0x15652a0
> 
> In the talk I gave at Cauldron [2], this was a (universe*), but I've
> changed my mind again, and pr

Re: [PATCH 1/6] Andes nds32: configure settings for nds32 target.

[Chung-Ju Wu]

Hi, Joseph,

Sorry for the late revised patch.
We have completed all of it based on your review comments.

On 7/10/13 6:56 AM, Joseph S. Myers wrote:

On Mon, 8 Jul 2013, Chung-Ju Wu wrote:


+   nds32*-*-*)
+   supported_defaults="arch nds32_lib"
+
+   # process --with-arch
+   # the 'with_arch' will be analyzed and then set its ISA and 
FLAGS


I don't think this approach for processing --with-arch and setting
target_cpu_default in a complicated way based on it is a good idea.

The normal handling of --with-arch is to generate a -march= option via
OPTION_DEFAULT_SPECS.  If you do that, then the conversion from -march=
strings to sets of options enabled internally is done within the compiler
proper.



Now we handled --with-arch as you suggested.
The OPTION_DEFAULT_SPECS is added in nds32.h and we enable/disable
corresponding flags internally for -march= option in nds32.c.
The option -march is further described in documentation.


+nds32*-elf*)
+   # Basic makefile fragment and extra_parts for crt stuff.
+   tmake_file="${tmake_file} nds32/t-nds32"
+   extra_parts="crtbegin1.o crtend1.o"
+   # Append extra c-isr library according to --with-arch=X setting.


Now, given that you add a -march= option, there's the possibility that
someone might do a build with multilibs for different -march= values.  So
the choice here (libgcc configuration) needs to depend on the actual
configuration of the compiler for the multilib being built, probably via
configure tests in libgcc/configure.ac.



After discussing with other engineers,
we decided to support c-isr library for all arch configuration
so that we can avoid modifying libgcc/configure.ac.


Thanks for the review comments.
A revised patch is provided and here is a summary:

  1. Handle -march option within the compiler proper.
 Simplify the handling of --with-arch in config.gcc.
  2. The c-isr library is supported for all arch configuration.
  3. Use tm_defines so that we can have only one t-mlibs used.


contrib/
2013-07-24  Chung-Ju Wu  
Shiva Chen  

* config-list.mk (nds32le-elf, nds32be-elf): Add nds32 target.

gcc/
2013-07-24  Chung-Ju Wu  
Shiva Chen  

* config.gcc (nds32*-*-*): Add nds32 target.

libgcc/
2013-07-24  Chung-Ju Wu  
Shiva Chen  

* config.host (nds32*-elf*): Add nds32 target.


Best regards,
jasonwucj

diff --git contrib/config-list.mk contrib/config-list.mk
index 9a141c2..08acc35 100644
--- contrib/config-list.mk
+++ contrib/config-list.mk
@@ -43,7 +43,9 @@ LIST = aarch64-elf aarch64-linux-gnu \
   mipsisa64-elfoabi mipsisa64r2el-elf mipsisa64sr71k-elf mipsisa64sb1-elf \
   mipsel-elf mips64-elf mips64vr-elf mips64orion-elf mips-rtems \
   mips-wrs-vxworks mipstx39-elf mmix-knuth-mmixware mn10300-elf moxie-elf \
-  moxie-uclinux moxie-rtems pdp11-aout picochip-elfOPT-enable-obsolete \
+  moxie-uclinux moxie-rtems \
+  nds32le-elf nds32be-elf \
+  pdp11-aout picochip-elfOPT-enable-obsolete \
   powerpc-darwin8 \
   powerpc-darwin7 powerpc64-darwin powerpc-freebsd6 powerpc-netbsd \
   powerpc-eabispe powerpc-eabisimaltivec powerpc-eabisim ppc-elf \
diff --git gcc/config.gcc gcc/config.gcc
index 177677c..e941152 100644
--- gcc/config.gcc
+++ gcc/config.gcc
@@ -416,6 +416,10 @@ mips*-*-*)
extra_headers="loongson.h"
extra_options="${extra_options} g.opt mips/mips-tables.opt"
;;
+nds32*)
+   cpu_type=nds32
+   extra_headers="nds32_intrinsic.h"
+   ;;
 picochip-*-*)
 cpu_type=picochip
 ;;
@@ -2037,6 +2041,18 @@ mn10300-*-*)
use_collect2=no
use_gcc_stdint=wrap
;;
+nds32le-*-*)
+   target_cpu_default="0"
+   tm_defines="${tm_defines}"
+   tm_file="dbxelf.h elfos.h newlib-stdint.h ${tm_file}"
+   tmake_file="nds32/t-mlibs"
+   ;;
+nds32be-*-*)
+   target_cpu_default="0|MASK_BIG_ENDIAN"
+   tm_defines="${tm_defines} TARGET_BIG_ENDIAN_DEFAULT=1"
+   tm_file="dbxelf.h elfos.h newlib-stdint.h ${tm_file}"
+   tmake_file="nds32/t-mlibs"
+   ;;
 pdp11-*-*)
tm_file="${tm_file} newlib-stdint.h"
use_gcc_stdint=wrap
@@ -3622,6 +3638,39 @@ case "${target}" in
esac
;;
 
+   nds32*-*-*)
+   supported_defaults="arch nds32_lib"
+
+   # process --with-arch
+   case "${with_arch}" in
+   "" | v2 | v3 | v3m)
+   # OK
+   ;;
+   *)
+   echo "Cannot accept --with-arch=$with_arch, available 
values are: v2 v3 v3m" 1>&2
+   exit 1
+   ;;
+   esac
+
+   # process --with-nds32-lib
+   case "${with_nds32_lib}" in
+   "")
+   # the default library is newlib
+   with_nds32_lib=newlib
+   ;;
+   newlib)
+   

Re: [PATCH, i386, MPX] Support of Intel MPX ISA

[Joseph S. Myers]

On Wed, 24 Jul 2013, Ilya Enkovich wrote:

> Here is a patch which adds support for new instructions from Intel
> Memory Protection Extensions (MPX) ISA [1]
> 
> This patch introduces bound type, modes, registers and all MPX instructions.
> 
> Control transfer instructions are modified to support 'bnd' prefix
> used by Intel MPX.
> 
> Bootstrap and checked on x86_64-linux. There is one issue [2] with
> length attribute computation which leads to several fails in make
> check. Currently I assume it is not a bug in this patch. But in case
> it is a patch problem I have a version which uses temp attribute for
> length computation as a workaround (resulting in clean make check).
> 
> Does it look good for trunk?

This patch has no documentation (no changes to .texi files to document the 
new features added for users compiling code in C or other languages) and 
no testcases, so I have no idea what it is supposed to do at the 
user-visible level and I don't think it's suitable to be considered for 
trunk without either adding documentation and testcases to it, or posting 
subsequent patches in the series that actually add the user-visible 
features (and include documentation and testcases for them) that this 
patch is meant to enable.

(If this is the start of a patch series, you probably want to start with a 
0/N mail from that series, explaining the processor feature in high-level 
terms, how you intend that feature to be used from C code, the internal 
datastructures used inside the compiler to correspond to the uses of that 
feature from C, and the rationale for the choices you made.  Then this 
present patch might be 1/N, followed by a series of other patches adding 
other infrastructure or user-visible features.)

Your new function mode_for_bound lacks a comment explaining its semantics 
(those of the arguments and return value).

The definition of the new tree code BOUND_TYPE needs a substantial comment 
explaining the full, machine-independent semantics of such a tree type and 
of whatever tree fields are used in such a type - it's not a standard C 
concept.

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

Re: [www] Mention avx512 and mpx branches

[Gerald Pfeifer]

On Wed, 24 Jul 2013, Kirill Yukhin wrote:
> Patch adds mention of avx512 and mpx branches in svn.html.
> 
> Ok to install?

Yes, thanks!

Gerald

Re: [PATCH 2/6] Andes nds32: machine description of nds32 porting (1).

[Joseph S. Myers]

On Wed, 24 Jul 2013, Chung-Ju Wu wrote:

> We removed the fancy comment formatting as you suggested.
> However, for the comments like:
> 
> /* = */
> /* Title of section */
> /* = */
> 
> /* Title of subsection 1 */
> 
> /* Title of subsection 2 */
> 
> I wish I can keep such kinds of comment formatting so that
> it would be easier to distinguish the levels between sections
> and subsections against the chapter 17 in GCC Internals documentation.
> 
> Is it ok to keep such formatting? :)

You can use form-feeds (control-L characters) to separate logical sections 
in a source file.

> > > +/* Define intrinsic register names.
> > > +   Please refer to nds32_intrinsic.h file, the index is corresponding to
> > > +   'enum nds32_intrinsic_registers' data type values.
> > > +   NOTE that the base value starting from 1024.  */
> > > +static const char* nds32_intrinsic_register_names[] =
> > 
> > I suspect the array here can itself be made const.
> > 
> 
> I am declaring an array in which every element is "const char *" type.
> It is different to the declaration:
> "static char* const nds32_intrinsic_register_names[] ="

The question is whether it can be "static const char *const" - or do you 
need to modify the array itself at runtime (which would be unfortunate in 
terms of the aim to avoid global state)?

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

Re: [Patch, PR 57800] Waste work in gfc_match_call()

[Bernhard Reutner-Fischer]

On 23 July 2013 23:32:27 pcha...@cs.wisc.edu wrote:

Hi,

The problem appears in revision 201034 in version 4.9. I attached a
one-line patch that fixes it.  I also reported this problem
at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57800

Bootstrap and regression-tested on x86_64-linux.

In method "gfc_match_call()" in gcc/fortran/match.c, the loop on line
4189 should break immediately after "i" is set to 1.


2013-07-22  Chang  

* match.c (gfc_match_call): Exit loop after setting i.


Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c (revision 201034)
+++ gcc/fortran/match.c (working copy)
@@ -4188,7 +4188,10 @@
   i = 0;
   for (a = arglist; a; a = a->next)

   for (a = arglist; a || i; a = a->next)

Sounds more reasonable to me.

To repeat the previous question, curious how you get at these? scev one-liner?

Thanks,


 if (a->expr == NULL)
-  i = 1;
+  {
+   i = 1;
+   break;
+  }

   if (i)
 {

-Chang



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

Re: [Patch] Reimplment regex matcher using DFS

[Paolo Carlini]

On 07/24/2013 05:18 PM, Jonathan Wakely wrote:

Should I register a new bugzilla account to comment on these two
bugs(53622 and 57173), or any other one will do this?
I've added a comment to the bugs.

With svn commit rights you should be able to receive email at @gcc.gnu.org and if you use that address to create a bugzilla
account then you'll be able to update the status of Bugzilla entries.
Thanks. I added a few words to 57513 too. It would be nice to figure out 
which specific change fixed the link-time issue (provided a definition 
for the default constructor?)


Paolo.

Re: [PATCH 4/6] Andes nds32: testsuite modifications for nds32 target.

[Chung-Ju Wu]

Hi, Joseph,

Sorry for the late revised patch.
We have completed all of it based on your review comments.

On 7/10/13 8:08 AM, Joseph S. Myers wrote:

On Mon, 8 Jul 2013, Chung-Ju Wu wrote:


* gcc.dg/ucnid-11.c: Skip for nds32*-*-*.
* gcc.dg/ucnid-2.c: Skip for nds32*-*-*.
* gcc.dg/ucnid-3.c: Skip for nds32*-*-*.


Skipping these tests seems dubious - you should fix the assembler bug that
it fails to support extended identifiers instead of skipping the tests.



We have cooperated with toolchain engineers.
These three cases now are able to tested for nds32 target.


I don't see any sign of new architecture-specific testcases.  It's
generally a good idea to have such tests, to verify that built-in
functions and attributes and options work as expected, that the
diagnostics in the back end are given for the invalid input you expect to
give such diagnostics, etc.  (Of course the gcc.target/nds32 testsuite
will grow over time with testcases for bugs in such architecture-specific
functionality that get found and fixed over time.)



Thanks for the comments.  We added several new target-specific testcases
under gcc.target/nds32, including basic main execution and built-in
functions verification.


A revised patch is provided and here is a summary:

  1. The extend identifiers testcases are supposed to be tested.
  2. Add preliminary nds32-specific testcases.


gcc/testsuite/
2013-07-24  Chung-Ju Wu  
Shiva Chen  

* g++.dg/other/PR23205.C: Skip for nds32*-*-*.
* g++.dg/other/pr23205-2.C: Skip for nds32*-*-*.
* gcc.dg/20020312-2.c: Add __nds32__ case.
* gcc.dg/builtin-apply2.c: Skip for nds32*-*-*.
* gcc.dg/lower-subreg-1.c: Skip for nds32*-*-*.
* gcc.dg/sibcall-3.c: Expected fail for nds32*-*-*.
* gcc.dg/sibcall-4.c: Expected fail for nds32*-*-*.
* gcc.dg/stack-usage-1.c (SIZE): Define case for __nds32__.
* gcc.dg/torture/pr37868.c: Skip for nds32*-*-*.
* gcc.dg/torture/stackalign/builtin-apply-2.c: Skip for nds32*-*-*.
* gcc.dg/tree-ssa/20040204-1.c: Expected fail for nds32*-*-*.
* gcc.dg/tree-ssa/forwprop-28.c: Skip for nds32*-*-*.
* gcc.dg/tree-ssa/pr42585.c: Skip for nds32*-*-*.
* gcc.dg/tree-ssa/sra-12.c: Skip for nds32*-*-*.
* gcc.target/nds32: New nds32 specific directory and testcases.
* lib/target-supports.exp (check_profiling_available): Check for
nds32*-*-elf.


Best regards,
jasonwucj

diff --git gcc/testsuite/g++.dg/other/PR23205.C 
gcc/testsuite/g++.dg/other/PR23205.C
index e55710b..26a9dd5 100644
--- gcc/testsuite/g++.dg/other/PR23205.C
+++ gcc/testsuite/g++.dg/other/PR23205.C
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-skip-if "No stabs" { aarch64*-*-* mmix-*-* *-*-aix* alpha*-*-* 
hppa*64*-*-* ia64-*-* tile*-*-* *-*-vxworks } { "*" } { "" } } */
+/* { dg-skip-if "No stabs" { aarch64*-*-* mmix-*-* nds32*-*-* *-*-aix* 
alpha*-*-* hppa*64*-*-* ia64-*-* tile*-*-* *-*-vxworks } { "*" } { "" } } */
 /* { dg-options "-gstabs+ -fno-eliminate-unused-debug-types" } */
 
 const int foobar = 4;
diff --git gcc/testsuite/g++.dg/other/pr23205-2.C 
gcc/testsuite/g++.dg/other/pr23205-2.C
index 607e5a2..b25cb73 100644
--- gcc/testsuite/g++.dg/other/pr23205-2.C
+++ gcc/testsuite/g++.dg/other/pr23205-2.C
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-skip-if "No stabs" { aarch64*-*-* mmix-*-* *-*-aix* alpha*-*-* 
hppa*64*-*-* ia64-*-* tile*-*-* } { "*" } { "" } } */
+/* { dg-skip-if "No stabs" { aarch64*-*-* mmix-*-* nds32*-*-* *-*-aix* 
alpha*-*-* hppa*64*-*-* ia64-*-* tile*-*-* } { "*" } { "" } } */
 /* { dg-options "-gstabs+ -fno-eliminate-unused-debug-types 
-ftoplevel-reorder" } */
 
 const int foobar = 4;
diff --git gcc/testsuite/gcc.dg/20020312-2.c gcc/testsuite/gcc.dg/20020312-2.c
index 633da5b..6f5a953 100644
--- gcc/testsuite/gcc.dg/20020312-2.c
+++ gcc/testsuite/gcc.dg/20020312-2.c
@@ -52,6 +52,8 @@ extern void abort (void);
 /* No pic register.  */
 #elif defined(__moxie__)
 /* No pic register.  */
+#elif defined(__nds32__)
+/* No pic register.  */
 #elif defined(__hppa__)
 /* PIC register is %r27 or %r19, but is used even without -fpic.  */
 #elif defined(__pdp11__)
diff --git gcc/testsuite/gcc.dg/builtin-apply2.c 
gcc/testsuite/gcc.dg/builtin-apply2.c
index 9b73147..7bf3049 100644
--- gcc/testsuite/gcc.dg/builtin-apply2.c
+++ gcc/testsuite/gcc.dg/builtin-apply2.c
@@ -1,5 +1,5 @@
 /* { dg-do run } */
-/* { dg-skip-if "Variadic funcs have all args on stack. Normal funcs have args 
in registers." { "aarch64*-*-* avr-*-* " } { "*" } { "" } } */
+/* { dg-skip-if "Variadic funcs have all args on stack. Normal funcs have args 
in registers." { "aarch64*-*-* avr-*-* nds32*-*-*" } { "*" } { "" } } */
 /* { dg-skip-if "Variadic funcs use Base AAPCS.  Normal funcs use VFP 
variant." { "arm*-*-*" } { "-mfloat-abi=hard" } { "" } } */
 
 /* PR target/12503 */
diff --git gcc/testsuite/gcc.dg/lower-subreg-1.c 
gcc/testsuite/gcc.dg/lower-s

Re: [Patch] Reimplment regex matcher using DFS

[Tim Shen]

On Thu, Jul 25, 2013 at 12:13 AM, Paolo Carlini
 wrote:
> Thanks. I added a few words to 57513 too. It would be nice to figure out
> which specific change fixed the link-time issue (provided a definition for
> the default constructor?)

Comment added.


-- 
Tim Shen

Re: [PATCH 5/6] Andes nds32: documentation for nds32 target.

[Chung-Ju Wu]

On 7/12/13 1:35 AM, Chung-Ju Wu wrote:

On 7/10/13 8:11 AM, Joseph S. Myers wrote:

Don't you have built-in functions to document as well?



You are right.
We did forget to describe built-in functions in the documentation.
Thanks for pointing out our carelessness. :)


Use "@:" (or a comma) after "i.e." in Texinfo sources.  The range "16-47"
should use an en dash (so "16--47").



Fixed accordingly.

Thanks for the review comments.  A revised patch is provided
and the issues you mentioned are fixed:
   a. Describe nds32 built-in functions.
   b. Use "@:" and "16--47"



Because we have replaced -misa= with -march= option,
we have another revised patch for documentation.

A revised patch is provided and here is a summary:

  1. Replace -misa= with -march= option.


gcc/
2013-07-24  Chung-Ju Wu  
Shiva Chen  

* doc/invoke.texi (NDS32 options): Document nds32 specific options.
* doc/md.texi (NDS32 family): Document nds32 specific constraints.
* doc/install.texi (Cross-Compiler-Specific Options): Document
--with-nds32-lib for nds32 target.
* doc/extend.texi (Function Attributes): Document nds32 specific
attributes.


Best regards,
jasonwucj

diff --git gcc/doc/extend.texi gcc/doc/extend.texi
index 4dfaaa8..c876aed 100644
--- gcc/doc/extend.texi
+++ gcc/doc/extend.texi
@@ -2502,6 +2502,12 @@ on data in the eight-bit data area.  Note the eight-bit 
data area is limited to
 You must use GAS and GLD from GNU binutils version 2.7 or later for
 this attribute to work correctly.
 
+@item exception
+@cindex exception handler functions
+Use this attribute on the NDS32 target to indicate that the specified function
+is an exception handler.  The compiler will generate corresponding sections
+for use in an exception handler.
+
 @item exception_handler
 @cindex exception handler functions on the Blackfin processor
 Use this attribute on the Blackfin to indicate that the specified function
@@ -2922,6 +2928,32 @@ void __attribute__ ((interrupt, use_shadow_register_set,
  use_debug_exception_return)) v7 ();
 @end smallexample
 
+On NDS32 target, this attribute is to indicate that the specified function
+is an interrupt handler.  The compiler will generate corresponding sections
+for use in an interrupt handler.  You can use the following attributes
+to modify the behavior:
+@table @code
+@item nested
+@cindex @code{nested} attribute
+This interrupt service routine is interruptible.
+@item not_nested
+@cindex @code{not_nested} attribute
+This interrupt service routine is not interruptible.
+@item nested_ready
+@cindex @code{nested_ready} attribute
+This interrupt service routine is interruptible after @code{PSW.GIE}
+(global interrupt enable) is set.  This allows interrupt service routine to
+finish some short critical code before enabling interrupts.
+@item save_all
+@cindex @code{save_all} attribute
+The system will help save all registers into stack before entering
+interrupt handler.
+@item partial_save
+@cindex @code{partial_save} attribute
+The system will help save caller registers into stack before entering
+interrupt handler.
+@end table
+
 On RL78, use @code{brk_interrupt} instead of @code{interrupt} for
 handlers intended to be used with the @code{BRK} opcode (i.e.@: those
 that must end with @code{RETB} instead of @code{RETI}).
@@ -3143,10 +3175,11 @@ and newer.
 
 @item naked
 @cindex function without a prologue/epilogue code
-Use this attribute on the ARM, AVR, MCORE, RL78, RX and SPU ports to indicate 
that
-the specified function does not need prologue/epilogue sequences generated by
-the compiler.  It is up to the programmer to provide these sequences. The
-only statements that can be safely included in naked functions are
+Use this attribute on the ARM, AVR, MCORE, NDS32, RL78, RX and SPU ports
+to indicate that the specified function does not need prologue/epilogue
+sequences generated by the compiler.
+It is up to the programmer to provide these sequences.
+The only statements that can be safely included in naked functions are
 @code{asm} statements that do not have operands.  All other statements,
 including declarations of local variables, @code{if} statements, and so
 forth, should be avoided.  Naked functions should be used to implement the
@@ -3491,6 +3524,21 @@ safe since the loaders there save EAX, EDX and ECX.  
(Lazy binding can be
 disabled with the linker or the loader if desired, to avoid the
 problem.)
 
+@item reset
+@cindex reset handler functions
+Use this attribute on the NDS32 target to indicate that the specified function
+is a reset handler.  The compiler will generate corresponding sections
+for use in a reset handler.  You can use the following attributes
+to provide extra exception handling:
+@table @code
+@item nmi
+@cindex @code{nmi} attribute
+Provide a user-defined function to handle NMI exception.
+@item warm
+@cindex @code{warm} attribute
+Provide a user-defined function to handle warm reset exce

Re: [www] Mention avx512 and mpx branches

[Kirill Yukhin]

Thanks, checked in!

On Wed, Jul 24, 2013 at 8:06 PM, Gerald Pfeifer  wrote:
> On Wed, 24 Jul 2013, Kirill Yukhin wrote:
>> Patch adds mention of avx512 and mpx branches in svn.html.
>>
>> Ok to install?
>
> Yes, thanks!
>
> Gerald

Re: [Patch, PR 57800] Waste work in gfc_match_call()

[Bernhard Reutner-Fischer]

On 24 July 2013 18:12:00 "Bernhard Reutner-Fischer"  
wrote:

On 23 July 2013 23:32:27 pcha...@cs.wisc.edu wrote:
> Hi,
>
> The problem appears in revision 201034 in version 4.9. I attached a
> one-line patch that fixes it.  I also reported this problem
> at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57800
>
> Bootstrap and regression-tested on x86_64-linux.
>
> In method "gfc_match_call()" in gcc/fortran/match.c, the loop on line
> 4189 should break immediately after "i" is set to 1.
>
>
> 2013-07-22  Chang  
>
> * match.c (gfc_match_call): Exit loop after setting i.
>
>
> Index: gcc/fortran/match.c
> ===
> --- gcc/fortran/match.c(revision 201034)
> +++ gcc/fortran/match.c(working copy)
> @@ -4188,7 +4188,10 @@
>i = 0;
>for (a = arglist; a; a = a->next)


   for (a = arglist; !i || a; a = a->next)
Swap that, obviously..


Sounds more reasonable to me.

To repeat the previous question, curious how you get at these? scev one-liner?

Thanks,

>  if (a->expr == NULL)
> -  i = 1;
> +  {
> +  i = 1;
> +  break;
> +  }
>
>if (i)
>  {
>
> -Chang



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

Re: [PATCH 3/6] Andes nds32: libgcc of nds32 porting.

[Chung-Ju Wu]

Hi, Joseph,

Sorry for that we have to zip this patch.  It seems that the plaintext
revised patch is too large to be sent to mailing list due to lots of
copyright information.

And I am really sorry for that you probably kept receiving the same mail.
Somehow the this [PATCH 3/6] mail just didn't appear on mailing list archive.
So I tried several times.  Really sorry about that.

On 7/10/13 8:04 AM, Joseph S. Myers wrote:

There are lots of files in this patch with no copyright or license
notices.  GNU policy is that every file of more than ten lines needs
copyright and license notices (with the libgcc license exception in this
case), or a notice that the file is in the public domain.

License notices should be GPLv3+exception, not GPLv2 with the old version
of the exception which you have in
libgcc/config/nds32/lib1asmsrc-mculib.S and some other files.



Thanks for the comment.  We have add GPLv3+exception for all the files.

A revised patch is provided and here is a summary:

  1. Add GPLv3+exception copyright and license notice for all
 c-isr implementation and libgcc stuff.


libgcc/
2013-07-24  Chung-Ju Wu  
Shiva Chen  

* config/nds32 : New directory and files.


Best regards,
jasonwucj



3-nds32-libgcc.v2.patch.tar.gz
Description: GNU Zip compressed data

[PATCH] doc: mention that -ftls-model is subject to optimization

[Alexander Monakov]

Hello,

As discussed here, the current behavior of -ftls-model is intended:
http://gcc.gnu.org/ml/gcc/2013-07/msg00248.html
(in short: unlike the attribute, -ftls-model sets a "most general" model to be
used, but the compiler can use a less general model than specified, making it
impossible to set global-dynamic model on the command line for non-PIC code).

I'd like to add a clarification to the docs. OK for trunk?

2013-07-24  Alexander Monakov  

* doc/invoke.texi: Mention that -ftls-model does not force the final
model.

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index d99d217..4d1fbee 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -20802,6 +20802,9 @@ Not all targets provide complete support for this 
switch.
 Alter the thread-local storage model to be used (@pxref{Thread-Local}).
 The @var{model} argument should be one of @code{global-dynamic},
 @code{local-dynamic}, @code{initial-exec} or @code{local-exec}.
+Note that the choice is subject to optimization: the compiler may use
+a more efficient model for symbols not visible outside of the translation
+unit, or if @option{-fpic} is not given on the command line.
 
 The default without @option{-fpic} is @code{initial-exec}; with
 @option{-fpic} the default is @code{global-dynamic}.

Re: Go patch committed: Update libgo to 1.1.1

[Ian Lance Taylor]

On Wed, Jul 24, 2013 at 4:49 AM, Rainer Orth
 wrote:
> Ian Lance Taylor  writes:
>
>> On Thu, Jul 18, 2013 at 6:59 AM, Rainer Orth
>>  wrote:
>>> Ian Lance Taylor  writes:
>>>
 I have committed a large patch to update libgo to the library that was
 part of the Go 1.1.1 release.  As usual, I'm not including the entire
 patch in this e-mail message, because it is too large.  I'm only
 including the changes to the files that are partially gccgo-specific.
 Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
 Committed to mainline and 4.8 branch.
>>>
>>> This broke the Solaris build:
>>>
>>> /vol/gcc/src/hg/trunk/local/libgo/go/log/syslog/syslog_libc.go:18:25: 
>>> error: use of undefined type 'serverConn'
>>>  func unixSyslog() (conn serverConn, err error) {
>>>  ^
>>> make[6]: *** [log/syslog.lo] Error 1
>>>
>>> Didn't make much progress on this one.
>>
>> The interface I put in a while back for Solaris support got taken out
>> from the master library, and I missed it.  This patch restores it.
>> Committed to mainline and 4.8 branch.  I've also sent a patch to the
>> master library to restore the interface.
>
>
> --- FAIL: TestReadUnixgramWithUnnamedSocket (0.00 seconds)
> :0: neighbor address is @
> --- FAIL: TestReadUnixgramWithZeroBytesBuffer (0.00 seconds)
> :0: neighbor address is @
> --- FAIL: TestUnixConnLocalAndRemoteNames (0.01 seconds)
> :0: got &net.UnixAddr{Name:"@", Net:"unix"}, expected 
> &net.UnixAddr{Name:"", Net:"unix"}
> unix_test.go:159: Listener.Accept failed: use of closed network 
> connection
> --- FAIL: TestUnixgramConnLocalAndRemoteNames (0.00 seconds)
> :0: got &net.UnixAddr{Name:"@", Net:"unixgram"}, expected 
> &net.UnixAddr{Name:"", Net:"unixgram"}
> FAIL
> FAIL: net

Fixed with this patch.  Committed to mainline and 4.8 branch.

Ian


foo.patch
Description: Binary data

Re: Go patch committed: Update libgo to 1.1.1

[Ian Lance Taylor]

On Wed, Jul 24, 2013 at 4:49 AM, Rainer Orth
 wrote:
> Ian Lance Taylor  writes:
>
>> On Thu, Jul 18, 2013 at 6:59 AM, Rainer Orth
>>  wrote:
>>> Ian Lance Taylor  writes:
>>>
 I have committed a large patch to update libgo to the library that was
 part of the Go 1.1.1 release.  As usual, I'm not including the entire
 patch in this e-mail message, because it is too large.  I'm only
 including the changes to the files that are partially gccgo-specific.
 Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
 Committed to mainline and 4.8 branch.
>>>
>>> This broke the Solaris build:
>>>
>>> /vol/gcc/src/hg/trunk/local/libgo/go/log/syslog/syslog_libc.go:18:25: 
>>> error: use of undefined type 'serverConn'
>>>  func unixSyslog() (conn serverConn, err error) {
>>>  ^
>>> make[6]: *** [log/syslog.lo] Error 1
>>>
>>> Didn't make much progress on this one.
>>
>> The interface I put in a while back for Solaris support got taken out
>> from the master library, and I missed it.  This patch restores it.
>> Committed to mainline and 4.8 branch.  I've also sent a patch to the
>> master library to restore the interface.
>
> The new failures are:
>
> 32-bit runtime:
>
> runtime: memory allocated by OS (0xbd60) not in usable range 
> [0xdde0,0x5de0)
> runtime: out of memory: cannot allocate 2097152-byte block (536870912 in use)
> fatal error: out of memory

This patch fixes it.  Looks like the Solaris linker does not define
the symbol "end", and the value was being picked up from some shared
library.  Committed to mainline and 4.8 branch.

Ian


foo.patch
Description: Binary data

Re: [PATCH, i386, MPX 1/X] Support of Intel MPX ISA

[Ilya Enkovich]

2013/7/24 Joseph S. Myers :
> On Wed, 24 Jul 2013, Ilya Enkovich wrote:
>
>> Here is a patch which adds support for new instructions from Intel
>> Memory Protection Extensions (MPX) ISA [1]
>>
>> This patch introduces bound type, modes, registers and all MPX instructions.
>>
>> Control transfer instructions are modified to support 'bnd' prefix
>> used by Intel MPX.
>>
>> Bootstrap and checked on x86_64-linux. There is one issue [2] with
>> length attribute computation which leads to several fails in make
>> check. Currently I assume it is not a bug in this patch. But in case
>> it is a patch problem I have a version which uses temp attribute for
>> length computation as a workaround (resulting in clean make check).
>>
>> Does it look good for trunk?
>
> This patch has no documentation (no changes to .texi files to document the
> new features added for users compiling code in C or other languages) and
> no testcases, so I have no idea what it is supposed to do at the
> user-visible level and I don't think it's suitable to be considered for
> trunk without either adding documentation and testcases to it, or posting
> subsequent patches in the series that actually add the user-visible
> features (and include documentation and testcases for them) that this
> patch is meant to enable.
>
> (If this is the start of a patch series, you probably want to start with a
> 0/N mail from that series, explaining the processor feature in high-level
> terms, how you intend that feature to be used from C code, the internal
> datastructures used inside the compiler to correspond to the uses of that
> feature from C, and the rationale for the choices you made.  Then this
> present patch might be 1/N, followed by a series of other patches adding
> other infrastructure or user-visible features.)
>
Well, this patch does not introduce any changes on user-visible level.
It just adds MPX instructions support to i386 target. Usually each new
x86 instruction has corresponding builtin function and therefore is
provided with a testcase. But MPX instructions do not have builtin
function for direct generation and therefore there are no tests for
this patch.

I have subsequent patches to add user-visible features based on MPX.
Sorry for missing series indicator (fixed). High-level feature based
on MPX is described on GCC Wiki
(http://gcc.gnu.org/wiki/Intel%20MPX%20support%20in%20the%20GCC%20compiler).
Current implementation state is available in recently announced mpx
branch.

> Your new function mode_for_bound lacks a comment explaining its semantics
> (those of the arguments and return value).
>
> The definition of the new tree code BOUND_TYPE needs a substantial comment
> explaining the full, machine-independent semantics of such a tree type and
> of whatever tree fields are used in such a type - it's not a standard C
> concept.

Thanks for comments! I'll add descriptions.

Thanks,
Ilya
>
> --
> Joseph S. Myers
> jos...@codesourcery.com

Go patch committed: Fix handling of zero sized struct

[Ian Lance Taylor]

When a Go global variable has zero size, we fudge it to make it larger
to avoid problems with the linker.  This turned out to cause a bug with
a struct with a zero-sized field, since code still expected to be able
to access the field.  This patch changes the zero size handling to
recreate such structs, making sure that the first field has non-zero
size.  Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline and 4.8 branch.

Ian


2013-07-24  Ian Lance Taylor  

* go-gcc.cc (Gcc_backend::non_zero_size_type): If a struct has a
fields, recreate those fields with the first one with a non-zero
size.


Index: go-gcc.cc
===
--- go-gcc.cc	(revision 201178)
+++ go-gcc.cc	(working copy)
@@ -1242,20 +1242,41 @@ Gcc_backend::non_zero_size_type(tree typ
   switch (TREE_CODE(type))
 {
 case RECORD_TYPE:
-  {
-	if (go_non_zero_struct == NULL_TREE)
-	  {
-	type = make_node(RECORD_TYPE);
-	tree field = build_decl(UNKNOWN_LOCATION, FIELD_DECL,
-get_identifier("dummy"),
-boolean_type_node);
-	DECL_CONTEXT(field) = type;
-	TYPE_FIELDS(type) = field;
-	layout_type(type);
-	go_non_zero_struct = type;
-	  }
-	return go_non_zero_struct;
-  }
+  if (TYPE_FIELDS(type) != NULL_TREE)
+	{
+	  tree ns = make_node(RECORD_TYPE);
+	  tree field_trees = NULL_TREE;
+	  tree *pp = &field_trees;
+	  for (tree field = TYPE_FIELDS(type);
+	   field != NULL_TREE;
+	   field = DECL_CHAIN(field))
+	{
+	  tree ft = TREE_TYPE(field);
+	  if (field == TYPE_FIELDS(type))
+		ft = non_zero_size_type(ft);
+	  tree f = build_decl(DECL_SOURCE_LOCATION(field), FIELD_DECL,
+  DECL_NAME(field), ft);
+	  DECL_CONTEXT(f) = ns;
+	  *pp = f;
+	  pp = &DECL_CHAIN(f);
+	}
+	  TYPE_FIELDS(ns) = field_trees;
+	  layout_type(ns);
+	  return ns;
+	}
+
+  if (go_non_zero_struct == NULL_TREE)
+	{
+	  type = make_node(RECORD_TYPE);
+	  tree field = build_decl(UNKNOWN_LOCATION, FIELD_DECL,
+  get_identifier("dummy"),
+  boolean_type_node);
+	  DECL_CONTEXT(field) = type;
+	  TYPE_FIELDS(type) = field;
+	  layout_type(type);
+	  go_non_zero_struct = type;
+	}
+  return go_non_zero_struct;
 
 case ARRAY_TYPE:
   {

Merge from gcc 4.8 branch to gccgo branch

[Ian Lance Taylor]

I merged gcc 4.8 branch revision 201223 to the gccgo branch.

Ian

Re: RFA: Fix rtl-optimization/57968

[Jeff Law]

On 07/24/2013 06:07 AM, Joern Rennecke wrote:

The problem is fixed by simply moving the code that skips insns that don't
set a part of the return value below the code that checks if the insn needs
a non-MODE_EXIT mode setting.

bootstrapped/regtested on i686-pc-linux-gnu


2013-07-24  Joern Rennecke  

 PR rtl-optimization/57968
 * mode-switching.c (create_pre_exit): Allow instructions that
 don't set a return register to need a non-exit mode.

This is fine.  Please install.

jeff

[PATCH, PowerPC] Fix vector pack insns for little endian

[Bill Schmidt]

In little endian mode, we need to reverse the order of operands for
vector pack operations.  This corrects 20 failures in the test suite in
LE mode.

Patch based on work by Anton Blanchard; I simplified it and generalized
it to all the vector pack insns.

Bootstrapped and tested on powerpc64-unknown-linux-gnu with no new
regressions.  Ok for trunk?

Thanks,
Bill


2013-07-24  Bill Schmidt  
Anton Blanchard 

* config/rs6000/altivec.md (altivec_vpkpx): Handle little endian.
(altivec_vpksss): Likewise.
(altivec_vpksus): Likewise.
(altivec_vpkuus): Likewise.
(altivec_vpkuum): Likewise.


Index: gcc/config/rs6000/altivec.md
===
--- gcc/config/rs6000/altivec.md(revision 201207)
+++ gcc/config/rs6000/altivec.md(working copy)
@@ -1047,7 +1047,13 @@
   (match_operand:V4SI 2 "register_operand" "v")]
 UNSPEC_VPKPX))]
   "TARGET_ALTIVEC"
-  "vpkpx %0,%1,%2"
+  "*
+  {
+if (BYTES_BIG_ENDIAN)
+  return \"vpkpx %0,%1,%2\";
+else
+  return \"vpkpx %0,%2,%1\";
+  }"
   [(set_attr "type" "vecperm")])
 
 (define_insn "altivec_vpksss"
@@ -1056,7 +1062,13 @@
(match_operand:VP 2 "register_operand" "v")]
   UNSPEC_VPACK_SIGN_SIGN_SAT))]
   ""
-  "vpksss %0,%1,%2"
+  "*
+  {
+if (BYTES_BIG_ENDIAN)
+  return \"vpksss %0,%1,%2\";
+else
+  return \"vpksss %0,%2,%1\";
+  }"
   [(set_attr "type" "vecperm")])
 
 (define_insn "altivec_vpksus"
@@ -1065,7 +1077,13 @@
(match_operand:VP 2 "register_operand" "v")]
   UNSPEC_VPACK_SIGN_UNS_SAT))]
   ""
-  "vpksus %0,%1,%2"
+  "*
+  {
+if (BYTES_BIG_ENDIAN)
+  return \"vpksus %0,%1,%2\";
+else
+  return \"vpksus %0,%2,%1\";
+  }"
   [(set_attr "type" "vecperm")])
 
 (define_insn "altivec_vpkuus"
@@ -1074,7 +1092,13 @@
(match_operand:VP 2 "register_operand" "v")]
   UNSPEC_VPACK_UNS_UNS_SAT))]
   ""
-  "vpkuus %0,%1,%2"
+  "*
+  {
+if (BYTES_BIG_ENDIAN)
+  return \"vpkuus %0,%1,%2\";
+else
+  return \"vpkuus %0,%2,%1\";
+  }"
   [(set_attr "type" "vecperm")])
 
 (define_insn "altivec_vpkuum"
@@ -1083,7 +1107,13 @@
(match_operand:VP 2 "register_operand" "v")]
   UNSPEC_VPACK_UNS_UNS_MOD))]
   ""
-  "vpkuum %0,%1,%2"
+  "*
+  {
+if (BYTES_BIG_ENDIAN)
+  return \"vpkuum %0,%1,%2\";
+else
+  return \"vpkuum %0,%2,%1\";
+  }"
   [(set_attr "type" "vecperm")])
 
 (define_insn "*altivec_vrl"

Re: msp430 port

[Jeff Law]

On 07/19/2013 05:32 PM, DJ Delorie wrote:

Every pattern that is using (subreg:SI (thing:PSI)) needs to be
explained on this list and given an explicit clearance.  It really looks
like you're just papering over problems elsewhere.


Most of them are just optimizations, but the problem with reload is
that an SImode register *can't* hold a PSImode value.  Registers are
20 bits; a PSImode value is 20 bits.  SImode values require two
registers (16 bits each).
Sorry, but I don't see how this is any different than what we've done 
before.  For example, the mn102 had 24bit address registers (PSImode), 
but anytime you wanted to work on in SImode, you head to use a pair of 
16 bit data registers.


What you need to do is explain the reload issue in enough detail that 
someone can help guide you to what needs to be fixed either in reload or 
in the port itself.




Converting between SImode and PSImode is
both nontrivial and very common (pointer math).

Yes, I'm painfully aware.




What I really need is an int20_t type in the core of gcc, so I can set
Pmode to *that*, to avoid the SImode stuff completely.  But that's a
core change, not a target change.
Right.  I'm not aware of anything that'll make adding int20_t a 
tractable problem in GCC.






As the comment in addhi_cy mentions, that is truly dangerous and
wrong.  You can't let that stay in the port without proving GCC
won't do a code motion that causes problems.  Just because sub, cmp,
shift, etc haven't shown up in your tests doesn't mean they can't
happen, they just didn't show up in your tests.


I'll try again, but last time I put all the carry logic in all the
insns, and code size grew quite a bit, and I couldn't figure out why.
Do I need two patterns for each insn?  One that clobbers the carry,
and one that sets it?

Look at the x86, where we have all this pain as well.

My point is that by not modeling this right, you're running the risk of 
having an insn which sets the carry flag get inserted right in between 
these two insn sequences.


You might also get better code by keeping those two instruction 
sequences as a single insn until after reload.


Jeff

Re: [PATCH, PowerPC] Fix vector pack insns for little endian

[David Edelsohn]

On Wed, Jul 24, 2013 at 5:05 PM, Bill Schmidt
 wrote:
> In little endian mode, we need to reverse the order of operands for
> vector pack operations.  This corrects 20 failures in the test suite in
> LE mode.
>
> Patch based on work by Anton Blanchard; I simplified it and generalized
> it to all the vector pack insns.
>
> Bootstrapped and tested on powerpc64-unknown-linux-gnu with no new
> regressions.  Ok for trunk?
>
> Thanks,
> Bill
>
>
> 2013-07-24  Bill Schmidt  
> Anton Blanchard 
>
> * config/rs6000/altivec.md (altivec_vpkpx): Handle little endian.
> (altivec_vpksss): Likewise.
> (altivec_vpksus): Likewise.
> (altivec_vpkuus): Likewise.
> (altivec_vpkuum): Likewise.

Okay.

Thanks, David

[Patch, Fortran] PR 57639: [OOP] ICE with polymorphism (and illegal code)

[Janus Weil]

Hi all,

here is a straightforward patch for an ICE-on-invalid problem, which
basically adds some checks for 'class_ok'.

Regtested on x86_64-unknown-linux-gnu. Ok for trunk?

Cheers,
Janus


2013-07-24  Janus Weil  

PR fortran/57639
* interface.c (compare_parameter): Check for class_ok.
* simplify.c (gfc_simplify_same_type_as): Ditto.

2013-07-24  Janus Weil  

PR fortran/57639
* gfortran.dg/unlimited_polymorphic_9.f90: New.


pr57639.diff
Description: Binary data


unlimited_polymorphic_9.f90
Description: Binary data

Re: [Patch, Fortran] PR 57639: [OOP] ICE with polymorphism (and illegal code)

[Steve Kargl]

On Wed, Jul 24, 2013 at 11:53:09PM +0200, Janus Weil wrote:
> Hi all,
> 
> here is a straightforward patch for an ICE-on-invalid problem, which
> basically adds some checks for 'class_ok'.
> 
> Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
> 

OK.

-- 
Steve

[google][4.8] Expose all target specific builtins unconditionally for LIPO builds

[Sriraman Tallam]

The following test-case fails in LIPO mode during profile-use build:

main.cc

__attribute__((target("sse4.2")))
unsigned int problem_aux (unsigned int A, unsigned int B);


int main (int argc, char *argv[])
{
  return problem_aux (0, 0);
}

aux.cc
-
__attribute__((target("sse4.2")))
unsigned int problem_aux (unsigned int A, unsigned int B)
{
  return __builtin_ia32_crc32qi (A, B);
}

$ g++ -O2 -fprofile-generate main.cc aux.cc
$ ./a.out
$ g++ -O2 -fprofile-use main.cc
error: '__builtin_ia32_crc32qi' was not declared in this scope

This happens when parsing the auxiliary module. __builtin_ia32_crc32qi
is a target specific builtin that gets created after the target
attribute is seen in the declaration of problem_aux in the primary
module. This is too late for adding theisbuiltin to the list of
knowns, the buitlins get saved when cp_save_built_in_decl_pre_parsing
in cp/cp-objcp-common.c is called much earlier.  Hence, this builtin
which is created during primary module parsing is not available when
parsing the auxiliary module.

A simple fix is to expose all target builtins unconditionally in LIPO
mode. Patch:


Index: config/i386/i386.c
===
--- config/i386/i386.c  (revision 201046)
+++ config/i386/i386.c  (working copy)
@@ -26957,7 +26957,8 @@ def_builtin (HOST_WIDE_INT mask, const char *name,
   ix86_builtins_isa[(int) code].isa = mask;

   mask &= ~OPTION_MASK_ISA_64BIT;
-  if (mask == 0
+  if (flag_dyn_ipa
+ || mask == 0
  || (mask & ix86_isa_flags) != 0
  || (lang_hooks.builtin_function
  == lang_hooks.builtin_function_ext_scope))


Is this ok?

Thanks
Sri

Re: [google][4.8] Expose all target specific builtins unconditionally for LIPO builds

[Xinliang David Li]

Can you collect some number on ggc_memory increase  with this change
in profile_gen build -- the value is recorded gcov_module_info object
in coverage.c.

thanks,

David

On Wed, Jul 24, 2013 at 3:14 PM, Sriraman Tallam  wrote:
> The following test-case fails in LIPO mode during profile-use build:
>
> main.cc
> 
> __attribute__((target("sse4.2")))
> unsigned int problem_aux (unsigned int A, unsigned int B);
>
>
> int main (int argc, char *argv[])
> {
>   return problem_aux (0, 0);
> }
>
> aux.cc
> -
> __attribute__((target("sse4.2")))
> unsigned int problem_aux (unsigned int A, unsigned int B)
> {
>   return __builtin_ia32_crc32qi (A, B);
> }
>
> $ g++ -O2 -fprofile-generate main.cc aux.cc
> $ ./a.out
> $ g++ -O2 -fprofile-use main.cc
> error: '__builtin_ia32_crc32qi' was not declared in this scope
>
> This happens when parsing the auxiliary module. __builtin_ia32_crc32qi
> is a target specific builtin that gets created after the target
> attribute is seen in the declaration of problem_aux in the primary
> module. This is too late for adding theisbuiltin to the list of
> knowns, the buitlins get saved when cp_save_built_in_decl_pre_parsing
> in cp/cp-objcp-common.c is called much earlier.  Hence, this builtin
> which is created during primary module parsing is not available when
> parsing the auxiliary module.
>
> A simple fix is to expose all target builtins unconditionally in LIPO
> mode. Patch:
>
>
> Index: config/i386/i386.c
> ===
> --- config/i386/i386.c  (revision 201046)
> +++ config/i386/i386.c  (working copy)
> @@ -26957,7 +26957,8 @@ def_builtin (HOST_WIDE_INT mask, const char *name,
>ix86_builtins_isa[(int) code].isa = mask;
>
>mask &= ~OPTION_MASK_ISA_64BIT;
> -  if (mask == 0
> +  if (flag_dyn_ipa
> + || mask == 0
>   || (mask & ix86_isa_flags) != 0
>   || (lang_hooks.builtin_function
>   == lang_hooks.builtin_function_ext_scope))
>
>
> Is this ok?
>
> Thanks
> Sri

[C++ Patch] PR 57880

[Paolo Carlini]

Hi,

submitter ran a static analysis tool on parser.c and found in the main 
switch of cp_parser_operator some broken cases having to do with user 
defined literals. When I looked into it I found a rather convoluted 
logic which tried to possibly emit *both* the error message for and 
invalid encoding prefix (as tested in udlit-enc-prefix-neg.C) and the 
error message for non-empty string after 'operator' (untested in the 
testsuite) before returning error_mark_node. Then when only the former 
was appropriate, it was emitted twice. The second missed cases - too big 
string_len.


Now, I don't think it should be so common that the user code has both 
issues in the same user defined literal (in that case providing both 
error messages at once would make debugging quicker), thus in the below 
I decided to simplify everything and immediately return error_mark_node 
after any error along the way.


Tested x86_64-linux.

Thanks,
Paolo.


/cp
2013-07-25  Paolo Carlini  

PR c++/57880
* parser.c (cp_parser_operator, case CPP_WSTRING, CPP_STRING16,
CPP_STRING32, CPP_UTF8STRING, CPP_WSTRING_USERDEF,
CPP_STRING16_USERDEF, CPP_STRING32_USERDEF, CPP_UTF8STRING_USERDEF):
Fix string_len management, tidy.

/testsuite
2013-07-25  Paolo Carlini  

PR c++/57880
* g++.dg/cpp1y/udlit-empty-string-neg.C: New.
Index: cp/parser.c
===
--- cp/parser.c (revision 201214)
+++ cp/parser.c (working copy)
@@ -12261,7 +12261,6 @@ cp_parser_operator (cp_parser* parser)
   tree id = NULL_TREE;
   cp_token *token;
   bool bad_encoding_prefix = false;
-  int string_len = 2;
 
   /* Peek at the next token.  */
   token = cp_lexer_peek_token (parser->lexer);
@@ -12462,20 +12461,22 @@ cp_parser_operator (cp_parser* parser)
   return ansi_opname (ARRAY_REF);
 
 case CPP_WSTRING:
-  string_len = 3;
 case CPP_STRING16:
 case CPP_STRING32:
-  string_len = 5;
 case CPP_UTF8STRING:
-  string_len = 4;
-  bad_encoding_prefix = true;
+ bad_encoding_prefix = true;
+  /* Fall through.  */
+
 case CPP_STRING:
   if (cxx_dialect == cxx98)
maybe_warn_cpp0x (CPP0X_USER_DEFINED_LITERALS);
   if (bad_encoding_prefix)
-   error ("invalid encoding prefix in literal operator");
-  if (TREE_STRING_LENGTH (token->u.value) > string_len)
{
+ error ("invalid encoding prefix in literal operator");
+ return error_mark_node;
+   }
+  if (TREE_STRING_LENGTH (token->u.value) > 2)
+   {
  error ("expected empty string after % keyword");
  return error_mark_node;
}
@@ -12505,21 +12506,23 @@ cp_parser_operator (cp_parser* parser)
}
 
 case CPP_WSTRING_USERDEF:
-  string_len = 3;
 case CPP_STRING16_USERDEF:
 case CPP_STRING32_USERDEF:
-  string_len = 5;
 case CPP_UTF8STRING_USERDEF:
-  string_len = 4;
   bad_encoding_prefix = true;
+  /* Fall through.  */
+
 case CPP_STRING_USERDEF:
   if (cxx_dialect == cxx98)
maybe_warn_cpp0x (CPP0X_USER_DEFINED_LITERALS);
   if (bad_encoding_prefix)
-   error ("invalid encoding prefix in literal operator");
+   {
+ error ("invalid encoding prefix in literal operator");
+ return error_mark_node;
+   }
   {
tree string_tree = USERDEF_LITERAL_VALUE (token->u.value);
-   if (TREE_STRING_LENGTH (string_tree) > string_len)
+   if (TREE_STRING_LENGTH (string_tree) > 2)
  {
error ("expected empty string after % keyword");
return error_mark_node;
Index: testsuite/g++.dg/cpp1y/udlit-empty-string-neg.C
===
--- testsuite/g++.dg/cpp1y/udlit-empty-string-neg.C (revision 0)
+++ testsuite/g++.dg/cpp1y/udlit-empty-string-neg.C (working copy)
@@ -0,0 +1,5 @@
+// { dg-options -std=c++1y }
+
+int
+operator "*"_s(unsigned long long) // { dg-error "expected empty string after 
'operator'" }
+{ return 0; }

libgo patch committed: Handle allocating memory in cgo/SWIG return

[Ian Lance Taylor]

When a function created by cgo or SWIG returns an interface type and at
runtime returns a value that requires allocation when converting to
interface, it will call the memory allocation routine while appearing to
be in a system call.  In particular there will be no memory cache
allocated.  This patch permits this case to work.  Bootstrapped and ran
Go testsuite on x86_64-unknown-linux-gnu.  Committed to mainline and 4.8
branch.

Ian

diff -r bc94be12533f libgo/runtime/malloc.goc
--- a/libgo/runtime/malloc.goc	Wed Jul 24 10:36:05 2013 -0700
+++ b/libgo/runtime/malloc.goc	Wed Jul 24 15:22:39 2013 -0700
@@ -41,11 +41,24 @@
 	uintptr npages;
 	MSpan *s;
 	void *v;
+	bool incallback;
 
 	m = runtime_m();
 	g = runtime_g();
-	if(g->status == Gsyscall)
-		dogc = 0;
+
+	incallback = false;
+	if(m->mcache == nil && g->ncgo > 0) {
+		// For gccgo this case can occur when a cgo or SWIG function
+		// has an interface return type and the function
+		// returns a non-pointer, so memory allocation occurs
+		// after syscall.Cgocall but before syscall.CgocallDone.
+		// We treat it as a callback.
+		runtime_exitsyscall();
+		m = runtime_m();
+		incallback = true;
+		dogc = false;
+	}
+
 	if(runtime_gcwaiting && g != m->g0 && m->locks == 0 && dogc) {
 		runtime_gosched();
 		m = runtime_m();
@@ -129,6 +142,10 @@
 		runtime_racemalloc(v, size, m->racepc);
 		m->racepc = nil;
 	}
+
+	if(incallback)
+		runtime_entersyscall();
+
 	return v;
 }
 

Merge from gcc 4.8 branch to gccgo branch

[Ian Lance Taylor]

I merged gcc 4.8 branch revision 201227 to the gccgo branch.

Ian

Re: [PATCH 1/2] Introduce context class

[Diego Novillo]

On Wed, Jul 24, 2013 at 11:09 AM, David Malcolm  wrote:
> gcc/
>
> Introduce context class.
>
> * Makefile.in (CONTEXT_H): New.
> (OBJS): Add context.o.
> (toplev.o): Add CONTEXT_H to dependencies.
> (context.o): New.
>
> * toplev.c (general_init): Create the singleton gcc::context
> instance.
>
> * context.c: New.
>
> * context.h: New.

OK.


Diego.

Re: [PATCH 2/2] Introduce beginnings of a pipeline class.

[Diego Novillo]

Could you please add a description of what this does?

On Wed, Jul 24, 2013 at 11:09 AM, David Malcolm  wrote:
> gcc/
> * Makefile.in (PIPELINE_H): New.
> (lto-cgraph.o): Depend on CONTEXT_H and PIPELINE_H.
> (passes.o): Likewise.
> (statistics.o): Likewise.
> (cgraphunit.o): Likewise.
> (context.o): Depend on PIPELINE_H.
>
> * pipeline.h: New.
>
> * cgraphunit.c (cgraph_add_new_function): Update for moves
> of globals to fields of pipeline.
> (analyze_function): Likewise.
> (expand_function): Likewise.
> (ipa_passes): Likewise.
> (compile): Likewise.
>
> * context.c (context::context): New.
> * context.h  (context::context): New.
> (context::get_passes): New.
> (context::passes_): New.
>
> * lto-cgraph.c (input_node): Update for moves of globals to
> fields of pipeline.
>
> * passes.c (all_passes): Remove, in favor of a field of the
> same name within the new class pipeline.
> (all_small_ipa_passes): Likewise.
> (all_lowering_passes): Likewise.
> (all_regular_ipa_passes): Likewise.
> (all_late_ipa_passes): Likewise.
> (all_lto_gen_passes): Likewise.
> (passes_by_id): Likewise.
> (passes_by_id_size): Likewise.
> (gcc_pass_lists): Remove, in favor of "pass_lists" field within
> the new class pipeline.
> (set_pass_for_id): Convert to...
> (pipeline::set_pass_for_id): ...method.
> (get_pass_for_id): Convert to...
> (pipeline::get_pass_for_id): ...method.
> (register_one_dump_file): Move body of implementation into...
> (pipeline::register_one_dump_file): ...here.
> (register_dump_files_1): Convert to...
> (pipeline::register_dump_files_1): ...method.
> (register_dump_files): Convert to...
> (pipeline::register_dump_files): ...method.
> (create_pass_tab): Update for moves of globals to fields of
> pipeline.
> (dump_passes): Move body of implementation into...
> (pipeline::dump_passes): ...here.
> (register_pass): Move body of implementation into...
> (pipeline::register_pass): ...here.
> (init_optimization_passes): Convert into...
> (pipeline::pipeline): ...constructor for new pipeline class, and
> initialize the pass_lists array.
> (check_profile_consistency): Update for moves of globals to
> fields of pipeline.
> (dump_profile_report): Move body of implementation into...
> (pipeline::dump_profile_report): ...here.
> (ipa_write_summaries_1): Update for moves of pass lists from
> being globals to fields of pipeline.
> (ipa_write_optimization_summaries): Likewise.
> (ipa_read_summaries):  Likewise.
> (ipa_read_optimization_summaries): Likewise.
> (execute_all_ipa_stmt_fixups): Likewise.
>
> * statistics.c (statistics_fini): Update for moves of globals to
> fields of pipeline.
>
> * toplev.c (general_init): Replace call to
> init_optimization_passes with construction of the pipeline
> instance.
>
> * tree-pass.h (all_passes): Remove, in favor of a field of the
> same name within the new class pipeline.
> (all_small_ipa_passes): Likewise.
> (all_lowering_passes): Likewise.
> (all_regular_ipa_passes): Likewise.
> (all_lto_gen_passes): Likewise.
> (all_late_ipa_passes): Likewise.
> (passes_by_id): Likewise.
> (passes_by_id_size): Likewise.
> (gcc_pass_lists): Remove, in favor of "pass_lists" field within
> the new class pipeline.
> (get_pass_for_id): Remove.
>
> gcc/lto/
>
> * Make-lang.in (lto/lto.o:): Depend on CONTEXT_H and
> PIPELINE_H.
>
> * lto.c (do_whole_program_analysis): Update for move of
> all_regular_ipa_passes from a global to a field of class
> pipeline.
> ---
>  gcc/Makefile.in  | 15 +---
>  gcc/cgraphunit.c | 22 +++-
>  gcc/context.c|  6 
>  gcc/context.h| 11 +-
>  gcc/lto-cgraph.c |  7 ++--
>  gcc/lto/Make-lang.in |  3 +-
>  gcc/lto/lto.c|  4 ++-
>  gcc/passes.c | 97 
> +++-
>  gcc/pipeline.h   | 89 +++
>  gcc/statistics.c |  7 ++--
>  gcc/toplev.c |  4 +--
>  gcc/tree-pass.h  | 29 
>  12 files changed, 212 insertions(+), 82 deletions(-)
>  create mode 100644 gcc/pipeline.h
>
> diff --git a/gcc/Makefile.in b/gcc/Makefile.in
> index fb0cb4b..0b28c2d 100644
> --- a/gcc/Makefile.in
> +++ b/gcc/Makefile.in
> @@ -987,6 +987,7 @@ PLUGIN_VERSION_H = plugin-version.h configargs.h
>  LIBFUNCS_H = libfuncs.h $(HASHTAB_H)
>  GRAPHITE_HTAB_H = graphite-htab.h graphite-clast-to-gimple.h

Re: [PATCH, i386, MPX 1/X] Support of Intel MPX ISA

[Joseph S. Myers]

On Wed, 24 Jul 2013, Ilya Enkovich wrote:

> Well, this patch does not introduce any changes on user-visible level.
> It just adds MPX instructions support to i386 target. Usually each new
> x86 instruction has corresponding builtin function and therefore is
> provided with a testcase. But MPX instructions do not have builtin
> function for direct generation and therefore there are no tests for
> this patch.

Usually also new instructions have a -m option to enable them, but you 
don't have that here either.  I realise the instructions are NOPs on 
processors not supporting them (all processors not supporting them?), but 
given that the availability of the instructions must at some point affect 
either the semantics of RTL containing checks, or what RTL the compiler 
can generate code for, I'd think you should have such an option anyway.

> I have subsequent patches to add user-visible features based on MPX.
> Sorry for missing series indicator (fixed). High-level feature based
> on MPX is described on GCC Wiki
> (http://gcc.gnu.org/wiki/Intel%20MPX%20support%20in%20the%20GCC%20compiler).

Thanks.  You also need to post the implementation design in terms of 
semantics of machine-independent tree/GIMPLE/RTL additions (which of 
course should be added to the relevant .texi files).

Having options starting -fmpx seems odd.  If something is 
machine-independent, as using -f options implies, then the options should 
have a machine-independent name rather than being named after one 
particular implementation.  Given we already have a -fbounds-check option 
(documented as supported for Java and Fortran only), that seems an obvious 
possibility for naming.  If for some reason it's a bad idea to use that 
option, at least the option names should make clear the similarities and 
differences from that option.  More generally, the patch series submission 
should include a comparison with other bounds-checking features in GCC 
such as -fmudflap and -fsanitize=address (and the user documentation 
should enable users to understand the advantages and disadvantages of 
each, so they can choose which is the best match to their requirements).  
I'm far from clear at present about why so many different approaches are 
needed, at the user-interface level, and whether there is anything in 
common between them that could usefully be shared within the 
implementations in GCC.

As I understand it, the feature logically splits into:

* Support the bounds checking within functions but with bounds being lost 
for function arguments and return values.  This does not need any 
architecture-specific support, although it would be slow without such 
support.

* Bounds checking across ABI boundaries.  This requires the architecture 
support (although one could also imagine such a feature defined in a way 
not needing new registers / instructions - again, slow).  So, if the user 
requests this and doesn't use -mmpx to enable the instructions, an error 
would seem appropriate.

Maybe the first is of too little value without the hardware support (e.g. 
too slow), and so the two only make sense together - I don't know.  But in 
any case it needs to be clear what the machine-independent semantics of 
each option are, and what does or does not depend in hardware support.  Do 
you do anything to disable optimizations that are based on making 
deductions from assuming that a pointer is valid?

Naming new built-in functions __bnd_* seems unfortunate.  We already have 
__builtin_*, __sync_* and __atomic_* as built-in function naming 
conventions (with consequent checks in various places based on function 
name) - do we really need yet another such prefix?

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

Re: [PATCH 2/2] Introduce beginnings of a pipeline class.

[Diego Novillo]

On Wed, Jul 24, 2013 at 6:56 PM, Diego Novillo  wrote:
> Could you please add a description of what this does?

Sorry.  You did, but in a previous message that I had managed to miss.
 Maybe include a reference to it in future postings?

Diego.

Re: [PATCH 1/2] Introduce context class

[David Malcolm]

On Wed, 2013-07-24 at 18:55 -0400, Diego Novillo wrote:
> On Wed, Jul 24, 2013 at 11:09 AM, David Malcolm  wrote:
> > gcc/
> >
> > Introduce context class.
> >
> > * Makefile.in (CONTEXT_H): New.
> > (OBJS): Add context.o.
> > (toplev.o): Add CONTEXT_H to dependencies.
> > (context.o): New.
> >
> > * toplev.c (general_init): Create the singleton gcc::context
> > instance.
> >
> > * context.c: New.
> >
> > * context.h: New.
> 
> OK.

Thanks.

I doublechecked the bootstrap of *just* this patch (rather than the
combination of *both* patches) on x86_64-unknown-linux-gnu and it worked
OK, so I've committed this to svn trunk as r201230.

Re: [PATCH 2/2] Introduce beginnings of a pipeline class.

[David Malcolm]

On Wed, 2013-07-24 at 19:10 -0400, Diego Novillo wrote:
> On Wed, Jul 24, 2013 at 6:56 PM, Diego Novillo  wrote:
> > Could you please add a description of what this does?
> 
> Sorry.  You did, but in a previous message that I had managed to miss.
>  Maybe include a reference to it in future postings?

FWIW I used "git format-patch" with the --cover-letter option and then
put the bulk of the description in the cover letter i.e. the [PATCH 0/2]
email i.e. http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01088.html - is
that what you're referring to, or to some other email (e.g. the
discussion about passes.def in the other thread, which is:
http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01028.html )

Is the cover letter and patch series approach OK for this list?

Also, and sorry if I'm being slow here, but are you still looking for
more descriptive text within the ChangeLog header, within the body of
the code, or in the email?

Thanks
Dave

Re: [Patch, PR 57800] Waste work in gfc_match_call()

[pchang9]

> On 23 July 2013 23:32:27 pcha...@cs.wisc.edu wrote:
>> Hi,
>>
>> The problem appears in revision 201034 in version 4.9. I attached a
>> one-line patch that fixes it.  I also reported this problem
>> at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57800
>>
>> Bootstrap and regression-tested on x86_64-linux.
>>
>> In method "gfc_match_call()" in gcc/fortran/match.c, the loop on line
>> 4189 should break immediately after "i" is set to 1.
>>
>>
>> 2013-07-22  Chang  
>>
>> * match.c (gfc_match_call): Exit loop after setting i.
>>
>>
>> Index: gcc/fortran/match.c
>> ===
>> --- gcc/fortran/match.c  (revision 201034)
>> +++ gcc/fortran/match.c  (working copy)
>> @@ -4188,7 +4188,10 @@
>>i = 0;
>>for (a = arglist; a; a = a->next)
> for (a = arglist; a || i; a = a->next)
>
> Sounds more reasonable to me.
>
> To repeat the previous question, curious how you get at these? scev one-liner?
>
> Thanks,

We found these by analysis tool using LLVM, but not so-fancy as scev one-linear.
Of course, at very beginning we inspected the code manually.

Thanks,
-Chang

Re: [C++ Patch] PR 57880

[Jason Merrill]

You need to have tests for the other string prefixes, since you're 
changing the code for them.


Jason

Re: [C++ Patch] PR 57880

[Paolo Carlini]

On 07/25/2013 03:35 AM, Jason Merrill wrote:
You need to have tests for the other string prefixes, since you're 
changing the code for them.

Oh yes, something like this?

(believe me, I had it, but then the last minute I simplified the 
testcase because the last lines didn't seem to exercise any additional 
code path in the new code. But I agree it may be useful if we do change 
the code)


Thanks,
Paolo.

//
Index: cp/parser.c
===
--- cp/parser.c (revision 201233)
+++ cp/parser.c (working copy)
@@ -12261,7 +12261,6 @@ cp_parser_operator (cp_parser* parser)
   tree id = NULL_TREE;
   cp_token *token;
   bool bad_encoding_prefix = false;
-  int string_len = 2;
 
   /* Peek at the next token.  */
   token = cp_lexer_peek_token (parser->lexer);
@@ -12462,20 +12461,22 @@ cp_parser_operator (cp_parser* parser)
   return ansi_opname (ARRAY_REF);
 
 case CPP_WSTRING:
-  string_len = 3;
 case CPP_STRING16:
 case CPP_STRING32:
-  string_len = 5;
 case CPP_UTF8STRING:
-  string_len = 4;
-  bad_encoding_prefix = true;
+ bad_encoding_prefix = true;
+  /* Fall through.  */
+
 case CPP_STRING:
   if (cxx_dialect == cxx98)
maybe_warn_cpp0x (CPP0X_USER_DEFINED_LITERALS);
   if (bad_encoding_prefix)
-   error ("invalid encoding prefix in literal operator");
-  if (TREE_STRING_LENGTH (token->u.value) > string_len)
{
+ error ("invalid encoding prefix in literal operator");
+ return error_mark_node;
+   }
+  if (TREE_STRING_LENGTH (token->u.value) > 2)
+   {
  error ("expected empty string after % keyword");
  return error_mark_node;
}
@@ -12505,21 +12506,23 @@ cp_parser_operator (cp_parser* parser)
}
 
 case CPP_WSTRING_USERDEF:
-  string_len = 3;
 case CPP_STRING16_USERDEF:
 case CPP_STRING32_USERDEF:
-  string_len = 5;
 case CPP_UTF8STRING_USERDEF:
-  string_len = 4;
   bad_encoding_prefix = true;
+  /* Fall through.  */
+
 case CPP_STRING_USERDEF:
   if (cxx_dialect == cxx98)
maybe_warn_cpp0x (CPP0X_USER_DEFINED_LITERALS);
   if (bad_encoding_prefix)
-   error ("invalid encoding prefix in literal operator");
+   {
+ error ("invalid encoding prefix in literal operator");
+ return error_mark_node;
+   }
   {
tree string_tree = USERDEF_LITERAL_VALUE (token->u.value);
-   if (TREE_STRING_LENGTH (string_tree) > string_len)
+   if (TREE_STRING_LENGTH (string_tree) > 2)
  {
error ("expected empty string after % keyword");
return error_mark_node;
Index: testsuite/g++.dg/cpp1y/udlit-empty-string-neg.C
===
--- testsuite/g++.dg/cpp1y/udlit-empty-string-neg.C (revision 0)
+++ testsuite/g++.dg/cpp1y/udlit-empty-string-neg.C (working copy)
@@ -0,0 +1,21 @@
+// { dg-options -std=c++1y }
+
+int
+operator "*"_s(unsigned long long) // { dg-error "expected empty string after 
'operator'" }
+{ return 0; }
+
+int
+operator L"*"_Ls(unsigned long long) // { dg-error "invalid encoding prefix in 
literal operator" }
+{ return 0; }
+
+int
+operator u"*"_s16(unsigned long long) // { dg-error "invalid encoding prefix 
in literal operator" }
+{ return 0; }
+
+int
+operator U"*"_s32(unsigned long long) // { dg-error "invalid encoding prefix 
in literal operator" }
+{ return 0; }
+
+int
+operator u8"*"_u8s(unsigned long long) // { dg-error "invalid encoding prefix 
in literal operator" }
+{ return 0; }