[Bug fortran/77903] gfortran 6.1.0/7.0.0 accept invalid code with conflicting module/submodule interfaces

[damian at sourceryinstitute dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77903

--- Comment #4 from Damian Rouson  ---
Check the date on your draft.   The latest draft is dated 31 August 2016. 
C1556 appears on page 330. Does the following link work for you?

http://j3-fortran.org/doc/year/16/16-007.pdf

I'm working on obtaining a publicly accessible link in case the above one
doesn't work.

Damian

[Bug tree-optimization/77937] [7 Regression] ICE: in replace_one_candidate, at gimple-ssa-strength-reduction.c:3370

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77937

--- Comment #6 from Markus Trippelsdorf  ---
Unfortunately it doesn't work:

dirac.i:3:6: internal compiler error: Segmentation fault
 void fn1(char *p1, int p2) {
  ^~~
0xb6d367 crash_signal
../../gcc/gcc/toplev.c:337
0x7ff87981f10f ???
   
/home/markus/glibc/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0xb9bad2 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/gcc/tree.h:3144
0xb9bad2 verify_gimple_assign_binary
../../gcc/gcc/tree-cfg.c:3732
0xbb479b verify_gimple_in_cfg(function*, bool)
../../gcc/gcc/tree-cfg.c:5135
0xa97737 execute_function_todo
../../gcc/gcc/passes.c:1964
0xa987ec execute_todo
../../gcc/gcc/passes.c:2014

[Bug c++/77943] Optimization incorrectly commons noexcept calls with non-noexcept calls

[redbeard0531 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77943

--- Comment #3 from Mathias Stearn  ---
> Not being a C++ expect, but following spec:
> http://en.cppreference.com/w/cpp/language/noexcept_spec
> 
> "If a search for a matching exception handler leaves a function marked
> noexcept or noexcept(true), std::terminate is called immediately."
> 
> Which is probably what happens in fatal() function

The problem is that it merges the calls to fatal() and notFatal() into a single
call with no branch, so there is no way to only call std::terminate() if the
call to throws() was through fatal(). (In reply to Martin Liška from comment
#2)

PS - I realized I uploaded an old version of the repro that shows the alternate
incorrect behavior of always calling std::terminate even when it should go
through nonFatal(). Sorry about that. If you reverse the branches of the
if/else you'll get the behavior I describe in the initial report.

[Bug target/77934] pattern for mtvsrdd needs to use b constraint not r

[acsawdey at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77934

--- Comment #1 from acsawdey at gcc dot gnu.org ---
Author: acsawdey
Date: Wed Oct 12 02:12:06 2016
New Revision: 241017

URL: https://gcc.gnu.org/viewcvs?rev=241017=gcc=rev
Log:
2016-10-12  Aaron Sawdey  

PR target/77934
* config/rs6000/vmx.md (vsx_concat_): The mtvsrdd instruction
needs a base register for arg 1.



Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/vsx.md

[Bug libstdc++/77944] New: FAIL: 20_util/variant/compile.cc (test for excess errors)

[danglin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77944

Bug ID: 77944
   Summary: FAIL: 20_util/variant/compile.cc (test for excess
errors)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa2.0w-hp-hpux11.11
Target: hppa2.0w-hp-hpux11.11
 Build: hppa2.0w-hp-hpux11.11

spawn /test/gnu/gcc/objdir/./gcc/xg++ -shared-libgcc
-B/test/gnu/gcc/objdir/./gc
c -nostdinc++ -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src
-L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src/.libs
-L/test/gnu/gcc/
objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/libsupc++/.libs
-B/opt/gnu/gcc/gcc-7/hppa2.0w-hp-hpux11.11/bin/
-B/opt/gnu/gcc/gcc-7/hppa2.0w-hp-hpux11.11/lib/ -isyst
em /opt/gnu/gcc/gcc-7/hppa2.0w-hp-hpux11.11/include -isystem
/opt/gnu/gcc/gcc-7/hppa2.0w-hp-hpux11.11/sys-include
-B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs
-D_GLIBCXX_ASSERT -fmessage-length=0 -fno-show-column -g -O2 -DLOCALEDIR="."
-nostdinc++
-I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11.11
-I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include
-I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/test/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/20_util/variant/compile.cc
-std=gnu++17 -fno-diagnostics-show-caret -fdiagnostics-color=never -S -o
compile.s
[...]
Excess errors:
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/variant:453:
error: '__try' was not declared in this scope
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/variant:457:
error: expected primary-expression before '...' token
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/variant:457:
error: there are no arguments to '__catch' that depend on a template parameter,
so a declaration of '__catch' must be available [-fpermissive]
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/variant:458:
error: expected ';' before '{' token
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/variant:485:
error: '__try' was not declared in this scope
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/variant:489:
error: expected primary-expression before '...' token
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/variant:489:
error: there are no arguments to '__catch' that depend on a template parameter,
so a declaration of '__catch' must be available [-fpermissive]
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/variant:490:
error: expected ';' before '{' token
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/variant:1188:
error: '__try' was not declared in this scope
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/variant:1193:
error: expected primary-expression before '...' token
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/variant:1193:
error: there are no arguments to '__catch' that depend on a template parameter,
so a declaration of '__catch' must be available [-fpermissive]
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/variant:1194:
error: expected ';' before '{' token
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/variant:1207:
error: '__try' was not declared in this scope
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/variant:1212:
error: expected primary-expression before '...' token
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/variant:1212:
error: there are no arguments to '__catch' that depend on a template parameter,
so a declaration of '__catch' must be available [-fpermissive]
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/variant:1213:
error: expected ';' before '{' token
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/variant:1193:
error: '__catch' was not declared in this scope
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/variant:1212:
error: '__catch' was not declared in this scope
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/variant:1193:
error: '__catch' was not declared in this scope
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/variant:489:
error: '__catch' was not declared in this scope
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/variant:1193:
error: '__catch' was not declared in this scope
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/variant:1193:
error: '__catch' was not declared in this scope
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/variant:1193:
error: '__catch' was not declared in this scope

[Bug c++/77943] Optimization incorrectly commons noexcept calls with non-noexcept calls

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77943

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Not being a C++ expect, but following spec:
http://en.cppreference.com/w/cpp/language/noexcept_spec

"If a search for a matching exception handler leaves a function marked noexcept
or noexcept(true), std::terminate is called immediately."

Which is probably what happens in fatal() function

[Bug fortran/77942] [6/7 Regression] ICE: Floating point exception, in gfc_simplify_cshift, at fortran/simplify.c:1845

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77942

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org

--- Comment #4 from kargl at gcc dot gnu.org ---
Fixed.

[Bug fortran/77942] [6/7 Regression] ICE: Floating point exception, in gfc_simplify_cshift, at fortran/simplify.c:1845

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77942

--- Comment #3 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Tue Oct 11 21:46:12 2016
New Revision: 241011

URL: https://gcc.gnu.org/viewcvs?rev=241011=gcc=rev
Log:
2016-10-11  Steven G. Kargl  

PR fortran/77942
* simplify.c (gfc_simplify_cshift): Check for zero.

2016-10-11  Steven G. Kargl  

PR fortran/77942
* gfortran.dg/pr77942.f90

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/pr77942.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/simplify.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug other/77421] Bugs found in GCC with the help of PVS-Studio

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77421
Bug 77421 depends on bug 77424, which changed state.

Bug 77424 Summary: Identical statements in if-else branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77424

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug tree-optimization/77424] Identical statements in if-else branches

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77424

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Jeffrey A. Law  ---
Fixed by commit on the trunk.

[Bug tree-optimization/77424] Identical statements in if-else branches

[law at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77424

--- Comment #4 from Jeffrey A. Law  ---
Author: law
Date: Tue Oct 11 21:41:51 2016
New Revision: 241009

URL: https://gcc.gnu.org/viewcvs?rev=241009=gcc=rev
Log:
PR tree-optimization/77424
* tree-ssa-threadupdate.c (thread_through_all_blocks): Remove
dead conditionals.  Assert that all e->aux fields are NULL.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-threadupdate.c

[Bug fortran/77942] [6/7 Regression] ICE: Floating point exception, in gfc_simplify_cshift, at fortran/simplify.c:1845

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77942

--- Comment #2 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Tue Oct 11 21:03:04 2016
New Revision: 241008

URL: https://gcc.gnu.org/viewcvs?rev=241008=gcc=rev
Log:
2016-10-11  Steven G. Kargl  

PR fortran/77942
* simplify.c (gfc_simplify_cshift): Check for zero.

2016-10-11  Steven G. Kargl  

PR fortran/77942
* gfortran.dg/pr77942.f90

Added:
trunk/gcc/testsuite/gfortran.dg/pr77942.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/simplify.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/77937] [7 Regression] ICE: in replace_one_candidate, at gimple-ssa-strength-reduction.c:3370

[wschmidt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77937

Bill Schmidt  changed:

   What|Removed |Added

 Target||x86_64-pc-linux-gnu

--- Comment #5 from Bill Schmidt  ---
OK, thanks.  While I get a cross built, could you please try the following
patch?

Index: gcc/gimple-ssa-strength-reduction.c  
===
--- gcc/gimple-ssa-strength-reduction.c (revision 240946)   
+++ gcc/gimple-ssa-strength-reduction.c (working copy)  
@@ -3367,7 +3367,7 @@ replace_one_candidate (slsr_cand_t c, unsigned i,
 {  
   tree stride_type = TREE_TYPE (c->stride);
   tree orig_type = TREE_TYPE (orig_rhs2);  
-  gcc_assert (repl_code != POINTER_PLUS_EXPR); 
+  tree basis_type = TREE_TYPE (basis_name);

   if (types_compatible_p (orig_type, stride_type)) 
rhs2 = c->stride;   
@@ -3374,7 +3374,16 @@ replace_one_candidate (slsr_cand_t c, unsigned i,
   else 
rhs2 = introduce_cast_before_cand (c, orig_type, c->stride);

-  if (orig_code != MINUS_EXPR  
+  if (POINTER_TYPE_P (basis_type)) 
+   {   
+ tree neg_stride = fold_unary (NEGATE_EXPR, sizetype, rhs2);   
+ gimple_stmt_iterator gsi = gsi_for_stmt (c->cand_stmt);   
+ gimple_assign_set_rhs_with_ops (, POINTER_PLUS_EXPR,  
+ basis_name, neg_stride);  
+ update_stmt (gsi_stmt (gsi)); 
+ c->cand_stmt = gsi_stmt (gsi);
+   }   
+  else if (orig_code != MINUS_EXPR 
  || !operand_equal_p (basis_name, orig_rhs1, 0)
  || !operand_equal_p (rhs2, orig_rhs2, 0)) 
{

[Bug c++/77943] Optimization incorrectly commons noexcept calls with non-noexcept calls

[redbeard0531 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77943

--- Comment #1 from Mathias Stearn  ---
Created attachment 39787
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39787=edit
Reproducer

[Bug c++/77943] New: Optimization incorrectly commons noexcept calls with non-noexcept calls

[redbeard0531 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77943

Bug ID: 77943
   Summary: Optimization incorrectly commons noexcept calls with
non-noexcept calls
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redbeard0531 at gmail dot com
  Target Milestone: ---

When compiled with -O0 and -01 the program behaves correctly and only calls
std::terminate() when passed an argument. With -O2 and -O3 it doesn't call
std::terminate() which means that it allowed an exception to escape from a
noexcept function in violation of the standard. 

> g++ -O0 noexcept_test.cpp && ./a.out ; ./a.out 1
should die: 0
should die: 1
terminate called after throwing an instance of 'int'
Aborted (core dumped)

> g++ -O1 noexcept_test.cpp && ./a.out ; ./a.out 1
should die: 0
should die: 1
terminate called after throwing an instance of 'int'
Aborted (core dumped)

> g++ -O2 noexcept_test.cpp && ./a.out ; ./a.out 1
should die: 0
should die: 1

> g++ -O3 noexcept_test.cpp && ./a.out ; ./a.out 1
should die: 0
should die: 1

The actual behavior with -O2 and -O3 depends on which way the if block is
written. The attached version is the scariest, but if you swap the if and else
blocks and remove the ! from the condition, the executable will always call
std::terminate() even when it shouldn't.

[Bug bootstrap/77917] undefined reference to '__aeabi_unwind_cpp_pr0' during ARM bootstrap

[tulipawn at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77917

PeteVine  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |---

--- Comment #4 from PeteVine  ---
Well, `--with-build-config=bootstrap-lto` doesn't work on aarch64 either (-flto
-ffat-lto-objects and ld.gold/gcc7):

../build/./prev-gcc/xg++ -B../build/./prev-gcc/
-B/usr/gcc7/aarch64-linux-gnu/bin/ -nostdinc++
-B../build/prev-aarch64-linux-gnu/libstdc++-v3/src/.libs
-B../build/prev-aarch64-linux-gnu/libstdc++-v3/libsupc++/.libs 
-I../build/prev-aarch64-linux-gnu/libstdc++-v3/include/aarch64-linux-gnu 
-I../build/prev-aarch64-linux-gnu/libstdc++-v3/include 
-I../libstdc++-v3/libsupc++
-L../build/prev-aarch64-linux-gnu/libstdc++-v3/src/.libs
-L../build/prev-aarch64-linux-gnu/libstdc++-v3/libsupc++/.libs   -g -O2
-flto=jobserver -frandom-seed=1 -DIN_GCC -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   -DHAVE_CONFIG_H
-DGENERATOR_FILE -fno-PIE -static-libstdc++ -static-libgcc  -no-pie -o
build/genmddeps \
build/genmddeps.o build/read-md.o build/errors.o .././libiberty/libiberty.a
/usr/bin/aarch64-linux-gnu-ld: error in
/tmp/ccuJfPyg.ltrans0.ltrans.o(.eh_frame); no .eh_frame_hdr table will be
created.
/tmp/ccuJfPyg.ltrans0.ltrans.o: In function `__verbose_terminate_handler':
../build/gcc/../../../../libstdc++-v3/libsupc++/vterminate.cc:82: undefined
reference to `_Unwind_Resume'
collect2: error: ld returned 1 exit status
Makefile:2761: recipe for target 'build/genconstants' failed
make[3]: *** [build/genconstants] Error 1
make[3]: *** Waiting for unfinished jobs
/usr/bin/aarch64-linux-gnu-ld: error in
/tmp/ccLUh7n0.ltrans0.ltrans.o(.eh_frame); no .eh_frame_hdr table will be
created.
/tmp/ccLUh7n0.ltrans0.ltrans.o: In function `__verbose_terminate_handler':
../build/gcc/../../../../libstdc++-v3/libsupc++/vterminate.cc:82: undefined
reference to `_Unwind_Resume'
collect2: error: ld returned 1 exit status
Makefile:2761: recipe for target 'build/genenums' failed
make[3]: *** [build/genenums] Error 1
/usr/bin/aarch64-linux-gnu-ld: error in
/tmp/ccuja50g.ltrans0.ltrans.o(.eh_frame); no .eh_frame_hdr table will be
created.
/tmp/ccuja50g.ltrans0.ltrans.o: In function `__verbose_terminate_handler':
../build/gcc/../../../../libstdc++-v3/libsupc++/vterminate.cc:82: undefined
reference to `_Unwind_Resume'
collect2: error: ld returned 1 exit status
Makefile:2761: recipe for target 'build/genmddeps' failed

[Bug tree-optimization/77937] [7 Regression] ICE: in replace_one_candidate, at gimple-ssa-strength-reduction.c:3370

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77937

--- Comment #4 from Markus Trippelsdorf  ---
Well, -march=amdfam10 is of course x86_64-pc-linux-gnu.

[Bug tree-optimization/77937] [7 Regression] ICE: in replace_one_candidate, at gimple-ssa-strength-reduction.c:3370

[wschmidt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77937

--- Comment #3 from Bill Schmidt  ---
Does not reproduce on powerpc64le-unknown-linux-gnu.  Can you please report the
target triple?

[Bug fortran/77942] [6/7 Regression] ICE: Floating point exception, in gfc_simplify_cshift, at fortran/simplify.c:1845

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77942

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-11
 CC||kargl at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
   Target Milestone|--- |6.3
Summary|ICE: Floating point |[6/7 Regression] ICE:
   |exception, in   |Floating point exception,
   |gfc_simplify_cshift, at |in gfc_simplify_cshift, at
   |fortran/simplify.c:1845 |fortran/simplify.c:1845
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r230709.

[Bug fortran/77941] ICE in expand_expr_addr_expr_1, at expr.c:7805

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77941

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-11
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Martin Liška  ---
Started to ICE with 4.6.0 (first version that supports -fcoarray).

[Bug fortran/77940] ICE in walk_coarray, at fortran/trans-array.c:6684

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77940

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-11
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Confirmed, started to ICE with 4.7.0.

[Bug fortran/77942] New: ICE: Floating point exception, in gfc_simplify_cshift, at fortran/simplify.c:1845

[gerhard.steinmetz.fort...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77942

Bug ID: 77942
   Summary: ICE: Floating point exception, in gfc_simplify_cshift,
at fortran/simplify.c:1845
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Affects version 6 and 7, works with 5 and below.


$ cat z1.f90
program p
   character, parameter :: c(2) = 'a'
   print *, cshift(c(2:1), 1)
end


$ cat z3.f90
program p
   character, parameter :: c(*) = [character ::]
   print *, cshift(c, 1)
end


$ gfortran-7-20161009 z1.f90
f951: internal compiler error: Floating point exception
0xc2a7cf crash_signal
../../gcc/toplev.c:337
0x703c5f gfc_simplify_cshift(gfc_expr*, gfc_expr*, gfc_expr*)
../../gcc/fortran/simplify.c:1845
0x69beb1 do_simplify
../../gcc/fortran/intrinsic.c:4269
0x6a5c9c gfc_intrinsic_func_interface(gfc_expr*, int)
../../gcc/fortran/intrinsic.c:4618
0x6ebc71 resolve_unknown_f
../../gcc/fortran/resolve.c:2718
0x6ebc71 resolve_function
../../gcc/fortran/resolve.c:3020
0x6ebc71 gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.c:6356
0x6f0a31 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:10580
0x6f06f7 gfc_resolve_blocks(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:9629
0x6f0b3e gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:10570
0x6f33b2 resolve_codes
../../gcc/fortran/resolve.c:15739
0x6f34ae gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:15774
0x6ddfca resolve_all_program_units
../../gcc/fortran/parse.c:5879
0x6ddfca gfc_parse_file()
../../gcc/fortran/parse.c:6131
0x720e22 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug fortran/77941] ICE in expand_expr_addr_expr_1, at expr.c:7805

[gerhard.steinmetz.fort...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77941

--- Comment #2 from Gerhard Steinmetz  
---

For completeness, with older test versions (--enable-checking=yes) :


$ gfortran-7-20161002 z1.f90
z1.f90:2:0:

print *, f(2_8**32+1)

internal compiler error: Segmentation fault
0xc29b8f crash_signal
../../gcc/toplev.c:337
0xc1abe4 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../gcc/tree.h:3153
0xc1abe4 layout_decl(tree_node*, unsigned int)
../../gcc/stor-layout.c:616
0xec0f7e build_decl_stat(unsigned int, tree_code, tree_node*, tree_node*)
../../gcc/tree.c:4730
0x98fb78 create_tmp_var_raw(tree_node*, char const*)
../../gcc/gimple-expr.c:438
0x723c67 gfc_create_var_np(tree_node*, char const*)
../../gcc/fortran/trans.c:91
0x723c67 gfc_create_var(tree_node*, char const*)
../../gcc/fortran/trans.c:108
0x723c67 gfc_evaluate_now_loc(unsigned int, tree_node*, stmtblock_t*)
../../gcc/fortran/trans.c:128
0x7653b6 gfc_apply_interface_mapping(gfc_interface_mapping*, gfc_se*,
gfc_expr*)
../../gcc/fortran/trans-expr.c:4400
0x76057a gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec*)
../../gcc/fortran/trans-expr.c:5913
0x762ca2 gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:7696
0x76a5f6 gfc_conv_expr_reference(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:7796
0x790026 gfc_trans_transfer(gfc_code*)
../../gcc/fortran/trans-io.c:2464
0x724057 trans_code
../../gcc/fortran/trans.c:1918
0x78ce50 build_dt
../../gcc/fortran/trans-io.c:1962
0x724077 trans_code
../../gcc/fortran/trans.c:1890
0x7538f8 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6257
0x6de270 translate_all_program_units
../../gcc/fortran/parse.c:5940
0x6de270 gfc_parse_file()
../../gcc/fortran/parse.c:6146
0x720e82 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug fortran/77941] New: ICE in expand_expr_addr_expr_1, at expr.c:7805

[gerhard.steinmetz.fort...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77941

Bug ID: 77941
   Summary: ICE in expand_expr_addr_expr_1, at expr.c:7805
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

ICEs with "value" attribute, down to at least 4.8 :


$ cat z1.f90
program p
   print *, f(2_8**32+1)
contains
   function f(n)
  integer(8), value :: n
  character(n) :: f
  f = 'a'
   end
end


$ gfortran-7-20161009 z1.f90
z1.f90:2:0:

print *, f(2_8**32+1)

Error: size of variable 'str.1' is too large
z1.f90:2:0:

print *, f(2_8**32+1)

internal compiler error: in expand_expr_addr_expr_1, at expr.c:7805
0x918987 expand_expr_addr_expr_1
../../gcc/expr.c:7805
0x90c145 expand_expr_addr_expr
../../gcc/expr.c:7918
0x90c145 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:10958
0x7f5741 expand_normal
../../gcc/expr.h:285
0x7f5741 precompute_register_parameters
../../gcc/calls.c:886
0x7f5741 expand_call(tree_node*, rtx_def*, int)
../../gcc/calls.c:3257
0x90b88c expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:10736
0x809192 expand_expr
../../gcc/expr.h:279
0x809192 expand_call_stmt
../../gcc/cfgexpand.c:2666
0x809192 expand_gimple_stmt_1
../../gcc/cfgexpand.c:3579
0x809192 expand_gimple_stmt
../../gcc/cfgexpand.c:3745
0x80a80e expand_gimple_basic_block
../../gcc/cfgexpand.c:5752
0x810996 execute
../../gcc/cfgexpand.c:6363

[Bug fortran/77941] ICE in expand_expr_addr_expr_1, at expr.c:7805

[gerhard.steinmetz.fort...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77941

--- Comment #1 from Gerhard Steinmetz  
---


No ICE with "intent(in)" instead :


$ cat z2.f90
program p
   print *, f(2_8**32+1)
contains
   function f(n)
  integer(8), intent(in) :: n
  character(n) :: f
  f = 'a'
   end
end


$ gfortran-7-20161009 z2.f90
$ a.out
 a

[Bug fortran/77940] ICE in walk_coarray, at fortran/trans-array.c:6684

[gerhard.steinmetz.fort...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77940

--- Comment #1 from Gerhard Steinmetz  
---

For completeness :


$ cat y1.f90
module m
   type t
   end type
contains
   subroutine s1(x)
  type(t) :: x[*]
   end
   subroutine s2(x)
  type(t) :: x(2)
  call s1(x(1))
   end
end


$ gfortran-7-20161009 -fcoarray=single y1.f90
y1.f90:10:14:

   call s1(x(1))
  1
Error: Actual argument to 'x' at (1) must be a coarray

[Bug fortran/77940] New: ICE in walk_coarray, at fortran/trans-array.c:6684

[gerhard.steinmetz.fort...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77940

Bug ID: 77940
   Summary: ICE in walk_coarray, at fortran/trans-array.c:6684
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

With invalid code, down to at least 4.8 :


$ cat z1.f90
module m
   type t
   end type
contains
   subroutine s1(x)
  class(t) :: x[*]
   end
   subroutine s2(x)
  class(t) :: x(2)
  call s1(x(1))
   end
end


$ gfortran-7-20161009 -fcoarray=single z1.f90
z1.f90:10:0:

   call s1(x(1))

internal compiler error: in walk_coarray, at fortran/trans-array.c:6684
0x73ddf0 walk_coarray
../../gcc/fortran/trans-array.c:6684
0x73ddf0 gfc_conv_expr_descriptor(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-array.c:6762
0x75e803 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec*)
../../gcc/fortran/trans-expr.c:5372
0x7a4dc4 gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool)
../../gcc/fortran/trans-stmt.c:407
0x72439a trans_code
../../gcc/fortran/trans.c:1787
0x7538b8 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6257
0x7289e9 gfc_generate_module_code(gfc_namespace*)
../../gcc/fortran/trans.c:2088
0x6de0cd translate_all_program_units
../../gcc/fortran/parse.c:5927
0x6de0cd gfc_parse_file()
../../gcc/fortran/parse.c:6146
0x720e22 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug tree-optimization/77938] missing tailcall optimization in case when local variable escapes that goes out of scope before the possible tail call site

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77938

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-11
Summary|missing tailcall|missing tailcall
   |optimization in case when   |optimization in case when
   |local variable escapes  |local variable escapes that
   ||goes out of scope before
   ||the possible tail call site
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #2 from Andrew Pinski  ---
Confirmed,  GCC Is very conservative here.  Basically any time a variable
escapes, tail call is not used.  This can be improved do to now GCC has a way
to track if a variable is in scope at the call site.

[Bug tree-optimization/77937] [7 Regression] ICE: in replace_one_candidate, at gimple-ssa-strength-reduction.c:3370

[wschmidt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77937

Bill Schmidt  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |wschmidt at gcc dot 
gnu.org
   Target Milestone|--- |7.0

--- Comment #2 from Bill Schmidt  ---
Mine to investigate -- looks like enabling copies to be handled properly has
exposed another "opportunity" here.  Looks like probably another issue with
pointer addition.

[Bug c++/77939] New: Valid program rejected due to access control

[ambrop7 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77939

Bug ID: 77939
   Summary: Valid program rejected due to access control
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ambrop7 at gmail dot com
  Target Milestone: ---

The following C++ program cannot be compiled, which is valid to my
understanding.

template 
class Test {
struct CatDog {
static void meow ()
{
CrazyHouse::TheCatDog::meow();
}

struct Dog {
static void bark ();
};
};

struct CrazyHouse {
using TheCatDog = CatDog;

static void startMadness ()
{
TheCatDog::meow();
TheCatDog::Dog::bark();
}
};

public:
static void init ()
{
CrazyHouse::startMadness();
}
};

int main ()
{
Test t;
t.init();
}

The error is:

In instantiation of 'static void Test::CatDog::meow() [with Dummy =
void]':
19 : required from 'static void Test::CrazyHouse::startMadness() [with
Dummy = void]'
27 : required from 'static void Test::init() [with Dummy = void]'
34 : required from here
6 : error: 'using TheCatDog = struct Test::CatDog' is private within this
context
CrazyHouse::TheCatDog::meow();
~~~^~
15 : note: declared private here
using TheCatDog = CatDog;

CatDog::meow() should have access to CatDog class because 1) CatDog::meow() is
part of CatDog class, 2) CatDog::meow() is declared within the Test class.

I believe the test case is minimal.

[Bug tree-optimization/77938] missing tailcall optimization in case when local variable escapes

[vanyacpp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77938

--- Comment #1 from Ivan Sorokin  ---
The generated code for caller is the following:

caller():
sub rsp, 24

lea rdi, [rsp+12]
callescape(int&)

callcallee()

add rsp, 24
ret

As you can see callee() is the regular call, not a jump.

P.S. Another strange thing is that the stack frame for this function is much
bigger than I expected (24 instead of 8). I'm not a expert in the ABI, is it
the expected behavior?

[Bug tree-optimization/77937] [7 Regression] ICE: in replace_one_candidate, at gimple-ssa-strength-reduction.c:3370

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77937

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-11
 CC||wschmidt at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
Started with r240945:

commit 41b5b58f52ee35f1efe7eeac644db6992dac5499
Author: wschmidt 
Date:   Mon Oct 10 18:39:41 2016 +

2016-10-10  Bill Schmidt  

PR tree-optimization/77824
* gimple-ssa-strength-reduction.c (stmt_cost): Explicitly return
zero cost for copies.
(find_candidates_dom_walker::before_dom_children): Replace
MODIFY_EXPR with SSA_NAME.
(replace_mult_candidate): Likewise.
(replace_profitable_candidates): Likewise.

[Bug c++/77911] Comparing function pointers in a constexpr function can produce an error.

[yhueotnk at pokemail dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77911

--- Comment #2 from Dr Hilbert Swan  ---
If a similar thing is done with ints the code would look like this:

constexpr int i[] = { 1, 2, 3 };

constexpr int FindMatchingIdx(const int w, const int idx) {
return (w == i[idx]) ? (idx) : (FindMatchingIdx(w, idx + 1));
}

constexpr unsigned int loc = FindMatchingIdx(2, 0);

int main() {
return loc;
}

Which compiles correctly. (https://godbolt.org/g/mYpxn9) I've also tried float
and doubles, which are fine, but there something about function pointers that
gcc doesn't like.

An alternative method using recursive template meta programming fails to
compile with a very similar error: (https://godbolt.org/g/zanwsd)

void test1(){}void test2(){}
void test3(){}void test4(){}


typedef void(*Type)();
constexpr Type i[] = { , ,  };

template
struct FindMatchingIdx2 {
enum { value = FindMatchingIdx2::value };
};

template
struct FindMatchingIdx2 {
enum { value = (idx) };
};

template
struct FindMatchingIdx {
  enum { flag = FindMatchingIdx2::value };
};

int main() {
return FindMatchingIdx::flag;
}

[Bug tree-optimization/77938] New: missing tailcall optimization in case when local variable escapes

[vanyacpp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77938

Bug ID: 77938
   Summary: missing tailcall optimization in case when local
variable escapes
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vanyacpp at gmail dot com
  Target Milestone: ---

GCC does not eliminate tailcalls in case when an address of any local variable
escapes the function. Consider the following code:

void escape(int& a);
void callee();

void caller()
{
  {
int local;
escape(local);
  }

  callee();
}

The variable "local" escaped, but it is dead by the time control reaches the
call to callee(). Therefore callee can not access it without invoking undefined
behavior. As the result the call to callee() can be a tailcall.

[Bug tree-optimization/77937] New: [7 Regression] ICE: in replace_one_candidate, at gimple-ssa-strength-reduction.c:3370

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77937

Bug ID: 77937
   Summary: [7 Regression] ICE: in replace_one_candidate, at
gimple-ssa-strength-reduction.c:3370
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

markus@x4 ffmpeg % cat diracdsp.i
int *a;
int b, c, d;
void fn1(char *p1, int p2) {
  int x;
  while (1) {
x = 0;
for (; x < 8; x++)
  p1[0] = -a[0] * d + p1[0] * c + 1 >> b >> 1;
p1 += p2;
  }
}

markus@x4 ffmpeg % gcc -c -O3 -march=amdfam10 diracdsp.i
diracdsp.i: In function ‘fn1’:
diracdsp.i:3:6: internal compiler error: in replace_one_candidate, at
gimple-ssa-strength-reduction.c:3370
 void fn1(char *p1, int p2) {
  ^~~
0x1269fe9 replace_one_candidate
../../gcc/gcc/gimple-ssa-strength-reduction.c:3370
0x126db67 replace_profitable_candidates
../../gcc/gcc/gimple-ssa-strength-reduction.c:3481
0x126dadb replace_profitable_candidates
../../gcc/gcc/gimple-ssa-strength-reduction.c:3490
0x1271fc6 analyze_candidates_and_replace
../../gcc/gcc/gimple-ssa-strength-reduction.c:3569
0x1271fc6 execute
../../gcc/gcc/gimple-ssa-strength-reduction.c:3643

[Bug libstdc++/77936] New: include/parallel/checkers.h:66: pointless local variable ?

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77936

Bug ID: 77936
   Summary: include/parallel/checkers.h:66: pointless local
variable ?
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

trunk/libstdc++-v3/include/parallel/checkers.h:66]: (style) Variable
'__position' is modified but its new value is never used.

$ fgrep __position trunk/libstdc++-v3/include/parallel/checkers.h
  unsigned long long __position = 1;
  __position++;
$

Suggest either delete it or use it.

[Bug c++/77922] Bogus suggestion: ‘constexpr’ does not name a type; did you mean ‘constexpr’?

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77922

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #4 from Martin Sebor  ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to Jakub Jelinek from comment #0)
> > pr.C:1:1: note: C++11 ‘constexpr’ only available with -std=c++11 or
> > -std=gnu++11
> 
> Also this note isn't true, because it's also available with -std=gnu++14, or
> with no option, etc.

This is similar to the text of some other C++ diagnostics where GCC says
something like "in C++ 11, this must be that" when the meaning is sometimes "in
C++ 11 and prior" and other times "in C++ 11 and later."

As we discussed (https://gcc.gnu.org/ml/gcc-patches/2016-09/msg02422.html) I
think it would be helpful to decide which style is clearer (or come up with one
that is) and adopt it throughout.

[Bug c++/77935] New: uninstantiated template constructor

[stefaan.deroeck at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77935

Bug ID: 77935
   Summary: uninstantiated template constructor
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stefaan.deroeck at gmail dot com
  Target Milestone: ---

The following code results in:
/tmp/ccOkdgv6.o: In function `main':
u.cpp:(.text+0x26): undefined reference to `A::A()'
collect2: error: ld returned 1 exit status

-- code --
template 
struct A
{
  A() {}
};

struct B
{
  A a;
};

void func(B b = {}) {}

int main()
{
  func();
}

-- end code --

observed on:

g++ (Ubuntu 5.4.0-6ubuntu1~16.04.2) 5.4.0 20160609
g++ (GCC) 6.1.0

[Bug sanitizer/77538] segmentation fault: thread sanitizer shadow stack overflow

[dvyukov at google dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77538

--- Comment #9 from Dmitry Vyukov  ---
Humm... what are they waiting for? Is it also core dump? Stack for the sleeping
task is missing for some reason.
What kernel version do you use? Maybe the problem is with the kernel? Isn't it
too old?.

[Bug sanitizer/77538] segmentation fault: thread sanitizer shadow stack overflow

[coollpe at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77538

--- Comment #8 from peien luo  ---
In another case, the process got stuck, compiled with gcc 4.9.4. I will try a
different version of gcc. The proc stack info is:

[god@localhost 5019]$ cat task/*/status | grep State
State:  D (disk sleep)
State:  D (disk sleep)
State:  D (disk sleep)
State:  D (disk sleep)
State:  D (disk sleep)
State:  D (disk sleep)
State:  D (disk sleep)
State:  S (sleeping)
[god@localhost 5019]$ cat task/*/stack
[] do_exit+0x1e4/0xa60
[] do_group_exit+0x3f/0xa0
[] get_signal_to_deliver+0x1d0/0x6d0
[] do_signal+0x57/0x6c0
[] do_notify_resume+0x5f/0xb0
[] int_signal+0x12/0x17
[] 0x
[] do_exit+0x1e4/0xa60
[] do_group_exit+0x3f/0xa0
[] get_signal_to_deliver+0x1d0/0x6d0
[] do_signal+0x57/0x6c0
[] do_notify_resume+0x5f/0xb0
[] int_signal+0x12/0x17
[] 0x
[] do_exit+0x1e4/0xa60
[] do_group_exit+0x3f/0xa0
[] get_signal_to_deliver+0x1d0/0x6d0
[] do_signal+0x57/0x6c0
[] do_notify_resume+0x5f/0xb0
[] int_signal+0x12/0x17
[] 0x
[] do_exit+0x1e4/0xa60
[] do_group_exit+0x3f/0xa0
[] get_signal_to_deliver+0x1d0/0x6d0
[] do_signal+0x57/0x6c0
[] do_notify_resume+0x5f/0xb0
[] int_signal+0x12/0x17
[] 0x
[] do_exit+0x1e4/0xa60
[] do_group_exit+0x3f/0xa0
[] get_signal_to_deliver+0x1d0/0x6d0
[] do_signal+0x57/0x6c0
[] do_notify_resume+0x5f/0xb0
[] int_signal+0x12/0x17
[] 0x
[] do_exit+0x1e4/0xa60
[] do_group_exit+0x3f/0xa0
[] get_signal_to_deliver+0x1d0/0x6d0
[] do_signal+0x57/0x6c0
[] do_notify_resume+0x5f/0xb0
[] int_signal+0x12/0x17
[] 0x
[] do_exit+0x1e4/0xa60
[] do_group_exit+0x3f/0xa0
[] get_signal_to_deliver+0x1d0/0x6d0
[] do_signal+0x57/0x6c0
[] do_notify_resume+0x5f/0xb0
[] int_signal+0x12/0x17
[] 0x
[] 0x
[god@localhost 5019]$ cat stack
[] do_exit+0x1e4/0xa60
[] do_group_exit+0x3f/0xa0
[] get_signal_to_deliver+0x1d0/0x6d0
[] do_signal+0x57/0x6c0
[] do_notify_resume+0x5f/0xb0
[] int_signal+0x12/0x17
[] 0x

[Bug testsuite/77710] FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-4.c

[thopre01 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77710

--- Comment #7 from Thomas Preud'homme  ---
(In reply to Martin Sebor from comment #6)
> (In reply to Thomas Preud'homme from comment #5)
> 
> Thanks for fixing it!  I keep making this mistake because { target *-*-*-* }
> matches on my own development boxes.  I wonder why DejaGnu doesn't accept {
> target * } for simplicity

I wondered this myself. Since *-*-* works for *-*-*-*, why * wouldn't?

[Bug testsuite/77710] FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-4.c

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77710

--- Comment #6 from Martin Sebor  ---
(In reply to Thomas Preud'homme from comment #5)

Thanks for fixing it!  I keep making this mistake because { target *-*-*-* }
matches on my own development boxes.  I wonder why DejaGnu doesn't accept {
target * } for simplicity

[Bug target/77934] New: pattern for mtvsrdd needs to use b constraint not r

[acsawdey at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77934

Bug ID: 77934
   Summary: pattern for mtvsrdd needs to use b constraint not r
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: acsawdey at gcc dot gnu.org
  Reporter: acsawdey at gcc dot gnu.org
CC: wschmidt at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc64le-linux

gcc 7 trunk generates incorrect code in spec 2k6 403.gcc where it tries to use
r0 as the first input register to mtvsrdd and results in storing a null pointer
instead of the desired value.

[Bug target/77924] -mfloat128-type change broke AIX

[meissner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77924

Michael Meissner  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Michael Meissner  ---
Fixed in subversion id 240994.

[Bug target/77924] -mfloat128-type change broke AIX

[meissner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77924

--- Comment #3 from Michael Meissner  ---
Author: meissner
Date: Tue Oct 11 14:12:09 2016
New Revision: 240994

URL: https://gcc.gnu.org/viewcvs?rev=240994=gcc=rev
Log:
2016-10-11  Michael Meissner  

PR target/77924
* config/rs6000/rs6000.c (rs6000_init_builtins): Only create the
distinct __ibm128 IBM extended double type if long doubles are
128-bits and the default format for long double is IEEE 128-bit.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c

[Bug libstdc++/66146] call_once not C++11-compliant on ppc64le

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org

[Bug c++/77922] Bogus suggestion: ‘constexpr’ does not name a type; did you mean ‘constexpr’?

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77922

--- Comment #3 from David Malcolm  ---
(In reply to Jakub Jelinek from comment #0)
> constexpr int a = 1;
> with -std=c++98 gives
> pr.C:1:1: error: ‘constexpr’ does not name a type; did you mean ‘constexpr’?
>  constexpr int a = 1;
>  ^
>  constexpr
> pr.C:1:1: note: C++11 ‘constexpr’ only available with -std=c++11 or
> -std=gnu++11
> 
> I'd say we should just not print the bogus "did you mean" if the identifier
> fuzzy matching found is the same as the one used originally.  Or not add
> constexpr into the suggestions in this case because it is not C++98?

If we accidentally add the goal string to the list of candidate strings when
building the list, then we'll get the goal string back, with an edit distance
of 0, and it will always be a bad suggestion.

So we probably should put a check for this case into
get_best_meaningful_candidate.  It seems to me that doing so could mask an
error: we've mispopulated the candidate list; the bad suggestion could still be
offered if someone typed something similar (e.g. "consexpr" or somesuch).  But
at least if they then try the suggestion, they'll get the:
  note: C++11 ‘constexpr’ only available with -std=c++11 or -std=gnu++11

So I think there are three parts to fixing this:
(a) fix get_best_meaningful_candidate to detect the distance == 0 case and
return NULL
(b) filter the identifiers based on "-std" when figuring out the candidate
strings
(c) update the note's text as noted in comment #2.

[Bug target/77933] Stack corruption on ARM when using high registers and __builtin_return_address

[thopre01 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77933

Thomas Preud'homme  changed:

   What|Removed |Added

   Keywords||wrong-code
  Known to fail||6.2.1, 7.0

--- Comment #1 from Thomas Preud'homme  ---
Also affects 6.2.1

[Bug debug/77931] PASS->FAIL: gdb.cp/namespace.exp: print ina

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77931

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Tue Oct 11 12:52:44 2016
New Revision: 240991

URL: https://gcc.gnu.org/viewcvs?rev=240991=gcc=rev
Log:
2016-10-11  Richard Biener  

PR debug/77931
* gimple-low.c (lower_gimple_bind): Handle arbitrary common
sub-chains of BLOCK_VARS and gimple_bind_vars.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-low.c

[Bug target/77933] New: Stack corruption on ARM when using high registers and __builtin_return_address

[thopre01 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77933

Bug ID: 77933
   Summary: Stack corruption on ARM when using high registers and
__builtin_return_address
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thopre01 at gcc dot gnu.org
  Target Milestone: ---
Target: arm-none-eabi

When compiling the following testcase with -march=armv6-m -mthumb -O1:

void* foo() {

  asm volatile("" : : : "r8", "r9");

  return __builtin_return_address(0);

}

GCC produces the following assembler:

mov r3, r9
push{r3, lr}
mov r3, r8
push{r3, lr}
mov r0, lr
pop {r2, r3}
mov r8, r2
mov r9, r3
pop {pc}

Note how 4 words are pushed on the stack but only 3 are popped, hence the stack
gets corrupted

[Bug testsuite/77710] FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-4.c

[thopre01 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77710

Thomas Preud'homme  changed:

   What|Removed |Added

  Known to work||7.0

--- Comment #5 from Thomas Preud'homme  ---
Fixed in r240979. No automatic notification because I messed up the ChangeLog
entry (extra PR before the number).

[Bug tree-optimization/77929] [7 Regression] ICE: verify_gimple failed (error: non-trivial conversion at assignment)

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77929

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Created attachment 39786
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39786=edit
gcc7-pr77929.patch

Untested fix.

[Bug tree-optimization/77921] [7 Regression] tree-ssanames.c miscompiled during PGO bootstrap

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77921

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #6 from Markus Trippelsdorf  ---
I think the transformation to an endless loop is OK.
So lets close this bug.

[Bug c/77932] New: [GRAPHITE] gmp-6.1.0, 6.1.1 breaks because of fgraphite-identity

[de.techno at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77932

Bug ID: 77932
   Summary: [GRAPHITE] gmp-6.1.0, 6.1.1 breaks because of
fgraphite-identity
   Product: gcc
   Version: 5.4.0
   URL: https://forums.gentoo.org/viewtopic-p-7850262.html?sid
=b501c3eb6e1b1b0ea55178547df18b2b
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: de.techno at gmail dot com
  Target Milestone: ---

After building gmp-6.1.0, 6.1.1 with fgraphite-identity, GCC starts complaining
'internal compiler error: Floating point exception' for almost everything
including gcc and gmp itself with or without any of the graphite flags.

[Bug debug/77931] PASS->FAIL: gdb.cp/namespace.exp: print ina

[thopre01 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77931

--- Comment #3 from Thomas Preud'homme  ---
Confirmed, this patch fixes the issue. Thanks!

[Bug debug/77931] PASS->FAIL: gdb.cp/namespace.exp: print ina

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77931

--- Comment #2 from Richard Biener  ---
It's that way in the original BIND_EXPR already.  So it looks like we need to
handle this gracefully :/

Index: gcc/gimple-low.c
===
--- gcc/gimple-low.c(revision 240964)
+++ gcc/gimple-low.c(working copy)
@@ -420,18 +420,24 @@ lower_gimple_bind (gimple_stmt_iterator
   /* Scrap DECL_CHAIN up to BLOCK_VARS to ease GC after we no longer
  need gimple_bind_vars.  */
   tree next;
-  tree end = NULL_TREE;
+  /* BLOCK_VARS and gimple_bind_vars share a common sub-chain.  Find
+ it by marking all BLOCK_VARS.  */
   if (gimple_bind_block (stmt))
-end = BLOCK_VARS (gimple_bind_block (stmt));
-  for (tree var = gimple_bind_vars (stmt); var != end; var = next)
+for (tree t = BLOCK_VARS (gimple_bind_block (stmt)); t; t = DECL_CHAIN
(t))
+  {
+   gcc_checking_assert (! TREE_VISITED (t));
+   TREE_VISITED (t) = 1;
+  }
+  for (tree var = gimple_bind_vars (stmt);
+   var && ! TREE_VISITED (var); var = next)
 {
-  /* Ugh, something is violating the constraint that BLOCK_VARS
- is a sub-chain of gimple_bind_vars.  */
-  if (! var)
-   break;
   next = DECL_CHAIN (var);
   DECL_CHAIN (var) = NULL_TREE;
 }
+  /* Unmark BLOCK_VARS.  */
+  if (gimple_bind_block (stmt))
+for (tree t = BLOCK_VARS (gimple_bind_block (stmt)); t; t = DECL_CHAIN
(t))
+  TREE_VISITED (t) = 0;

   lower_sequence (gimple_bind_body_ptr (stmt), data);


fixes it.

[Bug debug/77931] PASS->FAIL: gdb.cp/namespace.exp: print ina

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77931

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-10-11
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Ok, we're hitting /* Ugh */ which shouldn't really happen.  BLOCK_VARS should
be a sub-chain of gimple_bind_vars.  It looks like BLOCK_VARS in this case
has a common sub-chain with gimple_bind_vars instead...

  /* Scrap DECL_CHAIN up to BLOCK_VARS to ease GC after we no longer
 need gimple_bind_vars.  */
  tree next;
  tree end = NULL_TREE;
  if (gimple_bind_block (stmt))
end = BLOCK_VARS (gimple_bind_block (stmt));
  for (tree var = gimple_bind_vars (stmt); var != end; var = next)
{
  /* Ugh, something is violating the constraint that BLOCK_VARS
 is a sub-chain of gimple_bind_vars.  */
  if (! var)
break;
  next = DECL_CHAIN (var);
  DECL_CHAIN (var) = NULL_TREE;
}

and we have

gimple_bind_vars: c1D.2424 varD.2425 inaD.2426 yD.2460 clD.2462 
BLOCK_VARS: <<< Unknown tree: imported_decl >>> <<< Unknown tree: imported_decl
>>> c1D.2424 varD.2425 inaD.2426 yD.2460 clD.2462

[Bug debug/77931] New: PASS->FAIL: gdb.cp/namespace.exp: print ina

[thopre01 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77931

Bug ID: 77931
   Summary: PASS->FAIL: gdb.cp/namespace.exp: print ina
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thopre01 at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---
Target: arm-none-eabi

Hi,

I've tracked the following GDB tests regression on arm-none-eabi targets to
r240855. Keeping all components (gas, ld, gdb) fixed except for GCC confirmed
GCC is the source of the regression.

PASS->FAIL: gdb.cp/namespace.exp: print ina
PASS->FAIL: gdb.cp/namespace.exp: ptype ina
PASS->FAIL: gdb.cp/rtti.exp: print *e2

All three fail with the following error:

No symbol "ina" in current context. (respectively e2 for the last testcase). I
can see that indeed after the commit there is less debug info in namespace.cc
(in particular the bits about ina is removed).

Please let me know what dump would help you debug the issue.

Best regards.

[Bug target/77904] [ARM Cortex-M0] Frame pointer thrashes registers if assembly statements with "sp" clobber are used

[thopre01 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77904

Thomas Preud'homme  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed|2016-10-10 00:00:00 |2016-10-11
 Ever confirmed|0   |1

--- Comment #2 from Thomas Preud'homme  ---
Changing the status to NEW since bug can be reproduced

[Bug middle-end/77558] [6/7 regression] c-c++-common/va-arg-va-list-type.c fails for arm/aarch64

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77558

Tom de Vries  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Tom de Vries  ---
Patch committed to trunk and backported to 6 branch.

Marking resolved-fixed.

[Bug middle-end/77558] [6/7 regression] c-c++-common/va-arg-va-list-type.c fails for arm/aarch64

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77558

--- Comment #9 from Tom de Vries  ---
Author: vries
Date: Tue Oct 11 08:21:25 2016
New Revision: 240970

URL: https://gcc.gnu.org/viewcvs?rev=240970=gcc=rev
Log:
backport "Remove RECORD_TYPE special-casing in std_canonical_va_list_type"

2016-10-11  Tom de Vries  

backport from trunk:
2016-10-11  Tom de Vries  

PR middle-end/77558
* builtins.c (std_canonical_va_list_type): Remove RECORD_TYPE
special-casing.

Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/builtins.c

[Bug middle-end/77558] [6/7 regression] c-c++-common/va-arg-va-list-type.c fails for arm/aarch64

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77558

--- Comment #8 from Tom de Vries  ---
Author: vries
Date: Tue Oct 11 08:16:11 2016
New Revision: 240968

URL: https://gcc.gnu.org/viewcvs?rev=240968=gcc=rev
Log:
Remove RECORD_TYPE special-casing in std_canonical_va_list_type

2016-10-11  Tom de Vries  

PR middle-end/77558
* builtins.c (std_canonical_va_list_type): Remove RECORD_TYPE
special-casing.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c

[Bug target/77930] Compile time hog w/ -O2 -g -funroll-loops -ftree-loop-if-convert-stores on 32-bit targets

[asolokha at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77930

--- Comment #2 from Arseny Solokha  ---
(In reply to Richard Biener from comment #1)
> Wonder if it is var-tracking -- does -fno-var-tracking "fix" it?

Yes, it does.

[Bug tree-optimization/77929] [7 Regression] ICE: verify_gimple failed (error: non-trivial conversion at assignment)

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77929

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Yes, it's r240858.

[Bug rtl-optimization/77919] [5/6/7 Regression] ICE converting DC to V2DF mode

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77919

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*
   Target Milestone|--- |5.5
Summary|ICE converting DC to V2DF   |[5/6/7 Regression] ICE
   |mode|converting DC to V2DF mode

[Bug target/77930] Compile time hog w/ -O2 -g -funroll-loops -ftree-loop-if-convert-stores on 32-bit targets

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77930

--- Comment #1 from Richard Biener  ---
Wonder if it is var-tracking -- does -fno-var-tracking "fix" it?

[Bug tree-optimization/77929] [7 Regression] ICE: verify_gimple failed (error: non-trivial conversion at assignment)

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77929

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-11
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
caused by reassoc changes.

[Bug middle-end/77920] [7 Regression] 186.crafty doesn't compile

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77920

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #3 from Richard Biener  ---
Mine.

[Bug tree-optimization/77898] incorrect VR_ANTI_RANGE after evrp and before vrp1

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77898

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #10 from Richard Biener  ---
.

[Bug tree-optimization/77898] incorrect VR_ANTI_RANGE after evrp and before vrp1

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77898

--- Comment #9 from Marc Glisse  ---
(In reply to Martin Sebor from comment #8)
> I agree that in many cases there isn't enough information to tell that a
> range is final and can't be further improved.  But there certainly are such
> cases (the test case in comment #0 is an example of one)

The function could get inlined and i become constant...

> I think it should be possible to call set_range_info() on the result of the
> __builtin_object_size, and perhaps even on the offset variable in (p += i)
> since its value is constrained not only by the range of its type (before
> VRP1) and by statements like the 'if (i < 0 || 1 < i) i = 0;' (after VRP1)
> but also by the increment '(p += i)' which is only defined for i in [0, 3]
> as determined by the tree-object-size pass before VRP1.  Let me give that a
> try.

Careful with that last point. When we compute i+10 (in type int), we do not
restrict the range of i to [INT_MIN, INT_MAX-10]. The reason is that this
restriction is only valid starting from this statement, not from the definition
of i.

> It seems to me that there should many other opportunities to call
> set_range_info() in GCC that could help improve the generated code (and the
> ability to find bugs via warnings).  I count just 9 calls to the function in
> the whole code base.

It makes sense that most range computation happens in VRP (which has a single
set_range_info in a loop at the end). This pass duplicates variables to get
some sort of "local" range, which allows for tighter estimates. If you replace
'i = 0' with 'return' in your first example, then i may generally be any int,
but in the branch that contains __bos, it can only be in the range [0, 1],
which is something you are only aware of during the VRP pass.