[Bug tree-optimization/78317] "if (x & constant) z |= constant" should not be rendered with jumps and conditional moves

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||TREE
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-12
  Component|middle-end  |tree-optimization
 Ever confirmed|0   |1

--- Comment #3 from Andrew Pinski  ---
.

[Bug ipa/78309] [7 Regression] ICE: in get_hash, at ipa-icf.c:2124

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |7.0
Summary|ICE: in get_hash, at|[7 Regression] ICE: in
   |ipa-icf.c:2124  |get_hash, at ipa-icf.c:2124

[Bug rtl-optimization/78325] [7 regression] r235825 causes gcc.target/mips/call-5.c, gcc.target/mips/call-6.c R_MIPS_JALR failures

[ma...@linux-mips.org]

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

--- Comment #1 from Maciej W. Rozycki  ---
NB the notes are added by `mips_legitimize_move'.

Re: Weird Error with Hashtable Code for Assignment(Maybe Compiler Bug)

[Andrew Pinski]

On Fri, Nov 11, 2016 at 10:30 PM, nick  wrote:
> Greetings Gcc Folks,
> Either this is me doing something very simple in a school assignment for 
> creating a basic hashtable
> or a compiler bug. I am currently seeing this error during my tables run on 
> copy constructor call during
> the tester and have set to find out why it doesn't work. After some googling 
> it seems either I am doing
> string pointer to string swaps.

This should have gone to gcc-help@ rather than here.  This mailing
list is more for the automated emails from bugzilla.

Anyways I think the problem is you assume:
new Record*[N];

Will NULL out the array.  It does not.

Thanks,
Andrew


> or it's a compiler bug. This is the error I am getting after running in gdb 
> with backtrace:
> Program received signal SIGSEGV, Segmentation fault.
> 0x77b769bb in std::__cxx11::basic_string std::char_traits, std::allocator 
> >::basic_string(std::__cxx11::basic_string std::allocator > const&) ()
>from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> (gdb) backtrace
> #0  0x77b769bb in std::__cxx11::basic_string std::char_traits, std::allocator 
> >::basic_string(std::__cxx11::basic_string std::allocator > const&) ()
>from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> #1  0x004067f6 in HashTable::Record::getKey() const ()
> #2  0x004060ee in HashTable::HashTable(HashTable const&) ()
> #3  0x00403cab in main ()
> This is the complete code for the project:
> #include 
> #include 
> #include
> using namespace std;
> /*The functions I updated for Simple Table are
> 1.search
> 2.grow
> 3.update
> 4.Both Copy Constructor and Copy Assignment
> 5.Destructor
> */
> template 
> class Table {
> public:
> Table() {}
> virtual bool update(const string& key, const TYPE& value) = 0;
> virtual bool remove(const string& key) = 0;
> virtual bool find(const string& key, TYPE& value) = 0;
> virtual ~Table() {}
> };
>
> template 
> class SimpleTable :public Table {
>
> struct Record {
> TYPE data_;
> string key_;
> Record(const string& key, const TYPE& data) {
> key_ = key;
> data_ = data;
> }
>
> };
>
> Record** records_;   //the table
> int max_;   //capacity of the array
> int size_;  //current number of records held
> int search(const string& key);
> void sort();
> void grow();
> public:
> SimpleTable(int maxExpected);
> SimpleTable(const SimpleTable& other);
> SimpleTable(SimpleTable&& other);
> virtual int numRecords();
> virtual bool isEmpty();
> virtual bool update(const string& key, const TYPE& value);
> virtual bool remove(const string& key);
> virtual bool find(const string& key, TYPE& value);
> virtual const SimpleTable& operator=(const SimpleTable& other);
> virtual const SimpleTable& operator=(SimpleTable&& other);
> virtual ~SimpleTable();
> };
>
>
> //returns index of where key is found.
> template 
> int SimpleTable::search(const string& key) {
> int rc = -1;
> for (int i = 0; i if (records_[i]->key_ == key) {
> rc = i;
> break;
> }
> }
> return rc;
> }
> //checks if array is empty
> template 
> bool SimpleTable::isEmpty(){
> return size_==0;
> }
> template 
> //return size of array
> int SimpleTable::numRecords(){
> return size_;
> }
> //sort the according to key in table
> template 
> void SimpleTable::sort() {
> int minIdx = 0;
> for (int i = 0; i minIdx = i;
> for (int j = i + 1; j if (records_[j]->key_ < records_[minIdx]->key_) {
> minIdx = j;
> }
> }
> Record* tmp = records_[i];
> records_[i] = records_[minIdx];
> records_[minIdx] = tmp;
> }
> }
>
> //grow the array by one element
> template 
> void SimpleTable::grow() {
> Record** newArray = new Record*[max_ + 1];
> max_ = max_ + 1;
> for (int i = 0; i newArray[i] = records_[i];
> }
> records_ = std::move(newArray);
> }
>
> /* none of the code in the function definitions below are correct.  You can 
> replace what you need
> */
> template 
> SimpleTable::SimpleTable(int maxExpected) : Table() {
> records_ = new Record*[maxExpected];
> max_ = maxExpected;
> size_ = 0;
> }
>
> template 
> SimpleTable::SimpleTable(const SimpleTable& other) {
> records_ = new Record*[other.max_];
>

Weird Error with Hashtable Code for Assignment(Maybe Compiler Bug)

[nick]

Greetings Gcc Folks,
Either this is me doing something very simple in a school assignment for 
creating a basic hashtable
or a compiler bug. I am currently seeing this error during my tables run on 
copy constructor call during
the tester and have set to find out why it doesn't work. After some googling it 
seems either I am doing
string pointer to string swaps.
or it's a compiler bug. This is the error I am getting after running in gdb 
with backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x77b769bb in std::__cxx11::basic_string::basic_string(std::__cxx11::basic_string const&) ()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(gdb) backtrace
#0  0x77b769bb in std::__cxx11::basic_string::basic_string(std::__cxx11::basic_string const&) ()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x004067f6 in HashTable::Record::getKey() const ()
#2  0x004060ee in HashTable::HashTable(HashTable const&) ()
#3  0x00403cab in main ()
This is the complete code for the project:
#include 
#include 
#include
using namespace std;
/*The functions I updated for Simple Table are
1.search
2.grow
3.update
4.Both Copy Constructor and Copy Assignment
5.Destructor
*/
template 
class Table {
public:
Table() {}
virtual bool update(const string& key, const TYPE& value) = 0;
virtual bool remove(const string& key) = 0;
virtual bool find(const string& key, TYPE& value) = 0;
virtual ~Table() {}
};

template 
class SimpleTable :public Table {

struct Record {
TYPE data_;
string key_;
Record(const string& key, const TYPE& data) {
key_ = key;
data_ = data;
}

};

Record** records_;   //the table
int max_;   //capacity of the array
int size_;  //current number of records held
int search(const string& key);
void sort();
void grow();
public:
SimpleTable(int maxExpected);
SimpleTable(const SimpleTable& other);
SimpleTable(SimpleTable&& other);
virtual int numRecords();
virtual bool isEmpty();
virtual bool update(const string& key, const TYPE& value);
virtual bool remove(const string& key);
virtual bool find(const string& key, TYPE& value);
virtual const SimpleTable& operator=(const SimpleTable& other);
virtual const SimpleTable& operator=(SimpleTable&& other);
virtual ~SimpleTable();
};


//returns index of where key is found.
template 
int SimpleTable::search(const string& key) {
int rc = -1;
for (int i = 0; ikey_ == key) {
rc = i;
break;
}
}
return rc;
}
//checks if array is empty
template 
bool SimpleTable::isEmpty(){
return size_==0;
}
template 
//return size of array
int SimpleTable::numRecords(){
return size_;
}
//sort the according to key in table
template 
void SimpleTable::sort() {
int minIdx = 0;
for (int i = 0; ikey_ < records_[minIdx]->key_) {
minIdx = j;
}
}
Record* tmp = records_[i];
records_[i] = records_[minIdx];
records_[minIdx] = tmp;
}
}

//grow the array by one element
template 
void SimpleTable::grow() {
Record** newArray = new Record*[max_ + 1];
max_ = max_ + 1;
for (int i = 0; ikey_, other.records_[i]->data_);
}
}
template 
SimpleTable::SimpleTable(SimpleTable&& other) {
size_ = swap(other.size_);
max_ = swap(other.max_);
records_ = swap(other.records_);
}

template 
bool SimpleTable::update(const string& key, const TYPE& value) {
int idx = search(key);
if (idx == -1) {
if (size_ == max_) {
grow();
}

[Bug tree-optimization/78327] Improve VRP for ranges for compares which do ranges of [-TYPE_MAX + N, N]

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-12
Summary|Improve VRP for ranges of   |Improve VRP for ranges for
   |signed integers in the  |compares which do ranges of
   |range [-TYPE_MAX + N, N]|[-TYPE_MAX + N, N]
 Ever confirmed|0   |1

--- Comment #6 from Andrew Pinski  ---
Fine but again anti-ranges is not the issue but not understanding that:
(signed char) ((unsigned char) n + 125) < 0

is the same as n < -125 || 2 < n.

[Bug tree-optimization/78327] Improve VRP for ranges of signed integers in the range [-TYPE_MAX + N, N]

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
In your test case the int variable isn't in the [-TYPE_MAX + N, N] range which
is the one that triggers the bug/limitation (that's why I'd like to keep it in
the summary).  The following test case shows the problem with int for N = 2.

void f (void*);

void g (int n)
{
  if (n < -__INT_MAX__ + 2 || 2 < n) n = 0;

  f (__builtin_alloca (__INT_MAX__ + 1LU + n));
}

[Bug preprocessor/78324] Valgrind issues seen with gcc.dg/tree-ssa/builtin-sprintf-2.c

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

[Bug c++/78330] New: incorrectly accepts invalid C++ code with shadowed template parameter

[su at cs dot ucdavis.edu]

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

Bug ID: 78330
   Summary: incorrectly accepts invalid C++ code with shadowed
template parameter
   Product: gcc
   Version: unknown
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 affects at least as early as 4.8.x till the latest trunk. 


$ 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 2016 (experimental) [trunk revision 242066] (GCC) 
$ 
$ g++-trunk -c test.cpp
$ 
$ icc -c test.cpp
test.cpp(1): error: a template template parameter cannot have the same name as
one of its template parameters
  template < template < class T > class T > class A {}; 
^

compilation aborted for test.cpp (code 2)
$ 


---


template < template < class T > class T > class A {};

[Bug tree-optimization/78327] Improve VRP for ranges of signed integers in the range [-TYPE_MAX + N, N]

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
No it is only types < int. That is char and short.  Please look at my test case
and you will see that the one that does not work is only the char form.

[Bug tree-optimization/78327] Improve VRP for ranges of signed integers in the range [-TYPE_MAX + N, N]

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

Summary|Improve VRP for ranges of   |Improve VRP for ranges of
   |signed char |signed integers in the
   ||range [-TYPE_MAX + N, N]

--- Comment #3 from Martin Sebor  ---
The problem described here isn't specific to signed char but affects all signed
types.  Let's keep that in the subject so as not to suggest otherwise.  I think
mentioning the [-TYPE_MAX + N, N] range is also useful because the problem
doesn't seem to be triggered by values in other ranges.

The relationship to anti-ranges is only in the subject of the email thread I
referenced in comment #0.  Nothing in this bug or in that thread should imply
that they are the root cause of this problem.

[Bug tree-optimization/78327] Improve VRP for ranges of signed char

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|-Walloca-large-than false   |Improve VRP for ranges of
   |positives due to bad range  |signed char
   |info for signed integers in |
   |[-TYPE_MAX + N, N]  |
   Severity|normal  |enhancement

--- Comment #2 from Andrew Pinski  ---
The problem is related to anything described here.

The problem is VRP is not adding an assert in the true case of for n_9 usage:
  :
  n.0_1 = (unsigned char) n_9(D);
  _2 = n.0_1 + 125;
  _3 = (signed char) _2;
  if (_3 < 0)
goto ;
  else
goto ;

  :
  _15 = (int) n_9(D);
  _17 = _15 + 128;
  _19 = (long unsigned int) _17;

  :
  # prephitmp_20 = PHI <_19(3), 128(2)>

-- CUT -
Basically when we look at the if statement of if (_3 < 0) we don't recognize it
is doing ((signed char)(((unsigned char) n_9) + 125)) < 0.

This should be an easy thing to implement in VRP.

Here is a simple testcase without warnings.
void link_failure ();
void g (signed char n)
{
  if (n < -125 || 2 < n) n = 0;

  if ((n + 128) > 130)
link_failure();
}

void h (signed char n)
{
  if (n < -125 || 1 < n) n = 0;

  if ((n + 128) > 129)
link_failure();
}
void g1 (int n)
{
  if (n < -125 || 2 < n) n = 0;

  if ((n + 128) > 130)
link_failure();
}

void h1 (int n)
{
  if (n < -125 || 1 < n) n = 0;

  if ((n + 128) > 129)
link_failure();
}


Again this has nothing to with anti-range as there is no ranges being produced
here by VRP for g.

[Bug c++/78329] New: incorrect debug info for return type deduction C++14

[chihin.ko at oracle dot com]

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

Bug ID: 78329
   Summary: incorrect debug info for return type deduction C++14
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chihin.ko at oracle dot com
  Target Milestone: ---

cat t.cc
class AA {
public:
auto func(int arg) {
int i = 0;
for (; i < arg; i++);
return i;
}
} a;

auto func1(int arg) {
int i = 0;
for (; i < arg; i++);
return i;
}

int main() {
auto res = a.func(5);
res = func1(5);
return 0;
}

The return type of function "func" should resolved to type "int":

< 2><0x0034>  DW_TAG_subprogram
DW_AT_external  yes(1)
DW_AT_name  "func"
DW_AT_decl_file 0x0001
/workspace/chko/ws/dinstall/dbx_test/bugid/2484659
6/g61/t.cc
DW_AT_decl_line 0x0003
DW_AT_linkage_name  "_ZN2AA4funcEi"
DW_AT_type  <0x0054>
DW_AT_accessibility DW_ACCESS_public
DW_AT_declaration   yes(1)
DW_AT_object_pointer<0x0048>
< 3><0x0048>DW_TAG_formal_parameter
  DW_AT_type  <0x0059>
  DW_AT_artificialyes(1)
< 3><0x004d>DW_TAG_formal_parameter
  DW_AT_type  <0x0064>
< 1><0x0054>DW_TAG_unspecified_type
  DW_AT_name  "auto"  <== should resolve to
type "int"

[Bug middle-end/78328] wrong value in -Walloca-larger-than note

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||aldyh at gcc dot gnu.org
   Severity|normal  |minor

[Bug middle-end/78328] New: wrong value in -Walloca-larger-than note

[msebor at gcc dot gnu.org]

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

Bug ID: 78328
   Summary: wrong value in -Walloca-larger-than note
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The -Walloca-larger-than warning prints the wrong maximum value of the
function's argument in its note.  For example, in the following, the argument
can be as large as UINT_MAX but the note prints 13.  This seems to be caused by
the code that tries to handle casts in alloca_call_type where VR_ANTI_RANGE
isn't being handled correctly for ranges resulting from expressions like the
one below (in this case, ~[13, 13]).

$ cat c.c && gcc -O2 -S -Wall -Wextra -Walloca-larger-than=128 c.c
void f (void*);

void g (unsigned n)
{
  if (n == 7 || n == 13) n = 11;
  f (__builtin_alloca (n));
}
c.c: In function ‘g’:
c.c:6:3: warning: argument to ‘alloca’ may be too large [-Walloca-larger-than=]
   f (__builtin_alloca (n));
   ^~~~
c.c:6:3: note: limit is 128 bytes, but argument may be as large as 13

[Bug c++/71225] [7 Regression] Overeager instantiation of members of non-template class nested in class template

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/71225] [7 Regression] Overeager instantiation of members of non-template class nested in class template

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov 11 23:42:25 2016
New Revision: 242328

URL: https://gcc.gnu.org/viewcvs?rev=242328=gcc=rev
Log:
PR c++/71225
* g++.dg/cpp0x/pr71225.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr71225.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/71225] [7 Regression] Overeager instantiation of members of non-template class nested in class template

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
r236486 turned the ICE into rejection:
pr71225.C: In member function ‘void stride_view::adaptor::advance()’:
pr71225.C:23:19: error: call of overloaded ‘clean()’ is ambiguous
 clean();
   ^
pr71225.C:15:14: note: candidate: void stride_view::adaptor::clean() const
[with int _c_11 = 42; typename std::enable_if<((_c_11 == 43) ||
BidirectionalRange()), int>::type  = 0; Rng = Rng]
 void clean() const
  ^
pr71225.C:19:14: note: candidate: void stride_view::adaptor::clean() const
[with int _c_14 = 42; typename std::enable_if<((_c_14 == 43) || (!
BidirectionalRange())), int>::type  = 0; Rng = Rng]
 void clean() const
  ^
and starting with r237654 this is accepted again.

[Bug tree-optimization/78327] -Walloca-large-than false positives due to bad range info for signed integers in [-TYPE_MAX + N, N]

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #1 from Marc Glisse  ---
Already in the original dump, we can see that the comparisons are optimized to
different shapes:

-  if ((signed char) ((unsigned char) n + 125) < 0)
+  if ((unsigned char) n + 125 > 126)

For the second one, VRP knows how to build an assert_expr and interpret the
consequences on n, while for the first one it doesn't. Since we turn nice
comparisons into the first shape, I guess we should teach VRP to recognize it.

[Bug rtl-optimization/59461] missed zero-extension elimination in the combiner

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.0

--- Comment #5 from Eric Botcazou  ---
Fixed in GCC 7.

[Bug rtl-optimization/59461] missed zero-extension elimination in the combiner

[ebotcazou at gcc dot gnu.org]

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

--- Comment #4 from Eric Botcazou  ---
Author: ebotcazou
Date: Fri Nov 11 22:38:33 2016
New Revision: 242326

URL: https://gcc.gnu.org/viewcvs?rev=242326=gcc=rev
Log:
PR rtl-optimization/59461
* doc/rtl.texi (paradoxical subregs): Add missing word.
* combine.c (reg_nonzero_bits_for_combine): Do not discard results
in modes with precision larger than that of last_set_mode.
* rtlanal.c (nonzero_bits1) : If WORD_REGISTER_OPERATIONS is
set and LOAD_EXTEND_OP is appropriate, propagate results from inner
REGs to paradoxical SUBREGs.
(num_sign_bit_copies1) : Likewise.  Check that the mode is not
larger than a word before invoking LOAD_EXTEND_OP on it.

Added:
trunk/gcc/testsuite/gcc.target/sparc/2016-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c
trunk/gcc/doc/rtl.texi
trunk/gcc/rtlanal.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/25071] dummy argument larger than actual argument

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #20 from Jerry DeLisle  ---
(In reply to Dominique d'Humieres from comment #19)
> > Any opinions on this?
> 
> So far 2 for, 0 against. May be the patch can be committed?

Please do if you can, after testing on trunk.

[Bug sanitizer/78294] -fsanitize=thread broken

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #9 from Markus Trippelsdorf  ---
Not a gcc bug, so lets close it.

[Bug tree-optimization/78327] New: -Walloca-large-than false positives due to bad range info for signed integers in [-TYPE_MAX + N, N]

[msebor at gcc dot gnu.org]

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

Bug ID: 78327
   Summary: -Walloca-large-than false positives due to bad range
info for signed integers in [-TYPE_MAX + N, N]
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The following is a test case for the problem brought up in the the thread Re:
anti-ranges of signed variables
(https://gcc.gnu.org/ml/gcc/2016-11/msg00029.html).

In the test case below, n's range in function g is [-125, 2], making the
largest value that (n + 128) can evaluate to and alloca be called with 130. 
Yet -Walloca-larger-than=200 emits a warning for the function with a note
claiming that the computed value may be as large as 255.  That's incorrect.

Recompiling the same test case with -Walloca-larger-than=100 results in a
warning for function h as well (as expected), and with a note correctly
indicating the largest value alloca can be called with there given its range of
[-125, 1]: 129.  (The warning for g still says 255.)

  c.c:14:3: note: limit is 100 bytes, but argument may be as large as 129

The output of -fdump-tree-vrp confirms that the range GCC computes for n in g
is [0, 255], while in h [3, 129].  The same problem seems to affect all signed
integers.


$ cat c.c && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -O2 -S
-Wall -Wextra -Walloca-larger-than=200 c.c
void f (void*);

void g (signed char n)
{
  if (n < -125 || 2 < n) n = 0;

  f (__builtin_alloca (n + 128));
}

void h (signed char n)
{
  if (n < -125 || 1 < n) n = 0;

  f (__builtin_alloca (n + 128));
}

c.c: In function ‘g’:
c.c:7:3: warning: argument to ‘alloca’ may be too large [-Walloca-larger-than=]
   f (__builtin_alloca (n + 128));
   ^~
c.c:7:3: note: limit is 200 bytes, but argument may be as large as 255

[Bug sanitizer/78294] -fsanitize=thread broken

[trippels at gcc dot gnu.org]

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

--- Comment #8 from Markus Trippelsdorf  ---
I've opened https://sourceware.org/bugzilla/show_bug.cgi?id=20805.
It would be good if someone could come up with a small testcase.

[Bug libstdc++/78326] New: incorrect c++ usage in experimental/vector and others? _X_max_align is inaccessible

[mib.bugzilla at gmail dot com]

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

Bug ID: 78326
   Summary: incorrect c++ usage in experimental/vector and others?
_X_max_align is inaccessible
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mib.bugzilla at gmail dot com
  Target Milestone: ---

Hello, I work for Intel on the Intel c++ compiler and our compiler uses the g++
headers when we are compiling on Linux host.  When we compile the
experimental/vector file we are finding a programming problem.  We've also
compiled this construct using the Microsoft visual studio compiler and the
clang compiler, those compilers likewise are not able to process this
construct.

Here's what our compiler reports:
include/c++/6.2.0/experimental/memory_resource(284): error #308: member
"std::experimental::fundamentals_v2::pmr::memory_resource::_S_max_align"
(declared at line 74) is inaccessible
__alignment : _S_max_align);
  ^
  detected during instantiation of "void
*std::experimental::fundamentals_v2::pmr::__resource_adaptor_imp<_Alloc>::do_allocate(std::size_t={unsigned
long}, std::size_t={unsigned long}) [with _Alloc=std::allocator]" 

Using creduce, we created this smaller test case:

icpc -c vecE.cpp -w

vecE.cpp(14): error #308: member "C::_S_max_align" (declared at line 10) is
inaccessible
  size_t __new_size = _S_max_align;
^
  detected during instantiation of "void *D<>::m_fn1() [with
=B::rebind_alloc]"

compilation aborted for vecE.cpp (code 2)
-bash-4.2$ cat !$
cat vecE.cpp
typedef int size_t;
class A;
struct B {
template < typename > using rebind_alloc = A;
};
template < typename > class D;
template < typename > using resource_adaptor = D < B::rebind_alloc < int >>;
class C {
static constexpr size_t
_S_max_align = 0;
};
template < typename > class D:C {
virtual void * m_fn1 () {
size_t __new_size = _S_max_align;
}
};
resource_adaptor < A > __get_default_resource___r;

What do you think, is it possible you could correct this? We see the same
diagnostic in experimental/unordered_set, unordered_map, string, set, regex,
memory_resource, map, list, forward_list, dequeue

Thanks and regards, Melanie Blower

[Bug rtl-optimization/70890] [7 regression] r235660 miscompiles stage2 compiler on ia64

[ma...@linux-mips.org]

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

Maciej W. Rozycki  changed:

   What|Removed |Added

 CC||ma...@linux-mips.org

--- Comment #9 from Maciej W. Rozycki  ---
This has caused PR rtl-optimization/78325.  Perhaps the fix has to be
reverted and a different solution found as the MIPS target does need
these notes for PIC call annotation even though the register is dead.

[Bug rtl-optimization/78325] New: [7 regression] r235825 causes gcc.target/mips/call-5.c, gcc.target/mips/call-6.c R_MIPS_JALR failures

[ma...@linux-mips.org]

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

Bug ID: 78325
   Summary: [7 regression] r235825 causes
gcc.target/mips/call-5.c, gcc.target/mips/call-6.c
R_MIPS_JALR failures
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ma...@linux-mips.org
  Target Milestone: ---
Target: mips-linux-gnu

PR rtl-optimization/70890 fix (r235825) causes REG_EQUIV notes to be
removed from PIC call register loads in the MIPS new ABIs for function
calls to local symbols which use GOT_PAGE/GOT_OFST relocations.  These
notes are used in `mips_pic_call_symbol_from_set' to determine the
actual symbol referred in call insns and use it to produce a suitable
R_MIPS_JALR relocation.  Consequently the relocations are not output
anymore causing these regression test failures:

FAIL: gcc.target/mips/call-5.c   -O2   scan-assembler
\\.reloc\t1f,R_MIPS_JALR,staticfunc\n1:\tjalrc?\t
FAIL: gcc.target/mips/call-5.c   -O3 -g   scan-assembler
\\.reloc\t1f,R_MIPS_JALR,staticfunc\n1:\tjalrc?\t
FAIL: gcc.target/mips/call-5.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none   scan-assembler
\\.reloc\t1f,R_MIPS_JALR,staticfunc\n1:\tjalrc?\t
FAIL: gcc.target/mips/call-5.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects   scan-assembler
\\.reloc\t1f,R_MIPS_JALR,staticfunc\n1:\tjalrc?\t
FAIL: gcc.target/mips/call-6.c   -O2   scan-assembler
\\.reloc\t1f,R_MIPS_JALR,staticfunc\n1:\tjalrc?\t
FAIL: gcc.target/mips/call-6.c   -O3 -g   scan-assembler
\\.reloc\t1f,R_MIPS_JALR,staticfunc\n1:\tjalrc?\t
FAIL: gcc.target/mips/call-6.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none   scan-assembler
\\.reloc\t1f,R_MIPS_JALR,staticfunc\n1:\tjalrc?\t
FAIL: gcc.target/mips/call-6.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects   scan-assembler
\\.reloc\t1f,R_MIPS_JALR,staticfunc\n1:\tjalrc?\t

and the linker cannot perform the branch optimisation intended, which
is especially relevant for function calls to local symbols.  With
r235825 reverted on top of current trunk these regressions are gone.

[Bug ipa/78296] [7 regression] test case gcc.dg/ipa/vrp7.c fails starting with r242032

[kugan at gcc dot gnu.org]

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

kugan at gcc dot gnu.org changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org

--- Comment #2 from kugan at gcc dot gnu.org ---
*** Bug 78316 has been marked as a duplicate of this bug. ***

[Bug ipa/78316] FAIL: gcc.dg/ipa/vrp7.c scan-ipa-dump-times cp "Setting value range of param 0 \\[-10, 9\\]" 1

[kugan at gcc dot gnu.org]

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

kugan at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||kugan at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #3 from kugan at gcc dot gnu.org ---
duplicate.

*** This bug has been marked as a duplicate of bug 78296 ***

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[davmac at davmac dot org]

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

Davin McCall  changed:

   What|Removed |Added

 CC||davmac at davmac dot org

--- Comment #25 from Davin McCall  ---
(In reply to Tim Rentsch from comment #21)
>
> Three:  The "one special guarantee" rule is independent of the
> rules for effective types.  This observation is obviously right
> because effective type rules matter only for access to objects.
> The only objects being accessed under the "one special guarantee"
> rule are guaranteed to have compatible types, which is always
> allowed by effective type rules.

However, the two structures are not compatible types; in a union as per the
example at the head of this PR -

union U {
struct t1 { int m; } s1;
struct t2 { int m; } s2;
};

- the types 'struct t1' and 'struct t2' are not compatible. This line:

p2->m = -p2->m;

- is accessing the active union member (s1) via an incompatible type. From
6.5.2.3:

"A postfix expression followed by the -> operator and an identifier designates
a member of a structure or union object. The value is that of the named member
of the object to which the first expression points"

This makes it IMO clear enough that the structure object is being accessed,
since you can't extract the member of an object without the object existing. If
that were not the case, then you could *always* use p2->m to access the 'm'
member of a 'struct t1' object regardless of the existence of a suitable union
declaration, unless you interpret the "special guarantee" just to mean that the
layout of a C.I.S. need only be identical between two structs if those structs
are part of the same union. In that case however there is no reason for
visibility of the union to matter at point of access, since the struct layout
surely cannot be different in different parts of the program (i.e. if two
structs are visible in a union anywhere and this forces common layout of the
C.I.S, then the C.I.S must have the same common layout throughout the program;
it doesn't make sense to require visibility of the union declaration to make
use of the "special guarantee").

> Four:  The "one special guarantee" rule is related to the area of
> "type punning" through unions, but seen by WG14 as a separate
> issue relative to the general topic.  This is evident from the
> committee response in DR 257.

It's problematic though that the committee response doesn't really follow from
the text. You cannot access the member of one structure via a pointer to
another structure with the same layout, as I have shown above, due to the
aliasing rules. If you (or WG14) are claiming that the "special guarantee" is
not directly concerned with aliasing, then the only way you could make use of
the rule is anyway via type punning, and the only way we can do that without
violating aliasing rules is to go via the union object, at which point the
question of union declaration visibility is moot.

> Five:  The footnote added in C99 TC3 about type punning is seen
> by WG14 not as a change but just as a clarifying comment noting
> what behavior was intended all along.  This is evident from the
> text and response in DR 283.  Note that Clark Nelson, the author
> of this DR, is a long-standing member of WG14, and the suggested
> revision given in the text was adopted verbatim for the TC.

While I agree that this is what WG14 seem to believe, I see no normative part
of the text which supports the footnote, and I see some parts which contradict
it (such as 6.7.2.1 "The value of at most one of the members can be stored in a
union object at any time" / 6.5.2.3 "The value is that of the named member of
the object to which the first expression points" - if the value of only one
member can be stored, how can the value of any other member be defined?).

[Bug target/78243] incorrect byte offset in vextractuh with -mcpu=power9

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

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

[Bug target/78243] incorrect byte offset in vextractuh with -mcpu=power9

[meissner at gcc dot gnu.org]

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

--- Comment #3 from Michael Meissner  ---
Author: meissner
Date: Fri Nov 11 19:12:12 2016
New Revision: 242317

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

PR target/78243
* config/rs6000/vsx.md (vsx_extract__p9): Correct the
element order for little endian ordering.

* config/rs6000/altivec.md (reduc_plus_scal_): Use
VECTOR_ELT_ORDER_BIG and not BYTES_BIG_ENDIAN to adjust element
number.


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

[Bug preprocessor/78324] New: Valgrind issues seen with gcc.dg/tree-ssa/builtin-sprintf-2.c

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 78324
   Summary: Valgrind issues seen with
gcc.dg/tree-ssa/builtin-sprintf-2.c
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

Seen on x86_64 with r242065.

$ ./xgcc -B. -c ../../src/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-2.c -O2
-fprintf-return-value -fdump-tree-optimized -ftrack-macro-expansion=0 -w
-wrapper valgrind

==9312== Invalid read of size 1
==9312==at 0x1AE9864: cpp_interpret_string_1(cpp_reader*, cpp_string
const*, unsigned long, cpp_string*, cpp_ttype, cpp_string_location_reader*,
cpp_substring_ranges*) (charset.c:1568)
==9312==by 0x1AEA07B: cpp_interpret_string_ranges(cpp_reader*, cpp_string
const*, cpp_string_location_reader*, unsigned long, cpp_substring_ranges*,
cpp_ttype) (charset.c:1744)
==9312==by 0x1AD73F9: get_substring_ranges_for_loc(cpp_reader*,
string_concat_db*, unsigned int, cpp_ttype, cpp_substring_ranges&)
(input.c:1406)
==9312==by 0x1AD74FD: get_source_location_for_substring(cpp_reader*,
string_concat_db*, unsigned int, cpp_ttype, int, int, int, unsigned int*)
(input.c:1449)
==9312==by 0x834BF3: c_get_substring_location(substring_loc const&,
unsigned int*) (c-common.c:864)
==9312==by 0xF237A1: format_warning_va(substring_loc const&, source_range
const*, char const*, int, char const*, __va_list_tag (*) [1])
(substring-locations.c:112)
==9312==by 0xF23AA7: format_warning_at_substring(substring_loc const&,
source_range const*, char const*, int, char const*, ...)
(substring-locations.c:179)
==9312==by 0x1997C15: (anonymous namespace)::format_directive((anonymous
namespace)::pass_sprintf_length::call_info const&, (anonymous
namespace)::format_result*, char const*, unsigned long, (anonymous
namespace)::conversion_spec const&, tree_node*) (gimple-ssa-sprintf.c:1819)
==9312==by 0x1999135: (anonymous
namespace)::pass_sprintf_length::compute_format_length((anonymous
namespace)::pass_sprintf_length::call_info const&, (anonymous
namespace)::format_result*) (gimple-ssa-sprintf.c:2457)
==9312==by 0x1999ECF: (anonymous
namespace)::pass_sprintf_length::handle_gimple_call(gimple_stmt_iterator)
(gimple-ssa-sprintf.c:2775)
==9312==by 0x1999FE3: (anonymous
namespace)::pass_sprintf_length::execute(function*) (gimple-ssa-sprintf.c:2802)
==9312==by 0xDE7523: execute_one_pass(opt_pass*) (passes.c:2388)
==9312==  Address 0xc9bd7e3 is 0 bytes after a block of size 3 alloc'd
==9312==at 0x4A0645D: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==9312==by 0x1B33F17: xmalloc (xmalloc.c:148)
==9312==by 0x1B33FDA: xmemdup (xmemdup.c:37)
==9312==by 0x1AD7303: get_substring_ranges_for_loc(cpp_reader*,
string_concat_db*, unsigned int, cpp_ttype, cpp_substring_ranges&)
(input.c:1385)
==9312==by 0x1AD74FD: get_source_location_for_substring(cpp_reader*,
string_concat_db*, unsigned int, cpp_ttype, int, int, int, unsigned int*)
(input.c:1449)
==9312==by 0x834BF3: c_get_substring_location(substring_loc const&,
unsigned int*) (c-common.c:864)
==9312==by 0xF237A1: format_warning_va(substring_loc const&, source_range
const*, char const*, int, char const*, __va_list_tag (*) [1])
(substring-locations.c:112)
==9312==by 0xF23AA7: format_warning_at_substring(substring_loc const&,
source_range const*, char const*, int, char const*, ...)
(substring-locations.c:179)
==9312==by 0x1997C15: (anonymous namespace)::format_directive((anonymous
namespace)::pass_sprintf_length::call_info const&, (anonymous
namespace)::format_result*, char const*, unsigned long, (anonymous
namespace)::conversion_spec const&, tree_node*) (gimple-ssa-sprintf.c:1819)
==9312==by 0x1999135: (anonymous
namespace)::pass_sprintf_length::compute_format_length((anonymous
namespace)::pass_sprintf_length::call_info const&, (anonymous
namespace)::format_result*) (gimple-ssa-sprintf.c:2457)
==9312==by 0x1999ECF: (anonymous
namespace)::pass_sprintf_length::handle_gimple_call(gimple_stmt_iterator)
(gimple-ssa-sprintf.c:2775)
==9312==by 0x1999FE3: (anonymous
namespace)::pass_sprintf_length::execute(function*) (gimple-ssa-sprintf.c:2802)
==9312== 
==9312== Conditional jump or move depends on uninitialised value(s)
==9312==at 0x1AE9867: cpp_interpret_string_1(cpp_reader*, cpp_string
const*, unsigned long, cpp_string*, cpp_ttype, cpp_string_location_reader*,
cpp_substring_ranges*) (charset.c:1568)
==9312==by 0x1AEA07B: cpp_interpret_string_ranges(cpp_reader*, cpp_string
const*, cpp_string_location_reader*, unsigned long, cpp_substring_ranges*,
cpp_ttype) (charset.c:1744)
==9312==by 0x1AD73F9: get_substring_ranges_for_loc(cpp_reader*,
string_concat_db*, unsigned int, cpp_ttype, cpp_substring_ranges&)

[Bug sanitizer/78294] -fsanitize=thread broken

[trippels at gcc dot gnu.org]

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

--- Comment #7 from Markus Trippelsdorf  ---
Disassembly of libtsan.so.0.0.0:

0006efd0 <_ZN6__tsan10InitializeEPNS_11ThreadStateE>:   
  if (is_initialized)   
   6efd0:   80 3d f5 8f 27 00 00cmpb   $0x0,0x278ff5(%rip)#
2e7fcc <_ZZN6__tsan10InitializeEPNS_11ThreadStateEE14is_initialized>
   6efd7:   74 07   je 6efe0
<_ZN6__tsan10InitializeEPNS_11ThreadStateE+0x10>
   6efd9:   f3 c3   repz retq   
   6efdb:   0f 1f 44 00 00  nopl   0x0(%rax,%rax,1) 
void Initialize(ThreadState *thr) { 
   6efe0:   41 57   push   %r15 
   6efe2:   41 56   push   %r14 
   6efe4:   41 55   push   %r13 
   6efe6:   41 54   push   %r12 
   6efe8:   55  push   %rbp 
   6efe9:   53  push   %rbx 
   6efea:   48 83 ec 48 sub$0x48,%rsp   
  is_initialized = true;
   6efee:   c6 05 d7 8f 27 00 01movb   $0x1,0x278fd7(%rip)#
2e7fcc <_ZZN6__tsan10InitializeEPNS_11ThreadStateEE14is_initialized>
   6eff5:   48 89 7c 24 18  mov%rdi,0x18(%rsp)  
   6effa:   66 48 8d 3d 66 cf 06data16 lea 0x6cf66(%rip),%rdi#
dbf68 <_ZN6__tsan22cur_thread_placeholderE@@Base+0xdbf28>   
   6f001:   00  
cur_thread()->ignore_interceptors++;
   6f002:   66 66 48 e8 16 3d fbdata16 data16 callq 22d20
<__tls_get_addr@plt>
   6f009:   ff  
  SetCheckFailedCallback(TsanCheckFailed);  
   6f00a:   48 8d 3d 6f ce 00 00lea0xce6f(%rip),%rdi# 7be80
<_ZN6__tsan15TsanCheckFailedEPKciS1_yy> 
  SanitizerToolName = "ThreadSanitizer";
   6f011:   48 8d 0d 3b df 03 00lea0x3df3b(%rip),%rcx#
acf53 <_fini+0x35ab> 

vs.

0006d3e0 <_ZN6__tsan10InitializeEPNS_11ThreadStateE>:   
  if (is_initialized)   
   6d3e0:   80 3d 65 7a 47 00 00cmpb   $0x0,0x477a65(%rip)#
4e4e4c <_ZZN6__tsan10InitializeEPNS_11ThreadStateEE14is_initialized>
   6d3e7:   74 07   je 6d3f0
<_ZN6__tsan10InitializeEPNS_11ThreadStateE+0x10>
   6d3e9:   f3 c3   repz retq   
   6d3eb:   0f 1f 44 00 00  nopl   0x0(%rax,%rax,1) 
void Initialize(ThreadState *thr) { 
   6d3f0:   41 57   push   %r15 
   6d3f2:   41 56   push   %r14 
   6d3f4:   41 55   push   %r13 
   6d3f6:   41 54   push   %r12 
   6d3f8:   55  push   %rbp 
   6d3f9:   53  push   %rbx 
   6d3fa:   48 83 ec 48 sub$0x48,%rsp   
  is_initialized = true;
   6d3fe:   c6 05 47 7a 47 00 01movb   $0x1,0x477a47(%rip)#
4e4e4c <_ZZN6__tsan10InitializeEPNS_11ThreadStateEE14is_initialized>
   6d405:   48 89 7c 24 18  mov%rdi,0x18(%rsp)  
   6d40a:   64 48 8b 04 25 00 00mov%fs:0x0,%rax 
   6d411:   00 00   
cur_thread()->ignore_interceptors++;
   6d413:   48 03 05 be a7 26 00add0x26a7be(%rip),%rax#
2d7bd8 <.got+0x7c0> 
  SetCheckFailedCallback(TsanCheckFailed);  
   6d41a:   48 8d 3d 6f ce 00 00lea0xce6f(%rip),%rdi# 7a290
<_ZN6__tsan15TsanCheckFailedEPKciS1_yy> 
  SanitizerToolName = "ThreadSanitizer";
   

[Bug sanitizer/78294] -fsanitize=thread broken

[trippels at gcc dot gnu.org]

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

--- Comment #6 from Markus Trippelsdorf  ---
OK, it looks like a ld.gold bug. I normally always use ld.gold on my system.
However if I build gcc with ld.bfd then everything works fine.

[Bug fortran/77505] Negative character length not treated as LEN=0

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #4 from Steve Kargl  ---
On Fri, Nov 11, 2016 at 04:49:49AM +, elizebethp at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77505
> 
> Elizebeth Punnoose  changed:
> 

Hi Elizebeth,

Just an administrative question at the moment.  Do you have
a copyright assignment for GCC on file with the FSF?

I need to review the standards, but if the standard state
a negative length should be treated as if it is len=0 then
the I think the warning message should be hidden behind
a -fcheck= option.  Perhaps, we can overload -fcheck=bounds
or introduce a new option key -fcheck=charlen.  My reason
is that it can be annoying for standard conforming code 
to issue a warning for standard conforming behavior.

[Bug c++/78323] New: pathological code generation for long logical expression with temporary objects

[froydnj at gcc dot gnu.org]

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

Bug ID: 78323
   Summary: pathological code generation for long logical
expression with temporary objects
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: froydnj at gcc dot gnu.org
  Target Milestone: ---

Created attachment 40030
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40030=edit
logical-or.cpp

Compiling the attached testcase -O2 -std=c++11 reveals a significant disparity
in the code GCC produces versus clang:

froydnj@thor:~$ gcc -O2 -std=c++11 -c logical-or-gcc.cpp 
froydnj@thor:~$ clang -O2 -std=c++11 -c logical-or.cpp  -o logical-or-clang.o
froydnj@thor:~$ size logical-or*.o
   textdata bss dec hex filename
 633354   0   0  633354   9aa0a logical-or-gcc.o
  17628   0   0   1762844dc logical-or-clang.o

That was with GCC 4.9; a colleague tried it with GCC 6.2.0 and got:

   textdata  bss   dechex filename
 591843   80591851  907eb logical-or.o 

which is some kind of improvement, but not enough of one.

I gone over the assembly with a fine-toothed comb or looked at the tree dumps,
but I think GCC is falling into some kind of O(n^2) situation where it sets a
flag for the constructed status of every temporary object after each exit from
the chained condition.

[Bug debug/78322] New: Debug info still present for fully optimized away functions

[dblaikie at gmail dot com]

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

Bug ID: 78322
   Summary: Debug info still present for fully optimized away
functions
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dblaikie at gmail dot com
  Target Milestone: ---

Consider this:

  inline void __attribute__((always_inline)) f1() {
  }
  inline void __attribute__((always_inline)) f2() {
  }
  void f() {
f1();
  }

GCC produces DWARF for f, and for f1 (where f1 has no high/low pc, no
inlined_subroutines referring to it, etc), but no DWARF for f2.

I think f1 and f2 should be the same - or perhaps a flag to allow them to be
treated the same.

If the function has been entirely optimized away, it's pretty close to not
having ever been called & producing DWARF for it doesn't seem to enhance the
user experience. (if it does, having DWARF for f2 would also enhance the user
experience in the same way) & the extra DWARF this produces (referenced types,
their types, etc) could be part of the reason Clang's DWARF is so much smaller
(1/6th of the type information - but due to several other bugs as well, which
I've filed).

[Bug c++/78264] [7 regression] ICE in build_noexcept_spec, at cp/except.c:1196

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Target|i386-pc-solaris2.12,|i386-pc-solaris2.12,
   |sparc-sun-solaris2.12   |sparc-sun-solaris2.12,
   ||x86-64-linux-gnu
   Host|i386-pc-solaris2.12,|i386-pc-solaris2.12,
   |sparc-sun-solaris2.12   |sparc-sun-solaris2.12,
   ||x86-64-linux-gnu
  Build|i386-pc-solaris2.12,|i386-pc-solaris2.12,
   |sparc-sun-solaris2.12   |sparc-sun-solaris2.12,
   ||x86-64-linux-gnu

--- Comment #4 from Aldy Hernandez  ---
Testcase in #2 also fails on x86-64 Linux native.

[Bug debug/78321] New: Fission + type units + compression are suboptimal

[dblaikie at gmail dot com]

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

Bug ID: 78321
   Summary: Fission + type units + compression are suboptimal
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dblaikie at gmail dot com
  Target Milestone: ---

GCC is producing separate (though non-comdat) sections for each type in the
.dwo file when using fission+type units.

There's no need for these to be in separate sections - and it hurts compression
greatly. (this may be one of the reasons Clang's .debug_types.dwo section is
1/6th the size of GCC's in a large example at Google)

It may make merging types a little more efficient - by not having to decompress
the whole set of types to merge in just one/a few types, so there's potentially
a memory/storage tradeoff here.

[Bug debug/78320] New: Excess debug info -fdebug-types-section

[dblaikie at gmail dot com]

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

Bug ID: 78320
   Summary: Excess debug info -fdebug-types-section
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dblaikie at gmail dot com
  Target Milestone: ---

Enabling -fdebug-types-section causes nested type declarations and definitions
to be emitted by GCC, producing substantially more debug info than without this
option.

Consider:

  struct a {
struct inner { };
  } x;
  struct b {
struct inner;
  } y;
  struct b::inner { };
  struct c {
struct inner;
  } z;

without -fdebug-types-section the DWARF contains 3 structures (a, b, c) and no
mention of nested types. With -fdebug-types-section the DWARF contains type
units for all 5 types. (& 'c's definition contains a declaration of 'inner',
where it did not in the baseline/no-type-units case)

At least it should be reasonable to argue that case (b) and (c) could/should be
treated similarly - if 'c' is valid DWARF, containing only the declaration of
inner, then the same representation should be used for 'b', since its inner
type is unused.

Beyond that, I'd argue 'a' could be represented this way too, even if it's not
precisely accurate to the source - it allows the DWARF to be smaller (& is
already what's done in the non-type-unit case).

And beyond /that/, I'd argue to be even closer to the original DWARF, and not
even emit the member type declarations: The set of members is unbounded and a
debugger/DWARF consumer is going to have to check all the definitions anyway
(check out how the DWARF looks for this:

  struct foo {
template
void f() { }
  };
  ... foo().f(); ...

- the type unit contains no mention of 'f' (which is right and proper, in my
opinion) - and the declaration that references the type unit, contains a
declaration of f)

Ultimately, I'd argue that member function templates, implicit special members,
and nested types all be treated in this way - omitted from the type unit, and
included only in the nested declaration. (FWIW, I'm partly arguing from this
perspective because it's how I implemented it in Clang and it seems
tidy/terse/simple to reason about, etc - but I can see some counter arguments)

Including types that are otherwise unreferenced can cause a substantial
increase in debug info (this bug, coupled with PR78265 may be part of the
reason that, for a large program at Google, GCC's (compressed) .debug_types
section in the object files is 500% larger than Clang's... - well, there's a
few other bugs I know of there too, to be fair)

[Bug c++/78264] [7 regression] ICE in build_noexcept_spec, at cp/except.c:1196

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #3 from Aldy Hernandez  ---
Confirmed on a cross build to i386-pc-solaris2.12 with the testcase in comment
#2.

Started with:

commit 56c12fd4ba064759724236ad896232603b8797ed
Author: jason 
Date:   Fri Aug 7 05:44:49 2015 +

Add C++ Concepts TS support.

[Bug sanitizer/78294] -fsanitize=thread broken

[dvyukov at google dot com]

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

--- Comment #5 from Dmitry Vyukov  ---
Markus, how do you configure and build gcc? Is there anything special?

Our tls accesses should not go through __tls_get_addr because we use
initial-exec attribute. __tls_get_addr vs indirect access through got is chosen
by compiler, right? So it's not linker. The question is why does your compiler
chooses to use the call... If I am not mistaken,
__tsan::ScopedInterceptor::ScopedInterceptor should have been already accesses
cur_thread, and that did not crash, which suggests that there is no
__tls_get_addr call.

[Bug sanitizer/77823] [7 Regression] ICE: in ubsan_encode_value, at ubsan.c:137 with -fsanitize=undefined and vector types

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Created attachment 40029
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40029=edit
ubsan-pr77823.patch

Completely untested patch to allow libubsan handling vector types.
Though, not sure if it wouldn't be better to just always compute the sanitized
checks/operations for vectors as scalar, per element, operations.  It would be
certainly more precise, with this patch it would just report say for division
by { 5, 0, -1, 3 } that it is a division by -1 (or division by 0, but not
both).
For the arithmetic signed overflow checks, I think trying to implement it on
vectors might be too hard.  For cheaper tests like testing for shifts (e.g. lhs
< 0, or rhs < 0, or rhs >= bitsize, or division by 0 or by -1, etc.) e.g. SSE2
has pmovmskb instruction where we could check if any vector elements are false
or true, but I think we don't have something like that in GIMPLE IL.

[Bug rtl-optimization/78120] [6/7 Regression] If conversion no longer performed

[ubizjak at gmail dot com]

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

--- Comment #8 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #0)

> typedef unsigned long u64;
> 
> typedef struct {
>   u64 hi, lo;
> } u128;
> 
> static inline u128 add_u128 (u128 a, u128 b)
> {
>   a.lo += b.lo;
>   if (a.lo < b.lo)
> a.hi++;
> 
>   return a;

While not connected to this problem, it has been pointed out that 

a.hi += b.hi;

is missing in the above source, if we want to implement true 128bit addition.

So, if we want to be pedantic, the missing line should be added to the test. It
doesn't change the outcome in any way.

[Bug rtl-optimization/78120] [6/7 Regression] If conversion no longer performed

[bernds at gcc dot gnu.org]

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

--- Comment #7 from Bernd Schmidt  ---
Sorry James, I think these two got mixed up in my memory.

I've attached a candidate patch I'm testing. This tries to make a better effort
to calculate before/after costs for the speed case so we don't rely entirely on
max_seq_cost. I'd be interested in whether it produces good results on ARM (or
even on x86) if someone is set up to run benchmarks.

[Bug rtl-optimization/78120] [6/7 Regression] If conversion no longer performed

[bernds at gcc dot gnu.org]

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

--- Comment #6 from Bernd Schmidt  ---
Created attachment 40028
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40028=edit
Candidate patch

[Bug fortran/50438] [F03] proc pointer to subroutine in structure constructors

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres  ---
> The patch in comment 5 regtests cleanly. However, it only fixes comment 1
> but not comment 0.

Any progress?

[Bug fortran/25071] dummy argument larger than actual argument

[dominiq at lps dot ens.fr]

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

--- Comment #19 from Dominique d'Humieres  ---
> Any opinions on this?

So far 2 for, 0 against. May be the patch can be committed?

[Bug c++/56480] Explicit specialization in a namespace enclosing the specialized template

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug target/78310] ICE: insn does not satisfy its constraints: {*bmi2_rorxdi3_1} with -mbmi2

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #5 from Uroš Bizjak  ---
Fixed everywhere.

[Bug target/78310] ICE: insn does not satisfy its constraints: {*bmi2_rorxdi3_1} with -mbmi2

[uros at gcc dot gnu.org]

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

--- Comment #4 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri Nov 11 17:04:18 2016
New Revision: 242124

URL: https://gcc.gnu.org/viewcvs?rev=242124=gcc=rev
Log:
PR target/78310
* config/i386/i386.md (rotate to rotatex splitter): Avoid overflow
when calculating operand 2.
(rotate to rotatex zext splitter): Ditto.

testsuite/ChangeLog:

PR target/78310
* gcc.target/i386/pr78310.c: New test.


Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr78310.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/i386/i386.md
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug ipa/78316] FAIL: gcc.dg/ipa/vrp7.c scan-ipa-dump-times cp "Setting value range of param 0 \\[-10, 9\\]" 1

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #2 from Dominique d'Humieres  ---
Also on x86_64-apple-darwin16.

[Bug target/78310] ICE: insn does not satisfy its constraints: {*bmi2_rorxdi3_1} with -mbmi2

[uros at gcc dot gnu.org]

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

--- Comment #3 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri Nov 11 16:42:54 2016
New Revision: 242077

URL: https://gcc.gnu.org/viewcvs?rev=242077=gcc=rev
Log:
PR target/78310
* config/i386/i386.md (rotate to rotatex splitter): Avoid overflow
when calculating operand 2.
(rotate to rotatex zext splitter): Ditto.

testsuite/ChangeLog:

PR target/78310
* gcc.target/i386/pr78310.c: New test.


Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/i386/pr78310.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/i386/i386.md
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/78319] New: PASS->FAIL: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line 20)

[thopre01 at gcc dot gnu.org]

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

Bug ID: 78319
   Summary: PASS->FAIL: gcc.dg/uninit-pred-8_a.c bogus warning
(test for bogus messages, line 20)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thopre01 at gcc dot gnu.org
CC: prathamesh3492 at gcc dot gnu.org
  Target Milestone: ---
Target: arm-none-eabi

Created attachment 40027
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40027=edit
Before and after tree dumps for uninit-pred-8_a.c on ARM Cortex-M7

Hi Prathamesh,

gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line 20)
started to fail for arm-none-eabi after your commit r241915 when targeting ARM
Cortex-M7. The test PASS for ARM Cortex-M4 (which share the same ISA with ARM
Cortex-M7).

I'm attaching the tree dump before (good) and after (bad) the commit. Please
let me know if you need anything else to analyse the issue.

Best regards,

Thomas

[Bug target/78310] ICE: insn does not satisfy its constraints: {*bmi2_rorxdi3_1} with -mbmi2

[uros at gcc dot gnu.org]

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

--- Comment #2 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri Nov 11 16:21:52 2016
New Revision: 242076

URL: https://gcc.gnu.org/viewcvs?rev=242076=gcc=rev
Log:
PR target/78310
* config/i386/i386.md (rotate to rotatex splitter): Avoid overflow
when calculating operand 2.
(rotate to rotatex zext splitter): Ditto.

testsuite/ChangeLog:

PR target/78310
* gcc.target/i386/pr78310.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr78310.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog

[Bug testsuite/78318] New: FAIL: g++.dg/pr78112.C scan-assembler-times DW_AT_object_pointer 37

[thopre01 at gcc dot gnu.org]

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

Bug ID: 78318
   Summary: FAIL: g++.dg/pr78112.C scan-assembler-times
DW_AT_object_pointer 37
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thopre01 at gcc dot gnu.org
CC: derodat at adacore dot com, jakub at gcc dot gnu.org
  Target Milestone: ---
Target: arm-none-eabi

Created attachment 40026
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40026=edit
Assembly file produced for g++.dg/pr78112.C targeting ARM Cortex-M3

Hi,

scan-assembler-times DW_AT_object_pointer 37 fails for g++.dg/pr78112.C on
arm-none-eabi targets because there is 38 occurences of DW_AT_object_pointer.
Please find attached the assembly file produced when compiling for ARM
Cortex-M3.

Best regards.

[Bug rtl-optimization/78120] [6/7 Regression] If conversion no longer performed

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #5 from James Greenhalgh  ---
If this is a 6 regression it may be more likely related to Kyrill's work on
if-converting arithmetic instructions ( r227368 and follow-ups) than my cost
work (which only landed for GCC 7) - though I'm sure my cost work won't have
helped as the impact of my changes would likely cause less if-conversion for
x86, which reports branches as cheap and conditional moves as expensive.

My ifcvt work for GCC 6 was more related to multiple sets in a basic block,
which I don't think this testcase requires.

[Bug middle-end/78317] "if (x & constant) z |= constant" should not be rendered with jumps and conditional moves

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Bug 9814 but that was marked as fixed 

[Bug c/78317] "if (x & constant) z |= constant" should not be rendered with jumps and conditional moves

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #1 from Andrew Pinski  ---
I think there is another bug about this already.

[Bug c/78317] New: "if (x & constant) z |= constant" should not be rendered with jumps and conditional moves

[dhowells at redhat dot com]

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

Bug ID: 78317
   Summary: "if (x & constant) z |= constant" should not be
rendered with jumps and conditional moves
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dhowells at redhat dot com
  Target Milestone: ---

Created attachment 40025
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40025=edit
Test code

The following code:

unsigned test1(unsigned x)
{
unsigned z = 0;
if (x & 0x10)
z |= 0x10;
return z;
}

on x86_64 compiled with -Os to:

   0:   89 f8   mov%edi,%eax
   2:   ba 10 00 00 00  mov$0x10,%edx
   7:   83 e0 10and$0x10,%eax
   a:   0f 45 c2cmovne %edx,%eax
   d:   c3  retq   

when what it should probable do is what clang does:

   0:   83 e7 10and$0x10,%edi
   3:   89 f8   mov%edi,%eax
   5:   c3  retq   

as the bit can be transferred by an AND and an OR.

Further, two or more such statements can be combined, for instance:

unsigned test2(unsigned x)
{
unsigned z = 0;
if (x & 0x10)
z |= 0x10;
if (x & 0x40)
z |= 0x40;
return z;
}

but gcc gives the following:

   e:   89 f8   mov%edi,%eax
  10:   ba 10 00 00 00  mov$0x10,%edx
  15:   83 e0 10and$0x10,%eax
  18:   0f 45 c2cmovne %edx,%eax
  1b:   89 c2   mov%eax,%edx
  1d:   83 ca 40or $0x40,%edx
  20:   40 80 e7 40 and$0x40,%dil
  24:   0f 45 c2cmovne %edx,%eax
  27:   c3  retq   

when clang gives:

   6:   83 e7 50and$0x50,%edi
   9:   89 f8   mov%edi,%eax
   b:   c3  retq   


If z isn't passed in, but rather is initialised to another argument, say y:

unsigned test3(unsigned x, unsigned y)
{
unsigned z = y;
if (x & 0x10)
z |= 0x10;
return z;
}

unsigned test4(unsigned x, unsigned y)
{
unsigned z = y;
if (x & 0x10)
z |= 0x10;
if (x & 0x40)
z |= 0x40;
return z;
}

then gcc gives:

0028 :
  28:   89 f2   mov%esi,%edx
  2a:   89 f0   mov%esi,%eax
  2c:   83 ca 10or $0x10,%edx
  2f:   40 80 e7 10 and$0x10,%dil
  33:   0f 45 c2cmovne %edx,%eax
  36:   c3  retq   

0037 :
  37:   89 f2   mov%esi,%edx
  39:   89 f0   mov%esi,%eax
  3b:   83 ca 10or $0x10,%edx
  3e:   40 f6 c7 10 test   $0x10,%dil
  42:   0f 45 c2cmovne %edx,%eax
  45:   89 c2   mov%eax,%edx
  47:   83 ca 40or $0x40,%edx
  4a:   40 80 e7 40 and$0x40,%dil
  4e:   0f 45 c2cmovne %edx,%eax
  51:   c3  retq   

and clang gives:

000c :
   c:   83 e7 10and$0x10,%edi
   f:   09 f7   or %esi,%edi
  11:   89 f8   mov%edi,%eax
  13:   c3  retq   

0014 :
  14:   89 f8   mov%edi,%eax
  16:   83 e0 10and$0x10,%eax
  19:   09 f0   or %esi,%eax
  1b:   83 e7 40and$0x40,%edi
  1e:   09 c7   or %eax,%edi
  20:   89 f8   mov%edi,%eax
  22:   c3  retq   

Both gcc and clang give suboptimal code for test4().  What they should do is:

and$0x50,%edi
or %esi,%edi
mov%edi,%eax
retq

Note that gcc also produces similarly suboptimal output for targets other than
x86_64.

[Bug ipa/78316] FAIL: gcc.dg/ipa/vrp7.c scan-ipa-dump-times cp "Setting value range of param 0 \\[-10, 9\\]" 1

[amker at gcc dot gnu.org]

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

--- Comment #1 from amker at gcc dot gnu.org ---
The gcc is configured as:

configure --target=aarch64-none-elf --prefix=... --with-gmp=... --with-mpfr=...
--with-mpc=... --with-isl=... --with-pkgversion=unknown --disable-shared
--disable-nls --disable-threads --disable-tls --enable-checking=yes
--enable-languages=c,c++ --with-newlib

[Bug ipa/78316] New: FAIL: gcc.dg/ipa/vrp7.c scan-ipa-dump-times cp "Setting value range of param 0 \\[-10, 9\\]" 1

[amker at gcc dot gnu.org]

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

Bug ID: 78316
   Summary: FAIL: gcc.dg/ipa/vrp7.c scan-ipa-dump-times cp
"Setting value range of param 0 \\[-10, 9\\]" 1
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amker at gcc dot gnu.org
  Target Milestone: ---

The new test case introduced by below commit failed on aarch64:

Author: kugan 
Date:   Wed Nov 9 01:44:04 2016 +

Handle unary pass-through jump functions for ipa-vrp
gcc/testsuite/ChangeLog:

2016-11-09  Kugan Vivekanandarajah  

* gcc.dg/ipa/vrp7.c: New test.


gcc/ChangeLog:

2016-11-09  Kugan Vivekanandarajah  

* ipa-cp.c (ipa_get_jf_pass_through_result): Handle unary expressions.
(propagate_vr_accross_jump_function): Likewise.
* ipa-prop.c (ipa_set_jf_unary_pass_through): New.
(load_from_param_1): New.
(load_from_unmodified_param): Factor common part into
load_from_param_1.
(load_from_param): New.
(compute_complex_assign_jump_func): Handle unary expressions.
(ipa_write_jump_function): Likewise.
(ipa_read_jump_function): Likewise.



git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@241990
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug ipa/78309] ICE: in get_hash, at ipa-icf.c:2124

[trippels at gcc dot gnu.org]

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

--- Comment #3 from Markus Trippelsdorf  ---
Yes, your patch seems to fix the issue. Thanks.

[Bug libfortran/78314] [aarch64] ieee_support_halting does not report unsupported fpu traps correctly

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Earnshaw  ---
current code has 

int
support_fpu_trap (int flag)
{
  return support_fpu_flag (flag);
}


In other words, it assumes that if there is a flag for noting that an exception
has occurred, then it is also possible to trap on that flag being changed. 
That's not a valid assumption for AArch64.

[Bug web/78315] New: "Changes" don't explain what "LRA" is

[schnetter at gmail dot com]

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

Bug ID: 78315
   Summary: "Changes" don't explain what "LRA" is
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: schnetter at gmail dot com
  Target Milestone: ---

The page  points to the GCC wiki page
 "LRA by default". However, this page
never explains what "LRA" actually is. Since this wiki page is mentioned so
prominently, it could spend a paragraph explaining the acronym.

[Bug ipa/78309] ICE: in get_hash, at ipa-icf.c:2124

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Created attachment 40024
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40024=edit
Un-tested patch

Can you please Markus test the attached patch?

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

[dominiq at lps dot ens.fr]

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

--- Comment #16 from Dominique d'Humieres  ---
> Also on arm/aarch64.

Also on x86_64-apple-darwin16.

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

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org

--- Comment #15 from amker at gcc dot gnu.org ---
(In reply to Rainer Orth from comment #14)
> Created attachment 40023 [details]
> i386-pc-solaris2.12 assembler output: pr78112.s
> 
> Unfortunately, the new testcase FAILs on both Solaris/SPARC and Solaris/x86:
> 
> FAIL: g++.dg/pr78112.C   scan-assembler-times DW_AT_object_pointer 37
> 
> In both cases (and for either 32 and 64-bit), DW_AT_object_pointer occurs 39
> times instead.  Attaching the Solaris/x86 assembler output.
> 
> I cannot yet tell if this is related to assembler capabilities: still
> waiting for
> bootstrap results with gas instead of as.
> 
>   Rainer

Also on arm/aarch64.

Thanks,
bin

[Bug testsuite/78292] [7 regression] test case gcc.dg/vect/vect-cond-2.c fails starting with r241967

[amker at gcc dot gnu.org]

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

--- Comment #4 from amker at gcc dot gnu.org ---
Author: amker
Date: Fri Nov 11 14:59:48 2016
New Revision: 242073

URL: https://gcc.gnu.org/viewcvs?rev=242073=gcc=rev
Log:
gcc/testsuite
PR testsuite/78292
* gcc.dg/vect/vect-cond-2.c: Only drop xfail for targets supporting
vect_max_reduc.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/vect-cond-2.c

[Bug libfortran/78314] [aarch64] ieee_support_halting does not report unsupported fpu traps correctly

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
No wonder that one fails on thunderx.

[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977

[dominiq at lps dot ens.fr]

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

--- Comment #25 from Dominique d'Humieres  ---
Confirmed provided I run genfixes in the fixincludes directory.

For the record, note that configuring gcc with --disable-libsanitizer replace
an ICE with accept-invalid in pr44348.

[Bug fortran/44348] ICE in build_function_decl

[dominiq at lps dot ens.fr]

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

--- Comment #20 from Dominique d'Humieres  ---
> I cannot confirm that. I do see the ICE on comment 2 at r242066.

OK. I have "recovered" the ICE with the patch at
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01045.html (pr78267). AFAICT the
ICE is replaced by accept-invalid when gcc is configured with
--disable-libsanitizer or with the patch in pr78267 comment 15.

[Bug libfortran/78314] New: [aarch64] ieee_support_halting does not report unsupported fpu traps correctly

[nsz at gcc dot gnu.org]

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

Bug ID: 78314
   Summary: [aarch64] ieee_support_halting does not report
unsupported fpu traps correctly
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nsz at gcc dot gnu.org
  Target Milestone: ---

on aarch64 trapping fpu exceptions are optional, but
ieee_support_halting(except_flag) does not report this
correctly, so fortran tests that depend on trap bit
changes would fail:

Program aborted. Backtrace:
#0  0x2472D3
FAIL: gfortran.dg/ieee/ieee_6.f90   -Os  execution test

[Bug tree-optimization/78114] [7 regression] gfortran.dg/vect/fast-math-mgrid-resid.f FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #6 from amker at gcc dot gnu.org ---
> But for tests:
> FAIL: gfortran.dg/vect/fast-math-mgrid-resid.f   -O   scan-tree-dump-times 
> pcom
> "Executing predictive commoning without unrolling" 1
> FAIL: gfortran.dg/vect/fast-math-mgrid-resid.f   -O   scan-tree-dump-times 
> pcom
> "Predictive commoning failed: no suitable chains" 0
>
> they happened before 20161011.  I tried revision at:
> commit ab93a7014158ec67a0b34e2986742da8a55013f9
> Author: sje 
> Date:   Wed Oct 5 18:42:10 2016 +
>
> 2016-10-05  Steve Ellcey  
>
> * MAINTAINERS: Update email address after it got reverted.
>
>
> git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@240801
> 138bc75d-0d04-0410-961f-82ee72b054a4
>
> And it's not working either?

In my tests (Solaris on various x86 systems, both Intel and AMD), the
failure started consistently between 20161011 (r240990) and 20161013
(r241136).

Rainer

[Bug c++/78313] [7 Regression] Misleading spelling suggestion

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
Thanks. Has some similarities to PR 77922.

[Bug sanitizer/78307] [7 Regression] missing symbols in libubsan without changing the soname

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
(In reply to Maxim Ostapenko from comment #6)
> (In reply to Jakub Jelinek from comment #5)
> > (In reply to Maxim Ostapenko from comment #4)
> > > But LLVM doesn't support shared UBSan runtime (the only one supported is
> > > ASan) and AFAIK there aren't any plans to support it there.
> > 
> > Yeah, it is a very weird policy.
> > 
> > > > In any case, we shouldn't be making ABI incompatible changes in the
> > > > libraries.  So, either we should bump soname, or preferably, if it is 
> > > > not
> > > > that hard to readd those symbols, just do that, so that people don't 
> > > > have to
> > > > fight yet another changed library.
> > > 
> > > Do you mean we can apply a local patch?
> > 
> > We can, sure.
> 
> Ok, I think I can just add (perhaps empty?) stubs into libubsan to readd
> those symbols, this should be quite trivial.

I think we shouldn't add empty functions, instead look at upstream
http://llvm.org/viewvc/llvm-project?view=revision=258744
change and undo the - parts of it essentially - most likely translate the old
CFIBadTypeData structure we are given into the new CFICheckFailData and just
call HandleCFIBadType.

[Bug c++/78313] [7 Regression] Misleading spelling suggestion

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org
   Target Milestone|--- |7.0

--- Comment #1 from Jakub Jelinek  ---
CCing David as the author of r238538.

[Bug c++/78313] New: [7 Regression] Misleading spelling suggestion

[jakub at gcc dot gnu.org]

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

Bug ID: 78313
   Summary: [7 Regression] Misleading spelling suggestion
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
CC: bernds at gcc dot gnu.org, chengniansun at gmail dot com,
jakub at gcc dot gnu.org, unassigned at gcc dot gnu.org,
webrown.cpp at gmail dot com
Depends on: 72774
  Target Milestone: ---

+++ This bug was initially created as a clone of Bug #72774 +++

// PR c++/72774
// { dg-do compile }

void baz ();
namespace A { void foo (); }
void bar ()
{
  using A::foo;
  0 ? static_cast (0) : baz;   // { dg-error "does not name a type" }
}

Actually, the suggestion looks wrong:

pr72774.C:9:19: error: ‘foo’ does not name a type; did you mean ‘foo’?

We call lookup_name_fuzzy with kind that we want a typename, but we actually
except for members consider even FUNCTION_DECLs/VAR_DECLs.  That doesn't look
right.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72774
[Bug 72774] [7 Regression] ICE on invalid C++ code on x86_64-linux-gnu (tree
check: expected tree that contains ‘decl minimal’ structure, have ‘tree_list’
in consider_binding_level, at cp/name-lookup.c:4721)

[Bug sanitizer/78307] [7 Regression] missing symbols in libubsan without changing the soname

[m.ostapenko at samsung dot com]

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

--- Comment #6 from Maxim Ostapenko  ---
(In reply to Jakub Jelinek from comment #5)
> (In reply to Maxim Ostapenko from comment #4)
> > But LLVM doesn't support shared UBSan runtime (the only one supported is
> > ASan) and AFAIK there aren't any plans to support it there.
> 
> Yeah, it is a very weird policy.
> 
> > > In any case, we shouldn't be making ABI incompatible changes in the
> > > libraries.  So, either we should bump soname, or preferably, if it is not
> > > that hard to readd those symbols, just do that, so that people don't have 
> > > to
> > > fight yet another changed library.
> > 
> > Do you mean we can apply a local patch?
> 
> We can, sure.

Ok, I think I can just add (perhaps empty?) stubs into libubsan to readd those
symbols, this should be quite trivial.

[Bug c++/72774] [7 Regression] ICE on invalid C++ code on x86_64-linux-gnu (tree check: expected tree that contains ‘decl minimal’ structure, have ‘tree_list’ in consider_binding_level, at cp/name-loo

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug sanitizer/78307] [7 Regression] missing symbols in libubsan without changing the soname

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
(In reply to Maxim Ostapenko from comment #4)
> But LLVM doesn't support shared UBSan runtime (the only one supported is
> ASan) and AFAIK there aren't any plans to support it there.

Yeah, it is a very weird policy.

> > In any case, we shouldn't be making ABI incompatible changes in the
> > libraries.  So, either we should bump soname, or preferably, if it is not
> > that hard to readd those symbols, just do that, so that people don't have to
> > fight yet another changed library.
> 
> Do you mean we can apply a local patch?

We can, sure.

[Bug c++/72774] [7 Regression] ICE on invalid C++ code on x86_64-linux-gnu (tree check: expected tree that contains ‘decl minimal’ structure, have ‘tree_list’ in consider_binding_level, at cp/name-loo

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov 11 13:39:06 2016
New Revision: 242070

URL: https://gcc.gnu.org/viewcvs?rev=242070=gcc=rev
Log:
PR c++/72774
* g++.dg/parse/pr72774.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/parse/pr72774.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug sanitizer/78307] [7 Regression] missing symbols in libubsan without changing the soname

[m.ostapenko at samsung dot com]

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

--- Comment #4 from Maxim Ostapenko  ---
(In reply to Jakub Jelinek from comment #3)
> Sure, it doesn't affect gcc emitted code unless somebody calls those
> directly, but perhaps say llvm compiled code using the shared libubsan.so. 

But LLVM doesn't support shared UBSan runtime (the only one supported is ASan)
and AFAIK there aren't any plans to support it there.

> In any case, we shouldn't be making ABI incompatible changes in the
> libraries.  So, either we should bump soname, or preferably, if it is not
> that hard to readd those symbols, just do that, so that people don't have to
> fight yet another changed library.

Do you mean we can apply a local patch?

[Bug inline-asm/78311] "register value used as expression" on i386 in inline assembly statement with "o" constraint

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
Requires -fpie to reproduce.  Your testcase is compiled to

f:
.LFB0:
.cfi_startproc
pushl   %ebp
.cfi_def_cfa_offset 8
.cfi_offset 5, -8
movl%esp, %ebp
.cfi_def_cfa_register 5
call__x86.get_pc_thunk.ax
addl$_GLOBAL_OFFSET_TABLE_, %eax
movlA@GOT(%eax), %eax
#APP
# 4 "t.c" 1
movd (%eax) (, %edx, 4), %mm0

# 0 "" 2
#NO_APP


and appearantly your GCC distributor chose to enable -fpie by default.

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

[ro at gcc dot gnu.org]

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

--- Comment #14 from Rainer Orth  ---
Created attachment 40023
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40023=edit
i386-pc-solaris2.12 assembler output: pr78112.s

Unfortunately, the new testcase FAILs on both Solaris/SPARC and Solaris/x86:

FAIL: g++.dg/pr78112.C   scan-assembler-times DW_AT_object_pointer 37

In both cases (and for either 32 and 64-bit), DW_AT_object_pointer occurs 39
times instead.  Attaching the Solaris/x86 assembler output.

I cannot yet tell if this is related to assembler capabilities: still waiting
for
bootstrap results with gas instead of as.

  Rainer

[Bug rtl-optimization/78120] [6/7 Regression] If conversion no longer performed

[bernds at gcc dot gnu.org]

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

--- Comment #4 from Bernd Schmidt  ---
The other issue here seems to be simply that BRANCH_COST is 0 for predictable
branches on x86. Which makes the default implementation of the hook used here

  if_info.max_seq_cost
= targetm.max_noce_ifcvt_seq_cost (then_edge);

come out as zero, and we fail the conversion because of this.

[Bug sanitizer/78307] [7 Regression] missing symbols in libubsan without changing the soname

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Sure, it doesn't affect gcc emitted code unless somebody calls those directly,
but perhaps say llvm compiled code using the shared libubsan.so.  In any case,
we shouldn't be making ABI incompatible changes in the libraries.  So, either
we should bump soname, or preferably, if it is not that hard to readd those
symbols, just do that, so that people don't have to fight yet another changed
library.

[Bug tree-optimization/78312] [7 Regression] wrong code probably due to VRP of multiplication

[zsojka at seznam dot cz]

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

--- Comment #2 from Zdenek Sojka  ---
(In reply to Richard Biener from comment #1)
> Hmm.
> 
> So [0, 1] * ~[1, 65534] gets
> 
> MEET ([0, 1] * [0, 0] == [0, 0],
>   [0, 1] * [65535, 65535] == ~[1, 65534]) == ~[1, 65534]
> 
> that looks ok to me.
> 
> And then ~[1, 65534] * ~[1, 65534] is [0, 1], also ok.
> 

Thanks, I didn't realize that ((65535 * 65535) & 0x) == 1.

[Bug sanitizer/78307] [7 Regression] missing symbols in libubsan without changing the soname

[doko at gcc dot gnu.org]

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

--- Comment #2 from Matthias Klose  ---
I can't tell. I was just looking at symbol difference in the library, like
using the abigail tools.

[Bug sanitizer/78307] [7 Regression] missing symbols in libubsan without changing the soname

[m.ostapenko at samsung dot com]

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

Maxim Ostapenko  changed:

   What|Removed |Added

 CC||m.ostapenko at samsung dot com

--- Comment #1 from Maxim Ostapenko  ---
Did this cause the link error?

AFAIK GCC doesn't support CFI thus doesn't emit these symbols at compiler side.

[Bug tree-optimization/78312] [7 Regression] wrong code probably due to VRP of multiplication

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
Hmm.

So [0, 1] * ~[1, 65534] gets

MEET ([0, 1] * [0, 0] == [0, 0],
  [0, 1] * [65535, 65535] == ~[1, 65534]) == ~[1, 65534]

that looks ok to me.

And then ~[1, 65534] * ~[1, 65534] is [0, 1], also ok.

But then somewhen the IL changes to


  :
  # RANGE [0, 1]
  _1 = p1_8(D) > 0;
  # RANGE [0, 1] NONZERO 1
  _2 = (short unsigned int) _1;
  # RANGE ~[1, 65534]
  _3 = -_2;
  # RANGE [0, 1]
  _4 = _3 != 0;
  # RANGE [0, 1] NONZERO 1
  _5 = (short unsigned int) _4;
  # RANGE ~[1, 65534]
  _6 = _2 * _5;

and [0,1] * [0, 1] is not ~[1, 65534].

It is backprop messing up the IL, invalidating the range-info on SSA names.

Index: gcc/gimple-ssa-backprop.c
===
--- gcc/gimple-ssa-backprop.c   (revision 242066)
+++ gcc/gimple-ssa-backprop.c   (working copy)
@@ -728,6 +728,7 @@ backprop::prepare_change (tree var)
 {
   if (MAY_HAVE_DEBUG_STMTS)
 insert_debug_temp_for_var_def (NULL, var);
+  reset_flow_sensitive_info (var);
 }

 /* STMT has been changed.  Give the fold machinery a chance to simplify

[Bug target/77346] [7 Regression] ICE in push_reload, at reload.c:1350

[aldyh at gcc dot gnu.org]

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

--- Comment #3 from Aldy Hernandez  ---
Nope, still can't reproduce.  Can you run your compile line with -v and post
the results, to see if there are any other flags passed to cc1 that I am
unaware of?

powerpc-e300c3-linux-gnu-gcc-7.0.0-alpha20161106 -mno-lra -Os -fPIC
-fstack-protector -c -w buwdtjav.c

[Bug rtl-optimization/78120] [6/7 Regression] If conversion no longer performed

[bernds at gcc dot gnu.org]

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

--- Comment #3 from Bernd Schmidt  ---
Gah, that's obviously bogus and fails elsewhere. Still looking...

[Bug target/78310] ICE: insn does not satisfy its constraints: {*bmi2_rorxdi3_1} with -mbmi2

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-11-11
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
   Target Milestone|--- |5.5
 Ever confirmed|0   |1

--- Comment #1 from Uroš Bizjak  ---
Yeah, we need to avoid overflow.

--cut here--
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index a5650a1..b46d6d1 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -10908,8 +10908,9 @@
   [(set (match_dup 0)
(rotatert:SWI48 (match_dup 1) (match_dup 2)))]
 {
-  operands[2]
-= GEN_INT (GET_MODE_BITSIZE (mode) - INTVAL (operands[2]));
+  int bitsize = GET_MODE_BITSIZE (mode);
+
+  operands[2] = GEN_INT ((bitsize - INTVAL (operands[2])) % bitsize);
 })

 (define_split
@@ -10975,8 +10976,9 @@
   [(set (match_dup 0)
(zero_extend:DI (rotatert:SI (match_dup 1) (match_dup 2]
 {
-  operands[2]
-= GEN_INT (GET_MODE_BITSIZE (SImode) - INTVAL (operands[2]));
+  int bitsize = GET_MODE_BITSIZE (SImode);
+
+  operands[2] = GEN_INT ((bitsize - INTVAL (operands[2])) % bitsize);
 })

 (define_split
--cut here--

[Bug c++/72774] [7 Regression] ICE on invalid C++ code on x86_64-linux-gnu (tree check: expected tree that contains ‘decl minimal’ structure, have ‘tree_list’ in consider_binding_level, at cp/name-loo

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Ah, and I've fixed it already in r240148.  I'll check the testcase in and
close.

[Bug middle-end/78295] [7 Regression] Spurious -Wuninitialized warning for vector element assignment

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Fixed.

[Bug tree-optimization/71575] [6 Regression] [graphite] internal compiler error: in copy_cond_phi_nodes, at graphite-isl-ast-to-gimple.c:2500

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||7.0
Summary|[6/7 Regression] [graphite] |[6 Regression] [graphite]
   |internal compiler error: in |internal compiler error: in
   |copy_cond_phi_nodes, at |copy_cond_phi_nodes, at
   |graphite-isl-ast-to-gimple. |graphite-isl-ast-to-gimple.
   |c:2500  |c:2500
  Known to fail||6.2.0

--- Comment #13 from Richard Biener  ---
Fixed on trunk sofar.

[Bug tree-optimization/71575] [6/7 Regression] [graphite] internal compiler error: in copy_cond_phi_nodes, at graphite-isl-ast-to-gimple.c:2500

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
Author: rguenth
Date: Fri Nov 11 12:54:25 2016
New Revision: 242069

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

PR tree-optimization/71575
* graphite-isl-ast-to-gimple.c (copy_cond_phi_nodes): Remove
bogus assert.

* gcc.dg/graphite/pr71575-1.c: New testcase.
* gcc.dg/graphite/pr71575-2.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/graphite/pr71575-1.c
trunk/gcc/testsuite/gcc.dg/graphite/pr71575-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/graphite-isl-ast-to-gimple.c
trunk/gcc/testsuite/ChangeLog