[Bug rtl-optimization/77289] [7 Regression] ICE in extract_constrain_insn, at recog.c:2212 on powerpc64

[bergner at gcc dot gnu.org]

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

--- Comment #7 from Peter Bergner  ---
Author: bergner
Date: Sat Sep 10 01:36:33 2016
New Revision: 240065

URL: https://gcc.gnu.org/viewcvs?rev=240065=gcc=rev
Log:
gcc/
PR rtl-optimization/77289
* lra-constraints.c (get_final_hard_regno): Add support for non hard
register numbers.  Remove support for subregs.
(get_hard_regno): Use SUBREG_P.  Don't call get_final_hard_regno().
(get_reg_class): Delete removed get_final_hard_regno() argument.
(uses_hard_regs_p): Call get_final_hard_regno().

gcc/testsuite/
PR rtl-optimization/77289
* gcc.target/powerpc/pr77289.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr77289.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-constraints.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/77420] [5/6/7 Regression] gfortran and equivalence produces internal compiler error

[kargl at gcc dot gnu.org]

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

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
   Target Milestone|5.5 |7.0

--- Comment #3 from kargl at gcc dot gnu.org ---
Fixed on trunk.

[Bug fortran/77420] [5/6/7 Regression] gfortran and equivalence produces internal compiler error

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sat Sep 10 00:52:45 2016
New Revision: 240063

URL: https://gcc.gnu.org/viewcvs?rev=240063=gcc=rev
Log:
2016-09-09  Steven G. Kargl  

PR fortran/77420
* module.c (load_equiv): If the current namespace has a list of
equivalence statements, initialize duplicate to false and then
look for duplicates; otherwise, initialize it to true.

2016-09-09  Steven G. Kargl  

PR fortran/77420
* gfortran.dg/pr77420.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr77420.f90
Modified:
trunk/gcc/fortran/module.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/77546] New: [5 to 6 regression] C++ software renderer performance drop

[tulipawn at gmail dot com]

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

Bug ID: 77546
   Summary: [5 to 6 regression] C++ software renderer performance
drop
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tulipawn at gmail dot com
  Target Milestone: ---

Created attachment 39595
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39595=edit
Annotated assembly files

I've found a regression in the linked C++ software renderer on aarch64. 
Doing a `configure && make && make bench` yields:

GCC5 Average value: 37.912720
GCC6 Average value: 35.691360

CPU: ARM Cortex-A53, speed 1536 MHz (estimated)

GCC5

samples  %linenr info image name   app name
symbol
2760258  67.5931  Screen.cc:76renderer renderer
unsigned int IlluminatePixel(FatPointPhongAndSoftShadowed
const&, TriangleCarrier const&, Scene const&,
SDL_Surface*)
682926   16.7235  Rasterizers.cc:249  renderer renderer
   
RasterizeScene::DrawTriangles(int, int) const
[clone ._omp_fn.7] [clone .lto_priv.84]
1553813.8050  (no location information)   libgomp.so.1.0.0 renderer
/usr/lib/aarch64-linux-gnu/libgomp.so.1.0.0
1118292.7385  Screen.h:349renderer renderer
void DrawPixelBasic<4>(int, int, unsigned int)
1052022.5762  (no location information)   libSDL-1.2.so.0.11.4 renderer
/usr/lib/aarch64-linux-gnu/libSDL-1.2.so.0.11.4
89315 2.1871  ScanConverter.h:37  renderer renderer
ScanConverter::ScanlineAdd(int,
FatPointPhongAndSoftShadowed const&)
80560 1.9727  ScanConverter.h:96  renderer renderer
ScanConverter::InnerLoop(int,
int, FatPointPhongAndSoftShadowed const&, FatPointPhongAndSoftShadowed const&)
54032 1.3231  memset.S:56 libc-2.23.so renderer
memset
19974 0.4891  (no location information)   no-vmlinux   renderer
/no-vmlinux
13407 0.3283  Algebra.h:28renderer renderer
Matrix3::multiplyRightWith(Vector3 const&) const
2771  0.0679  Light.cc:101renderer renderer
DrawSceneInShadowBuffer::DrawTriangles(int, int) const [clone
._omp_fn.0] [clone .lto_priv.71]
2253  0.0552  vector.tcc:452  renderer renderer
std::vector::_M_fill_insert(__gnu_cxx::__normal_iterator >, unsigned long,
FatPointPhongAndSoftShadowed const&)
783   0.0192  renderer.cc:169 renderer renderer
main


GCC6

samples  %linenr info image name   app name
symbol name
2914396  66.8866  Screen.cc:76renderer renderer
unsigned int IlluminatePixel(FatPointPhongAndSoftShadowed
const&, TriangleCarrier const&, Scene const&,
SDL_Surface*)
708202   16.2535  Rasterizers.cc:249  renderer renderer
   
RasterizeScene::DrawTriangles(int, int) const
[clone ._omp_fn.7] [clone .lto_priv.61]
1572373.6087  (no location information)   libgomp.so.1.0.0 renderer
/usr/lib/aarch64-linux-gnu/libgomp.so.1.0.0
1064852.4439  Screen.h:349renderer renderer
void DrawPixelBasic<4>(int, int, unsigned int)
1048182.4056  (no location information)   libSDL-1.2.so.0.11.4 renderer
/usr/lib/aarch64-linux-gnu/libSDL-1.2.so.0.11.4
95259 2.1862  Types.h:61  renderer renderer
Vector3::length()
90035 2.0663  ScanConverter.h:37  renderer renderer
ScanConverter::ScanlineAdd(int,
FatPointPhongAndSoftShadowed const&)
78224 1.7953  ScanConverter.h:90  renderer renderer
ScanConverter::InnerLoop(int,
int, FatPointPhongAndSoftShadowed const&, FatPointPhongAndSoftShadowed const&)
56357 1.2934  memset.S:56 libc-2.23.so renderer
memset
21294 0.4887  (no 

[Bug c/77520] wrong value for extended ASCII characters in -Wformat message

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
Fixed via r240059.

[Bug c/77521] %qc format directive should quote non-printable characters

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
Fixed via r240059.

[Bug c/77521] %qc format directive should quote non-printable characters

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
Author: msebor
Date: Fri Sep  9 23:12:10 2016
New Revision: 240059

URL: https://gcc.gnu.org/viewcvs?rev=240059=gcc=rev
Log:
PR c/77520 - wrong value for extended ASCII characters in -Wformat message
PR c/77521 - %qc format directive should quote non-printable characters

gcc/c-family/ChangeLog:

PR c/77520
PR c/77521
* c-format.c (argument_parser::find_format_char_info): Use %qc
format directive unconditionally.

gcc/ChangeLog:

PR c/77520
PR c/77521
* pretty-print.c (pp_quoted_string): New function.
(pp_format): Call it for %c and %s directives.

gcc/testsuite/ChangeLog:

PR c/77520
PR c/77521
* gcc.dg/pr77520.c: New test.
* gcc.dg/pr77521.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/pr77520.c
trunk/gcc/testsuite/gcc.dg/pr77521.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-format.c
trunk/gcc/pretty-print.c
trunk/gcc/testsuite/ChangeLog

[Bug c/77520] wrong value for extended ASCII characters in -Wformat message

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
Author: msebor
Date: Fri Sep  9 23:12:10 2016
New Revision: 240059

URL: https://gcc.gnu.org/viewcvs?rev=240059=gcc=rev
Log:
PR c/77520 - wrong value for extended ASCII characters in -Wformat message
PR c/77521 - %qc format directive should quote non-printable characters

gcc/c-family/ChangeLog:

PR c/77520
PR c/77521
* c-format.c (argument_parser::find_format_char_info): Use %qc
format directive unconditionally.

gcc/ChangeLog:

PR c/77520
PR c/77521
* pretty-print.c (pp_quoted_string): New function.
(pp_format): Call it for %c and %s directives.

gcc/testsuite/ChangeLog:

PR c/77520
PR c/77521
* gcc.dg/pr77520.c: New test.
* gcc.dg/pr77521.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/pr77520.c
trunk/gcc/testsuite/gcc.dg/pr77521.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-format.c
trunk/gcc/pretty-print.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/77545] New: ICE on valid C++11 code: in potential_constant_expression_1, at cp/constexpr.c:5480

[su at cs dot ucdavis.edu]

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

Bug ID: 77545
   Summary: ICE on valid C++11 code: in
potential_constant_expression_1, at
cp/constexpr.c:5480
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

This is a regression from 6.2.x. 

$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160909 (experimental) [trunk revision 240043] (GCC)
$
$ g++-6.2 -c small.cpp
$ clang++-3.8 -c -std=c++11 small.cpp
$
$ g++-trunk -c small.cpp
small.cpp: In function ‘void f(A)’:
small.cpp:10:35: sorry, unimplemented: unexpected AST of kind cleanup_stmt
   for (auto x : (A < int >[]) { a })
   ^
small.cpp:10:35: internal compiler error: in potential_constant_expression_1,
at cp/constexpr.c:5480
0x8c1357 potential_constant_expression_1
../../gcc-source-trunk/gcc/cp/constexpr.c:5480
0x8c1227 potential_constant_expression_1
../../gcc-source-trunk/gcc/cp/constexpr.c:5039
0x8c0511 potential_constant_expression_1
../../gcc-source-trunk/gcc/cp/constexpr.c:5399
0x8c1ed3 potential_constant_expression
../../gcc-source-trunk/gcc/cp/constexpr.c:5491
0x8c1ed3 potential_nondependent_constant_expression(tree_node*)
../../gcc-source-trunk/gcc/cp/constexpr.c:5533
0x8c2f62 maybe_constant_value_1
../../gcc-source-trunk/gcc/cp/constexpr.c:4574
0x8c2f62 maybe_constant_value(tree_node*, tree_node*)
../../gcc-source-trunk/gcc/cp/constexpr.c:4608
0x89e941 cp_fully_fold(tree_node*)
../../gcc-source-trunk/gcc/cp/cp-gimplify.c:1971
0x733375 store_init_value(tree_node*, tree_node*, vec<tree_node*, va_gc,
vl_embed>**, int)
../../gcc-source-trunk/gcc/cp/typeck2.c:829
0x68ea5c check_initializer
../../gcc-source-trunk/gcc/cp/decl.c:6230
0x6b91fd cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc-source-trunk/gcc/cp/decl.c:6888
0x78fbc2 cp_convert_range_for(tree_node*, tree_node*, tree_node*, bool)
../../gcc-source-trunk/gcc/cp/parser.c:11451
0x7bfeb0 cp_parser_range_for
../../gcc-source-trunk/gcc/cp/parser.c:11335
0x7bfeb0 cp_parser_for
../../gcc-source-trunk/gcc/cp/parser.c:11236
0x7bfeb0 cp_parser_iteration_statement
../../gcc-source-trunk/gcc/cp/parser.c:11735
0x7b5b79 cp_parser_statement
../../gcc-source-trunk/gcc/cp/parser.c:10448
0x7b711c cp_parser_statement_seq_opt
../../gcc-source-trunk/gcc/cp/parser.c:10859
0x7b720f cp_parser_compound_statement
../../gcc-source-trunk/gcc/cp/parser.c:10813
0x7b73bf cp_parser_function_body
../../gcc-source-trunk/gcc/cp/parser.c:20832
0x7b73bf cp_parser_ctor_initializer_opt_and_function_body
../../gcc-source-trunk/gcc/cp/parser.c:20868
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$





template < typename T > struct A
{ 
  A ();
  ~A ();
  T t;
};

void f (A < int > a)
{ 
  for (auto x : (A < int >[]) { a })
;
}

[Bug target/77267] MPX does not work in a presence of "-Wl,-as-needed" option (Ubuntu default)

[hjl at gcc dot gnu.org]

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

--- Comment #4 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Fri Sep  9 21:38:06 2016
New Revision: 240057

URL: https://gcc.gnu.org/viewcvs?rev=240057=gcc=rev
Log:
Fix PR target/77267

2016-09-10  Alexander Ivchenko  

PR target/77267
* config.in: Regenerate.
* config/i386/linux-common.h (MPX_LD_AS_NEEDED_GUARD_PUSH):
New macro.
(MPX_LD_AS_NEEDED_GUARD_PUSH): Ditto.
(LIBMPXWRAPPERS_SPEC): Remove "--no-whole-archive" from
static-libmpxwrappers case.
(LIBMPX_SPEC): Add guards with MPX_LD_AS_NEEDED_GUARD_PUSH and
MPX_LD_AS_NEEDED_GUARD_POP.
* configure: Regenerate.
* configure.ac (HAVE_LD_PUSHPOPSTATE_SUPPORT): New variable.
defined if linker support "--push-state"/"--pop-state".

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config.in
trunk/gcc/config/i386/linux-common.h
trunk/gcc/configure
trunk/gcc/configure.ac

[Bug c++/77543] ARM: G++ generates redundant instructions at -O0

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #1 from Andrew Pinski  ---
This is not a bug which we are going to fix.
The reason why C++ is different is due to the getNum() needs to be wrapped with
a tree which allows for eh to be correct.  GCC likes to wrap "complex"
statement but does not go and remove the wrapping when it can be proved it is
no longer needed.
If there was a temp associated with getNum you would need a cleanup statements
which is why the wrapping happens in the first place.

Basically GCC project has mentioned -O0 code generation is not always the best,
C++ is even worse.

By the way you get the same code between the two front-ends if you used a
variable for the return of getNum().

[Bug tree-optimization/77544] [Regression 6/7] segfault at -O0 - infinite loop in simplification

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-09
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
struct {
  long a : 17;
} b;
int c, d;
void e() { b.a = d + c + ~long(302806U >> 0); }

[Bug tree-optimization/77544] New: [Regression 6/7] segfault at -O0 - infinite loop in simplification

[babokin at gmail dot com]

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

Bug ID: 77544
   Summary: [Regression 6/7] segfault at -O0 - infinite loop in
simplification
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

Created attachment 39594
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39594=edit
reproducer

> g++ -O0 -c func.cpp
g++: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Here's top of the stack when it fails (stack is huge):
#0  0x00a37c59 in operand_equal_p (...) at
./svn/trunk/gcc/fold-const.c:2744
#1  0x00a37e50 in operand_equal_p (...) at
./svn/trunk/gcc/fold-const.c:2750
#2  0x0115c676 in generic_simplify_MINUS_EXPR (...) at
generic-match.c:11785
#3  0x01174bbe in generic_simplify (...) at generic-match.c:31249
#4  0x00a47af3 in fold_binary_loc (...) at
./svn/trunk/gcc/fold-const.c:9161
#5  0x00a52a0b in fold_build2_stat_loc (...) at
./svn/trunk/gcc/fold-const.c:12291
#6  0x01138dc0 in generic_simplify_181 (...) at generic-match.c:6690
#7  0x0114c81b in generic_simplify_PLUS_EXPR (...) at
generic-match.c:11152
#8  0x01174bde in generic_simplify (...) at generic-match.c:31245
#9  0x00a47af3 in fold_binary_loc (...) at
./svn/trunk/gcc/fold-const.c:9161
#10 0x00a52a0b in fold_build2_stat_loc (...) at
./svn/trunk/gcc/fold-const.c:12291
#11 0x00a4a142 in fold_binary_loc (...) at
./svn/trunk/gcc/fold-const.c:9695
#12 0x00a52a0b in fold_build2_stat_loc (...) at
./svn/trunk/gcc/fold-const.c:12291
#13 0x0115c762 in generic_simplify_MINUS_EXPR (...) at
generic-match.c:12390

It's reproducible with gcc6 and trunk. gcc5 works.

GCC build details:
> g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/users/ddd/gcc_20160909/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /users/ddd/stability/svn/trunk/configure --with-arch=corei7
--with-cpu=corei7 --enable-clocale=gnu --enable-libmpx=yes --with-system-zlib
--enable-shared --with-demangler-in-ld --enable-cloog-backend=isl
--with-fpmath=sse --with-pkgversion=Revision=240038/svn-rev:240038/
--prefix=/users/ddd/stability/work/trunk/64/install
--enable-languages=c,c++,fortran,java,lto
Thread model: posix
gcc version 7.0.0 20160908 (experimental) (Revision=240038/svn-rev:240038/)

[Bug fortran/77506] F2008 Standard does not allow CHARACTER(LEN=*) in array constructor

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Target Milestone|--- |7.0

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

[Bug fortran/77506] F2008 Standard does not allow CHARACTER(LEN=*) in array constructor

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Sep  9 18:04:23 2016
New Revision: 240052

URL: https://gcc.gnu.org/viewcvs?rev=240052=gcc=rev
Log:
2016-09-09  Steven G. Kargl  

PR fortran/77506
* array.c (gfc_match_array_constructor): CHARACTER(len=*) cannot
appear in an array constructor.

2016-09-09  Steven G. Kargl  

PR fortran/77506
* gfortran.dg/pr77506.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr77506.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/array.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/77507] gfortran rejects keyworded calls to procedures from intrinsic modules

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Target Milestone|--- |7.0

--- Comment #5 from kargl at gcc dot gnu.org ---
Fixed on trunk.

[Bug fortran/77507] gfortran rejects keyworded calls to procedures from intrinsic modules

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Sep  9 17:57:11 2016
New Revision: 240050

URL: https://gcc.gnu.org/viewcvs?rev=240050=gcc=rev
Log:
2016-09-09  Steven G. Kargl  

PR fortran/77507
* intrinsic.c (add_functions):  Use correct keyword.

2016-09-09  Steven G. Kargl  

PR fortran/77507
* ieee/ieee_arithmetic.F90 (IEEE_VALUE_4,IEEE_VALUE_8,IEEE_VALULE_10,
IEEE_VALUE_16):  Use correct keyword.

2016-09-09  Steven G. Kargl  

PR fortran/77507
* gfortran.dg/pr77507.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr77507.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/intrinsic.c
trunk/gcc/testsuite/ChangeLog
trunk/libgfortran/ChangeLog
trunk/libgfortran/ieee/ieee_arithmetic.F90

[Bug bootstrap/77512] gcc compilation stops with Arithmetic Exception

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Eric Botcazou  ---
> First stage was compiled using gcc 4.0.3
> Prerequisits are dowload using contrib/download_prerequisites
> GNU binutils-2.27 are used
> configuration was done with:
> ../gcc-6.2.0/configure --prefix=$HOME/gcc-6.2.0-bin
> --target=sparc-sun-solaris2.10 --with-gnu-as --with-gnu-ld --disable-libgcj
> --enable-languages=c,c++

Sorry, I missed this: the configuration is incorrect, you need to configure
with --build=sparc-sun-solaris2.10 instead of --target=sparc-sun-solaris2.10
since it's a native platform.

[Bug c++/77543] New: ARM: G++ generates redundant instructions at -O0

[mh at ashwireless dot com]

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

Bug ID: 77543
   Summary: ARM: G++ generates redundant instructions at -O0
   Product: gcc
   Version: 5.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mh at ashwireless dot com
  Target Milestone: ---

(This is using the 2016q2 release of the ARM toolchain, GCC 5.4.1).

Use first arm-none-eabi-gcc and then arm-none-eabi-g++ to compile this code
(without any optimisation i.e. -O0):

-
void doStuff(void);
int getNum(void);

void compare1(int n)
{
if(n > 33)
{
doStuff();
}
if(getNum() > 44)
{
doStuff();
}
}
--

GCC generates pretty much what I'd expect:

  27 0010 08301BE5 ldr  r3, [fp, #-8]
  28 0014 210053E3 cmp  r3, #33
  29 0018 00DA ble  .L2
  30 001c FEEB bl   doStuff
  31 .L2:
  32 0020 FEEB bl   getNum
  33 0024 0030A0E1 mov  r3, r0
  34 0028 2C0053E3 cmp  r3, #44
  35 002c 00DA ble  .L4
  36 0030 FEEB bl   doStuff
  37 .L4:

But from G++:

  32 0010 08301BE5 ldr  r3, [fp, #-8]
  33 0014 210053E3 cmp  r3, #33
  34 0018 00DA ble  .L2
  35 001c FEEB bl   _Z8doStuffv
  36 .L2:
  37 0020 FEEB bl   _Z6getNumv
  38 0024 0030A0E1 mov  r3, r0
  39 0028 2C0053E3 cmp  r3, #44
  40 002c 0130A0C3 movgtr3, #1 ; if >44, set flag = 1 
  41 0030 0030A0D3 movler3, #0 ; if <=44, set flag = 0 
  42 0034 FF3003E2 and  r3, r3, #255   ; treat as a byte
  43 0038 53E3 cmp  r3, #0 ; compare flag == 0?
  44 003c 000A beq  .L4
  45 0040 FEEB bl   _Z8doStuffv
  46 .L4:

Similar constructions are generated for Thumb and Thumb-2 instruction-sets.
So the bug occurs only if compiling as C++, and only when testing a value
returned from a function.

It seems to be using a uint8_t as a flag, initially setting it true, changing
it to false if the condition is not met, then zero-extending the uint8_t to 32
bits before jumping based on its value - 7 instructions instead of 2 (and using
an extra register). So two questions - why is it using a flag at all, and why
is the flag handled as a byte rather than a word?

The redundant instructions disappear if I enable optimisation O1 or Og, but it
would be better not to generate them in the first place.

[Bug ada/77535] GNAT.Perfect_Hash_Generators accesses invalid memory with non-1-based strings

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #1 from Eric Botcazou  ---
Confirmed.

[Bug c++/77542] New: __attribute__((warn_unused_result)) ignored on function template

[afenkart at gmail dot com]

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

Bug ID: 77542
   Summary: __attribute__((warn_unused_result)) ignored on
function template
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: afenkart at gmail dot com
  Target Milestone: ---

..
  template
  ReturnValue bind(Args&&... args) __attribute__((warn_unused_result));
..

When ignoring the return value, gcc emits no warning.



$ gcc --version
gcc (Debian 5.4.0-4) 5.4.0 20160609
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug rtl-optimization/77541] [7 Regression] wrong code with 512bit vectors of int128 @ -O1

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Keywords||ra
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-09
 CC||ubizjak at gmail dot com,
   ||vmakarov at gcc dot gnu.org
  Component|target  |rtl-optimization
 Ever confirmed|0   |1

--- Comment #1 from Uroš Bizjak  ---
This is RA failure, where reload tries to fix up:

(insn 54 10 12 2 (parallel [
(set (reg:DI 105 [ x4 ])
(lshiftrt:DI (reg:DI 37 r8 [ x4 ])
(reg:QI 37 r8 [ x4 ])))
(clobber (reg:CC 17 flags))
]) pr77541.c:10 564 {*lshrdi3_1}
 (expr_list:REG_DEAD (reg:QI 37 r8 [ x4 ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil

with:

(insn 56 10 58 2 (set (reg:DI 2 cx [orig:127 x4 ] [127])
(reg:DI 37 r8 [ x4 ])) pr77541.c:10 81 {*movdi_internal}
 (nil))
(insn 58 56 54 2 (set (reg:QI 2 cx [orig:128 x4 ] [128])
(reg:QI 37 r8 [ x4 ])) pr77541.c:10 85 {*movqi_internal}
 (nil))
(insn 54 58 12 2 (parallel [
(set (reg:DI 2 cx [orig:127 x4 ] [127])
(lshiftrt:DI (reg:DI 2 cx [orig:127 x4 ] [127])
(reg:QI 2 cx [orig:128 x4 ] [128])))
(clobber (reg:CC 17 flags))
]) pr77541.c:10 564 {*lshrdi3_1}
 (nil))

Please note (insn 58) that overwrites the result of (insn 56), needed in (insn
54).

[Bug java/71917] [7 regression] libjava.jar/ReturnProxyTest.jar etc. FAIL

[matthew.fortune at imgtec dot com]

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

--- Comment #12 from Matthew Fortune  ---
Created attachment 39593
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39593=edit
Proposed fix

Attached fix should resolve the issue on sparc64 BE.

The original attempt at the fix for mips64el is reverted and instead the rvalue
conversion for the native FFI interface now copes with 64-bit little endian
targets ensuring sign/zero extension is performed appropriately. The fix is for
all architectures but presumably others do not suffer if the sign/zero
extension is missing (or have not noticed).

[Bug target/77541] New: [7 Regression] wrong code with 512bit vectors of int128 @ -O1

[zsojka at seznam dot cz]

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

Bug ID: 77541
   Summary: [7 Regression] wrong code with 512bit vectors of
int128 @ -O1
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu

Created attachment 39592
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39592=edit
reduced testcase

Output:
$ x86_64-pc-linux-gnu-gcc -O testcase.c -Wno-psabi
$ ./a.out 
Aborted

The vector has values:
03020100
instead of:
0706050403020100

$ x86_64-pc-linux-gnu-gcc -v  
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-240036-checking-yes-rtl-df-extra-nographite-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--without-cloog --without-ppl --without-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-240036-checking-yes-rtl-df-extra-nographite-amd64
Thread model: posix
gcc version 7.0.0 20160908 (experimental) (GCC) 


Tested revisions:
r240036 - FAIL
6-branch r239849 - OK
5-branch r239848 - OK

[Bug target/77333] Incorrect stack adjust in epilogue when targeting i686-w64-mingw32

[tony at kelman dot net]

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

--- Comment #8 from Tony Kelman  ---
`git grep -n deriviz` returns nothing anywhere in the gcc source code
and -fno-derivization gives an error: unrecognized command line option.

[Bug tree-optimization/77454] [7 Regression] IMM ERROR w/ -O2 and above

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug c++/77540] New: Confusing diagnostics due to stray comma in ctor-init-list

[redi at gcc dot gnu.org]

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

Bug ID: 77540
   Summary: Confusing diagnostics due to stray comma in
ctor-init-list
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

struct A { };

struct B : A
{
  B() : A(),  // N.B. erroneous comma here
  {
  }

  typedef int C;

  C c;
};

This says:

e.cc:11:3: error: ‘C’ does not name a type
   C c;
   ^
e.cc: In constructor ‘B::B()’:
e.cc:6:3: error: expected identifier before ‘{’ token
   {
   ^

This doesn't help find the error in the code.

The first diagnostic is a consequence of the second one, so a user who tries to
fix the errors in the order they appear (usually the best approach to fixing
compiler errors) is stuck, because C certainly *is* a type from the user's
perspective. They have to ignore the "does not name a type" error and fix the
next one instead. If there are several uses of C then there could be several
errors before the important "expected identifier" one.

The second diagnostic is quite vague, and could have a better location. A
better diagnostic, with fixit hint, would be:

e.cc: In constructor ‘B::B()’:
e.cc:6:3: error: expected identifier before ‘{’ token. Remove the comma?
  B() : A(),  // N.B. erroneous comma here
   ^

Ideally this would also be printed first, but I realise that the "does not name
a type" error comes when compiling the class body, which happens before the
constructor body. I assume the parser consumes everything up to the semi-colon
after the typedef declaration as part of the constructor body, and so the
declaration isn't seen before the uses of C.

[Bug target/77333] Incorrect stack adjust in epilogue when targeting i686-w64-mingw32

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski  ---
Try -fno-derivization (I think that is the spelling).

[Bug target/77333] Incorrect stack adjust in epilogue when targeting i686-w64-mingw32

[tony at kelman dot net]

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

--- Comment #6 from Tony Kelman  ---
Created attachment 39590
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39590=edit
bisect-log.txt

[Bug target/77333] Incorrect stack adjust in epilogue when targeting i686-w64-mingw32

[tony at kelman dot net]

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

--- Comment #5 from Tony Kelman  ---
Created attachment 39589
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39589=edit
bisect-run.sh

[Bug target/77333] Incorrect stack adjust in epilogue when targeting i686-w64-mingw32

[tony at kelman dot net]

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

--- Comment #4 from Tony Kelman  ---
I managed to bisect this to SVN revision 217587 by
Martin Jambor  using the attached
Dockerfile and bisect-run.sh. This was cross-compiling
from openSUSE 42.1 which happened to have most of the
build-deps easily available but should be reproducible
with a cross-compiler most places you can get wine.

[Bug target/77333] Incorrect stack adjust in epilogue when targeting i686-w64-mingw32

[tony at kelman dot net]

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

--- Comment #3 from Tony Kelman  ---
Created attachment 39588
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39588=edit
Dockerfile

[Bug target/63250] Complex fp16 arithmetic uses nonexistent libgcc functions

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #4 from James Greenhalgh  ---
Author: jgreenhalgh
Date: Fri Sep  9 09:40:22 2016
New Revision: 240043

URL: https://gcc.gnu.org/viewcvs?rev=240043=gcc=rev
Log:
[Patch libgcc] Enable HCmode multiply and divide (mulhc3/divhc3)

This patch arranges for half-precision complex multiply and divide
routines to be built if __LIBGCC_HAS_HF_MODE__.  This will be true
if the target supports the _Float16 type.

libgcc/

PR target/63250
*  Makefile.in (lib2funcs): Build _mulhc3 and _divhc3.
* libgcc2.h (LIBGCC_HAS_HF_MODE): Conditionally define.
(HFtype): Likewise.
(HCtype): Likewise.
(__divhc3): Likewise.
(__mulhc3): Likewise.
* libgcc2.c: Support _mulhc3 and _divhc3.


Modified:
trunk/libgcc/ChangeLog
trunk/libgcc/Makefile.in
trunk/libgcc/libgcc2.c
trunk/libgcc/libgcc2.h

[Bug target/71399] [5/6/7 Regression] 5.3.0 bootstrap comparison failure on arm-linux-gnueabihf

[ludo at gnu dot org]

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

--- Comment #11 from Ludovic Courtès  ---
Created attachment 39587
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39587=edit
Dependency graph of the native compiler

[Bug target/71399] [5/6/7 Regression] 5.3.0 bootstrap comparison failure on arm-linux-gnueabihf

[ludo at gnu dot org]

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

--- Comment #10 from Ludovic Courtès  ---
In fact, the revert only needs to be done on the initial pseudo-cross-compiler
that is used to build the native compiler (I'm attaching a PDF of the
dependency graph, where the initial pseudo-cross-compiler as described at
http://linuxfromscratch.org/lfs/view/stable/chapter05/gcc-pass1.html is marked
as "gcc-cross-boot0", and the final native compiler is simply "gcc").

To summarize, if we build 4.9.4 with a cross-4.9.3, that's fine; if we build
4.9.4 with a cross-4.9.4, we get the bootstrap comparison failure.

That would suggest a code generation issue that somehow propagates from the
initial cross-compiler up to stage2 of the compiler we're building.

[Bug fortran/77516] ICE in is_gimple_min_invariant, at gimple-expr.c:706

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-09
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Plans to back port r240037?

[Bug fortran/77506] F2008 Standard does not allow CHARACTER(LEN=*) in array constructor

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-09
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (7.0). Patch submitted at
https://gcc.gnu.org/ml/fortran/2016-09/msg00026.html.

[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

Dmitry Vyukov  changed:

   What|Removed |Added

 CC||dvyukov at google dot com

--- Comment #1 from Dmitry Vyukov  ---
Hello,

Shadow stack size was increased several times, and as far as I remember we now
have a guard page at the end. Please retest with latest gcc/clang, or provide a
reproducer.

[Bug fortran/77517] ICE in conv_intrinsic_move_alloc, at fortran/trans-intrinsic.c:9517

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-09
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
Confirmed. The ICE for the test in comment 0 appeared between revisions r229946
(2015-11-08, error) and r229946 (2015-11-08, ICE) and has been back ported to
gcc-5, but not gcc-4.9. The only candidates I have found are r229992 (pr68053)
and r229955 (pr68224).

Any objection to mark this PR as a [5/6/7 Regression]?

[Bug c++/77539] gcc-5/6: comparison of array to nullptr failure in constexpr (fixed by r235506 on trunk)

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug fortran/77525] wrong requirement of an upper bound for an array argument

[francois.jacq at irsn dot fr]

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

--- Comment #2 from francois.jacq at irsn dot fr ---
(In reply to Dominique d'Humieres from comment #1)
> Confirmed from 4.5 up to trunk (7.0). Fortran 2003: Procedure components at
> (1) are not yet implemented in gfortran-4.4.
> 
> > This is a regression because gfortran 4.9.2 is OK
> 
> Are you sure of that? I don't have 4.9.2, but I see the error with various
> 4.9.0 and 4.9.4.

No you are right ! It does not work even with gfortran-4.9.2

Sorry for that wrong remark...

[Bug c++/77539] New: gcc-5/6: comparison to nullptr failure in constexpr (fixed by r235506 on trunk)

[trippels at gcc dot gnu.org]

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

Bug ID: 77539
   Summary: gcc-5/6: comparison to nullptr failure in constexpr
(fixed by r235506 on trunk)
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: nathan at gcc dot gnu.org
  Target Milestone: ---

In
http://stackoverflow.com/questions/39405241/constexpr-comparision-to-nullptr-bug-or-feature/
a user posted the following testcase:

trippels@gcc2-power8 ~ % cat const2.ii
constexpr int foobar()
{
  int array[100] = {};
  int *ar = array;
  if (ar == nullptr) // Error...
  {
return 0;
  }
  return 1;
}
static_assert(foobar(),"");

trippels@gcc2-power8 ~ % ~/gcc_6/usr/local/bin/g++ -c const2.ii
const2.ii:12:1: error: non-constant condition for static assertion
 static_assert(foobar(),"");
 ^
const2.ii:12:21:   in constexpr expansion of ‘foobar()’
const2.ii:5:10: error: ‘(((int*)(& array)) == 0u)’ is not a constant expression
   if (ar == nullptr) // Error...
   ~~~^~

This was fixed on trunk by r235506.

Nathan, would could you please backport your fix to gcc-6 branch?

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

[coollpe at hotmail dot com]

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

Bug ID: 77538
   Summary: segmentation fault: thread sanitizer shadow stack
overflow
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: coollpe at hotmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

The stack back trace showed there is an overflow of shadow stack and caused the
corruption of mset (size_ is written as a strange number in this overflow)

[Switching to Thread 0x7fffe35fc700 (LWP 29912)]
Hardware watchpoint 6: *0x7fffe3562080

Old value = 1
New value = -150984400
__tsan::FuncEntry (thr=thr@entry=0x7fffe3477840, pc=pc@entry=140737337370928)
at ../../../../libsanitizer/tsan/tsan_rtl.cc:583
583 ../../../../libsanitizer/tsan/tsan_rtl.cc: No such file or directory.
(gdb) bt
#0  __tsan::FuncEntry (thr=thr@entry=0x7fffe3477840,
pc=pc@entry=140737337370928) at ../../../../libsanitizer/tsan/tsan_rtl.cc:583
#1  0x76f6c97d in ScopedInterceptor::ScopedInterceptor
(this=0x7fffe34766d0, thr=0x7fffe3477840, fname=,
pc=140737337370928)
at ../../../../libsanitizer/tsan/tsan_interceptors.cc:158
#2  0x76f6e0d7 in __interceptor_memcmp (s1=0x7d06000b1108,
s2=0x7d06001a85a8, n=16) at
../../../../libsanitizer/tsan/tsan_interceptors.cc:470
#3  0x77002930 in std::char_traits::compare (__s1=0x7d06000b1108
"table_empty_node", __s2=0x7d06001a85a8 "table_empty_node", __n=16)
at
/home/opt/gcc-4.8.2.bpkg-r2/gcc-4.8.2.bpkg-r2/include/c++/4.8.2/bits/char_traits.h:255
#4  0x77002e66 in std::operator== (__lhs=..., __rhs=...) at
/home/opt/gcc-4.8.2.bpkg-r2/gcc-4.8.2.bpkg-r2/include/c++/4.8.2/bits/basic_string.h:2497
#5  0x77015ed2 in std::equal_to::operator()
(this=0x7d0ec752, __x=..., __y=...)
at
/home/opt/gcc-4.8.2.bpkg-r2/gcc-4.8.2.bpkg-r2/include/c++/4.8.2/bits/stl_function.h:208
#6  0x773accdb in __gnu_cxx::hashtable, std::equal_to,
std::allocator >::find (this=0x7d0ec750, __key=...)
at
/home/opt/gcc-4.8.2.bpkg-r2/gcc-4.8.2.bpkg-r2/include/c++/4.8.2/backward/hashtable.h:539
#7  0x773a921f in __gnu_cxx::hash_map >::find (
this=0x7d0ec750, __key=...) at
/home/opt/gcc-4.8.2.bpkg-r2/gcc-4.8.2.bpkg-r2/include/c++/4.8.2/ext/hash_map:217

gdb output:
(gdb) frame 0
#0  __tsan::FuncEntry (thr=thr@entry=0x7fffe3477840,
pc=pc@entry=140737337370928) at ../../../../libsanitizer/tsan/tsan_rtl.cc:583
583 in ../../../../libsanitizer/tsan/tsan_rtl.cc
(gdb) p thr->shadow_stack_pos
$24 = (__sanitizer::uptr *) 0x7fffe3562080
(gdb) p >shadow_stack[kShadowStackSize]
$25 = (unsigned long *) 0x7fffe3562080
(gdb) p >shadow_stack_pos[0]
$26 = (__sanitizer::uptr *) 0x7fffe3562080

The source code:
libsanitizer/tsan/tsan_rtl.cc:582
  thr->shadow_stack_pos[0] = pc;

The definition:
libsanitizer/tsan/tsan_rtl.h:360
  uptr shadow_stack[kShadowStackSize];
#else
  // Go uses satellite shadow stack with dynamic size.
  uptr *shadow_stack;
  uptr *shadow_stack_end;
#endif
  MutexSet mset;

So the overflow caused the corruption of mset, and later the size_ in mset is
corrupted, this caused the segmentation fault when accessed later.

[Bug bootstrap/77512] gcc compilation stops with Arithmetic Exception

[michael at mijobe dot org]

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

--- Comment #2 from michael at mijobe dot org ---
> Any options passed to this compiler during the first stage?
no

> Could you post the output of 'uname -a' on the machine?

SunOS kerberos 5.10 Generic_120011-14 sun4v sparc SUNW,Sun-Fire-T1000

[Bug driver/77529] -fno-pie disables -fPIC

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #5 from Markus Trippelsdorf  ---
Thanks. Closing.