Re: Clear basic block flags before using BB_VISITED for OpenACC loops processing

[Richard Biener]

On Tue, Oct 18, 2016 at 9:52 PM, Thomas Schwinge
 wrote:
> Hi!
>
> On Mon, 17 Oct 2016 15:38:50 +0200, I wrote:
>> On Mon, 17 Oct 2016 14:08:44 +0200, Richard Biener 
>>  wrote:
>> > On Mon, Oct 17, 2016 at 1:47 PM, Thomas Schwinge
>> >  wrote:
>> > > On Mon, 17 Oct 2016 13:22:17 +0200, Richard Biener 
>> > >  wrote:
>> > >> On Mon, Oct 17, 2016 at 11:38 AM, Thomas Schwinge
>> > >>  wrote:
>> > >> > On Fri, 14 Oct 2016 13:06:59 +0200, Richard Biener 
>> > >> >  wrote:
>> > >> >> On Fri, Oct 14, 2016 at 1:00 PM, Nathan Sidwell  
>> > >> >> wrote:
>> > >> >> > On 10/14/16 05:28, Richard Biener wrote:
>> > >> >> >
>> > >> >> >> The BB_VISITED flag has indetermined state at the beginning of a 
>> > >> >> >> pass.
>> > >> >> >> You have to ensure it is cleared yourself.
>> > >> >> >
>> > >> >> >
>> > >> >> > In that case the openacc (&nvptx?) passes should be modified to 
>> > >> >> > clear the
>> > >> >> > flags at their start, rather than at their end.
>
> This already is a "conceptual acknowledgement" of my patch, so...
>
>> > >> > OK to commit the following?  Is such a test case appropriate (which 
>> > >> > would
>> > >> > have caught this issue right away), in particular the dg-final
>> > >> > scan-tree-dump line?
>> > >>
>> > >> Ugh.  Not worse to what we do in various dwarf scanning I guess.
>> > >
>> > > ;-|
>> > >
>> > >> Doesn't failure lead to a miscompile eventually?  So you could formulate
>> > >> this as a dg-do run test with a check for the desired outcome?
>> > >
>> > > No, unfortunately.  In this case the error is "benign" such that the
>> > > OpenACC loop processing machinery will decide to not parallelize loops
>> > > that ought to be parallelized.
>> >
>> > So you can scan for "loop parallelized" instead?
>>
>> The dump would still contain the outer loop's "Loop 0(0)" marker, so I'd
>> have to scan for "Head"/"Tail"/"UNIQUE" or similar instead -- but that
>> seems likewise fragile (for false negatives), and less useful than
>> scanning for the complete pattern.
>>
>> > I fear your pattern
>> > is quite fragile
>> > to maintain over time.
>>
>> Agreed -- but then, that's intentional: my idea for this new test case
>> has been to have it actually verify the expected OpenACC loop processing,
>> so it's clear that this pattern will need to be adjusted if changing the
>> OpenACC loop processing.
>>
>> > >  This won't generally cause any problem
>> > > (apart from performance regression, obviously); it just caused problems
>> > > in a few libgomp test cases that actually at run time test for
>> > > parallelized execution -- which will/did trigger only with nvptx
>> > > offloading enabled, which not too many people are testing.  The test case
>> > > I propose below will trigger also for non-offloading configurations.
>>
>> On IRC, Segher suggested to 'use {} instead of "" to avoid [all those
>> backslashes]' -- thanks, done.
>
> If you don't like the test case as-is (do we need multi-line tree dump
> scanning, just like we recently got for compiler diagnostics?), can I at
> least commit the OpenACC loops processing fix?  Here is the latest
> version, simplified after your r241296 IRA vs. BB_VISITED fixes:

Sure, I considered that approved already (it's even obvious).

Richard.

> commit 766cf9959b15a17e17e89a50e905b4c546893823
> Author: Thomas Schwinge 
> Date:   Mon Oct 17 15:33:09 2016 +0200
>
> Clear basic block flags before using BB_VISITED for OpenACC loops 
> processing
>
> gcc/
> * omp-low.c (oacc_loop_discovery): Call clear_bb_flags before, and
> don't clear BB_VISITED after processing.
>
> gcc/testsuite/
> * gcc.dg/goacc/loop-processing-1.c: New file.
> ---
>  gcc/omp-low.c  |  8 +++-
>  gcc/testsuite/gcc.dg/goacc/loop-processing-1.c | 18 ++
>  2 files changed, 21 insertions(+), 5 deletions(-)
>
> diff --git gcc/omp-low.c gcc/omp-low.c
> index 77f89d5..3ef796f 100644
> --- gcc/omp-low.c
> +++ gcc/omp-low.c
> @@ -19236,7 +19236,9 @@ oacc_loop_sibling_nreverse (oacc_loop *loop)
>  static oacc_loop *
>  oacc_loop_discovery ()
>  {
> -  basic_block bb;
> +  /* Clear basic block flags, in particular BB_VISITED which we're going to 
> use
> + in the following.  */
> +  clear_bb_flags ();
>
>oacc_loop *top = new_oacc_loop_outer (current_function_decl);
>oacc_loop_discover_walk (top, ENTRY_BLOCK_PTR_FOR_FN (cfun));
> @@ -19245,10 +19247,6 @@ oacc_loop_discovery ()
>   that diagnostics come out in an unsurprising order.  */
>top = oacc_loop_sibling_nreverse (top);
>
> -  /* Reset the visited flags.  */
> -  FOR_ALL_BB_FN (bb, cfun)
> -bb->flags &= ~BB_VISITED;
> -
>return top;
>  }
>
> diff --git gcc/testsuite/gcc.dg/goacc/loop-processing-1.c 
> gcc/testsuite/gcc.dg/goacc/loop-processing-1.c
> new file mode 100644
> index 000..619576a
> --- /dev/null
> +++ gcc/testsuite/gcc.dg/goacc/loop-processing-1.c
> @@ -0,0 +1,18 @@
> +/* Make sure that OpenACC loop processing happen

[PR tree-optimization/78024] Clear basic block flags before using BB_VISITED for OpenACC loops processing

[Thomas Schwinge]

Hi!

On Wed, 19 Oct 2016 12:07:13 +0200, Richard Biener  
wrote:
> On Tue, Oct 18, 2016 at 9:52 PM, Thomas Schwinge
>  wrote:
> > can I at
> > least commit the OpenACC loops processing fix?  Here is the latest
> > version, simplified after your r241296 IRA vs. BB_VISITED fixes:
> 
> Sure, I considered that approved already

I don't see such an approval anywhere?

> (it's even obvious).

I've been told to be very careful in GCC with declaring something
"obvious".  (Though, I will be happy to increase my autonomy in declaring
patches "obvious"/"ready for commit".  This will potentially save me from
wasting hours when keeping patches up-to-date, while repeatedly begging
for review, and so on.)

Anyway, without changes now committed in r241334:

commit b3e3b38b4b1ac65df70d98f7e7557a27947948c1
Author: tschwinge 
Date:   Wed Oct 19 10:19:24 2016 +

[PR tree-optimization/78024] Clear basic block flags before using 
BB_VISITED for OpenACC loops processing

gcc/
* omp-low.c (oacc_loop_discovery): Call clear_bb_flags before, and
don't clear BB_VISITED after processing.

gcc/testsuite/
* gcc.dg/goacc/loop-processing-1.c: New file.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@241334 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/ChangeLog  |  6 ++
 gcc/omp-low.c  |  8 +++-
 gcc/testsuite/ChangeLog|  5 +
 gcc/testsuite/gcc.dg/goacc/loop-processing-1.c | 18 ++
 4 files changed, 32 insertions(+), 5 deletions(-)

diff --git gcc/ChangeLog gcc/ChangeLog
index d5830d5..4117eb3 100644
--- gcc/ChangeLog
+++ gcc/ChangeLog
@@ -1,3 +1,9 @@
+2016-10-19  Thomas Schwinge  
+
+   PR tree-optimization/78024
+   * omp-low.c (oacc_loop_discovery): Call clear_bb_flags before, and
+   don't clear BB_VISITED after processing.
+
 2016-10-19  Richard Biener  
 
* domwalk.c (dom_walker::walk): Use RPO order.
diff --git gcc/omp-low.c gcc/omp-low.c
index 77f89d5..3ef796f 100644
--- gcc/omp-low.c
+++ gcc/omp-low.c
@@ -19236,7 +19236,9 @@ oacc_loop_sibling_nreverse (oacc_loop *loop)
 static oacc_loop *
 oacc_loop_discovery ()
 {
-  basic_block bb;
+  /* Clear basic block flags, in particular BB_VISITED which we're going to use
+ in the following.  */
+  clear_bb_flags ();
   
   oacc_loop *top = new_oacc_loop_outer (current_function_decl);
   oacc_loop_discover_walk (top, ENTRY_BLOCK_PTR_FOR_FN (cfun));
@@ -19245,10 +19247,6 @@ oacc_loop_discovery ()
  that diagnostics come out in an unsurprising order.  */
   top = oacc_loop_sibling_nreverse (top);
 
-  /* Reset the visited flags.  */
-  FOR_ALL_BB_FN (bb, cfun)
-bb->flags &= ~BB_VISITED;
-
   return top;
 }
 
diff --git gcc/testsuite/ChangeLog gcc/testsuite/ChangeLog
index df73022..ec875aa 100644
--- gcc/testsuite/ChangeLog
+++ gcc/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2016-10-19  Thomas Schwinge  
+
+   PR tree-optimization/78024
+   * gcc.dg/goacc/loop-processing-1.c: New file.
+
 2016-10-19  Richard Biener  
 
* gcc.dg/tree-ssa/pr61839_2.c: Fix testcase.
diff --git gcc/testsuite/gcc.dg/goacc/loop-processing-1.c 
gcc/testsuite/gcc.dg/goacc/loop-processing-1.c
new file mode 100644
index 000..619576a
--- /dev/null
+++ gcc/testsuite/gcc.dg/goacc/loop-processing-1.c
@@ -0,0 +1,18 @@
+/* Make sure that OpenACC loop processing happens.  */
+/* { dg-additional-options "-O2 -fdump-tree-oaccdevlow" } */
+
+extern int place ();
+
+void vector_1 (int *ary, int size)
+{
+#pragma acc parallel num_workers (32) vector_length(32) copy(ary[0:size]) 
firstprivate (size)
+  {
+#pragma acc loop gang
+for (int jx = 0; jx < 1; jx++)
+#pragma acc loop auto
+  for (int ix = 0; ix < size; ix++)
+   ary[ix] = place ();
+  }
+}
+
+/* { dg-final { scan-tree-dump {OpenACC loops.*Loop 0\(0\).*Loop 
14\(1\).*\.data_dep\.[0-9_]+ = UNIQUE \(OACC_HEAD_MARK, 0, 1, 
20\);.*Head-0:.*\.data_dep\.[0-9_]+ = UNIQUE \(OACC_HEAD_MARK, 0, 1, 
20\);.*\.data_dep\.[0-9_]+ = UNIQUE \(OACC_FORK, \.data_dep\.[0-9_]+, 
0\);.*Tail-0:.*\.data_dep\.[0-9_]+ = UNIQUE \(OACC_TAIL_MARK, 
\.data_dep\.[0-9_]+, 1\);.*\.data_dep\.[0-9_]+ = UNIQUE \(OACC_JOIN, 
\.data_dep\.[0-9_]+, 0\);.*Loop 6\(4\).*\.data_dep\.[0-9_]+ = UNIQUE 
\(OACC_HEAD_MARK, 0, 1, 6\);.*Head-0:.*\.data_dep\.[0-9_]+ = UNIQUE 
\(OACC_HEAD_MARK, 0, 1, 6\);.*\.data_dep\.[0-9_]+ = UNIQUE \(OACC_FORK, 
\.data_dep\.[0-9_]+, 2\);.*Tail-0:.*\.data_dep\.[0-9_]+ = UNIQUE 
\(OACC_TAIL_MARK, \.data_dep\.[0-9_]+, 1\);.*\.data_dep\.[0-9_]+ = UNIQUE 
\(OACC_JOIN, \.data_dep\.[0-9_]+, 2\);} "oaccdevlow" } } */


Grüße
 Thomas

Re: [PR lto/77458] Avoid ICE in offloading with differing _FloatN, _FloatNx types

[Thomas Schwinge]

Hi!

On Mon, 17 Oct 2016 17:59:16 +0200, I wrote:
> On Thu, 29 Sep 2016 15:18:00 +0200, Thomas Schwinge  
> wrote:
> > On Mon, 19 Sep 2016 13:25:01 +0200, Richard Biener 
> >  wrote:
> > > On Mon, Sep 19, 2016 at 1:19 PM, Thomas Schwinge
> > >  wrote:
> > > > On Mon, 19 Sep 2016 10:18:35 +0200, Richard Biener 
> > > >  wrote:
> > > >> On Fri, Sep 16, 2016 at 3:32 PM, Thomas Schwinge
> > > >>  wrote:
> > > >> > --- gcc/tree-streamer.c
> > > >> > +++ gcc/tree-streamer.c
> > > >> > @@ -278,9 +278,23 @@ record_common_node (struct 
> > > >> > streamer_tree_cache_d *cache, tree node)
> > > >> >streamer_tree_cache_append (cache, node, cache->nodes.length ());
> > > >> >
> > > >> >if (POINTER_TYPE_P (node)
> > > >> > -  || TREE_CODE (node) == COMPLEX_TYPE
> > > >> >|| TREE_CODE (node) == ARRAY_TYPE)
> > > >> >  record_common_node (cache, TREE_TYPE (node));
> > > >> > +  else if (TREE_CODE (node) == COMPLEX_TYPE)
> > > >> > +{
> > > >> > +  /* Assert that complex types' component types have already 
> > > >> > been handled
> > > >> > +(and we thus don't need to recurse here).  See PR 
> > > >> > lto/77458.  */
> > > >> > +[...]
> > 
> > > >> So I very much like to go forward with this kind of change as well
> > 
> > > > [patch]
> > 
> > > Ok with [changes]
> > 
> > Like this?  (I'll then continue to replicate this for other tree codes.)

> --- gcc/tree-streamer.c
> +++ gcc/tree-streamer.c

> +/* Verify that NODE is in CACHE.  */
> +
> +static void
> +verify_common_node_recorded (struct streamer_tree_cache_d *cache, tree node)
> +{
> +  /* Restrict this to flag_checking only because in general violating it is
> + harmless plus we never know what happens on all targets/frontend/flag(!)
> + combinations.  */
> +  if (!flag_checking)
> +return;
> +
> +  bool found = false;
> +  if (cache->node_map)
> +gcc_assert (streamer_tree_cache_lookup (cache, node, NULL));
> +  else
> +{
> +  gcc_assert (cache->nodes.exists ());
> +  /* Linear search...  */
> +  for (unsigned i = 0; !found && i < cache->nodes.length (); ++i)
> + if (cache->nodes[i] == node)
> +   found = true;
> +  gcc_assert (found);
> +}
> +}

With the "bool found" definition moved into the else branch, committed to
trunk in r241338:

commit 2ba42fa30f9ea5bb8ade209d7ff40229fd574856
Author: tschwinge 
Date:   Wed Oct 19 10:48:46 2016 +

[PR lto/77458] Avoid ICE in offloading with differing _FloatN, _FloatNx 
types

gcc/
PR lto/77458
* tree-core.h (enum tree_index): Put the complex types after their
component types.
* tree-streamer.c (verify_common_node_recorded): New function.
(preload_common_nodes) : Use it.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@241338 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/ChangeLog   |  8 
 gcc/tree-core.h | 31 +--
 gcc/tree-streamer.c | 32 +++-
 3 files changed, 56 insertions(+), 15 deletions(-)

diff --git gcc/ChangeLog gcc/ChangeLog
index 59b00d16..b50e2e4 100644
--- gcc/ChangeLog
+++ gcc/ChangeLog
@@ -1,3 +1,11 @@
+2016-10-19  Thomas Schwinge  
+
+   PR lto/77458
+   * tree-core.h (enum tree_index): Put the complex types after their
+   component types.
+   * tree-streamer.c (verify_common_node_recorded): New function.
+   (preload_common_nodes) : Use it.
+
 2016-10-19  Martin Liska  
 
* cgraph.h (cgraph_edge::binds_to_current_def_p):
diff --git gcc/tree-core.h gcc/tree-core.h
index 1bfe682..3e3f31e 100644
--- gcc/tree-core.h
+++ gcc/tree-core.h
@@ -556,20 +556,6 @@ enum tree_index {
   TI_BOOLEAN_FALSE,
   TI_BOOLEAN_TRUE,
 
-  TI_COMPLEX_INTEGER_TYPE,
-  TI_COMPLEX_FLOAT_TYPE,
-  TI_COMPLEX_DOUBLE_TYPE,
-  TI_COMPLEX_LONG_DOUBLE_TYPE,
-
-  TI_COMPLEX_FLOAT16_TYPE,
-  TI_COMPLEX_FLOATN_NX_TYPE_FIRST = TI_COMPLEX_FLOAT16_TYPE,
-  TI_COMPLEX_FLOAT32_TYPE,
-  TI_COMPLEX_FLOAT64_TYPE,
-  TI_COMPLEX_FLOAT128_TYPE,
-  TI_COMPLEX_FLOAT32X_TYPE,
-  TI_COMPLEX_FLOAT64X_TYPE,
-  TI_COMPLEX_FLOAT128X_TYPE,
-
   TI_FLOAT_TYPE,
   TI_DOUBLE_TYPE,
   TI_LONG_DOUBLE_TYPE,
@@ -599,6 +585,23 @@ enum tree_index {
 - TI_FLOATN_NX_TYPE_FIRST  \
 + 1)
 
+  /* Put the complex types after their component types, so that in (sequential)
+ tree streaming we can assert that their component types have already been
+ handled (see tree-streamer.c:record_common_node).  */
+  TI_COMPLEX_INTEGER_TYPE,
+  TI_COMPLEX_FLOAT_TYPE,
+  TI_COMPLEX_DOUBLE_TYPE,
+  TI_COMPLEX_LONG_DOUBLE_TYPE,
+
+  TI_COMPLEX_FLOAT16_TYPE,
+  TI_COMPLEX_FLOATN_NX_TYPE_FIRST = TI_COMPLEX_FLOAT16_TYPE,
+  TI_COMPLEX_FLOAT32_TYPE,
+  TI_COMPLEX_FLOAT64_TYPE,
+  TI_COMPLEX_FLOAT128_TYPE,
+  TI_COMPLEX_FLOAT32X_TYPE,
+  TI_COMPLEX_FLOAT64X_TYPE,
+  TI_COMPLEX_FLOAT128X_TYPE,
+
   TI_FLOAT_PTR_TYPE,
   TI_DOUBLE_PTR_TYPE,
   TI_LONG_DOUBLE_PTR_TYPE,
diff --git 

[BUILDROBOT] s390.md:10630:9: error: this statement may fall through [-Werror=implicit-fallthrough=]

[Jan-Benedict Glaw]

Hi!

I noticed that building for --target=s390-linux-gnu (via
config_list.mk) also hits the new fall-through checking code,
see build
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=643406:

[...]
g++ -fno-PIE -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE   
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing 
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual 
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror 
-fno-common  -DHAVE_CONFIG_H -I. -I. -I/home/jbglaw/repos-configlist_mk/gcc/gcc 
-I/home/jbglaw/repos-configlist_mk/gcc/gcc/. 
-I/home/jbglaw/repos-configlist_mk/gcc/gcc/../include 
-I/home/jbglaw/repos-configlist_mk/gcc/gcc/../libcpp/include 
-I/opt/cfarm/mpc/include  
-I/home/jbglaw/repos-configlist_mk/gcc/gcc/../libdecnumber 
-I/home/jbglaw/repos-configlist_mk/gcc/gcc/../libdecnumber/dpd 
-I../libdecnumber -I/home/jbglaw/repos-configlist_mk/gcc/gcc/../libbacktrace   
-o insn-output.o -MT insn-output.o -MMD -MP -MF ./.deps/insn-output.TPo 
insn-output.c
/home/jbglaw/repos-configlist_mk/gcc/gcc/config/s390/s390.md: In function 
‘const char* output_1786(rtx_def**, rtx_insn*)’:
/home/jbglaw/repos-configlist_mk/gcc/gcc/config/s390/s390.md:10630:9: error: 
this statement may fall through [-Werror=implicit-fallthrough=]
 if (larl_operand (operands[0], Pmode))
 ^~
/home/jbglaw/repos-configlist_mk/gcc/gcc/config/s390/s390.md:10632:7: note: here
   default:
   ^~~
cc1plus: all warnings being treated as errors
Makefile:1097: recipe for target 'insn-output.o' failed


MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of: 17:44 <@uschebit> Evangelist ist doch ein Vertriebler
the second  :   für unverkäufliche Produkte, oder? (#korsett, 20120821)


signature.asc
Description: Digital signature

Re: [BUILDROBOT] s390.md:10630:9: error: this statement may fall through [-Werror=implicit-fallthrough=]

[Jeff Law]

On 10/19/2016 10:26 AM, Jan-Benedict Glaw wrote:

Hi!

I noticed that building for --target=s390-linux-gnu (via
config_list.mk) also hits the new fall-through checking code,
see build
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=643406:

[...]
g++ -fno-PIE -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE   
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing 
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual 
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror 
-fno-common  -DHAVE_CONFIG_H -I. -I. -I/home/jbglaw/repos-configlist_mk/gcc/gcc 
-I/home/jbglaw/repos-configlist_mk/gcc/gcc/. 
-I/home/jbglaw/repos-configlist_mk/gcc/gcc/../include 
-I/home/jbglaw/repos-configlist_mk/gcc/gcc/../libcpp/include 
-I/opt/cfarm/mpc/include  
-I/home/jbglaw/repos-configlist_mk/gcc/gcc/../libdecnumber 
-I/home/jbglaw/repos-configlist_mk/gcc/gcc/../libdecnumber/dpd 
-I../libdecnumber -I/home/jbglaw/repos-configlist_mk/gcc/gcc/../libbacktrace   
-o insn-output.o -MT insn-output.o -MMD -MP -MF ./.deps/insn-output.TPo 
insn-output.c
/home/jbglaw/repos-configlist_mk/gcc/gcc/config/s390/s390.md: In function 
‘const char* output_1786(rtx_def**, rtx_insn*)’:
/home/jbglaw/repos-configlist_mk/gcc/gcc/config/s390/s390.md:10630:9: error: 
this statement may fall through [-Werror=implicit-fallthrough=]
 if (larl_operand (operands[0], Pmode))
 ^~
/home/jbglaw/repos-configlist_mk/gcc/gcc/config/s390/s390.md:10632:7: note: here
   default:
   ^~~
cc1plus: all warnings being treated as errors
Makefile:1097: recipe for target 'insn-output.o' failed
From reading the comments in that pattern, I think falling-through is 
safe and expected.  So just adding an appropriate fallthru comment 
should fix this.


jeff

[BUILDROBOT] ICE in altivec_init_builtins, at config/rs6000/rs6000.c:17547

[Jan-Benedict Glaw]

Hi!

Building current GCC with current GCC (using config_list.mk) for
--target=rs6000-ibm-aix5.3.0, I noticed a gcc_unreachable() during -fself-test,
see build
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=643401 :

[...]
/scratch/4/jbglaw/configlist/build/rs6000-ibm-aix5.3.0/build-gcc/mk/rs6000-ibm-aix5.3.0/./gcc/xgcc
 
-B/scratch/4/jbglaw/configlist/build/rs6000-ibm-aix5.3.0/build-gcc/mk/rs6000-ibm-aix5.3.0/./gcc/
 -nostdinc -x c /dev/null -S -fself-test
: internal compiler error: in altivec_init_builtins, at 
config/rs6000/rs6000.c:17547
0xe4357a altivec_init_builtins
/scratch/4/jbglaw/configlist/repos/gcc/gcc/config/rs6000/rs6000.c:17547
0xe4357a rs6000_init_builtins
/scratch/4/jbglaw/configlist/repos/gcc/gcc/config/rs6000/rs6000.c:16823
0x640a20 c_define_builtins
/scratch/4/jbglaw/configlist/repos/gcc/gcc/c-family/c-common.c:4027
0x640a20 c_common_nodes_and_builtins()
/scratch/4/jbglaw/configlist/repos/gcc/gcc/c-family/c-common.c:4495
0x593679 c_init_decl_processing()
/scratch/4/jbglaw/configlist/repos/gcc/gcc/c/c-decl.c:4097
0x5e17e8 c_objc_common_init()
/scratch/4/jbglaw/configlist/repos/gcc/gcc/c/c-objc-common.c:58
0x58306f lang_dependent_init
/scratch/4/jbglaw/configlist/repos/gcc/gcc/toplev.c:1775
0x58306f do_compile
/scratch/4/jbglaw/configlist/repos/gcc/gcc/toplev.c:1998
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[2]: *** [s-selftest] Error 1


MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of:   ...und wenn Du denkst, es geht nicht mehr,
the second  :  kommt irgendwo ein Lichtlein her.


signature.asc
Description: Digital signature

Re: [BUILDROBOT] ICE in altivec_init_builtins, at config/rs6000/rs6000.c:17547

[David Edelsohn]

Hi, JBG

Yes, this is a known problem with Kelvin's recent patch.

- David


On Wed, Oct 19, 2016 at 12:59 PM, Jan-Benedict Glaw  wrote:
> Hi!
>
> Building current GCC with current GCC (using config_list.mk) for
> --target=rs6000-ibm-aix5.3.0, I noticed a gcc_unreachable() during 
> -fself-test,
> see build
> http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=643401 :
>
> [...]
> /scratch/4/jbglaw/configlist/build/rs6000-ibm-aix5.3.0/build-gcc/mk/rs6000-ibm-aix5.3.0/./gcc/xgcc
>  
> -B/scratch/4/jbglaw/configlist/build/rs6000-ibm-aix5.3.0/build-gcc/mk/rs6000-ibm-aix5.3.0/./gcc/
>  -nostdinc -x c /dev/null -S -fself-test
> : internal compiler error: in altivec_init_builtins, at 
> config/rs6000/rs6000.c:17547
> 0xe4357a altivec_init_builtins
> /scratch/4/jbglaw/configlist/repos/gcc/gcc/config/rs6000/rs6000.c:17547
> 0xe4357a rs6000_init_builtins
> /scratch/4/jbglaw/configlist/repos/gcc/gcc/config/rs6000/rs6000.c:16823
> 0x640a20 c_define_builtins
> /scratch/4/jbglaw/configlist/repos/gcc/gcc/c-family/c-common.c:4027
> 0x640a20 c_common_nodes_and_builtins()
> /scratch/4/jbglaw/configlist/repos/gcc/gcc/c-family/c-common.c:4495
> 0x593679 c_init_decl_processing()
> /scratch/4/jbglaw/configlist/repos/gcc/gcc/c/c-decl.c:4097
> 0x5e17e8 c_objc_common_init()
> /scratch/4/jbglaw/configlist/repos/gcc/gcc/c/c-objc-common.c:58
> 0x58306f lang_dependent_init
> /scratch/4/jbglaw/configlist/repos/gcc/gcc/toplev.c:1775
> 0x58306f do_compile
> /scratch/4/jbglaw/configlist/repos/gcc/gcc/toplev.c:1998
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.
> make[2]: *** [s-selftest] Error 1
>
>
> MfG, JBG
>
> --
>   Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
> Signature of:   ...und wenn Du denkst, es geht nicht mehr,
> the second  :  kommt irgendwo ein Lichtlein her.

glibc test tst-thread_local1.cc fails to compile with latest GCC

[Ellcey, Steve]

I have built the latest glibc sources with a ToT GCC and am trying to run the 
glibc testsuite now.  I ran into a couple of
new warnings that I fixed (locally) and am now looking at 
nptl/tst-thread_local1.cc which dies with:

tst-thread_local1.cc:172:7: error: ‘thread’ is not a member of ‘std’
   std::thread thr{[func] {func (nullptr);}};

Does anyone know what is going on here?  If I compile a small test program:

#include 
int main(int, char **){
std::thread tt;
}

With G++ 5.4 (using -std=c++11) this test program compiles. but with ToT GCC, 
it dies with:

g++ -std=c++11 thread.cc -lpthread -o x
thread.cc: In function ‘int main(int, char**)’:
thread.cc:5:5: error: ‘thread’ is not a member of ‘std’
 std::thread tt;
 ^~~
thread.cc:5:5: note: suggested alternative: ‘fread’
 std::thread tt;
 ^~~
 fread


Is there some C++ standard change that I am not aware of or some other header 
file I need to include?

Steve Ellcey

Re: glibc test tst-thread_local1.cc fails to compile with latest GCC

[Andrew Pinski]

On Wed, Oct 19, 2016 at 10:45 AM, Ellcey, Steve  wrote:
> I have built the latest glibc sources with a ToT GCC and am trying to run the 
> glibc testsuite now.  I ran into a couple of
> new warnings that I fixed (locally) and am now looking at 
> nptl/tst-thread_local1.cc which dies with:
>
> tst-thread_local1.cc:172:7: error: ‘thread’ is not a member of ‘std’
>std::thread thr{[func] {func (nullptr);}};
>
> Does anyone know what is going on here?  If I compile a small test program:
>
> #include 
> int main(int, char **){
> std::thread tt;
> }
>
> With G++ 5.4 (using -std=c++11) this test program compiles. but with ToT GCC, 
> it dies with:
>
> g++ -std=c++11 thread.cc -lpthread -o x
> thread.cc: In function ‘int main(int, char**)’:
> thread.cc:5:5: error: ‘thread’ is not a member of ‘std’
>  std::thread tt;
>  ^~~
> thread.cc:5:5: note: suggested alternative: ‘fread’
>  std::thread tt;
>  ^~~
>  fread

I Just tested it with revision 241328 of GCC, it works ...

apinski@apinski-ss1:~/src/local4$ ./tools/bin/g++ t88.cc -std=c++11  -mabi=ilp32
apinski@apinski-ss1:~/src/local4$ ./a.out


Thanks,
Andrew

>
>
> Is there some C++ standard change that I am not aware of or some other header 
> file I need to include?
>
> Steve Ellcey