[Bug tree-optimization/78154] memcpy et al can be assumed to return non-null

2016-10-29 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78154

--- Comment #2 from Andrew Pinski  ---
Funny I thought this was fixed already but I was wrong.
Anyways I had posted a patch over 4 years ago for this:
https://gcc.gnu.org/ml/gcc-patches/2012-09/msg00056.html

IIRC the reason why I wrote this patch was to fix some missed optimizations
while compiling the linux kernel on MIPS64 but I can't remember what I turned
on in the config to produce this kind of code.

[Bug fortran/78152] coarray and associate

2016-10-29 Thread kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78152

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from kargl at gcc dot gnu.org ---
I may have a patch for this, but I need to check on
what attributes the associate entity acquires from
it selector.

[Bug c++/77948] Option processing of -std=c++11 -std=gnu++11 doesn't reset ext_numeric_literals

2016-10-29 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77948

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 39919
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39919&action=edit
gcc7-pr77948-1.patch

Possible untested fix.

[Bug c++/77948] Option processing of -std=c++11 -std=gnu++11 doesn't reset ext_numeric_literals

2016-10-29 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77948

--- Comment #3 from Jakub Jelinek  ---
Created attachment 39920
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39920&action=edit
gcc7-pr77948-2.patch

Alternate patch.  As the gcc/g++ drivers reorder options (-std=*, present
anywhere on the command line, come before -f* options) passed to cc1plus, the
effects of the two patches should be the same unless cc1plus is invoked
manually and -f{,no-}ext-numeric-literals comes before -std=* options.  I'll
test the latter patch first.

[Bug sanitizer/78158] New: Strange data race detection with thread sanitizer

2016-10-29 Thread morandidodo at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78158

Bug ID: 78158
   Summary: Strange data race detection with thread sanitizer
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: morandidodo at gmail 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: ---

I am having an issue with the following piece of code:

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

using namespace std::chrono_literals;

static std::atomic_bool writing_locked = {false};
static std::atomic_int readers = {0};
static std::mutex mutex;
static std::atomic_bool loading = {false};

long double tester = 345.7654;

void fun()
{
static constexpr unsigned iterations = 1000;
long double local_tester = 0.;

for(unsigned iteration = 0;;)
{
if(not writing_locked)
{
int local_readers = readers;
if(local_readers < 0)
{
std::lock_guard lock(mutex);
continue;
}

if(not readers.compare_exchange_weak(local_readers, local_readers +
1))
continue;
}
else
{
std::lock_guard lock(mutex);
continue;
}

assert(readers > 0);

for(unsigned i = 0; i < 1000; ++i)
local_tester += std::log(tester); /* This line is said to race...
*/

assert(readers > 0);
--readers;

if(static_cast(local_tester) % 500 == 0)
{
bool current_loading = false;
if(loading.compare_exchange_strong(current_loading, true))
{
std::lock_guard lock(mutex);
writing_locked = true;

int zero_readers = 0;
do
{
zero_readers = 0;
} while(not readers.compare_exchange_weak(zero_readers, -1));

assert(readers == -1);

for(unsigned i = 0; i < 100; ++i)
tester = std::sqrt(std::pow(tester, 2) + 1); /* ...with
this line */

assert(readers == -1);

readers = 0;
writing_locked = false;

loading = false;
}
} else if(iteration++ >= iterations)
return;
}
}

int main()
{
static const unsigned max_threads = std::thread::hardware_concurrency();
std::vector threads(max_threads);
for(unsigned i = 0; i < max_threads; ++i)
threads[i] = std::thread(fun);

for(unsigned i = 0; i < max_threads; ++i)
threads[i].join();
}

IMHO there should not be any race in this code, but if it is compiled with
-fsanitize=thread, a data race is found between the two lines commented, but
only when NDEBUG is defined. clang does not warn about any issue.
I thought that it could be related to bug 68260, but I just compiled the last
version from Git and the problem is still there.

[Bug tree-optimization/78148] [7 Regression] r241649 causes -fcompare-debug failure on ppc64le

2016-10-29 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78148

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-10-29
 CC||jakub at gcc dot gnu.org
  Component|target  |tree-optimization
 Ever confirmed|0   |1

[Bug tree-optimization/78148] [7 Regression] r241649 causes -fcompare-debug failure on ppc64le

2016-10-29 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78148

--- Comment #1 from Jakub Jelinek  ---
Created attachment 39921
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39921&action=edit
gcc7-pr78148.patch

Untested fix.  Hopefully it will also fix the ada bootstrap failure on
x86_64-linux.

[Bug target/78105] ICE during LTO bootstrap on AARCH64 with gold linker

2016-10-29 Thread tulipawn at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78105

PeteVine  changed:

   What|Removed |Added

Summary|ICE during LTO bootstrap on |ICE during LTO bootstrap on
   |AARCH64 with extra options  |AARCH64 with gold linker

--- Comment #11 from PeteVine  ---
Ok, it was neither about binutils, nor special flags. I was able to complete
the build using 2.27 and full flags, provided ld.bfd was used and
--with-checking=release was never used.

The latter option was leading to discrepancies on 32/64-bit ARM platforms.

[Bug tree-optimization/78148] [7 Regression] r241649 causes -fcompare-debug failure on ppc64le

2016-10-29 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78148

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Sat Oct 29 15:55:50 2016
New Revision: 241679

URL: https://gcc.gnu.org/viewcvs?rev=241679&root=gcc&view=rev
Log:
PR target/78148
* gimple-ssa-store-merging.c
(imm_store_chain_info::output_merged_store): Use build_aligned_type
instead of SET_TYPE_ALIGN on shared integral type.

* gcc.dg/pr78148.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr78148.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-store-merging.c
trunk/gcc/testsuite/ChangeLog

[Bug gcov-profile/78086] FAIL: gcc.misc-tests/gcov-1.c, etc

2016-10-29 Thread danglin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78086

--- Comment #7 from John David Anglin  ---
The proposed patch fixes all the gcov tests.

[Bug ada/78159] New: a-teioed.adb:2724:4: error: alignment of array elements is greater than element size

2016-10-29 Thread danglin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78159

Bug ID: 78159
   Summary: a-teioed.adb:2724:4: error: alignment of array
elements is greater than element size
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa-unknown-linux-gnu
Target: hppa-unknown-linux-gnu
 Build: hppa-unknown-linux-gnu

/home/dave/gnu/gcc/objdir/./gcc/xgcc -B/home/dave/gnu/gcc/objdir/./gcc/
-B/home/
dave/opt/gnu/gcc/gcc-7/hppa-linux-gnu/bin/
-B/home/dave/opt/gnu/gcc/gcc-7/hppa-l
inux-gnu/lib/ -isystem /home/dave/opt/gnu/gcc/gcc-7/hppa-linux-gnu/include
-isys
tem /home/dave/opt/gnu/gcc/gcc-7/hppa-linux-gnu/sys-include-c -g -O2  -fPIC 
 -W -Wall -gnatpg -nostdinc   a-tienio.adb -o a-tienio.o
checking for alarm... a-teioed.adb: In function
‘Ada.Text_Io.Editing.To_Picture’
:
a-teioed.adb:2724:4: error: alignment of array elements is greater than element 
size
a-teioed.adb: In function ‘Ada.Text_Io.Editing.Valid’:
a-teioed.adb:2751:4: error: alignment of array elements is greater than element 
size
../gcc-interface/Makefile:295: recipe for target 'a-teioed.o' failed
make[7]: *** [a-teioed.o] Error 1

dave@mx3210:~/gnu/gcc/objdir/gcc$ ./xgcc -B./ -v
Reading specs from ./specs
COLLECT_GCC=./xgcc
COLLECT_LTO_WRAPPER=./lto-wrapper
Target: hppa-linux-gnu
Configured with: ../gcc/configure --with-gnu-as --with-gnu-ld --enable-shared
--enable-multiarch --enable-linker-build-id --build=hppa-linux-gnu
--host=hppa-linux-gnu --target=hppa-linux-gnu
--prefix=/home/dave/opt/gnu/gcc/gcc-7 --with-local-prefix=/home/dave/opt/gnu
--enable-threads=posix --enable-__cxa_atexit --build=hppa-linux-gnu
--enable-clocale=gnu --enable-checking=release
--enable-languages=c,c++,objc,fortran,obj-c++,ada,lto,go : (reconfigured)
../gcc/configure --with-gnu-as --with-gnu-ld --enable-shared --enable-multiarch
--enable-linker-build-id --build=hppa-linux-gnu --host=hppa-linux-gnu
--target=hppa-linux-gnu --prefix=/home/dave/opt/gnu/gcc/gcc-7
--with-local-prefix=/home/dave/opt/gnu --enable-threads=posix
--enable-__cxa_atexit --build=hppa-linux-gnu --enable-clocale=gnu
--enable-checking=release
--enable-languages=c,c++,objc,fortran,obj-c++,ada,lto,go
Thread model: posix
gcc version 7.0.0 20161029 (experimental) [trunk revision 241674] (GCC) 

r241609 was okay.

[Bug ada/78159] a-teioed.adb:2724:4: error: alignment of array elements is greater than element size

2016-10-29 Thread sch...@linux-m68k.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78159

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #1 from Andreas Schwab  ---
Fixed by r241679.

[Bug c++/78160] New: explicit template instantation with hidden symbols fails

2016-10-29 Thread gcc at ebasoft dot com.pl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78160

Bug ID: 78160
   Summary: explicit template instantation with hidden symbols
fails
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at ebasoft dot com.pl
  Target Milestone: ---

Created attachment 39922
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39922&action=edit
full source code with CMake configuration

When some template struct is specialized in shared library on other type that
has hidden visibility it passes compilation but no code is generated.
This causes missing symbols in library. If base type is required to be default
visible it should fail at compilation stage with error instead of causing hard
to understand source of problems.

I reproducted this error on gcc 5.4.1, 6.2.0

//Example code (full cmake project attached)
///LIBRARY HEADER some_shared.h
//--
#include 
#include 

#define visibility_hidden __attribute__((visibility("hidden")))
#define visibility_default __attribute__((visibility("default")))

struct visibility_default base_spec_char
  {
  using value_type  = char;
  char foo[10];
  };

//SPECIALIZING ON THIS TYPE WILL CAUSE MISSING CODE AND SYMBOLS
struct visibility_hidden base_spec_uint8
  {
  using value_type  = uint8_t;
  uint8_t foo[20];
  };

template
struct visibility_default var_t
  {
  using var_store_t = VarStoreType;
  using value_type  = typename var_store_t::value_type;

  std::unique_ptr alloc();
  };
using varchar_t = var_t;
using varbinary_t = var_t;

///LIBRARY SOURCE
//--
#include "some_shared.h"

template
std::unique_ptr::var_store_t>
 var_t::alloc( )
  {
  return std::make_unique();
  }

template struct var_t;
template struct var_t;

//MAIN PROGRAM LINKED TO SHARED LIBRARY
#include 
#include "some_shared.h"

int main(int argc, char **argv) 
  {
  varchar_t foo;
  varbinary_t bar;

  auto obj = foo.alloc();
  auto obj2 = bar.alloc(); //<- unresolved symbols
  std::cout << "Hello, world!"<< obj.get()<< obj2.get() << std::endl;
  return 0;
  }
main.cpp:10: undefined reference to `var_t::alloc()'

[Bug libstdc++/78156] constexpr basic_string_view::basic_string_view(const charT *) calls non-constexpr char_traits::length

2016-10-29 Thread daniel.kruegler at googlemail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78156

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
Strictly speaking, the provided example doesn't reveal a defect in the existing
implementation.

Changing char_traits::length to be constexpr would be non-conforming (at least
an extension), albeit one could argue that an implementation *could* decide to
implement std::string_view::string_view(const char*) [but only this specific
constructor] in a way where a built-in would be used (very similar as you
describe), whose semantics would be equivalent to calling
std::char_traits::length, since the existing wording does only impose
post-conditions and requirements imposed on user-input, it doesn't require
specifically the usage of std::char_traits::length (given the specific
type char). For user-defined traits and character types there would be no
alternative, though. But all this is just QoI and no requirement. 

As a user you could provide your own hand-rolled fully constexpr character
trait class and instantiate basic_string_view with that one or you could write
a constexpr helper function that uses a constexpr length function and returns a
std::string_view object by internally calling the
std::string_view::string_view(const char*, size_type) constructor instead.

Note that there exists an open library evolution issue related to that:

http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2232

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

2016-10-29 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77919

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Sat Oct 29 20:22:36 2016
New Revision: 241681

URL: https://gcc.gnu.org/viewcvs?rev=241681&root=gcc&view=rev
Log:
PR rtl-optimization/77919
* expr.c (expand_expr_real_1) : Only avoid forcing
into memory if both modes are complex and their inner modes have the
same precision.  If the two modes are different complex modes, convert
each part separately and generate a new CONCAT.

* g++.dg/torture/pr77919-2.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr77919-2.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/expr.c
trunk/gcc/testsuite/ChangeLog

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

2016-10-29 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77919

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[5/6/7 Regression] ICE  |[5/6 Regression] ICE
   |converting DC to V2DF mode  |converting DC to V2DF mode

--- Comment #9 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug tree-optimization/78148] [7 Regression] r241649 causes -fcompare-debug failure on ppc64le

2016-10-29 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78148

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Fixed.

[Bug rtl-optimization/78132] [7 Regression] GCC produces invalid instruction (kmovd and kmovq) for KNL.

2016-10-29 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78132

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Fixed.

[Bug libstdc++/78156] constexpr basic_string_view::basic_string_view(const charT *) calls non-constexpr char_traits::length

2016-10-29 Thread suokkos at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78156

--- Comment #2 from Pauli  ---
Maybe this isn't exactly defect. But constexpr is hard beast to get right in
any code.

For user code simplest workaround would be remembering to use operator""sv
everywhere. Too bad accessing those operator seems to be hard. I guess I need
configure time check for that and provide my own fallback if the sv operator is
missing.

[Bug middle-end/78025] [5/6 Regression] ICE in simd_clone_adjust, at omp-simd-clone.c:1126

2016-10-29 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78025

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[5/6/7 Regression] ICE in   |[5/6 Regression] ICE in
   |simd_clone_adjust, at   |simd_clone_adjust, at
   |omp-simd-clone.c:1126   |omp-simd-clone.c:1126

--- Comment #5 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug fortran/77872] [5/6/7 Regression] ICE in gfc_conv_descriptor_token, at fortran/trans-array.c:305

2016-10-29 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77872

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||burnus at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
This started to ICE with r209953.
And the second change is indeed r212299.

[Bug fortran/77871] [5/6/7 Regression] ICE in gfc_get_caf_token_offset, at fortran/trans-expr.c:1981

2016-10-29 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77871

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Indeed, started to ICE with r211748.

[Bug other/78161] New: contrib/download_prerequisites fails on MacOS, Lubuntu, and Windows

2016-10-29 Thread damian at sourceryinstitute dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78161

Bug ID: 78161
   Summary: contrib/download_prerequisites fails on MacOS,
Lubuntu, and Windows
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: damian at sourceryinstitute dot org
  Target Milestone: ---

The latest contrib/download_prerequisites fails on every operating system on
which I've tried it, including the following:

MacOS 10.12 (Sierra)
Lubuntu Linux 16.04
Windows 10 Ubuntu subsystem (beta)

In each case, the curl command in the script appears to be spewing a binary
into stdout rather than to the intended file destination.  I'm working on a
patch to fix this and will submit it for review.  In the patch, I would like to
broaden the download program options to choose the first available in the
following order:

1. curl
2. wget
3. ftp

These will be tested with a condition such as

if type curl &> /dev/null then
  fetch=curl
elif type wget &> /dev/null then
  fetch=wget
elif type ftp &> /dev/null then
  fetch=ftp-url
fi

where ftp-url is a short script written to use ftp for anonymous download of
the target file and where the appropriate arguments will be added for each
download program before invoking it.  I'll test the script on the
aforementioned three operating systems before submitting it.

Damian

[Bug debug/78112] [7 regression] invalid DWARF generated by the compiler: DIE has multiple AT_inline attributes

2016-10-29 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78112

--- Comment #8 from Jakub Jelinek  ---
Created attachment 39923
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39923&action=edit
pr78112.ii

Reduced testcase, on x86_64-linux with -g -dA one can see on a single DIE (so
it isn't just DW_AT_inline, but also DW_AT_object_pointer):
.uleb128 0x22   # (DIE (0x4ab) DW_TAG_subprogram)
.long   0x184   # DW_AT_specification
.byte   0   # DW_AT_inline
.long   0x4be   # DW_AT_object_pointer
.byte   0   # DW_AT_inline
.long   0x4be   # DW_AT_object_pointer
.long   0x55f   # DW_AT_sibling
The DW_AT_specification for this is:
.uleb128 0xb# (DIE (0x184) DW_TAG_subprogram)
# DW_AT_external
.long   .LASF26 # DW_AT_name: "_Hashtable"
.byte   0x1 # DW_AT_decl_file (pr78112.ii)
.byte   0x7f# DW_AT_decl_line
.long   .LASF28 # DW_AT_linkage_name:
"_ZNSt10_HashtableIiSt4pairIKiiE41Trans_NS___gnu_test_propagating_allocatorIiSaIiEENSt8__detail10_Select1stEiiNS6_18_Mod_range_hashingENS6_20_Default_ranged_hashENS6_20_Prime_rehash_policyENS6_17_Hashtable_traitsEEC4ERKSC_"
# DW_AT_declaration
.long   0x197   # DW_AT_object_pointer
.long   0x1a2   # DW_AT_sibling

[Bug c++/63349] ICE with template in get_narrower fold-const.c

2016-10-29 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63349

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||7.0
 Resolution|--- |FIXED

--- Comment #6 from Andrew Pinski  ---
Fixed on the trunk, I don't know by what.

[Bug tree-optimization/78162] New: ICE on invalid code at -Os and above on x86_64-linux-gnu: Segmentation fault

2016-10-29 Thread su at cs dot ucdavis.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78162

Bug ID: 78162
   Summary: ICE on invalid code at -Os and above on
x86_64-linux-gnu: Segmentation fault
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

This is a regression from 6.2.x.

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-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 20161030 (experimental) [trunk revision 241684] (GCC) 
$ 
$ gcc-trunk -O1 -c small.c
$ gcc-6.2 -Os -c small.c
$ 
$ gcc-trunk -Os -c small.c
small.c: In function ‘fn1’:
small.c:3:6: internal compiler error: Segmentation fault
 void fn1()
  ^~~
0xbedacf crash_signal
../../gcc-source-trunk/gcc/toplev.c:338
0x12dfed1 vec::operator[](unsigned int)
../../gcc-source-trunk/gcc/vec.h:732
0x12dfed1 vec::operator[](unsigned int)
../../gcc-source-trunk/gcc/vec.h:1216
0x12dfed1 get_alias_type_for_stmts
../../gcc-source-trunk/gcc/gimple-ssa-store-merging.c:941
0x12dfed1 output_merged_store
../../gcc-source-trunk/gcc/gimple-ssa-store-merging.c:1129
0x12dfed1 output_merged_stores
../../gcc-source-trunk/gcc/gimple-ssa-store-merging.c:1213
0x12dfed1 terminate_and_process_chain
../../gcc-source-trunk/gcc/gimple-ssa-store-merging.c:1251
0x12dfed1 terminate_and_release_chain
../../gcc-source-trunk/gcc/gimple-ssa-store-merging.c:833
0x12e0d38 terminate_all_aliasing_chains
../../gcc-source-trunk/gcc/gimple-ssa-store-merging.c:811
0x12e120e execute
../../gcc-source-trunk/gcc/gimple-ssa-store-merging.c:1456
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ 


---


int a, b[1][2]; 

void fn1() 
{
  for (a = 0; a < 2; a++)
b[-1][a] = 0;
}

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

2016-10-29 Thread coollpe at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77538

--- Comment #10 from peien luo  ---
It's a centOS7, kernel has been updated to 3.10.0-327.36.3.el7.x86_64, the
problem still occurs. Some new findings:

1, With gcc 4.8.5, it runs fine for this specific case.
2, With gcc 4.9.4, it stucks at some point, the ps says:
$ ps -flp 13600
F S UID PID   PPID  C PRI  NI ADDR SZ WCHAN  STIME TTY  TIME
CMD
0 D god   13600  13597 89  80   0 - 26038299885 exit 23:15 pts/9 00:15:28
./test_metaserver
3, With gdb, it runs OK by 'set disable-randomization off' it runs ok as well.
(I need to check it again)

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

2016-10-29 Thread coollpe at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77538

--- Comment #11 from peien luo  ---
Sorry for the previous comment regarding running in gdb. the result seems to be
random:

Sometimes it can runs fine
Sometimes it gets a SEGFAULT in calling to a function, gdb says:
   0x7ff0fa19b466 <+22>:lea-0x100060(%rbp),%rbx
   0x7ff0fa19b46d <+29>:sub$0x1000d8,%rsp
=> 0x7ff0fa19b474 <+36>:mov%rdi,-0x1000d8(%rbp)
   0x7ff0fa19b47b <+43>:mov0x8(%rbp),%rdi
   0x7ff0fa19b47f <+47>:mov%rdx,-0x1000e0(%rbp)
   0x7ff0fa19b486 <+54>:mov%rcx,-0x1000f0(%rbp)
   0x7ff0fa19b48d <+61>:mov%r8,-0x1000e8(%rbp)
   0x7ff0fa19b494 <+68>:callq  0x7ff0f9e12e00
<__tsan_func_entry(void*)>
   0x7ff0fa19b499 <+73>:mov%r15,%rax
   0x7ff0fa19b49c <+76>:add$0x30,%rax
   0x7ff0fa19b4a0 <+80>:mov%rax,%rdi
   0x7ff0fa19b4a3 <+83>:mov%rax,-0x1000c8(%rbp)
   0x7ff0fa19b4aa <+90>:callq  0x7ff0f9e1c7e0
<__interceptor_pthread_mutex_lock(void*)>
   0x7ff0fa19b4af <+95>:mov%rbx,%rdi
   0x7ff0fa19b4b2 <+98>:callq  0x7ff0f9e12020
<__tsan_vptr_update(void**, void*)>

[Bug target/62191] extra shift generated for vector integer division by constant 2

2016-10-29 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62191

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug middle-end/62206] Gcc doesn't optimize methods in template class, even when they don't depend on the template variable

2016-10-29 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62206

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|c++ |middle-end
 Resolution|--- |FIXED
   Target Milestone|--- |5.0

--- Comment #4 from Andrew Pinski  ---
Fixed in GCC 5 at least