[Bug c/51309] -Wstrict-overflow false alarm when overflow impossible in loop body

[eggert at gnu dot org]

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

--- Comment #2 from Paul Eggert  ---
(In reply to Eric Gallager from comment #1)
> I can't seem to reproduce the warning

Thanks, I can no longer reproduce the warning either. I used GCC 7.1.1 20170622
(Red Hat 7.1.1-3). So it looks like the problem is fixed.

[Bug c++/81557] New: Detect unused const char * and STL string

[jg at jguk dot org]

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

Bug ID: 81557
   Summary: Detect unused const char * and STL string
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jg at jguk dot org
  Target Milestone: ---

Would be great if GCC could detect warnings on line 10 and 12 in this unused
code code

Expected something like

$ g++ -Wall -o main main.cpp
main.cpp: In function ‘int main()’:
main.cpp:10:15: warning: ‘str’ replaced earlier initialization on line 9 that
was unused 
 str = "second";
 ^
main.cpp:12:15: warning: ‘str2’ replaced earlier initialization on line 12 that
was unused 
 str2 = "third";



//g++ -O2 -Wall -Wextra -Wpedantic -o main main.cpp

#include 
#include 

int main (void)
{
const char * str = "mystr";
str = "second";

std::string str2 = "test";
str2 = "third";

printf("%s %s\n", str, str2.c_str());

return 0;
}

[Bug other/79250] brig/brigfrontend/brig-to-generic.cc: two small problems

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from Eric Gallager  ---
(In reply to Pekka Jääskeläinen from comment #2)
> Committed in r245084.

Fixed then.

[Bug tree-optimization/81556] New: Wrong code at -O2

[babokin at gmail dot com]

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

Bug ID: 81556
   Summary: Wrong code at -O2
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

gcc trunk, rev250545, x86_64.

This one seems to be different from previously reported bugs. Minimum opt level
to trigger bug is -O2, switching slsr doesn't help (-fno-tree-slsr).

> cat f.cpp
#include 

unsigned long int var_0 = 13272098465497875865UL;
unsigned long int var_1 = 15341539099603541390UL;
unsigned long int var_2 = 2;
unsigned long int var_3 = 17471558040813171499UL;
unsigned long int var_4 = 1;
unsigned long int var_5 = 0;
unsigned long int var_6 = 0;

void foo() {
  bool a = var_2 > 1;
  var_5 = var_4 % ((var_2 > 1) << 9);
  var_6 = a & (var_3 & (a & var_0 & var_1));
}

int main() {
  foo();
  printf("0x%llx, 0x%llx\n", var_5, var_6);
  return 0;
}

> g++ -O0 f.cpp -o out; ./out
0x1, 0x0

> g++ -O2 f.cpp -o out; ./out
0x1, 0x90201108

[Bug demangler/67186] Libiberty fails to demangle C++ function name if clone suffix contains digit

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
  Component|other   |demangler

--- Comment #2 from Eric Gallager  ---
Changing component to demangler

[Bug demangler/67299] demangler mishandles complex types

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
  Component|other   |demangler

--- Comment #2 from Eric Gallager  ---
Changing component to demangler

[Bug c++/81527] Missing inherited constructor by "using-declarations"

[tuwwcn at gmail dot com]

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

--- Comment #4 from Wei-Wei Tu  ---
(In reply to Jonathan Wakely from comment #3)
> I don't think the code is valid, copy/move constructors are not inherited.
> See PR 69853 for a similar bug report.
> 
> *** This bug has been marked as a duplicate of bug 69853 ***

Yes, you are right. I've made a mistake about "using". Thank you for checking
this report.

[Bug tree-optimization/81555] New: Wrong code at -O1

[babokin at gmail dot com]

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

Bug ID: 81555
   Summary: Wrong code at -O1
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

gcc trunk, rev250545, x86_64.

> cat f.cpp
#include 

unsigned int var_1 = 1;
bool var_2 = false;
unsigned int var_3 = 679743406U;
unsigned int var_4 = 3054363510U;
bool var_5 = true;
unsigned char var_6 = 1;

void foo() {
  bool c = var_1 != var_2;
  if (c)
var_5 = 0;
  if (var_4 & c & (unsigned char)var_3 & c)
var_6 = 0;
}

int main() {
  foo();
  printf("%d, %d\n", var_5, var_6);
  return 0;
}

> g++ -O0 f.cpp -o out; ./out
0, 1

> g++ -O1 f.cpp -o out; ./out
0, 0

[Bug driver/81519] Enhancement: Add --help=target-distcc or similar to dump clean, optimal CFLAGS without using -march=native

[daniel.santos at pobox dot com]

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

--- Comment #3 from Daniel Santos  ---
(In reply to Martin Liška from comment #1)
> I can take a look later for GCC 8.0.

Thank you Martin!  I still don't understand enough of gcc to be able to do this
in any reasonable time frame and I've only worked with the i386 backend thus
far.

[Bug tree-optimization/81554] [8 Regression] 25% performance regression in Himeno benchmark

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
#define MR(mt,n,r,c,d)  mt->m[(n) * mt->mrows * mt->mcols * mt->mdeps + (r) *
mt->mcols* mt->mdeps + (c) * mt->mdeps + (d)]


#define MR(mt,n,r,c,d)  mt->m[(((n) * mt->mrows + (r)) * mt->mcols + (c)) *
mt->mdeps + (d)]

Is not being done. :)

[Bug tree-optimization/81554] [8 Regression] 25% performance regression in Himeno benchmark

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Target Milestone|--- |8.0

[Bug tree-optimization/81554] New: [8 Regression] 25% performance regression in Himeno benchmark

[kristerw at gcc dot gnu.org]

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

Bug ID: 81554
   Summary: [8 Regression] 25% performance regression in Himeno
benchmark
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kristerw at gcc dot gnu.org
  Target Milestone: ---

Created attachment 41831
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41831=edit
The Himeno benchmark

The Himeno benchmark from the Phoronix test suite lost 25% of its performance
by r248771 that fixed PR 66313 ("Unsafe factorization of a*b+a*c").

The benchmark is attached, can be compiled as
  gcc -O3 himenobmtxpa.c
and run as
  ./a.out s

I see 15% slowdown when the benchmark is compiled as "-O3" and 25% if compiled
as "-O3 -march=native" on a Broadwell CPU.

[Bug c/39808] warn_unused_result fails to produce warning in a statement expression

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-25
 CC||msebor at gcc dot gnu.org
Summary|warn_unused_result fails to |warn_unused_result fails to
   |produce warning |produce warning in a
   ||statement expression
 Ever confirmed|0   |1
  Known to fail||5.3.0, 6.3.0, 7.1.0, 8.0

--- Comment #4 from Martin Sebor  ---
Confirmed.

[Bug c++/77304] ICE on C++ code with invalid template parameter: in gimplify_expr, at gimplify.c:11260

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed|2016-09-07 00:00:00 |2017-07-25
 Ever confirmed|0   |1

[Bug rtl-optimization/81553] [8 Regression] ICE in immed_wide_int_const, at emit-rtl.c:607

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Target||x86_64-*-*
   Target Milestone|--- |8.0
Summary|ICE in  |[8 Regression] ICE in
   |immed_wide_int_const, at|immed_wide_int_const, at
   |emit-rtl.c:607  |emit-rtl.c:607

[Bug c/81524] Bogus or missing warnings when dereferencing pointer to deallocated stack memory

[fredrik.hederstie...@securitas-direct.com]

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

--- Comment #3 from Fredrik Hederstierna 
 ---
Isn't AddressSanitizer checking in run-time? There are several tools that can
find this bugs in runtime I think like Valgrind, but I need to find this at
compile-time.

I use embedded arm-eabi target and cannot add memory for instrumentation with
compile AddressSanitizer, or can AddressSanitizer do jobs alos in compile-time
without adding code size for run-time instrumentation?

[Bug libstdc++/81469] std::uncaught_exception should be marked as deprecated for C++1z

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
We'll probably also want to adjust any tests for uncaught_exception so they
don't give a deprecated warning when run with RUNTESTFLAGS=unix/-std=c++17

[Bug libstdc++/81469] std::uncaught_exception should be marked as deprecated for C++1z

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Patches should be sent to the gcc-patches anbd libstdc++ mailing lists, not
attached to bugzilla.

The line should be wrapped to less than 80 columns, and C++1z should be C++17,
although I wouldn't bother with "in C++1z" at all.

[Bug c++/80737] variant as class member resulting to compile errors

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #9 from Jonathan Wakely  ---
Fixed for 7.2

[Bug libstdc++/80939] Various helper function templates in incorrectly marked constexpr

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.2

--- Comment #4 from Jonathan Wakely  ---
Fixed for 7.2

[Bug libstdc++/81017] Class with vector of unique_ptr and std::function does not compile

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |7.2

--- Comment #9 from Jonathan Wakely  ---
Fixed for 7.2 now too.

[Bug c++/81527] Missing inherited constructor by "using-declarations"

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Jonathan Wakely  ---
I don't think the code is valid, copy/move constructors are not inherited. See
PR 69853 for a similar bug report.

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

[Bug libstdc++/69853] An inheriting constructor of the class that inherited std::tuple isn't called correctly

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||tuwwcn at gmail dot com

--- Comment #5 from Jonathan Wakely  ---
*** Bug 81527 has been marked as a duplicate of this bug. ***

[Bug libstdc++/80553] std::vector allows instantiation with type having a deleted destructor

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|8.0 |7.2

[Bug libstdc++/53984] iostream operation throwing exception when exceptions not enabled

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||8.0

--- Comment #10 from Jonathan Wakely  ---
Fixed on trunk. We might want to backport this to active branches too.

[Bug rtl-optimization/81553] New: ICE in immed_wide_int_const, at emit-rtl.c:607

[babokin at gmail dot com]

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

Bug ID: 81553
   Summary: ICE in immed_wide_int_const, at emit-rtl.c:607
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

gcc trunk, rev250527, x86_64

> cat f.cpp
int a, b, c;
struct d {
  static int e;
} f;
d g, h;
void i() {
  f.e = (10834211066969351267ULL || 0) >> c >> 1;
  b = ~(209883449764912897ULL & h.e) << (0 >= a) | ~g.e;
}

> g++ f.cpp -c -O2
during RTL pass: combine
f.cpp: In function ‘void i()’:
f.cpp:9:1: internal compiler error: in immed_wide_int_const, at emit-rtl.c:607
 }
 ^
0x6b2cc1 immed_wide_int_const(generic_wide_int
const&, machine_mode)
../../gcc_svn_intel/gcc/emit-rtl.c:607
0xf0fc34 simplify_const_unary_operation(rtx_code, machine_mode, rtx_def*,
machine_mode)
../../gcc_svn_intel/gcc/simplify-rtx.c:1882
0xf0df4e simplify_unary_operation(rtx_code, machine_mode, rtx_def*,
machine_mode)
../../gcc_svn_intel/gcc/simplify-rtx.c:883
0xf0f290 simplify_gen_unary(rtx_code, machine_mode, rtx_def*, machine_mode)
../../gcc_svn_intel/gcc/simplify-rtx.c:384
0x152bea0 if_then_else_cond
../../gcc_svn_intel/gcc/combine.c:9044
0x152bcef if_then_else_cond
../../gcc_svn_intel/gcc/combine.c:9063
0x15365f5 combine_simplify_rtx
../../gcc_svn_intel/gcc/combine.c:5636
0x1538d21 subst
../../gcc_svn_intel/gcc/combine.c:5519
0x1536a87 combine_simplify_rtx
../../gcc_svn_intel/gcc/combine.c:5653
0x1538d21 subst
../../gcc_svn_intel/gcc/combine.c:5519
0x1538aac subst
../../gcc_svn_intel/gcc/combine.c:5457
0x1538b95 subst
../../gcc_svn_intel/gcc/combine.c:5386
0x153be5e try_combine
../../gcc_svn_intel/gcc/combine.c:3368
0x15420de combine_instructions
../../gcc_svn_intel/gcc/combine.c:1434
0x15420de rest_of_handle_combine
../../gcc_svn_intel/gcc/combine.c:14646
0x15420de execute
../../gcc_svn_intel/gcc/combine.c:14691
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug libstdc++/53984] iostream operation throwing exception when exceptions not enabled

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
Author: redi
Date: Tue Jul 25 20:36:06 2017
New Revision: 250545

URL: https://gcc.gnu.org/viewcvs?rev=250545=gcc=rev
Log:
PR libstdc++/53984 handle exceptions in basic_istream::sentry

PR libstdc++/53984
* include/bits/basic_ios.h (basic_ios::_M_setstate): Adjust comment.
* include/bits/istream.tcc (basic_istream::sentry): Handle exceptions
during construction.
* include/std/istream: Adjust comments for formatted input functions
and unformatted input functions.
* testsuite/27_io/basic_fstream/53984.cc: New.
* testsuite/27_io/basic_istream/sentry/char/53984.cc: New.

Added:
trunk/libstdc++-v3/testsuite/27_io/basic_fstream/53984.cc
trunk/libstdc++-v3/testsuite/27_io/basic_istream/sentry/char/53984.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/basic_ios.h
trunk/libstdc++-v3/include/bits/istream.tcc
trunk/libstdc++-v3/include/std/istream

[Bug c/81448] False positive -Werror=multistatement-macros in openssl

[bernd.edlinger at hotmail dot de]

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

--- Comment #6 from Bernd Edlinger  ---
(In reply to Marek Polacek from comment #5)
> PR81364 is fixed, do you still see any false positives?

Well adding braces would fix the warning,
but consider this slightly reduced test case:

void b_ecb_encrypt();

#define BLOCK_CIPHER_ecb_loop() \
int i, bl; \
bl = 100; \
if (inl < bl) return 1; \
inl -= bl; \
for (i=0; i <= inl; i+=bl)

#define BLOCK_CIPHER_func_ecb(cname, cprefix, kstruct, ksched) \
int cname##_ecb_cipher(char *out, char *in, int inl) \
{ \
  BLOCK_CIPHER_ecb_loop() \
cprefix##_ecb_encrypt(in + i, out + i); \
  return 1; \
}

BLOCK_CIPHER_func_ecb(a,b,c,d)

int test(unsigned char *out, const unsigned char *in, int inl)
{
  BLOCK_CIPHER_ecb_loop()
b_ecb_encrypt(in + i, out + i);
  return 1;
}


Why is the warning only in the macro expansion
and not in explicit instantiation ?

[Bug libstdc++/53984] iostream operation throwing exception when exceptions not enabled

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
FAIL: 27_io/basic_filebuf/overflow/char/9182-2.cc execution test

This fails because it explicitly tests for an exception:

  try
{
  fbuf1.sputn("ison", 4);
  fbuf1.pubsync();
  VERIFY( false );
}
  catch (std::exception&)
{
}


FAIL: 27_io/basic_filebuf/seekoff/wchar_t/3.cc execution test

This also fails because it explicitly tests for an exception:

  try
{
  // seekoff should flush the output sequence, which will fail
  // if the output buffer contains illegal characters.
  fb.pubseekoff(0, ios_base::cur);
  VERIFY( false );
}
  catch (std::exception&)
{
}


FAIL: 27_io/basic_filebuf/seekpos/wchar_t/1.cc execution test

This also tests for an exception:

  try
{
  fb.pubseekpos(pos);
  VERIFY( false );
}
  catch (std::exception&)
{
}



FAIL: 27_io/basic_filebuf/sync/char/9182-1.cc execution test

And again:


  try
{
  fbuf1.sputn("onne", 4);
  fbuf1.close();
  VERIFY( false );
}
  catch (std::exception&)
{
}



FAIL: 27_io/basic_filebuf/underflow/wchar_t/11544-1.cc execution test
FAIL: 27_io/basic_filebuf/underflow/wchar_t/11544-2.cc execution test

These both check for a bad stream state:

  VERIFY( in.good() );
  in.get();
  VERIFY( !in.good() );
  VERIFY( in.bad() );
  VERIFY( !in.eof() );


FAIL: 27_io/basic_filebuf/underflow/wchar_t/11603.cc execution test

This fails because we have this:

  try
{
  wfilebuf::int_type ret = fb.pub_underflow();
  VERIFY( ret != wfilebuf::traits_type::eof() );
  fb.sbumpc();
  ret = fb.pub_underflow();
  VERIFY( ret == wfilebuf::traits_type::eof() );
}
  catch (...)
{ }

The first VERIFY is never reached because we throw in underflow. The test seems
broken.


Several of these tests are explicitly checking for exceptions, so the current
behaviour of throwing on invalid byte sequences (comment 2) is clearly by
design.

I don't think the problem here is actually in basic_filebuf. I think filebuf is
allowed to throw if there's an I/O error. I think the problem is that
basic_istream::sentry doesn't handle exceptions that happen while skipping
whitespace:

#include 
#include 

struct SB : std::streambuf {
  int_type underflow() override { throw 1; }
};

int main()
{
  SB sb;
  std::istream is();
  int i;
  is >> i;
}

This seems easy to fix.

[Bug c/51309] -Wstrict-overflow false alarm when overflow impossible in loop body

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #1 from Eric Gallager  ---
I can't seem to reproduce the warning; all of these are silent:

$ /usr/local/bin/gcc -Wstrict-overflow -O2 -S u.c
$ /usr/local/bin/gcc -Wstrict-overflow=1 -O2 -S u.c
$ /usr/local/bin/gcc -Wstrict-overflow=2 -O2 -S u.c
$ /usr/local/bin/gcc -Wstrict-overflow=3 -O2 -S u.c
$ /usr/local/bin/gcc -Wstrict-overflow=4 -O2 -S u.c
$ /usr/local/bin/gcc -Wstrict-overflow=5 -O2 -S u.c
$ /usr/local/bin/gcc -Wstrict-overflow -O1 -S u.c
$ /usr/local/bin/gcc -Wstrict-overflow -O0 -S u.c
$ /usr/local/bin/gcc -Wstrict-overflow -Os -S u.c
$ /usr/local/bin/gcc -Wstrict-overflow -Og -S u.c
$ /usr/local/bin/gcc -Wstrict-overflow -O3 -S u.c
$ /usr/local/bin/gcc -Wstrict-overflow -Ofast -S u.c

And seeing as -Wstrict-overflow is being considered for deprecation in the next
release of GCC anyways, I think I can close this.

[Bug tree-optimization/81162] [8 Regression] UBSAN switch triggers incorrect optimization in SLSR

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #17 from Bill Schmidt  ---
Now fixed everywhere.

[Bug tree-optimization/81162] [8 Regression] UBSAN switch triggers incorrect optimization in SLSR

[wschmidt at gcc dot gnu.org]

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

--- Comment #16 from Bill Schmidt  ---
Author: wschmidt
Date: Tue Jul 25 19:44:10 2017
New Revision: 250544

URL: https://gcc.gnu.org/viewcvs?rev=250544=gcc=rev
Log:
[gcc]

2016-07-25  Bill Schmidt  

Backport from mainline
2016-07-14  Bill Schmidt  

PR tree-optimization/81162
* gimple-ssa-strength-reduction.c (replace_mult_candidate): Don't
replace a negate with an add.

[gcc/testsuite]

2016-07-25  Bill Schmidt  

Backport from mainline
2016-07-14  Bill Schmidt  

PR tree-optimization/81162
* gcc.dg/ubsan/pr81162.c: New file.


Added:
branches/gcc-5-branch/gcc/testsuite/gcc.dg/ubsan/pr81162.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/gimple-ssa-strength-reduction.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/81162] [8 Regression] UBSAN switch triggers incorrect optimization in SLSR

[wschmidt at gcc dot gnu.org]

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

--- Comment #15 from Bill Schmidt  ---
Author: wschmidt
Date: Tue Jul 25 19:42:36 2017
New Revision: 250543

URL: https://gcc.gnu.org/viewcvs?rev=250543=gcc=rev
Log:
[gcc]

2016-07-25  Bill Schmidt  

Backport from mainline
2016-07-14  Bill Schmidt  

PR tree-optimization/81162
* gimple-ssa-strength-reduction.c (replace_mult_candidate): Don't
replace a negate with an add.

[gcc/testsuite]

2016-07-25  Bill Schmidt  

Backport from mainline
2016-07-14  Bill Schmidt  

PR tree-optimization/81162
* gcc.dg/ubsan/pr81162.c: New file.


Added:
branches/gcc-6-branch/gcc/testsuite/gcc.dg/ubsan/pr81162.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/gimple-ssa-strength-reduction.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/81162] [8 Regression] UBSAN switch triggers incorrect optimization in SLSR

[wschmidt at gcc dot gnu.org]

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

--- Comment #14 from Bill Schmidt  ---
Author: wschmidt
Date: Tue Jul 25 19:40:50 2017
New Revision: 250542

URL: https://gcc.gnu.org/viewcvs?rev=250542=gcc=rev
Log:
[gcc]

2016-07-25  Bill Schmidt  

Backport from mainline
2016-07-14  Bill Schmidt  

PR tree-optimization/81162
* gimple-ssa-strength-reduction.c (replace_mult_candidate): Don't
replace a negate with an add.

[gcc/testsuite]

2016-07-25  Bill Schmidt  

Backport from mainline
2016-07-14  Bill Schmidt  

PR tree-optimization/81162
* gcc.dg/ubsan/pr81162.c: New file.


Added:
branches/gcc-7-branch/gcc/testsuite/gcc.dg/ubsan/pr81162.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/gimple-ssa-strength-reduction.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/81538] Optimization problem compiling op.c (Perl_custom_op_get_field) in perl 5.26

[dave.anglin at bell dot net]

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

--- Comment #6 from dave.anglin at bell dot net ---
On 2017-07-25, at 2:46 PM, dave.anglin at bell dot net wrote:

> Both gcc-5 and gcc-6 are broken.

Take that back; only gcc-6 is broken.  I incorrectly set the package up for
gcc-5
in my first attempt and it used gcc-6.

--
John David Anglin   dave.ang...@bell.net

[Bug target/81521] [8 Regression] After [r250413] GCC 8.0 doesn't compile for Windows

[mateuszb at poczta dot onet.pl]

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

mateuszb at poczta dot onet.pl changed:

   What|Removed |Added

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

--- Comment #6 from mateuszb at poczta dot onet.pl ---
Thanks Jakub and Jim! It is fixed now.

[Bug c/50422] -Wswitch warns about unhandled cases in nested switches

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-25
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed that GCC still prints the warning

[Bug c/49702] Undefined static functions resolve to external definitions

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-25
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
Confirmed.

[Bug c/45977] "warning: 'i' initialized and declared 'extern'" could use a separate warning flag controlling it

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-25
 Ever confirmed|0   |1

--- Comment #6 from Eric Gallager  ---
(In reply to Eric Gallager from comment #5)
> Confirming on the basis that a separate warning flag here would be nice

Oops I retitled it but forgot to actually confirm it like I said I was doing
(sorry; hopefully I've got it this time)

[Bug c/45977] "warning: 'i' initialized and declared 'extern'" could use a separate warning flag controlling it

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
Summary|"warning: 'i' initialized   |"warning: 'i' initialized
   |and declared 'extern'" is   |and declared 'extern'"
   |spurious|could use a separate
   ||warning flag controlling it
   Severity|normal  |enhancement

--- Comment #5 from Eric Gallager  ---
Confirming on the basis that a separate warning flag here would be nice

[Bug c/38481] Add attribute for custom sentinels

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-25
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #2 from Eric Gallager  ---
I guess since I'm marking stuff as duplicates of this, I should confirm it as
an enhancement...

[Bug c/38481] Add attribute for custom sentinels

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||ericb at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
*** Bug 47702 has been marked as a duplicate of this bug. ***

[Bug c/47702] feature request: sentinel_value

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Eric Gallager  ---
Duplicate of bug 38481

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

[Bug libstdc++/81469] std::uncaught_exception should be marked as deprecated for C++1z

[danielgutson at gmail dot com]

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

--- Comment #3 from Daniel Gutson  ---
Any update on this? Could someone review the proposed patch?

[Bug c/20385] Lame parse error message for undefined type

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #12 from Eric Gallager  ---
(In reply to Eric Gallager from comment #11)
> 
> So can this be closed as FIXED now then?

I combined all the examples from this PR into a single testcase and can confirm
that gcc now prints decent errors for all of them:

$ cat 20385.c
unknowntype f() { return 0; }
unknowntype *fp() { return 0; }
int ff(unknowntype a) { return 0; }
int gg(unknowntype *a) { return 0; }

typedef uintt16_t pid_t;
extern uintt16_t x;
foo_t *P = 0;
$ /usr/local/bin/gcc -c 20385.c
20385.c:1:1: error: unknown type name ‘unknowntype’
 unknowntype f() { return 0; }
 ^~~
20385.c:2:1: error: unknown type name ‘unknowntype’
 unknowntype *fp() { return 0; }
 ^~~
20385.c:3:8: error: unknown type name ‘unknowntype’
 int ff(unknowntype a) { return 0; }
^~~
20385.c:4:8: error: unknown type name ‘unknowntype’
 int gg(unknowntype *a) { return 0; }
^~~
20385.c:6:9: error: unknown type name ‘uintt16_t’
 typedef uintt16_t pid_t;
 ^
20385.c:7:8: error: unknown type name ‘uintt16_t’
 extern uintt16_t x;
^
20385.c:8:1: error: unknown type name ‘foo_t’; did you mean ‘float’?
 foo_t *P = 0;
 ^
 float

So I'm going to close this as FIXED.

[Bug c/20385] Lame parse error message for undefined type

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #11 from Eric Gallager  ---
(In reply to Paolo Bonzini from comment #10)
> Author: bonzini
> Date: Fri Dec 17 21:23:36 2010
> New Revision: 167999
> 
> URL: http://gcc.gnu.org/viewcvs?root=gcc=rev=167999
> Log:
> gcc:
> 2010-12-17  Paolo Bonzini  
> 
>   PR c/20385
>   * function.c (used_types_insert): Handle ERROR_MARK.
>   * c-decl.c (grokdeclarator): Handle ERROR_MARK.
>   (declspecs_add_type): Leave error_mark_node in specs->type.
>   (finish_declspecs): Change it to integer_type_node here.
>   * c-parser.c (c_parser_peek_2nd_token): Move earlier.
>   (enum c_lookahead_kind): New.
>   (c_parser_next_token_starts_typename): New name of
>   c_parser_next_tokens_start_typename.  Accept lookahead enum
>   and handle it here instead of...
>   (c_parser_next_tokens_start_declaration): ... here.  Call it.
>   (c_parser_declspecs): Accept another argument.  Do not exit
>   on C_ID_ID if it is guessed to be an unknown typename.
>   (c_parser_parms_declarator): Use 2nd token to distinguish a K
>   declaration from an ANSI declaration starting with an unknown
>   typename.
>   (c_parser_struct_declaration, c_parser_objc_type_name,
>   c_parser_typeof_specifier, c_parser_declarator,
>   c_parser_direct_declarator_inner): Adjust calls.
>   (c_parser_parameter_declaration): Likewise.
>   (c_parser_type_name): Pass back an error_mark_node to the caller.
>   (c_parser_postfix_expression): Do error recovery when 
>   c_parser_type_name returns NULL.
> 
> testsuite:
> 2010-12-17  Paolo Bonzini  
> 
>   PR c/20385
>   * objc.dg/tls/init-2.m: Adjust.
>   * gcc.dg/noncompile/920923-1.c: Adjust.
>   * gcc.dg/noncompile/pr44517.c: Adjust.
>   * gcc.dg/declspec-18.c: New test.
> 
> 
> Added:
> trunk/gcc/testsuite/gcc.dg/declspec-18.c
> Modified:
> trunk/gcc/ChangeLog
> trunk/gcc/c-decl.c
> trunk/gcc/c-parser.c
> trunk/gcc/function.c
> trunk/gcc/testsuite/ChangeLog
> trunk/gcc/testsuite/gcc.dg/noncompile/920923-1.c
> trunk/gcc/testsuite/gcc.dg/noncompile/pr44517.c
> trunk/gcc/testsuite/objc.dg/tls/init-2.m

So can this be closed as FIXED now then?

[Bug rtl-optimization/81538] Optimization problem compiling op.c (Perl_custom_op_get_field) in perl 5.26

[dave.anglin at bell dot net]

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

--- Comment #5 from dave.anglin at bell dot net ---
On 2017-07-25, at 10:02 AM, dave.anglin at bell dot net wrote:

> Will check gcc-5 when current build
> completes.

Both gcc-5 and gcc-6 are broken.

--
John David Anglin   dave.ang...@bell.net

[Bug c/43728] Warning for redundant static function prototypes

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-25
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #8 from Eric Gallager  ---
Confirmed, although I probably wouldn't use such a warning myself if it were
added. (I like redundancy)

[Bug c/39985] Type qualifiers not actually ignored on function return type

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||patch
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-07-25
 CC||egallager at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |polacek at redhat dot 
com
 Ever confirmed|0   |1

--- Comment #4 from Eric Gallager  ---
(In reply to Anders Kaseorg from comment #3)
> > my inclination is that we should eliminate the inconsistent attempts to give
> > rvalues qualified types in some cases, and say that if the operand of typeof
> > is not an lvalue it never has a qualified type.
> 
> Should typeof ever return a qualified type?  It is easy to add qualifiers to
> a type if they are desired (const typeof(foo)), but seems difficult to
> remove them.
> 
> For example, seemingly reasonable macros like
>   #define MAX(__x, __y) ({   \
>   typeof(__x) __ret = __x;   \
>   if (__y > __ret) __ret = __y;  \
>   __ret; \
>   })
> currently fail when given a qualified argument:
>   const int c = 42;
>   MAX(c, 17);  /* error: assignment of read-only variable ‘__ret’ */
> 
> This bug report was motivated by my attempts to fix a macro like this, by
> replacing typeof(__x) with something that strips qualifiers.  These all fail
> to strip qualifiers:
>   typeof( ({ __x; }) )
>   typeof( ((typeof(__x)(*)(void)) 0)() )
>   typeof( (typeof(__x)) (__x) )
> This seems to work, but only for numeric and pointer types:
>   typeof( (typeof(__x)) 0 )
> This succeeds at stripping qualifiers for numeric types, but for some reason
> it promotes char and short to int, and it fails to strip qualifiers for
> non-numeric types:
>   typeof( 1 ? (__x) : (__x) )
> 
> Much confusion would be avoided if typeof(__x) just stripped qualifiers to
> begin with.

Related: bug 65455. Marek Polacek has been posting patches to the gcc-patches
mailing list towards solving this; latest message in the chain was:
https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01146.html
Assigning this to him since he's already been working on it anyways.

[Bug c/37874] gcc sometimes accepts attribute in identifier list

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #5 from Eric Gallager  ---
(In reply to Chris Lattner from comment #0)
> GCC rejects the former, but not the later.
> 
> void f2(y, __attribute__(()) x);
> void f3(__attribute__(()) x, y);

GCC can be made to reject f3() with -Werror:

$ /usr/local/bin/gcc -c -Wall -Wextra -pedantic -Werror 37874.c
37874.c:1:12: error: expected ‘)’ before ‘__attribute__’
 void f2(y, __attribute__(()) x);
^
37874.c:2:1: error: parameter names (without types) in function declaration
[-Werror]
 void f3(__attribute__(()) x, y);
 ^~~~
cc1: all warnings being treated as errors

I see you fixed this for f4() at least for clang:

$ /sw/opt/llvm-3.1/bin/clang-3.1 -c 37874.c
37874.c:1:12: error: expected identifier
void f2(y, __attribute__(()) x);
   ^
37874.c:2:27: warning: type specifier missing, defaults to 'int'
[-Wimplicit-int]
void f3(__attribute__(()) x, y);
~ ^
37874.c:2:30: warning: type specifier missing, defaults to 'int'
[-Wimplicit-int]
void f3(__attribute__(()) x, y);
 ^
37874.c:3:9: error: expected parameter declarator
void f4(__attribute__(()));
^
2 warnings and 2 errors generated.

[Bug libstdc++/80553] std::vector allows instantiation with type having a deleted destructor

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
Author: redi
Date: Tue Jul 25 18:05:13 2017
New Revision: 250539

URL: https://gcc.gnu.org/viewcvs?rev=250539=gcc=rev
Log:
PR libstdc++/80553 don't allow destroying non-destructible types

Backport from mainline
2017-04-28  Jonathan Wakely  

PR libstdc++/80553
* include/bits/stl_construct.h (_Destroy, _Destroy_n): Add static
assertions to ensure type is destructible.
(destroy_at, destroy, destroy_n): Move from stl_uninitialized.h.
* include/bits/stl_uninitialized.h (destroy_at, destroy, destroy_n):
Move to stl_construct.h.
* testsuite/20_util/specialized_algorithms/memory_management_tools/
destroy_neg.cc: New test.
* testsuite/23_containers/vector/cons/destructible_neg.cc: New test.

Added:
   
branches/gcc-7-branch/libstdc++-v3/testsuite/20_util/specialized_algorithms/memory_management_tools/destroy_neg.cc
   
branches/gcc-7-branch/libstdc++-v3/testsuite/23_containers/vector/cons/destructible_neg.cc
Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
branches/gcc-7-branch/libstdc++-v3/include/bits/stl_construct.h
branches/gcc-7-branch/libstdc++-v3/include/bits/stl_uninitialized.h

[Bug libstdc++/81017] Class with vector of unique_ptr and std::function does not compile

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
Author: redi
Date: Tue Jul 25 18:04:54 2017
New Revision: 250536

URL: https://gcc.gnu.org/viewcvs?rev=250536=gcc=rev
Log:
PR libstdc++/81017 add noexcept to std::function move operations

Backport from mainline
2017-06-08  Jonathan Wakely  

PR libstdc++/81017
* include/bits/std_function.h (function::function(function&&))
(function::operator=(funtion&&)): Add noexcept.
* testsuite/20_util/function/assign/move.cc: Check for noexcept.
* testsuite/20_util/function/cons/move.cc: Likewise.

Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
branches/gcc-7-branch/libstdc++-v3/include/bits/std_function.h
   
branches/gcc-7-branch/libstdc++-v3/testsuite/20_util/function/assign/move.cc
branches/gcc-7-branch/libstdc++-v3/testsuite/20_util/function/cons/move.cc

[Bug c++/80737] variant as class member resulting to compile errors

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
Author: redi
Date: Tue Jul 25 18:04:27 2017
New Revision: 250532

URL: https://gcc.gnu.org/viewcvs?rev=250532=gcc=rev
Log:
PR libstdc++/80737 backport std::variant fix from mainline

Backport from mainline
2017-05-20  Tim Shen  

PR libstdc++/80737
* include/std/variant(variant::variant): SFINAE on is_same first.
* testsuite/20_util/variant/any.cc: test case.

Added:
branches/gcc-7-branch/libstdc++-v3/testsuite/20_util/variant/any.cc
Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
branches/gcc-7-branch/libstdc++-v3/include/std/variant

[Bug libstdc++/80939] Various helper function templates in incorrectly marked constexpr

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Tue Jul 25 18:04:32 2017
New Revision: 250533

URL: https://gcc.gnu.org/viewcvs?rev=250533=gcc=rev
Log:
PR libstdc++/80939 Remove unmeetable constexpr specifiers

Backport from mainline
2017-06-02  Jonathan Wakely  

PR libstdc++/80939
* include/std/variant (__erased_ctor, __erased_assign, __erased_swap)
(__erased_hash): Remove constexpr specifier and qualify calls to
__ref_cast.
(__erased_dtor): Remove constexpr specifier and use _Destroy.

Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
branches/gcc-7-branch/libstdc++-v3/include/std/variant

[Bug c/41027] Missing warning from -Wc++-compat

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #1 from Eric Gallager  ---
gcc now prints this warning for the testcase:

$ /usr/local/bin/gcc -c -Wc++-compat 41027.c
41027.c: In function ‘h’:
41027.c:10:11: warning: uninitialized const member in ‘struct f’ is invalid in
C++ [-Wc++-compat]
  struct f h;
   ^
41027.c:3:12: note: ‘a’ should be initialized
  const int a;
^

So apparently this was fixed somewhere along the way.

[Bug sanitizer/81275] [5/6/7/8 Regression] -fsanitize=thread produce incorrect -Wreturn-type warning

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
To get rid of the warning just with -fsanitize=threads we could do:
--- gcc/tree-eh.c.jj2017-07-14 13:04:47.0 +0200
+++ gcc/tree-eh.c   2017-07-25 17:09:58.279461377 +0200
@@ -1598,7 +1598,8 @@ decide_copy_try_finally (int ndests, boo
  gimple *stmt = gsi_stmt (gsi);
  if (!is_gimple_debug (stmt)
  && !gimple_clobber_p (stmt)
- && !gimple_call_builtin_p (stmt, BUILT_IN_STACK_RESTORE))
+ && !gimple_call_builtin_p (stmt, BUILT_IN_STACK_RESTORE)
+ && !gimple_call_internal_p (stmt, IFN_TSAN_FUNC_EXIT))
return false;
}
   return true;

at the expense of (-O0) having more __tsan_func_exit calls but on the other
side perhaps simpler code.
But that doesn't solve the #c2 testcase where we'd warn anyway.
The problem is that for:
  switch (a) , case 0: >
  :
  switch (b) >
  :
  D.2315 = 0;
  return D.2315;
  goto ;
  :
  D.2315 = 0;
  return D.2315;
  :
this ends with a label and thus gimple_seq_may_fallthru returns true, even when
the only goto to that label is dead.  I guess we need to improve switch
expansion for these pathological cases.

[Bug c++/60517] warning/error for taking address of member of a temporary object

[lopezibanez at gmail dot com]

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

--- Comment #24 from Manuel López-Ibáñez  ---
How does typeck.c check that it is a temporary? The important thing is not
that it is an ARRAY_REF but that it is a member of a temporary object. Not
sure how to check that.

Marc points above that the FE introduces a clobber to mark the death of the
temporary, so it knows.

The problem of warning for artificials is that optimization passes create
and read uninitialized memory if this provides an advantage and it doesn't
change the behaviour of the code. Warning about those would be very
annoying, if the user code is correct.

[Bug target/81521] [8 Regression] After [r250413] GCC 8.0 doesn't compile for Windows

[wilson at gcc dot gnu.org]

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

Jim Wilson  changed:

   What|Removed |Added

 CC||wilson at gcc dot gnu.org

--- Comment #5 from Jim Wilson  ---
With my followup patch, I was able to do a i686-pc-cygwin gcc bootstrap.  I
have not tested mingw-w64.

[Bug c/19972] -Wreturn-local-addr misses return of local (nested) function pointer

[patrick.pelissier at gmail dot com]

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

--- Comment #3 from Patrick Pelissier  ---
I have tested with GCC 7.1.0 the code of #0 (forget the function h, this was
only a reference) and the status is the same as described in #0.

For the following code,

int (*apply (int (*f) (const void *, const void *), void *a))(const void *)
{
  int g(const void * b) { return f(a,b); };
  return 
}

I get no warning for returning the nested function 'g'.

[Bug target/81551] [ARM] Incorrect STRD to misaligned address.

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Closing as invalid then.

[Bug fortran/81552] New: -finit-integer=n

[poupycle at hotmail dot fr]

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

Bug ID: 81552
   Summary: -finit-integer=n
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: poupycle at hotmail dot fr
  Target Milestone: ---

Hello, 

  If I put the option : -fdefault-integer-8 it is not taken into account to
define the value in -finit-integer=N

  In fact, N is an 32-bit INTEGER in the range [-2147483648 ; 2147483647]

Analyse : 

In the file fortran/options.c you can define the value : 
case OPT_finit_integer_:
  gfc_option.flag_init_integer = GFC_INIT_INTEGER_ON;
  gfc_option.flag_init_integer_value = atoi (arg);
  break;

  but atoi is an INT function...

In the file fortran/fortran.h the structure gfc_option is defined :
/* Structure for holding compile options */
typedef struct
{
  char *module_dir;
  gfc_source_form source_form;
  int max_continue_fixed;
  int max_continue_free;
  int max_identifier_length;

  int max_errors;

  int flag_preprocessed;
  int flag_d_lines;
  int flag_init_integer;
  int flag_init_integer_value;
  int flag_init_logical;
  int flag_init_character;
  char flag_init_character_value;

  int fpe;
  int fpe_summary;
  int rtcheck;

  int warn_std;
  int allow_std;
}
gfc_option_t;

extern gfc_option_t gfc_option;

  Here again flag_init_integer_value is an INTEGER 32-bits


is it possible to make the flag_init_integer_value compatible with the
-fdefault-integer-8 ?


Best Regard
Poupycle

[Bug target/81521] [8 Regression] After [r250413] GCC 8.0 doesn't compile for Windows

[wilson at gcc dot gnu.org]

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

--- Comment #4 from Jim Wilson  ---
Author: wilson
Date: Tue Jul 25 16:06:37 2017
New Revision: 250529

URL: https://gcc.gnu.org/viewcvs?rev=250529=gcc=rev
Log:
Fix i686-pc-cygwin build failure.

gcc/
PR bootstrap/81521
* config/i386/winnt-cxx.c (i386_pe_adjust_class_at_definition): Look
for FUNCTION_DECLs in TYPE_FIELDS rather than TYPE_METHODS.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/winnt-cxx.c

[Bug c++/60517] warning/error for taking address of member of a temporary object

[fredrik.hederstie...@securitas-direct.com]

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

--- Comment #23 from Fredrik Hederstierna 
 ---
Ah ok, yes I think you are right. The check could possibly be in "cp/typeck.c"
and "cp/tree.c"? but I'm not familiar with this C++ parsing code.

Interesting that this code gets warning:

  B* foo(A a) {
B *b = &(a.getB());
return b;
  }

test.c: In function ‘B* foo2(A)’:
test.c:28:20: error: taking address of temporary [-fpermissive]
   B *b = &(a.getB());

but this does not (as you example)

  double foo(A a) {
double *x = &(a.getB().x[0]);
return x[0];
  }

though the addressing taken was done implicit when taking addressing of the
array x?

Checking flow in "typeck.c", it does not give warning since the 'kind' of
lvalue is not clk_class but clk_ordinary in latter case since its ARRAY_REF.
The warning-code in typeck.c does check for this, but I saw that recently some
code was made to consider an array to be a 'class' in PR 80415 patch:

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

Could it be possible to also include more 'kinds' or types in the warning-test
to also include this example?

Though checking this small patch will trigger the warning, but probably its not
the right thing to do, but maybe a starting point to seek for a solution?

diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c  
index 2122450..4dab925 100644   
--- a/gcc/cp/tree.c 
+++ b/gcc/cp/tree.c 
@@ -163,7 +163,6 @@ lvalue_kind (const_tree ref)
   /* FALLTHRU */
 case INDIRECT_REF:
 case ARROW_EXPR:
-case ARRAY_REF:
 case ARRAY_NOTATION_REF:
 case PARM_DECL:
 case RESULT_DECL:
@@ -212,6 +211,7 @@ lvalue_kind (const_tree ref)
 case COMPOUND_EXPR:
   return lvalue_kind (TREE_OPERAND (ref, 1));

+case ARRAY_REF:
 case TARGET_EXPR:
   return clk_class;

This will return lvalue 'kind' as clk_class also for arrays, and then the
warning will trigger in typeck.c. Probably this is just nonsense, so I will
leave this to someone else to solve that understands this part of code (not
me).

Still I think other path is also interesting about warning for uninitialized
artificials (that was removed in PR 43347 by unclear reasons - I think the
warning was correct, and the issue was rather that generated SRA name was not
the real variable name, which is a completely other problem related to debug
info I think)...

[Bug target/81551] [ARM] Incorrect STRD to misaligned address.

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #1 from ktkachov at gcc dot gnu.org ---
See PR81273.
GCC doesn't parse the literal to determine the alignment. It takes the
alignment information from the type (long long).

[Bug target/81551] New: [ARM] Incorrect STRD to misaligned address.

[belagod at gcc dot gnu.org]

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

Bug ID: 81551
   Summary: [ARM] Incorrect STRD to misaligned address.
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: belagod at gcc dot gnu.org
  Target Milestone: ---

For this piece of code:

void foo ()
{
  *((long long*)0x2000213F) = 0;
}

when compiled with

$ arm-none-eabi-gcc -S -march=armv7-a /tmp/strd.c -O0 -marm -o -

It generates an STRD to a misaligned address

.type   foo, %function
foo:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 1, uses_anonymous_args = 0
@ link register save eliminated.
str fp, [sp, #-4]!
add fp, sp, #0
movwr3, #8511
movtr3, 8192
mov r0, #0
mov r1, #0
strdr0, [r3]
nop
add sp, fp, #0
@ sp needed
ldr fp, [sp], #4
bx  lr
.size   foo, .-foo

but for -O1 and above:

foo:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
mov r3, #8448
movtr3, 8192
mov r2, #0
strbr2, [r3, #63]
strbr2, [r3, #64]
strbr2, [r3, #65]
strbr2, [r3, #66]
strbr2, [r3, #67]
strbr2, [r3, #68]
strbr2, [r3, #69]
strbr2, [r3, #70]
bx  lr

$ ./arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=./arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/data/embedded/dev-builds/trunk/install/libexec/gcc/arm-none-eabi/8.0.0/lto-wrapper
Target: arm-none-eabi
Configured with: /data/embedded/dev-builds/trunk/src/configure
--prefix=/data/embedded/dev-builds/trunk/install --target=arm-none-eabi
--enable-languages=c,c++ --with-cpu=cortex-m3 --with-mode=thumb --with-newlib
--enable-newlib-io-long-long --enable-newlib-register-fini
--enable-newlib-retargetable-locking --disable-newlib-supplied-syscalls
--disable-multilib --with-libexpat --with-system-zlib --disable-gdbtk
--enable-plugins --disable-threads --disable-tls --disable-libgomp
--disable-libmudflap --disable-libquadmath --disable-libssp
--disable-libstdcxx-pch --disable-nls --disable-rda --disable-sid --disable-tui
--disable-utils --disable-werror --disable-fixed-point
Thread model: single
gcc version 8.0.0 20170725 (experimental) (GCC)

[Bug target/81550] New: [8 regression] gcc.target/powerpc/loop_align.c fails starting with r250482

[seurer at gcc dot gnu.org]

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

Bug ID: 81550
   Summary: [8 regression] gcc.target/powerpc/loop_align.c fails
starting with r250482
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

spawn /home/seurer/gcc/build/gcc-test3/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test3/gcc/
/home/seurer/gcc/gcc-test3/gcc/testsuite/gcc.target/powerpc/loop_align.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -mcpu=power7
-falign-functions=16 -ffat-lto-objects -S -o loop_align.s
PASS: gcc.target/powerpc/loop_align.c (test for excess errors)
FAIL: gcc.target/powerpc/loop_align.c scan-assembler .p2align 5,,31

seurer@genoa:~/gcc/build/gcc-test2$ diff loop_align.s.r250481
loop_align.s.r250482
12,16c12,17
<   li 9,0
<   rldicl 6,6,0,32
<   addi 10,6,1
<   mtctr 10
<   .p2align 5,,31
---
>   addi 9,4,-8
>   rldic 6,6,3,29
>   addi 5,5,-8
>   add 4,4,6
>   addi 3,3,-8
>   .p2align 4,,15
18,19c19,21
<   lfdx 0,4,9
<   lfdx 12,5,9
---
>   lfdu 0,8(9)
>   lfdu 12,8(5)
>   cmpld 7,9,4
21,23c23,30
<   stfdx 0,3,9
<   addi 9,9,8
<   bdnz .L3
---
>   stfdu 0,8(3)
>   beqlr 7
>   lfdu 0,8(9)
>   lfdu 12,8(5)
>   cmpld 7,9,4
>   fadd 0,0,12
>   stfdu 0,8(3)
>   bne 7,.L3
28c35
<   .ident  "GCC: (GNU) 8.0.0 20170724 (experimental) [trunk revision
250481]"
---
>   .ident  "GCC: (GNU) 8.0.0 20170724 (experimental) [trunk revision 
> 250482]"

[Bug sanitizer/81275] [5/6/7/8 Regression] -fsanitize=thread produce incorrect -Wreturn-type warning

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
You get the same thing with any other cleanup, say:
struct C { C (); ~C (); };
int
foo (int a, int b)
{
  C c;
  switch (a)
{
case 0:
  switch (b)
{
default:
  return 0;
}
  break;
default:
  return 0;
}
}
with just -Wreturn-type will warn too.  And no optimizations, with -O1 and
above the eh pass optimizes it away.

[Bug c/63878] Variables of incomplete type can be defined with -fno-fat-lto-objects

[egallager at gcc dot gnu.org]

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

Bug 24293 Summary: Undefined behaviour not diagnosed with -fsyntax-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24293

   What|Removed |Added

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

[Bug c/24293] Undefined behaviour not diagnosed with -fsyntax-only

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #7 from Eric Gallager  ---
(In reply to prathamesh3492 from comment #6)
> Fixed on trunk.

Closing as FIXED then.

[Bug c/39117] missed strict-aliasing warning

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||egallager at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
(In reply to Benjamin Kosnik from comment #0)
> From this thread:
> http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00271.html
> 
> Compiling with -c -g -O2 -Wall from r143978, I only get one warning, but
> should get two.
> 
> struct A 
> { 
>   int j;
>   int i; 
> };
> 
> void foo()
> {
>   char buf[sizeof(struct A)];
> 
>   // warns
>   ((struct A*)buf)->i = 1;
>  
>   // does not warn
>   struct A* p = (struct A*) buf;
>   p->i = 4;
> }
> 
> Gives:
> alias2.c: In function ‘void foo()’:
> alias2.c:12: warning: dereferencing type-punned pointer will break
> strict-aliasing rules

Trying again with newer trunk, and I don't even get the first warning! GCC is
completely silent with all of these: 

$ /usr/local/bin/gcc -c -g -O2 -Wall 39117.c
$ /usr/local/bin/gcc -c -g -O2 -Wstrict-aliasing=1 39117.c
$ /usr/local/bin/gcc -c -g -O2 -Wstrict-aliasing=2 39117.c
$ /usr/local/bin/gcc -c -g -O2 -Wstrict-aliasing=3 39117.c
$ /usr/local/bin/gcc -c -g -O1 -Wall 39117.c
$ /usr/local/bin/gcc -c -g -O0 -Wall 39117.c
$ /usr/local/bin/gcc -c -g -Og -Wall 39117.c
$ /usr/local/bin/gcc -c -g -Os -Wall 39117.c
$ /usr/local/bin/gcc -c -g -O3 -Wall 39117.c
$ /usr/local/bin/gcc -c -g -Ofast -Wall 39117.c
$

[Bug target/81407] [avr] Diagnose if a variable in progmem needs constructing.

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Target Milestone|8.0 |7.2

[Bug target/81407] [avr] Diagnose if a variable in progmem needs constructing.

[gjl at gcc dot gnu.org]

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

--- Comment #3 from Georg-Johann Lay  ---
Author: gjl
Date: Tue Jul 25 14:32:30 2017
New Revision: 250522

URL: https://gcc.gnu.org/viewcvs?rev=250522=gcc=rev
Log:
gcc/
Backport from 2017-07-12 trunk r250151.
PR target/81407
* config/avr/avr.c (avr_encode_section_info)
[progmem && !TREE_READONLY]: Error if progmem object needs
constructing.

Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/avr/avr.c

[Bug other/56780] --disable-install-libiberty still installs libiberty.a

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #10 from Eric Gallager  ---
(In reply to Mike Frysinger from comment #9)
> http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00213.html has been committed
> now which should fix trunk

Assuming the fix was successful; closing

[Bug target/81532] [8 Regression] insn does not satisfy its constraints: extract_constrain_insn, at recog.c:2213

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Fixed.  Yd/Ye doesn't exist in gcc 7 and earlier.

[Bug rtl-optimization/81538] Optimization problem compiling op.c (Perl_custom_op_get_field) in perl 5.26

[dave.anglin at bell dot net]

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

--- Comment #4 from dave.anglin at bell dot net ---
On 2017-07-25, at 3:46 AM, rguenth at gcc dot gnu.org wrote:

> Any other compiler versions to put in known-to-work/fail?

The fault doesn't occur with gcc-7:
gcc version 7.1.0 (Debian 7.1.0-9).  Will check gcc-5 when current build
completes.

--
John David Anglin   dave.ang...@bell.net

[Bug tree-optimization/81549] PHI node should be eliminated if loop iterates enough times.

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de  ---
On Tue, 25 Jul 2017, amker at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81549
> 
> --- Comment #2 from amker at gcc dot gnu.org ---
> (In reply to Richard Biener from comment #1)
> > Confirmed.  This is sort of final value replacement (but not SCEV based).
> Hi, do we have dedicated pass responsible for this transformation?  Thanks.

Yes, pass_scev_cprop.

[Bug tree-optimization/81549] PHI node should be eliminated if loop iterates enough times.

[amker at gcc dot gnu.org]

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

--- Comment #3 from amker at gcc dot gnu.org ---
(In reply to amker from comment #2)
> (In reply to Richard Biener from comment #1)
> > Confirmed.  This is sort of final value replacement (but not SCEV based).
Hmm, it could be SCEV based if we recognize/support more kinds of scalar
evolution.
> Hi, do we have dedicated pass responsible for this transformation?  Thanks.

[Bug tree-optimization/81549] PHI node should be eliminated if loop iterates enough times.

[amker at gcc dot gnu.org]

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

--- Comment #2 from amker at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
> Confirmed.  This is sort of final value replacement (but not SCEV based).
Hi, do we have dedicated pass responsible for this transformation?  Thanks.

[Bug c/81544] attribute noreturn and warn_unused_result on the same function accepted

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-07-25
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug other/56860] Texinfo bug in doc/cppopts.texi

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #1 from Eric Gallager  ---
(In reply to David Narváez from comment #0)
> Could revision 192887 be backported to 4.7.2?

Seeing as the 4.7 branch has been closed for some time now, sorry, but I guess
it's too late for that.

[Bug target/81532] [8 Regression] insn does not satisfy its constraints: extract_constrain_insn, at recog.c:2213

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jul 25 13:35:17 2017
New Revision: 250520

URL: https://gcc.gnu.org/viewcvs?rev=250520=gcc=rev
Log:
PR target/81532
* config/i386/constraints.md (Yd, Ye): Use ALL_SSE_REGS for
TARGET_AVX512DQ rather than TARGET_AVX512BW.

* gcc.target/i386/pr80833-3.c: New test.
* gcc.target/i386/avx512dq-pr81532.c: New test.
* gcc.target/i386/avx512bw-pr81532.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/avx512bw-pr81532.c
trunk/gcc/testsuite/gcc.target/i386/avx512dq-pr81532.c
trunk/gcc/testsuite/gcc.target/i386/pr80833-3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/constraints.md
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/81549] PHI node should be eliminated if loop iterates enough times.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-25
 CC||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  This is sort of final value replacement (but not SCEV based).

[Bug other/49578] Profiling: call graph table overflows on Solaris.

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #2 from Eric Gallager  ---
Reporter emailed me to say he no longer has Solaris machines for testing an
updated patch and that it's okay if this never gets fixed. So I'm closing it.
Anyone who does have Solaris who does actually want to see this fixed can feel
free to reopen if necessary.

[Bug tree-optimization/81455] [7 Regression] Compile-time hog w/ -O1 -funswitch-loops

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||8.0
Summary|[7/8 Regression]|[7 Regression] Compile-time
   |Compile-time hog w/ -O1 |hog w/ -O1 -funswitch-loops
   |-funswitch-loops|

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Tue Jul 25 13:24:51 2017
New Revision: 250518

URL: https://gcc.gnu.org/viewcvs?rev=250518=gcc=rev
Log:
2017-07-25  Richard Biener  

PR tree-optimization/81455
* tree-ssa-loop-unswitch.c (find_loop_guard): Make sure to
not walk in cycles when looking for guards.

* gcc.dg/pr81455.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/pr81455.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-unswitch.c

[Bug tree-optimization/81455] [7 Regression] Compile-time hog w/ -O1 -funswitch-loops

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||8.0
Summary|[7/8 Regression]|[7 Regression] Compile-time
   |Compile-time hog w/ -O1 |hog w/ -O1 -funswitch-loops
   |-funswitch-loops|

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Tue Jul 25 13:24:51 2017
New Revision: 250518

URL: https://gcc.gnu.org/viewcvs?rev=250518=gcc=rev
Log:
2017-07-25  Richard Biener  

PR tree-optimization/81455
* tree-ssa-loop-unswitch.c (find_loop_guard): Make sure to
not walk in cycles when looking for guards.

* gcc.dg/pr81455.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/pr81455.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-unswitch.c

[Bug tree-optimization/81529] [8 Regression] ICE in vectorizable_induction, at tree-vect-loop.c:6613

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Tue Jul 25 13:22:31 2017
New Revision: 250517

URL: https://gcc.gnu.org/viewcvs?rev=250517=gcc=rev
Log:
2017-07-25  Richard Biener  

PR tree-optimization/81529
* tree-vect-stmts.c (process_use): Disregard live induction PHIs
when optimizing backedge uses.

* gfortran.dg/pr81529.f90: New testcase.

Added:
trunk/gcc/testsuite/gfortran.dg/pr81529.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-stmts.c

[Bug tree-optimization/81529] [8 Regression] ICE in vectorizable_induction, at tree-vect-loop.c:6613

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug target/79041] aarch64 backend emits R_AARCH64_ADR_PREL_PG_HI21 relocation despite -mpc-relative-literal-loads option being used

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #9 from Wilco  ---
Fixed in GCC7 and trunk. GCC6 requires
https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01708.html.

[Bug tree-optimization/81488] [8 Regression] gcc goes off the limits allocating memory in gimple-ssa-strength-reduction.c

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #2 from Bill Schmidt  ---
Mine.  Please be patient while I work through the sudden influx of bug reports.

[Bug tree-optimization/81549] New: PHI node should be eliminated if loop iterates enough times.

[amker at gcc dot gnu.org]

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

Bug ID: 81549
   Summary: PHI node should be eliminated if loop iterates enough
times.
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amker at gcc dot gnu.org
  Target Milestone: ---

Given below test:

int a[1], b[1], c[1];
int f(void)
{
  int i, n = 100;
  int t0 = a[0];
  int t1 = a[1];
 for (i = 0; i < n; i++)
   {
 a[i] = 1;
 int t2 = 2;
 t0 = t1;
 t1 = t2;
   }
 a[n] = t0;
 a[n+1] = t1;
  return 0;
}
Compile it at Ofast by default, the optimized dump is as:

   [1.00%] [count: INV]:
  t1_8 = a[1];
  ivtmp.9_17 = (unsigned long) 
  _16 = ivtmp.9_17 + 400;

   [99.00%] [count: INV]:
  # t1_20 = PHI <2(3), t1_8(2)>
  # ivtmp.9_2 = PHI 
  _15 = (void *) ivtmp.9_2;
  MEM[base: _15, offset: 0B] = 1;
  ivtmp.9_1 = ivtmp.9_2 + 4;
  if (ivtmp.9_1 != _16)
goto ; [98.99%] [count: INV]
  else
goto ; [1.01%] [count: INV]

   [1.00%] [count: INV]:
  a[100] = t1_20;
  a[101] = 2;
  return 0;

We now eliminate one phi and leave another behind.  It is vrp1/dce2 when the
phi is eliminated.

[Bug tree-optimization/81503] [8 Regression] Wrong code at -O2

[wschmidt at gcc dot gnu.org]

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

--- Comment #7 from Bill Schmidt  ---
Try -fno-slsr.

[Bug fortran/79930] Potentially Missed Optimisation for MATMUL / DOT_PRODUCT

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #16 from Thomas Koenig  ---
Let's keep this as a speed improvement for 8.1.

Closing

[Bug libfortran/80365] undefined memcpy while writing zero length array on unformatted stream in unix.c

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #7 from Thomas Koenig  ---
From the lack of reaction, no interest in backporting.

Closing.

[Bug target/79793] Incorrect stack alignment for interrupt handler in 64-bit

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

  Attachment #41826|0   |1
is obsolete||
  Attachment #41828|0   |1
is obsolete||

--- Comment #13 from H.J. Lu  ---
Created attachment 41830
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41830=edit
An untested patch

The only interrupt failures are

FAIL: gcc.dg/guality/pr68037-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 33 error == 0x12345670
FAIL: gcc.dg/guality/pr68037-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 33 frame->ip == 0x12345671
FAIL: gcc.dg/guality/pr68037-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 33 frame->cs == 0x12345672
FAIL: gcc.dg/guality/pr68037-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 33 frame->flags == 0x12345673
FAIL: gcc.dg/guality/pr68037-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 33 frame->sp == 0x12345674
FAIL: gcc.dg/guality/pr68037-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 33 frame->ss == 0x12345675

[Bug c++/81533] g++ pops up a constructor for objects that could be initialized at load-time

[gjl at gcc dot gnu.org]

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

--- Comment #2 from Georg-Johann Lay  ---
(In reply to Richard Biener from comment #1)
> I think there's a separate PR with the suggestion to try constexpr
> evaluation of all constructors for optimization.

Addresses are not constexpr because they are not known at compile-time.

[Bug tree-optimization/49857] Put constant switch-tables into flash

[gjl at gcc dot gnu.org]

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

--- Comment #16 from Georg-Johann Lay  ---
(In reply to Georg-Johann Lay from comment #15)
> pr49857-v2-all.diff: Proposed patch

Problems so far:

* ivopts may shred address-space which results in wrong code.  This is is the
  reason for why the patch doesn't -maddr-space-for-lookup=memx

$ make -k check-gcc RUNTESTFLAGS="--target_board=atmega128-sim
execute.exp='20120808-1.c pr35800.c' --tool_opts=-maddr-space-for-lookup=memx"

* tree-swich-conversion might bloat the code, cf. PR81540 so it may even
  be better to disable tree-switch-conversion per default.

[Bug tree-optimization/49857] Put constant switch-tables into flash

[gjl at gcc dot gnu.org]

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

--- Comment #15 from Georg-Johann Lay  ---
Created attachment 41829
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41829=edit
pr49857-v2-all.diff: Proposed patch

PR 49857
* target.def (TARGET_ADDR_SPACE_FOR_ARTIFICIAL_RODATA): New hook.
* targhooks.c (default_addr_space_for_artificial_rodata): New function.
* targhooks.h (default_addr_space_for_artificial_rodata): New proto.
* tree-switch-conversion.c (target.h): Include it.
(build_one_array): Set address space of array_type according to
targetm.addr_space.for_artificial_rodata().
* doc/tm.texi.in (Named Address Spaces)
[TARGET_ADDR_SPACE_FOR_ARTIFICIAL_RODATA]: Add hook anchor.
* doc/tm.texi: Regenerate.

* config/avr/avr-opts.h: New file.
* config/avr/avr.opt: Include it.
(-maddr-space-for-lookup=): New option and...
(avr_opt_addr_space_for_lookup): ...associated Var.
(avr_aspace_for_lookup): New option enums used by above.
* config/avr/avr-protos.h (avr_out_load_flashx): New proto.
* config/avr/avr.c (avr_out_load_flashx): New function.
* avr_adjust_insn_length [ADJUST_LEN_LOAD_FLASHX]: Handle it.
* avr_rtx_costs_1 [ZERO_EXTEND, SIGN_EXTEND]: Handle
shift-and-extend-by-1 of HI -> PSI.
[ASHIFT,PSImode]: Describe cost of extend-and-shift-by-1.
(TARGET_ADDR_SPACE_FOR_ARTIFICIAL_RODATA): Define to...
(avr_addr_space_for_artificial_rodata): ...this new static function.
* config/avr/avr.md (unspec): Add UNSPEC_LOAD_FLASHX.
(adjust_len): Add load_flashx.
(*ashiftpsi.1_sign_extend.hi, *ashiftpsi.1_zero_extend.hi)
(*extendpsi.ashift.1.uqi, *load-flashx): New insns.
(*split_xload-cswtch): New insn-and-split.
* doc/invoke.texi (AVR Options) <-maddr-space-for-lookup=>: Document.

[Bug target/79041] aarch64 backend emits R_AARCH64_ADR_PREL_PG_HI21 relocation despite -mpc-relative-literal-loads option being used

[wilco at gcc dot gnu.org]

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

--- Comment #8 from Wilco  ---
Author: wilco
Date: Tue Jul 25 12:08:59 2017
New Revision: 250514

URL: https://gcc.gnu.org/viewcvs?rev=250514=gcc=rev
Log:
Fix PR79041

As described in PR79041, -mcmodel=large -mpc-relative-literal-loads
may be used to avoid generating ADRP/ADD or ADRP/LDR.  However both
trunk and GCC7 may still emit ADRP for some constant pool literals.
Fix this by adding a aarch64_pcrelative_literal_loads check.

gcc/
PR target/79041
* config/aarch64/aarch64.c (aarch64_classify_symbol):
Avoid SYMBOL_SMALL_ABSOLUTE for literals with pc-relative literals.
gcc/testsuite/
* gcc.target/aarch64/pr79041-2.c: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.target/aarch64/pr79041-2.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/aarch64/aarch64.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug target/79793] Incorrect stack alignment for interrupt handler in 64-bit

[hjl.tools at gmail dot com]

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

--- Comment #12 from H.J. Lu  ---
Created attachment 41828
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41828=edit
An updated patch

Update gcc.dg/guality/pr68037-1.c.  I got

FAIL: gcc.dg/guality/pr68037-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 33 error == 0x12345670
FAIL: gcc.dg/guality/pr68037-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 33 frame->ip == 0x12345671
FAIL: gcc.dg/guality/pr68037-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 33 frame->cs == 0x12345672
FAIL: gcc.dg/guality/pr68037-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 33 frame->flags == 0x12345673
FAIL: gcc.dg/guality/pr68037-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 33 frame->sp == 0x12345674
FAIL: gcc.dg/guality/pr68037-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 33 frame->ss == 0x12345675

and

Running target unix/-m32
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using /export/gnu/import/git/sources/gcc/gcc/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/i386.exp ...
FAIL: gcc.target/i386/interrupt-12.c scan-assembler-times movl[\\t
]*-4\\(%ebp\\),[\\t ]*%eax 1
FAIL: gcc.target/i386/interrupt-13.c scan-assembler-times movl[\\t
]*-4\\(%ebp\\),[\\t ]*%eax 1
FAIL: gcc.target/i386/interrupt-15.c scan-assembler-times movl[\\t
]*-4\\(%ebp\\),[\\t ]*%eax 2

=== gcc Summary for unix/-m32 ===

# of expected passes211
# of unexpected failures3
# of unsupported tests  2

[Bug rtl-optimization/75964] insn combiner removes comparison after ABS

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||6.4.1, 7.1.1
 Resolution|--- |FIXED

--- Comment #10 from Georg-Johann Lay  ---
Fixed in v7.2 + v6.5.