[Bug target/91855] [8/9 Regression] OpenJDK Zero VM segfaults on SPARC

[ebotcazou at gcc dot gnu.org]

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

--- Comment #8 from Eric Botcazou  ---
> But this is the OpenJDK Zero VM crashing when being compiled with gcc-8/9,
> apparently because gcc miscompiles it. I don't know which piece of code is
> miscompiled, I just see the result and I provided instructions on how to get
> there.

This could be a bug in the OpenJDK Zero VM and we don't intend to debug it...

[Bug c/37591] suppress "signed and unsigned" warnings when signed value known to be positive

[egallager at gcc dot gnu.org]

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

--- Comment #10 from Eric Gallager  ---
(In reply to Eric Gallager from comment #9)
> I think this is related to bug 38470

Possibly a dup thereof? Or vice versa?

[Bug c/88566] -Wconversion not using value range information

[egallager at gcc dot gnu.org]

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

--- Comment #4 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #3)
> This is a non flow sensitive warning.  There are a bunch were are not; flow
> sensitivity would make this warning worse not better in my mind as it means
> in inlining would cause correct warnings to disappear.

Is that still the case in light of Project Ranger? Wouldn't it being on-demand
mean you could do it at a point before inlining becomes a problem?

[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare

[egallager at gcc dot gnu.org]

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

--- Comment #17 from Eric Gallager  ---
I'm wondering if Project Ranger will help this bug at all once it's merged?

[Bug middle-end/91858] [9/10 Regression] Compile time hog w/ complex float trigonometric functions

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|tree-optimization   |middle-end
   Target Milestone|--- |9.3

[Bug tree-optimization/91858] New: [9/10 Regression] Compile time hog w/ complex float trigonometric functions

[asolokha at gmx dot com]

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

Bug ID: 91858
   Summary: [9/10 Regression] Compile time hog w/ complex float
trigonometric functions
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: compile-time-hog
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: x86_64-unknown-linux-gnu

g++-10.0.0-alpha20190915 snapshot (r275736) linked against GNU MP 6.1.2 takes
indefinite time when compiling the following testcase, reduced from
test/std/numerics/complex.number/complex.transcendentals/tan.pass.cpp from the
libcxx 9.0.0 test suite, w/ -O1:

template  class yx;

template  void
operator== (yx, yx);

template <> struct yx {
  yx (_Complex float ph) : lu{ph} { }
  yx (float c0 = 0.0f, float m5 = 0.0f) : lu{c0, m5} { }
  _Complex float lu;
};

template  void
al (yx qo)
{
  _Complex float xy = qo.lu, ny = __builtin_ctanf (xy);
  yx k2 = ny, oi (1);
  k2 == oi;
}

void
al ()
{
  al (yx (1, 1));
}

% timeout 10 g++-10.0.0-alpha20190915 -O1 -c ahpihctw.cpp 
zsh: exit 124   timeout 10 g++-10.0.0-alpha20190915 -O1 -c ahpihctw.cpp

Some perf top entries:

  51.41%  libgmp.so.10.3.2  [.] __gmpn_mul_basecase
  15.23%  libgmp.so.10.3.2  [.] __gmpn_sub_n
  11.09%  libgmp.so.10.3.2  [.] __gmpn_add_n
  10.50%  libgmp.so.10.3.2  [.] __gmpn_sqr_basecase
   6.00%  libgmp.so.10.3.2  [.] __gmpn_rsblsh1_n
   1.97%  libgmp.so.10.3.2  [.] 0x000468e3
   1.84%  libgmp.so.10.3.2  [.] __gmpn_lshiftc
   0.69%  libgmp.so.10.3.2  [.] __gmpn_copyi
   0.53%  libgmp.so.10.3.2  [.] __gmpn_lshift
   0.36%  libgmp.so.10.3.2  [.] __gmpn_rsh1sub_n
   0.27%  libgmp.so.10.3.2  [.] __gmpn_bdiv_dbm1c
   0.03%  libgmp.so.10.3.2  [.] 0x000462fb
   0.03%  libgmp.so.10.3.2  [.] 0x0003c251
   0.03%  libgmp.so.10.3.2  [.] __gmpn_rsh1add_n

I believe this was already reported somewhere but I failed to find the PR.

[Bug c++/91844] Implement CWG 2352, Similar types and reference binding

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
I have a patch.

[Bug c++/91857] internal compiler error: in verify_marks_clear, at dwarf2out.c:29123

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-09-22
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
The title doesn't say it all, we will need a stand-alone reproducer, see
https://gcc.gnu.org/bugs/

[Bug c++/91844] Implement CWG 2352, Similar types and reference binding

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
And this will become valid (used to fail with call of overloaded ‘f(int*&)’ is
ambiguous):

template int f (const T *const &); // (1)
template int f (T *const &); // (2)
template int f (T *); // (3)

void
g (int *p, const int *q, const int *const r)
{
  f (p); // calls (1)
  f (q); // calls (1)
  f (r); // calls (1)
}

[Bug target/78762] Regression: Splitting unaligned AVX loads also when AVX2 is enabled

[john at johnkeiser dot com]

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

John Keiser  changed:

   What|Removed |Added

 CC||john at johnkeiser dot com

--- Comment #17 from John Keiser  ---
I can confirm that with -mavx2 and -march=haswell, this still happens. We see
it in simdjson on https://github.com/lemire/simdjson/pull/315 . Fixed by
`-mtune=haswell` or `-mno-avx256-split-unaligned-load`.

[Bug c++/91857] New: internal compiler error: in verify_marks_clear, at dwarf2out.c:29123

[vincent.lextrait at gmail dot com]

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

Bug ID: 91857
   Summary: internal compiler error: in verify_marks_clear, at
dwarf2out.c:29123
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincent.lextrait at gmail dot com
  Target Milestone: ---

Erratic (sorry) error, with gcc on MacOS 10.14.6.
The title says it all.

[Bug fortran/91726] [7/8/9/10 Regression] ICE in gfc_conv_array_ref, at fortran/trans-array.c:3612

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #2 from Paul Thomas  ---
Created attachment 46910
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46910=edit
Patch for the PR

I am just about to submit to the list.

The offending revision was not as Dominique suggested. Not only did it look
unlikely but I reverted it and tested because I just could not figure out which
one was responsible. 

Paul

[Bug target/90835] Incompatibilities with macOS 10.15 headers

[howarth.at.gcc at gmail dot com]

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

--- Comment #10 from Jack Howarth  ---
FYI, Xcode 11 is now released and being pushed, via App Store updates, to
Mojave users. So the gcc bootstrap is now officially broken on Mojave and
Catalina.

[Bug lto/83452] FAIL: gfortran.dg/save_6.f90 -O0 (test for excess errors)

[dave.anglin at bell dot net]

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

--- Comment #16 from dave.anglin at bell dot net ---
On 2019-09-21 5:03 p.m., dimitar.yordanov at sap dot com wrote:
> after this fix I see.debug_info entries in the .symtab, which seem unneeded to
> me(on Linux x86_64). If they are unnecessary should they be removed by the
> linker or the plugin? Is the fix in this patch only needed for HPUX, because 
> of
> misbehaving linker?
>
>
> cat > foo.c << EOF
> const char *a = "a";
> EOF
>
> g++ -flto -gdwarf-4 -g1 -o foo.c.o -c foo.c
> g++ -flto -shared -o libfoo.so foo.c.o
> objdump -t libfoo.so | grep debug_info
I suggest you try mainline.  This change and a preceding change revised the lto
processing
for weak symbols:

2019-08-27  Martin Liska  

PR lto/91478
* simple-object-elf.c (simple_object_elf_copy_lto_debug_sections):
First find a WEAK HIDDEN symbol in symbol table that will be
preserved.  Later, use the symbol name for all removed symbols.

The special handling for 64bit HPUX has been removed.

If problem still exists, then there should be a new bug report.

[Bug c++/91819] [10 Regression] ICE when iterating over enum values

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Polacek  ---
Fixed.

[Bug c++/91819] [10 Regression] ICE when iterating over enum values

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
Author: mpolacek
Date: Sun Sep 22 12:35:00 2019
New Revision: 276027

URL: https://gcc.gnu.org/viewcvs?rev=276027=gcc=rev
Log:
PR c++/91819 - ICE with operator++ and enum.
* call.c (build_new_op_1): Set arg2_type.

* g++.dg/other/operator4.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/other/operator4.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/ChangeLog

[Bug target/91855] [8/9 Regression] OpenJDK Zero VM segfaults on SPARC

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #7 from John Paul Adrian Glaubitz  ---
(In reply to Eric Botcazou from comment #5)
> > Is there anything missing in my instructions? I have provided a step-by-step
> > explanation how to reproduce the crash. I'm not skilled enough with gcc
> > unfortunately to be able to provide a reduced piece of code.
> 
> As documented and explained on the page, we don't need a reduced piece of
> code, but just a reproducer, i.e. the preprocessed file of the faulty object
> file.

But this is the OpenJDK Zero VM crashing when being compiled with gcc-8/9,
apparently because gcc miscompiles it. I don't know which piece of code is
miscompiled, I just see the result and I provided instructions on how to get
there.

[Bug target/91855] [8/9 Regression] OpenJDK Zero VM segfaults on SPARC

[ebotcazou at gcc dot gnu.org]

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

--- Comment #6 from Eric Botcazou  ---
"What we need

Please include all of the following items, the first three of which can be
obtained from the output of gcc -v:

the exact version of GCC;
the system type;
the options given when GCC was configured/built;
the complete command line that triggers the bug;
the compiler output (error messages, warnings, etc.); and
the preprocessed file (*.i*) that triggers the bug, generated by adding
-save-temps to the complete compilation command, or, in the case of a bug
report for the GNAT front end, a complete set of source files (see below)."

[Bug target/91855] [8/9 Regression] OpenJDK Zero VM segfaults on SPARC

[ebotcazou at gcc dot gnu.org]

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

--- Comment #5 from Eric Botcazou  ---
> Is there anything missing in my instructions? I have provided a step-by-step
> explanation how to reproduce the crash. I'm not skilled enough with gcc
> unfortunately to be able to provide a reduced piece of code.

As documented and explained on the page, we don't need a reduced piece of code,
but just a reproducer, i.e. the preprocessed file of the faulty object file.

[Bug libstdc++/91856] New: std::list::remove(const T& value) is broken with -D_GLIBCXX_DEBUG when value is a reference inside the list

[kp.lehrmann+gcc at gmail dot com]

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

Bug ID: 91856
   Summary: std::list::remove(const T& value) is broken with
-D_GLIBCXX_DEBUG when value is a reference inside the
list
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kp.lehrmann+gcc at gmail dot com
  Target Milestone: ---

Created attachment 46909
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46909=edit
preprocessed file

Hi,

I believe this is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17012 for
_GLIBCXX_DEBUG.

---
#define _GLIBCXX_DEBUG
#include 

main() {
std::list l{1, 2, 3};
l.remove(*l.begin());
return 0;
}
---

Address sanitizer would report a use after free:
> LANG=C g++ -v -save-temps a.cpp  -g  -fsanitize=undefined -fsanitize=address 
> && ./a.out
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 8.3.0-6'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.3.0 (Debian 8.3.0-6) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-g' '-fsanitize=undefined'
'-fsanitize=address' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/8/cc1plus -E -quiet -v -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE a.cpp -mtune=generic -march=x86-64
-fsanitize=undefined -fsanitize=address -g -fworking-directory -fpch-preprocess
-o a.ii
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/8"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/8/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/8
 /usr/include/x86_64-linux-gnu/c++/8
 /usr/include/c++/8/backward
 /usr/lib/gcc/x86_64-linux-gnu/8/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/8/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-g' '-fsanitize=undefined'
'-fsanitize=address' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/8/cc1plus -fpreprocessed a.ii -quiet -dumpbase
a.cpp -mtune=generic -march=x86-64 -auxbase a -g -version -fsanitize=undefined
-fsanitize=address -o a.s
GNU C++14 (Debian 8.3.0-6) version 8.3.0 (x86_64-linux-gnu)
compiled by GNU C version 8.3.0, GMP version 6.1.2, MPFR version 4.0.2,
MPC version 1.1.0, isl version isl-0.20-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++14 (Debian 8.3.0-6) version 8.3.0 (x86_64-linux-gnu)
compiled by GNU C version 8.3.0, GMP version 6.1.2, MPFR version 4.0.2,
MPC version 1.1.0, isl version isl-0.20-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 3c854693d01dc9a844a56a0b1ab1c0f4
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-g' '-fsanitize=undefined'
'-fsanitize=address' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 as -v --64 -o a.o a.s
GNU assembler version 2.31.1 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Debian) 2.31.1
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/8/:/usr/lib/gcc/x86_64-linux-gnu/8/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/8/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/8/:/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/8/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/8/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-g' '-fsanitize=undefined'
'-fsanitize=address' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 

[Bug target/91855] [8/9 Regression] OpenJDK Zero VM segfaults on SPARC

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #4 from John Paul Adrian Glaubitz  ---
(In reply to Eric Botcazou from comment #3)
> We need a reproducer as explained in https://gcc.gnu.org/bugs/

Is there anything missing in my instructions? I have provided a step-by-step
explanation how to reproduce the crash. I'm not skilled enough with gcc
unfortunately to be able to provide a reduced piece of code.

[Bug target/91855] [8/9 Regression] OpenJDK Zero VM segfaults on SPARC

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-09-22
 Ever confirmed|0   |1

--- Comment #3 from Eric Botcazou  ---
We need a reproducer as explained in https://gcc.gnu.org/bugs/

[Bug target/91855] [8/9 Regression] OpenJDK Zero VM segfaults on SPARC

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #2 from John Paul Adrian Glaubitz  ---
(In reply to Andreas Schwab from comment #1)
> SIGBUS probably means unaligned access.  What is the executed code?

(gdb) disassemble
Dump of assembler code for function SharedRuntime::generate_stubs():
   0xfff8000100c80f90 <+0>: save  %sp, -176, %sp
   0xfff8000100c80f94 <+4>: sethi  %hi(0x253000), %l7
   0xfff8000100c80f98 <+8>: call  0xfff8000100882ac0
<__sparc_get_pc_thunk.l7>
   0xfff8000100c80f9c <+12>:add  %l7, 0x68, %l7 ! 0x253068
   0xfff8000100c80fa0 <+16>:sethi  %hi(0x135400), %o1
   0xfff8000100c80fa4 <+20>:sethi  %hi(0x24b000), %o0
   0xfff8000100c80fa8 <+24>:xor  %o1, -648, %o1
   0xfff8000100c80fac <+28>:xor  %o0, -152, %o0
   0xfff8000100c80fb0 <+32>:add  %l7, %o1, %o1
   0xfff8000100c80fb4 <+36>:call  0xfff8000100c8dec4

   0xfff8000100c80fb8 <+40>:add  %l7, %o0, %o0
   0xfff8000100c80fbc <+44>:sethi  %hi(0x3c800), %g1
   0xfff8000100c80fc0 <+48>:xor  %g1, 0x60, %g1
   0xfff8000100c80fc4 <+52>:add  %l7, %g1, %g1
   0xfff8000100c80fc8 <+56>:sethi  %hi(0x135400), %o1
   0xfff8000100c80fcc <+60>:stx  %o0, [ %g1 ]
   0xfff8000100c80fd0 <+64>:xor  %o1, -624, %o1
   0xfff8000100c80fd4 <+68>:sethi  %hi(0x24f000), %o0
   0xfff8000100c80fd8 <+72>:add  %l7, %o1, %o1
   0xfff8000100c80fdc <+76>:xor  %o0, -312, %o0
   0xfff8000100c80fe0 <+80>:call  0xfff8000100c8dec4

   0xfff8000100c80fe4 <+84>:add  %l7, %o0, %o0
   0xfff8000100c80fe8 <+88>:sethi  %hi(0x3c800), %g1
   0xfff8000100c80fec <+92>:xor  %g1, 0x58, %g1
   0xfff8000100c80ff0 <+96>:add  %l7, %g1, %g1
   0xfff8000100c80ff4 <+100>:   sethi  %hi(0x135400), %o1
   0xfff8000100c80ff8 <+104>:   stx  %o0, [ %g1 ]
   0xfff8000100c80ffc <+108>:   xor  %o1, -592, %o1
   0xfff8000100c81000 <+112>:   sethi  %hi(0x24b400), %o0
   0xfff8000100c81004 <+116>:   add  %l7, %o1, %o1
   0xfff8000100c81008 <+120>:   xor  %o0, -308, %o0
   0xfff8000100c8100c <+124>:   call  0xfff8000100c8dec4

   0xfff8000100c81010 <+128>:   add  %l7, %o0, %o0
   0xfff8000100c81014 <+132>:   sethi  %hi(0x3c800), %g1
   0xfff8000100c81018 <+136>:   xor  %g1, 0x50, %g1
   0xfff8000100c8101c <+140>:   add  %l7, %g1, %g1
   0xfff8000100c81020 <+144>:   sethi  %hi(0x135400), %o1
   0xfff8000100c81024 <+148>:   stx  %o0, [ %g1 ]
   0xfff8000100c81028 <+152>:   xor  %o1, -576, %o1
   0xfff8000100c8102c <+156>:   sethi  %hi(0x24c000), %o0
   0xfff8000100c81030 <+160>:   add  %l7, %o1, %o1
   0xfff8000100c81034 <+164>:   xor  %o0, -976, %o0
   0xfff8000100c81038 <+168>:   call  0xfff8000100c8dec4

   0xfff8000100c8103c <+172>:   add  %l7, %o0, %o0
   0xfff8000100c81040 <+176>:   sethi  %hi(0x3c800), %g1
   0xfff8000100c81044 <+180>:   xor  %g1, 0x48, %g1
   0xfff8000100c81048 <+184>:   add  %l7, %g1, %g1
   0xfff8000100c8104c <+188>:   sethi  %hi(0x135400), %o1
   0xfff8000100c81050 <+192>:   stx  %o0, [ %g1 ]
   0xfff8000100c81054 <+196>:   xor  %o1, -544, %o1
   0xfff8000100c81058 <+200>:   sethi  %hi(0x24c800), %o0
   0xfff8000100c8105c <+204>:   add  %l7, %o1, %o1
   0xfff8000100c81060 <+208>:   xor  %o0, -116, %o0
   0xfff8000100c81064 <+212>:   call  0xfff8000100c8dec4

   0xfff8000100c81068 <+216>:   add  %l7, %o0, %o0
   0xfff8000100c8106c <+220>:   sethi  %hi(0x3c800), %g1
   0xfff8000100c81070 <+224>:   xor  %g1, 0x40, %g1
   0xfff8000100c81074 <+228>:   add  %l7, %g1, %g1
   0xfff8000100c81078 <+232>:   sethi  %hi(0x135400), %o1
   0xfff8000100c8107c <+236>:   stx  %o0, [ %g1 ]
   0xfff8000100c81080 <+240>:   xor  %o1, -520, %o1
   0xfff8000100c81084 <+244>:   sethi  %hi(0x24cc00), %o0
   0xfff8000100c81088 <+248>:   add  %l7, %o1, %o1
   0xfff8000100c8108c <+252>:   xor  %o0, -280, %o0
   0xfff8000100c81090 <+256>:   call  0xfff8000100c8dec4

   0xfff8000100c81094 <+260>:   add  %l7, %o0, %o0
=> 0xfff8000100c81098 <+264>:   ldx  [ %o0 + 0x20 ], %g3
   0xfff8000100c8109c <+268>:   sethi  %hi(0x3c800), %g2
   0xfff8000100c810a0 <+272>:   sethi  %hi(0x3c800), %g1
   0xfff8000100c810a4 <+276>:   xor  %g2, 0x38, %g2
   0xfff8000100c810a8 <+280>:   xor  %g1, 0x30, %g1
   0xfff8000100c810ac <+284>:   add  %l7, %g2, %g2
   0xfff8000100c810b0 <+288>:   add  %l7, %g1, %g1
   0xfff8000100c810b4 <+292>:   stx  %o0, [ %g2 ]
   0xfff8000100c810b8 <+296>:   sethi  %hi(0x258400), %o0
   0xfff8000100c810bc <+300>:   xor  %o0, -312, %o0
   0xfff8000100c810c0 <+304>:   stx  %g3, [ %g1 ]
   0xfff8000100c810c4 <+308>:   add  %l7, %o0, %i5
   0xfff8000100c810c8 <+312>:   mov  1, %o1
   0xfff8000100c810cc <+316>:   call  0xfff8000100c8dea0

   0xfff8000100c810d0 <+320>:   mov  %i5, %o0
   0xfff8000100c810d4 <+324>:   sethi  %hi(0x3c800), %g1
   0xfff8000100c810d8 <+328>:   mov  %o0, %g2
   0xfff8000100c810dc <+332>:   xor  %g1, 0x18, %g1
   0xfff8000100c810e0 <+336>:   add  %l7, %g1, %g1
   0xfff8000100c810e4 <+340>:   clr  %o1
   0xfff8000100c810e8 <+344>:   stx  %g2, [ %g1 ]
   

[Bug target/91855] [8/9 Regression] OpenJDK Zero VM segfaults on SPARC

[sch...@linux-m68k.org]

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

--- Comment #1 from Andreas Schwab  ---
SIGBUS probably means unaligned access.  What is the executed code?

[Bug target/91855] New: [8/9 Regression] OpenJDK Zero VM segfaults on SPARC

[glaubitz at physik dot fu-berlin.de]

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

Bug ID: 91855
   Summary: [8/9 Regression] OpenJDK Zero VM segfaults on SPARC
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glaubitz at physik dot fu-berlin.de
CC: ebotcazou at gcc dot gnu.org, jrtc27 at jrtc27 dot com,
matorola at gmail dot com
  Target Milestone: ---
Target: sparc*-*-*

Building the Zero VM (interpreter-type VM) of OpenJDK on SPARC with gcc-8 or
gcc-9 results in the virtual machine segfaulting with:

glaubitz@gcc202:~/openjdk-test/jdk11u-046604d257d7$ gdb
./build/linux-sparcv9-normal-zero-release/jdk/bin/java
GNU gdb (Debian 8.3-1) 8.3
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "sparc64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./build/linux-sparcv9-normal-zero-release/jdk/bin/java...
(No debugging symbols found in
./build/linux-sparcv9-normal-zero-release/jdk/bin/java)
(gdb) r
Starting program:
/home/glaubitz/openjdk-test/jdk11u-046604d257d7/build/linux-sparcv9-normal-zero-release/jdk/bin/java
 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/sparc64-linux-gnu/libthread_db.so.1".
[New Thread 0xfff8000101379900 (LWP 41760)]

Thread 2 "java" received signal SIGBUS, Bus error.
[Switching to Thread 0xfff8000101379900 (LWP 41760)]
0xfff8000100c81098 in SharedRuntime::generate_stubs ()
at
/home/glaubitz/openjdk-test/jdk11u-046604d257d7/src/hotspot/share/runtime/sharedRuntime.cpp:106
106   _resolve_static_call_blob=
generate_resolve_blob(CAST_FROM_FN_PTR(address,
SharedRuntime::resolve_static_call_C),"resolve_static_call");
(gdb) bt
#0  0xfff8000100c81098 in SharedRuntime::generate_stubs ()
at
/home/glaubitz/openjdk-test/jdk11u-046604d257d7/src/hotspot/share/runtime/sharedRuntime.cpp:106
#1  0xfff8000100a570e8 in init_globals ()
at
/home/glaubitz/openjdk-test/jdk11u-046604d257d7/src/hotspot/share/runtime/init.cpp:122
#2  0xfff8000100ccebd0 in Threads::create_vm (args=,
canTryAgain=0xfff8000101378c2f)
at
/home/glaubitz/openjdk-test/jdk11u-046604d257d7/src/hotspot/share/runtime/thread.cpp:3732
#3  0xfff8000100a9d064 in JNI_CreateJavaVM_inner (args=0xfff8000101378d58,
penv=0xfff8000101378d50, 
vm=0xfff8000101378d48)
at
/home/glaubitz/openjdk-test/jdk11u-046604d257d7/src/hotspot/share/prims/jni.cpp:3954
#4  JNI_CreateJavaVM (vm=0xfff8000101378d48, penv=0xfff8000101378d50,
args=0xfff8000101378d58)
at
/home/glaubitz/openjdk-test/jdk11u-046604d257d7/src/hotspot/share/prims/jni.cpp:4045
#5  0xfff800010036ba88 in InitializeJVM (ifn=,
penv=0xfff8000101378d50, 
pvm=0xfff8000101378d48)
at
/home/glaubitz/openjdk-test/jdk11u-046604d257d7/src/java.base/share/native/libjli/java.c:1527
#6  JavaMain (_args=)
at
/home/glaubitz/openjdk-test/jdk11u-046604d257d7/src/java.base/share/native/libjli/java.c:414
#7  0xfff8000100251010 in start_thread (arg=0xfff8000101379900) at
pthread_create.c:486
#8  0xfff8000100672154 in __thread_start () at
../sysdeps/unix/sysv/linux/sparc/sparc64/clone.S:78
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)

This can be reproduced on gcc202 with:

$ mkdir openjdk
$ cd openjdk
$ wget https://hg.openjdk.java.net/jdk-updates/jdk11u/archive/tip.zip
$ unzip tip.zip
$ cd jdk11u-*
$ export CC=gcc-9 ; export CXX=g++-9 ; CONF=linux-sparcv9-normal-zero-release
MAKE_VERBOSE=y QUIETLY= LOG=debug make clean CONF=linux-sparcv9-zero-release ;
sh ./configure --with-jvm-variants=zero
--with-boot-jdk=/usr/lib/jvm/java-11-openjdk-sparc64/
--disable-precompiled-headers --disable-warnings-as-errors && make JOBS=64
MAKE_VERBOSE=y QUIETLY= LOG=debug CONF=linux-sparcv9-normal-zero-release
$ ./build/linux-sparcv9-normal-zero-release/jdk/bin/java
Segmentation fault
$

Setting CC=gcc-7 and CXX=g++-7 fixes the problem, so it must be a regression
with gcc-8 and gcc-9.

[Bug middle-end/80824] Missing 'variable-is-used-uninitialized' warning

[gccbugs at dima dot secretsauce.net]

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

--- Comment #2 from Dima Kogan  ---
I just tried this with Debian builds of gcc8 and gcc9: 8.3.0-19 and 9.2.1-8.
This bug still exists in both.