[Bug c/77992] Failures to initialize padding bytes -- causing many information leaks

[kjlu at gatech dot edu]

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

--- Comment #9 from Kangjie Lu  ---
(In reply to Andrew Pinski from comment #8)
> A simple google search (secure memset [glibc]) finds a few things:
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1381.pdf
> 
> https://sourceware.org/ml/libc-alpha/2014-12/msg00506.html
> 
> https://www.securecoding.cert.org/confluence/display/c/MSC06-C.
> +Beware+of+compiler+optimizations
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8537

Thanks for sharing these interesting links. 
Sure, compiler optimizations sometime may aggressively eliminate dead code.

As I mentioned in my last reply, this is not a problem in our work because
our instrumentation is inserted after all LLVM optimization passes. 
The inserted memset will not be removed.

Back to my original problem, many Linux kernel developers also hope GCC can 
provide a feature (like a compilation option) that can zero-initialize 
padding bytes. Fixing these information leaks manually will make the code
maintenance extremely difficult.  
Anyway, I just wanted to report this issue :)

[Bug c/77992] Failures to initialize padding bytes -- causing many information leaks

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski  ---
A simple google search (secure memset [glibc]) finds a few things:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1381.pdf

https://sourceware.org/ml/libc-alpha/2014-12/msg00506.html

https://www.securecoding.cert.org/confluence/display/c/MSC06-C.+Beware+of+compiler+optimizations

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

[Bug c/77992] Failures to initialize padding bytes -- causing many information leaks

[kjlu at gatech dot edu]

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

--- Comment #7 from Kangjie Lu  ---
(In reply to Andrew Pinski from comment #6)
> >More information can be found in our research paper: 
> >http://www.cc.gatech.edu/~klu38/publications/unisan-ccs16.pdf
> 
> 
> You research paper is wrong and does not consider C is an inherently
> insecure language to be begin with.  There are many other things wrong with
> it.  Like for an example recommending the use of memset when you want to
> hide the stores from the compiler.  There is already a thread on the glibc
> mailing list about this exact thing about adding a secure memset which is
> GCC is not going to optimize away.

Thanks for your feedback. 
We do think C is not safe language and that's why we want to secure programs 
written in C.
Could you provide me more information about the thread. We use LLVM instead
of GCC. Our instrumentation is inserted after optimization passes.

Thanks!

[Bug c/77992] Failures to initialize padding bytes -- causing many information leaks

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  ---
>More information can be found in our research paper: 
>http://www.cc.gatech.edu/~klu38/publications/unisan-ccs16.pdf


You research paper is wrong and does not consider C is an inherently insecure
language to be begin with.  There are many other things wrong with it.  Like
for an example recommending the use of memset when you want to hide the stores
from the compiler.  There is already a thread on the glibc mailing list about
this exact thing about adding a secure memset which is GCC is not going to
optimize away.

[Bug c/77992] Failures to initialize padding bytes -- causing many information leaks

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|driver  |c
 Resolution|--- |INVALID
   Severity|critical|normal

--- Comment #5 from Andrew Pinski  ---
Again C is not the language you want for this.
Also if you want this you should use a loop which hides the stores from GCC
Using inline-asm.

>Besides performance (I understand that the unaligned initialization could be 
>expensive), any other reasons?

Because there is no reason to do it that way.  You said to initialize only
those fields anyways.

[Bug testsuite/77623] [7 regression] test cases gcc.target/powerpc/warn-1.c and warn-2.c fail starting with r239994

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #2 from Segher Boessenkool  ---
Fixed with r241056, I wasn't aware there was a BZ, sorry.

[Bug middle-end/77989] [7 Regression] -O3 causes verify_gimple fail

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-15
 CC||trippels at gcc dot gnu.org
  Component|c   |middle-end
Summary|-O3 causes verify_gimple|[7 Regression] -O3 causes
   |fail|verify_gimple fail
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
markus@x4 tmp % cat fail.i
int a, d;
char b;
char *c;
void fn1() {
  char *e = 
  c =  + 48;
  while (e < c)
e++;
  e++;
  c =  + a;
  while (e < c)
d += *e++;
}

markus@x4 tmp % gcc -fchecking -O3 -c fail.i
fail.i: In function ‘fn1’:
fail.i:4:5: error: invalid address operand in MEM_REF
 int fn1() {
 ^~~
MEM[(void *) + 49B];

fail.i:4:5: error: invalid first operand of MEM_REF
[(void *) + 49B]
fail.i:12:10: note: in statement
 d += *e++;
  ^~~~
# VUSE <.MEM_59>
_15 = MEM[(void *) + 49B];
fail.i:4: confused by earlier errors, bailing out

[Bug rtl-optimization/77843] ICE for gcc.dg/tree-ssa/forwprop-35.c

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Segher Boessenkool  ---
It is fixed.

[Bug driver/77992] Failures to initialize padding bytes -- causing many information leaks

[kjlu at gatech dot edu]

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

Kangjie Lu  changed:

   What|Removed |Added

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

--- Comment #4 from Kangjie Lu  ---
(In reply to Andrew Pinski from comment #3)
> There is no way in C to do that. If you want a secure language you need
> something different.

Could you please explain why there is no way in C to initialize padding?
Besides performance (I understand that the unaligned initialization could be
expensive), any other reasons?

Thanks!

[Bug driver/77992] Failures to initialize padding bytes -- causing many information leaks

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
There is no way in C to do that. If you want a secure language you need
something different.

[Bug driver/77992] Failures to initialize padding bytes -- causing many information leaks

[kjlu at gatech dot edu]

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

Kangjie Lu  changed:

   What|Removed |Added

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

--- Comment #2 from Kangjie Lu  ---
Then I guess this is an unspecified area in C11.

Anyway, the failure to initialize the padding bytes will cause information
leaks; many leaks have been confirmed.

I would suggest gcc to initialize padding bytes even it is not specified in
C11.


Thanks,
Kangjie

[Bug driver/77992] Failures to initialize padding bytes -- causing many information leaks

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Martin Sebor  ---
As the quoted text states, paragraph 10 applies to objects with static or
thread storage duration.  The object s in the test program has automatic
storage duration, so the requirement doesn't apply, and padding bits are not
required to be initialized.

[Bug driver/77992] New: Failures to initialize padding bytes -- causing many information leaks

[kjlu at gatech dot edu]

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

Bug ID: 77992
   Summary: Failures to initialize padding bytes -- causing many
information leaks
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kjlu at gatech dot edu
  Target Milestone: ---

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

Hello,

I'd like to report an implementation (or even design) problem in GCC.

Chapter §6.7.9/10 in C11:
"If an object that has static or thread storage duration is not initialized
explicitly, then:
...
if it is an aggregate, every member is initialized (recursively) according to
these rules, and any padding is initialized to zero bits;"

According to this specification, padding bytes should be initialized when the
initializer is static.
Take a look at this example (say x86_64):
/
struct S {
long l;
char c;
};

void main () {
struct S s ={
.l = 0,
.c = 0
};
}
/
The developer has carefully initialized all fields with constants.
Object "s" is supposed to be fully initialized, i.e., the seven padding bytes
right after "s.c" are supposed to be initialized.
However, these padding bytes are not initialized in fact. 
In contrast, LLVM would initialize the padding bytes in such a case.

Similarly, when "variables" are used to initialize the fields of "s", padding
bytes are not initialized either, such as:
/
struct S s ={
.l = variable1,
.c = variable2
};
/

Such failures to initialize padding bytes will result in many information
leaks. We have found many information leaks in the Linux kernel.
Here is an example:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-4482
More information can be found in our research paper:
http://www.cc.gatech.edu/~klu38/publications/unisan-ccs16.pdf

The testing program for reproducing the leak is attached.

Testing environment:
"Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
5.4.0-6ubuntu1~16.04.2' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.2)"


My suggestion to reliably address this problem is that padding bytes of an
object, which are implicitly introduced by compilers, should be
zero-initialized upon object allocation.

Please let me know if you need more information or any assistance.

Best Regards,
Kangjie Lu

[Bug libstdc++/77987] unique_ptr<T[]> reset rejects cv-compatible pointers

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Seems simple enough to fix:

@@ -608,8 +608,9 @@
   >
>>
   void
-  reset(_Up __p) noexcept
+  reset(_Up __ptr) noexcept
   {
+   pointer __p = __ptr;
using std::swap;
swap(std::get<0>(_M_t), __p);
if (__p != nullptr)

[Bug middle-end/77991] New: ICE on x32 in plus_constant, at explow.c:87

[kilobyte at angband dot pl]

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

Bug ID: 77991
   Summary: ICE on x32 in plus_constant, at explow.c:87
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kilobyte at angband dot pl
  Target Milestone: ---

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

The attached test case ICEs on x32 target in plus_constant, at explow.c:87,
when compiling with -O1 or higher.  No splat with -O0.

The test case comes from a new version of qemu, where this ICE triggers on a
number of files.  No other target seems to be affected, as qemu built
successfully on all architectures but x32.

Host arch doesn't seem to matter, only target: reproducible with -mx32 on amd64
too.

Reproduced on Debian packages of gcc 5.4.1-2, 6.2.0-6 and 20161006-1 trunk
snapshot.

Minimal invocation:
(on x32) gcc -O -c f.i
(on amd64) gcc -mx32 -O -c f.i

[Bug fortran/77978] stop codes misinterpreted in both f2003 and f2008

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from kargl at gcc dot gnu.org ---
I have a patch cooking.

   Fortran 95 has

   R840 stop-stmt  is STOP [ stop-code ]
   R841 stop-code  is scalar-char-constant
   or digit [ digit [ digit [ digit [ digit ] ] ] ]

   Fortran 2003 is the same as Fortran 95 except R840 and R841 are now
   R849 and R850.

   Fortran 2008 has

   R855 stop-stmt is STOP [ stop-code ]
   R856 allstop-stmt  is ALL STOP [ stop-code ]
   R857 stop-code is scalar-default-char-constant-expr
  or scalar-int-constant-expr

[Bug libstdc++/77987] unique_ptr<T[]> reset rejects cv-compatible pointers

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug libstdc++/77990] unique_ptr<T, D>::unique_ptr(T*) imposes CopyConstructible on the deleter

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug fortran/77978] stop codes misinterpreted in both f2003 and f2008

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to john.harper from comment #0)
> Stop codes changed from the f2003 standard to f2008. The first of these 2 
> programs has a stop code valid in f2003 but not in f2008, the second has a
> stop code valid in f2008 but not in f2003. But gfortran 6.1.1 happily
> compiles and runs both programs with either -std=f2003 or -f2008.
> 
> Here are the program listings, gfortran -v result, and the results of
> compiling with the -std options that should not have worked:
> 
> cayley[~/Jfh] % cat stopnumber.f90
> ! stop666 (no space before 666) is valid f95 or f2003 but bad f2008
>   implicit none
>   stop666
> end program
> cayley[~/Jfh] % cat stopnumber2.f90
> ! stop expression is valid f2008 but bad f2003
>   implicit none 
> 

It actually worse than it appears.

% gfc7 -o z -std=f95 a.f90
% ./z
STOP -66
% cat a.f90
  implicit none
  stop -66
end program
% vi a.f90 (remove minus sign)
% gfc7 -o z -std=f95 a.f90
% ./z
STOP 66

[Bug middle-end/77959] ICE in ix86_decompose_address, at i386/i386.c:14954

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Fri Oct 14 19:36:58 2016
New Revision: 241182

URL: https://gcc.gnu.org/viewcvs?rev=241182=gcc=rev
Log:
PR middle-end/77959
* expr.c (expand_expr_real_1) : For EXPAND_WRITE
return a MEM.

* gfortran.dg/pr77959.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr77959.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/expr.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/77990] New: unique_ptr<T, D>::unique_ptr(T*) imposes CopyConstructible on the deleter

[evansr at google dot com]

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

Bug ID: 77990
   Summary: unique_ptr::unique_ptr(T*) imposes
CopyConstructible on the deleter
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: evansr at google dot com
CC: brooks at gcc dot gnu.org
  Target Milestone: ---

Created attachment 39815
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39815=edit
test case

C++11 spec [unique.ptr.single.ctor] says:

For unique_ptr the ctor overload:

  explicit unique_ptr(pointer p);

Requires: D shall satisfy DefaultConstructible.

The current libstdc++ implementation imposes CopyConstructible because it
constructs the _M_t data member tuple as _M_t(__p, deleter_type()).

See:
https://gcc.gnu.org/viewcvs/gcc/trunk/libstdc%2B%2B-v3/include/bits/unique_ptr.h?revision=237531=markup#l171

[Bug sanitizer/65479] sanitizer stack trace missing frames past #0 on powerpc64

[seurer at linux dot vnet.ibm.com]

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

Bill Seurer  changed:

   What|Removed |Added

 CC||seurer at linux dot 
vnet.ibm.com

--- Comment #18 from Bill Seurer  ---
With other fixes that have been made the only thing remaining to get the 3 test
cases working is the -fasynchronous-unwind-tables option.  I tried this on
powerpc64 LE and BE and it works fine.  I also verified it doesn't break on
x86.

c-c++-common/asan/misalign-1.c
c-c++-common/asan/misalign-2.c
c-c++-common/asan/null-deref-1.c


/* { dg-additional-options "-fasynchronous-unwind-tables" { target {
powerpc*-*-linux* } } } */

(plus some tweaking of line numbers in expected outputs)

I'll be submitting a patch for this.

[Bug c++/67182] Initialising map with disabled copy elision yields unexpected results.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||4.9.4, 5.4.0, 6.2.0
 Resolution|--- |FIXED
   Target Milestone|--- |5.4
  Known to fail||5.1.0, 5.3.0

--- Comment #1 from Jonathan Wakely  ---
This is fixed in GCC 5.4

[Bug libstdc++/24693] Deque improvements

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Prototype patch: https://gcc.gnu.org/ml/libstdc++/2016-10/msg00017.html

[Bug libstdc++/66338] std::forward_as_tuple() issue with single argument

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #15 from Jonathan Wakely  ---
.

[Bug c/77989] New: -O3 causes verify_gimple fail

[dcb314 at hotmail dot com]

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

Bug ID: 77989
   Summary: -O3 causes verify_gimple fail
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 39814
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39814=edit
C source code

The attached C code, when compiled by gcc trunk dated 20161014 and 
compiler flag -O3, does this:

tar.c: In function ‘tar_wr’:
tar.c:554:1: error: invalid address operand in MEM_REF
MEM[(char *)[(void *) + 156B]];

tar.c:554:1: error: invalid first operand of MEM_REF
[(void *) + 156B]
tar.c:300:15: note: in statement
# VUSE <.MEM_505>
_324 = MEM[(char *)[(void *) + 156B]];
tar.c:554:1: internal compiler error: verify_gimple failed
0xd7a849 verify_gimple_in_cfg(function*, bool)
../../trunk/gcc/tree-cfg.c:5208
0xbf46fb execute_function_todo
../../trunk/gcc/passes.c:1965

[Bug tree-optimization/77988] New: ICE on valid code at -Os and above on x86_64-linux-gnu: verify_gimple failed

[su at cs dot ucdavis.edu]

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

Bug ID: 77988
   Summary: ICE on valid code at -Os and above on
x86_64-linux-gnu: verify_gimple failed
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

It is a regression from 6.2.x. 


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20161013 (experimental) [trunk revision 241143] (GCC)
$
$ gcc-trunk -O1 small.c
$ gcc-6.2 -Os small.c
$
$ gcc-trunk -Os small.c
small.c: In function ‘main’:
small.c:4:5: error: invalid address operand in MEM_REF
 int main ()
 ^~~~
b[0];

small.c:4:5: error: invalid first operand of MEM_REF
[0]
small.c:15:11: note: in statement
   if (*f)
   ^~
# VUSE <.MEM_9(D)>
_2 = b[0];
small.c:4:5: internal compiler error: verify_gimple failed
 int main ()
 ^~~~
0xc31eff verify_gimple_in_cfg(function*, bool)
../../gcc-source-trunk/gcc/tree-cfg.c:5208
0xb12492 execute_function_todo
../../gcc-source-trunk/gcc/passes.c:1965
0xb12e49 execute_todo
../../gcc-source-trunk/gcc/passes.c:2015
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$


--


static int a = 2;
int b[1], c, d;

int main ()
{ 
  int e = a, *f = [0];
  if (d)
for (e = 0; e < 1; e++)
  ;
  if (e)
{
L1:
  if (b < f)
__builtin_abort ();
  if (*f)
c++;
  return 0;
}
  f = 0;
  goto L1;
  return 0;
}

[Bug c++/77987] New: unique_ptr<T[]> reset rejects cv-compatible pointers

[barry.revzin at gmail dot com]

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

Bug ID: 77987
   Summary: unique_ptr reset rejects cv-compatible pointers
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

#include 

int main() {
std::unique_ptr p;
p.reset(new char[1]);
}

fails to compile with due to reset invoking swap on two different types.
However, this code should be well-formed per N4089.

[Bug target/77966] Corrupt function with -fsanitize-coverage=trace-pc

[jpoimboe at redhat dot com]

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

--- Comment #6 from Josh Poimboeuf  ---
(In reply to Arnd Bergmann from comment #5)
> I checked the test case using "-fsanitize=unreachable" and that avoids the
> problem.
> 
> Josh, should we set that whenever we enable objtool in the kernel?

In theory, adding -fsanitize=unreachable might be a workable option for
allowing objtool to detect such unreachable blocks.

However, in practice, that option doesn't seem to work as advertised.  It seems
to change the control flow unexpectedly.  When adding it to the test case, it
doesn't add a __ubsan_handle_builtin_unreachable() call to the unreachable
block.  Instead, it treats it as a normal loop, and removes the assumption that
the loop can only run one time.

Here's the same test case from comment #1, with -fsanitize-unreachable added:

 :
   0:   55  push   %rbp
   1:   53  push   %rbx
   2:   48 89 fdmov%rdi,%rbp
   5:   31 db   xor%ebx,%ebx
   7:   48 83 ec 08 sub$0x8,%rsp
   b:   e8 00 00 00 00  callq  10 
c: R_X86_64_PC32__sanitizer_cov_trace_pc-0x4
  10:   8b 45 00mov0x0(%rbp),%eax
  13:   85 c0   test   %eax,%eax
  15:   75 11   jne28 
  17:   48 83 c4 08 add$0x8,%rsp
  1b:   5b  pop%rbx
  1c:   5d  pop%rbp
  1d:   e9 00 00 00 00  jmpq   22 
1e: R_X86_64_PC32   __sanitizer_cov_trace_pc-0x4
  22:   66 0f 1f 44 00 00   nopw   0x0(%rax,%rax,1)
  28:   e8 00 00 00 00  callq  2d 
29: R_X86_64_PC32   __sanitizer_cov_trace_pc-0x4
  2d:   89 d8   mov%ebx,%eax
  2f:   83 c3 01add$0x1,%ebx
  32:   48 8b 7c c5 08  mov0x8(%rbp,%rax,8),%rdi
  37:   e8 00 00 00 00  callq  3c 
38: R_X86_64_PC32   ioread32-0x4
  3c:   39 5d 00cmp%ebx,0x0(%rbp)
  3f:   77 e7   ja 28 
  41:   eb d4   jmp17 

[Bug rtl-optimization/68212] Loop unroller breaks basic block frequencies

[pthaugen at gcc dot gnu.org]

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

--- Comment #4 from Pat Haugen  ---
Author: pthaugen
Date: Fri Oct 14 17:10:18 2016
New Revision: 241170

URL: https://gcc.gnu.org/viewcvs?rev=241170=gcc=rev
Log:
PR rtl-optimization/68212
* cfgloopmanip.c (duplicate_loop_to_header_edge): Use preheader edge
frequency when computing scale factor for peeled copies.
* loop-unroll.c (unroll_loop_runtime_iterations): Fix freq/count
values for switch/peel blocks/edges.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgloopmanip.c
trunk/gcc/loop-unroll.c

[Bug fortran/77978] stop codes misinterpreted in both f2003 and f2008

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (7.0).

[Bug c/77965] -Wduplicated-cond should find duplicated condition / identical expressions of form "a || a" or "a && a"

[egall at gwmail dot gwu.edu]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #1 from Eric Gallager  ---
Use -Wlogical-op:

$ /usr/local/bin/gcc -c -Wall -Wextra -pedantic -Wlogical-op -Wduplicated-cond
-Wtautological-compare logical_op.c 
logical_op.c: In function ‘foo’:
logical_op.c:5:17: warning: logical ‘or’ of equal expressions [-Wlogical-op]
  return (x == 5 || x == 5) ? 1 : 0;
 ^~

[Bug c++/71912] [6 regression] flexible array in struct in union rejected

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #10 from Martin Sebor  ---
Backported to 6-branch in r241168.

[Bug c++/69698] [meta-bug] flexible array members

[msebor at gcc dot gnu.org]

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

Bug 71912 Summary: [6 regression] flexible array in struct in union rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71912

   What|Removed |Added

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

[Bug c++/71912] [6 regression] flexible array in struct in union rejected

[msebor at gcc dot gnu.org]

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

--- Comment #9 from Martin Sebor  ---
Author: msebor
Date: Fri Oct 14 15:37:54 2016
New Revision: 241168

URL: https://gcc.gnu.org/viewcvs?rev=241168=gcc=rev
Log:
PR c++/71912 - [6/7 regression] flexible array in struct in union rejected

gcc/cp/ChangeLog:
* class.c (struct flexmems_t):  Add members.
(find_flexarrays): Add arguments.  Correct handling of anonymous
structs.
(diagnose_flexarrays): Adjust to issue warnings in addition to errors.
(check_flexarrays): Add argument.
(diagnose_invalid_flexarray): New functions.

gcc/testsuite/ChangeLog:
* g++.dg/ext/flexary4.C: Adjust.
* g++.dg/ext/flexary5.C: Same.
* g++.dg/ext/flexary9.C: Same.
* g++.dg/ext/flexary19.C: New test.
* g++.dg/ext/flexary18.C: New test.
* g++.dg/torture/pr64312.C: Add a dg-error directive to an ill-formed
regression test.
* g++.dg/compat/struct-layout-1_generate.c (subfield): Add argument.
Avoid generating a flexible array member in an array.


Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/class.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog
   
branches/gcc-6-branch/gcc/testsuite/g++.dg/compat/struct-layout-1_generate.c
branches/gcc-6-branch/gcc/testsuite/g++.dg/ext/flexary4.C
branches/gcc-6-branch/gcc/testsuite/g++.dg/ext/flexary5.C
branches/gcc-6-branch/gcc/testsuite/g++.dg/ext/flexary9.C
branches/gcc-6-branch/gcc/testsuite/g++.dg/torture/pr64312.C

[Bug middle-end/77964] [7 Regression] Linux kernel firmware loader miscompiled

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

URL||http://marc.info/?t=1466867
   ||2242=1=2

--- Comment #13 from Markus Trippelsdorf  ---
See: http://marc.info/?t=14668672242=1=2 for kernel side discussion.

[Bug fortran/77973] [6/7 Regression] ICE in scan_omp_1_op, at omp-low.c:3841

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Martin Jambor  ---
The variable is introduced to the clause in the omp_finish_clause
lang_hook.  The following patch (untested) fixes it for me.  Jakub, is
it even remotely close to a proper fix?

diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index c8de1e6..98c63d1 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -7733,6 +7733,10 @@ gimplify_adjust_omp_clauses_1 (splay_tree_node n, void
*data)
   struct gimplify_omp_ctx *ctx = gimplify_omp_ctxp;
   gimplify_omp_ctxp = ctx->outer_context;
   lang_hooks.decls.omp_finish_clause (clause, pre_p);
+  if (code == OMP_CLAUSE_MAP
+  && gimplify_omp_ctxp
+  && DECL_P (OMP_CLAUSE_SIZE (clause)))
+omp_notice_variable (gimplify_omp_ctxp, OMP_CLAUSE_SIZE (clause), true);
   gimplify_omp_ctxp = ctx;
   return 0;
 }

[Bug target/77966] Corrupt function with -fsanitize-coverage=trace-pc

[arnd at linaro dot org]

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

--- Comment #5 from Arnd Bergmann  ---
I checked the test case using "-fsanitize=unreachable" and that avoids the
problem.

Josh, should we set that whenever we enable objtool in the kernel?

[Bug target/77966] Corrupt function with -fsanitize-coverage=trace-pc

[vda.linux at googlemail dot com]

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

--- Comment #4 from Denis Vlasenko  ---
This confuses object code sanity analysis tools which check that every function
ends "properly", i.e. with a return or jump (possibly padded with nops).

Can gcc get an option like -finsert-stop-insn-when-unreachable[=insn], making
bad programs crash if they do reach "impossible" code, rather than happily
running off and executing random stuff?

For x86, one-byte INT3, INT1, HLT or two-byte UD2 insn would be a good choice.

[Bug debug/77985] DW_AT_comp_dir is omitted when filename is absolute and the file does not contain a specific typedef

[infinity0 at pwned dot gg]

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

infinity0 at pwned dot gg changed:

   What|Removed |Added

  Attachment #39812|0   |1
is obsolete||

--- Comment #9 from infinity0 at pwned dot gg ---
Created attachment 39813
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39813=edit
Emit DW_AT_comp_dir even if filename is an absolute path

Whoops my bad, I did not mean to remove the remap_debug_filename call, that was
left over from some experimenting. Fixed now.

[Bug debug/77985] DW_AT_comp_dir is omitted when filename is absolute and the file does not contain a specific typedef

[infinity0 at pwned dot gg]

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

--- Comment #8 from infinity0 at pwned dot gg ---
(In reply to Richard Biener from comment #6)
> So I just fixed the bug here, but yes, I don't know about the design
> decision.  I suppose CWD was decided to be useless in case of an absolute
> path to the file.
> 
> I don't think the debug info preserves -I paths in any standard way, so
> what's exactly the reason you consider CWD not redundant here?  [we could
> rewrite the file-name to relative to CWD]

Sorry, I only noticed your reply after I posted that patch. The main reasons
are:

1. So I can write a test case for the next patch I'd be submitting, since GCC
submission processes demand this :p and

2. Reduces code complexity - my patch deletes more lines than it adds.

3. It will be able to handle any extensions to DWARF in the future that add
relative paths elsewhere that one would want to resolve against DW_AT_comp_dir.
One could reuse the same logic everywhere (in bad pseudo-code):

resolve_some_dwarf_path (path) {
  return relative(path) ? DW_AT_comp_dir/path : path;
}

Conceptually, the working directory is independent from an input file, so it
would not be redundant to add it in the general case. *Sometimes*, *parts* of
it might be redundant yes - and rewriting the filename to be relative to this,
would remove the redundancy. Doing this is compatible with the above points,
and I could amend the patch to do this, although I suggest it's not worth the
effort (unless there is a function in GCC code that already does this).

[Bug debug/77985] DW_AT_comp_dir is omitted when filename is absolute and the file does not contain a specific typedef

[infinity0 at pwned dot gg]

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

--- Comment #7 from infinity0 at pwned dot gg ---
Created attachment 39812
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39812=edit
Emit DW_AT_comp_dir even if filename is an absolute path

Suggested patch attached, with a test case.

Note that without this patch, it is hard to test anything relating to
DW_AT_comp_dir in the testsuite, since it compiles the test cases using
absolute paths.

[Bug tree-optimization/77979] [7 Regression] ICE on valid code at -Os and above on x86_64-linux-gnu: Segmentation fault

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug debug/77985] DW_AT_comp_dir is omitted when filename is absolute and the file does not contain a specific typedef

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
So I just fixed the bug here, but yes, I don't know about the design decision. 
I suppose CWD was decided to be useless in case of an absolute path to the
file.

I don't think the debug info preserves -I paths in any standard way, so what's
exactly the reason you consider CWD not redundant here?  [we could rewrite the
file-name to relative to CWD]

[Bug tree-optimization/77979] [7 Regression] ICE on valid code at -Os and above on x86_64-linux-gnu: Segmentation fault

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Fri Oct 14 12:58:18 2016
New Revision: 241162

URL: https://gcc.gnu.org/viewcvs?rev=241162=gcc=rev
Log:
2016-10-14  Richard Biener  

PR tree-optimization/77979
* tree-vrp.c (compare_name_with_value): Handle released SSA names
in the equivalency sets.
(compare_names): Likewise.

* gcc.dg/torture/pr77979.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr77979.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vrp.c

[Bug tree-optimization/77983] [5/6/7 Regression] destructor call optimized out

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Use something different than memset is the other fix. There is also a thread in
glibc mailing list about a secure memset

[Bug debug/77985] DW_AT_comp_dir is omitted when filename is absolute and the file does not contain a specific typedef

[infinity0 at pwned dot gg]

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

--- Comment #5 from infinity0 at pwned dot gg ---
> Piggybacking a slightly unrelated issue: [..]

Upon further investigation it seems that, whilst the debug-prefix-maps do not
get applied to DW_AT_name filenames in the output of -dA, it does get applied
in the final assembled binary. Sorry for the noise.

The other point about DW_AT_comp_dir and absolute paths remains though - I'm
thinking it would be simpler to just emit it in all cases, and get rid of the
IS_ABSOLUTE_PATH checks. Since most things "in the wild" actually do have this
typedef via standard library includes, this is actually the "expected"
behaviour, hence why I titled this bug the way it is titled.

[Bug fortran/77973] [6/7 Regression] ICE in scan_omp_1_op, at omp-low.c:3841

[jamborm at gcc dot gnu.org]

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

--- Comment #3 from Martin Jambor  ---
...and the assert is triggered when remapping the D.3442 part in
clause:

map(tofrom:*x.0 [len: D.3442])

of the target statement.

The variable indeed belongs to the top-level function bind, but there
is an OMP parallel statement in between it and the target, which does
not specify how it is or isn't shared in it, which I assume is the
bug.

[Bug fortran/77973] [6/7 Regression] ICE in scan_omp_1_op, at omp-low.c:3841

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org

--- Comment #2 from Martin Jambor  ---
Out of the entire hsa merge, it is only addition of the assert itself
that "causes" the ICE.  If I check out r232546 and patch it with:

diff --git a/gcc/omp-low.c b/gcc/omp-low.c
index d7df3db..f38dc88 100644
--- a/gcc/omp-low.c
+++ b/gcc/omp-low.c
@@ -3777,7 +3777,11 @@ scan_omp_1_op (tree *tp, int *walk_subtrees, void *data)
 case LABEL_DECL:
 case RESULT_DECL:
   if (ctx)
-   *tp = remap_decl (t, >cb);
+   {
+ tree repl = remap_decl (t, >cb);
+ gcc_checking_assert (TREE_CODE (repl) != ERROR_MARK);
+ *tp = repl;
+   }
   break;

 default:


I get the same ICE, so if the assert is correct (I believe it is), the
bug is pre-existing.  But let me have a look a bit more.

[Bug c++/77984] Invalid warning on templated operator= with -Weffc++

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
-Weffc++ is basically broken and not useful for modern C++ code.

[Bug libstdc++/65122] std::vector doesn't honor element alignment

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #24 from Jonathan Wakely  ---
Fixed for GCC 7

[Bug libstdc++/65122] std::vector doesn't honor element alignment

[redi at gcc dot gnu.org]

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

--- Comment #25 from Jonathan Wakely  ---
Author: redi
Date: Fri Oct 14 12:03:47 2016
New Revision: 241158

URL: https://gcc.gnu.org/viewcvs?rev=241158=gcc=rev
Log:
PR65122 extended alignment support in allocators

PR libstdc++/65122
* include/ext/malloc_allocator.h (malloc_allocator::allocate): Use
aligned_alloc for types with extended alignment if available,
otherwise throw bad_alloc if malloc doesn't return a suitable value.
* include/ext/bitmap_allocator.h (bitmap_allocator::allocate)
(bitmap_allocator::deallocate): Use aligned new/delete for types with
extended alignment.
* include/ext/mt_allocator.h (__mt_alloc::allocate)
(__mt_alloc::deallocate): Likewise.
* include/ext/new_allocator.h (new_allocator::allocate)
(new_allocator::deallocate): Likewise.
* include/ext/pool_allocator.h (__pool_alloc::allocate)
(__pool_alloc::deallocate): Likewise.
* testsuite/20_util/allocator/overaligned.cc: New test.
* testsuite/ext/bitmap_allocator/overaligned.cc: New test.
* testsuite/ext/malloc_allocator/overaligned.cc: New test.
* testsuite/ext/mt_allocator/overaligned.cc: New test.
* testsuite/ext/new_allocator/overaligned.cc: New test.
* testsuite/ext/pool_allocator/overaligned.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/20_util/allocator/overaligned.cc
trunk/libstdc++-v3/testsuite/ext/bitmap_allocator/overaligned.cc
trunk/libstdc++-v3/testsuite/ext/malloc_allocator/overaligned.cc
trunk/libstdc++-v3/testsuite/ext/mt_allocator/overaligned.cc
trunk/libstdc++-v3/testsuite/ext/new_allocator/overaligned.cc
trunk/libstdc++-v3/testsuite/ext/pool_allocator/overaligned.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/ext/bitmap_allocator.h
trunk/libstdc++-v3/include/ext/malloc_allocator.h
trunk/libstdc++-v3/include/ext/mt_allocator.h
trunk/libstdc++-v3/include/ext/new_allocator.h
trunk/libstdc++-v3/include/ext/pool_allocator.h

[Bug ada/77986] Re-building from the toplevel doesn't work when Ada changes

[rguenther at suse dot de]

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

--- Comment #2 from rguenther at suse dot de  ---
On Fri, 14 Oct 2016, ebotcazou at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77986
> 
> Eric Botcazou  changed:
> 
>What|Removed |Added
> 
>  Status|UNCONFIRMED |NEW
>Last reconfirmed||2016-10-14
>  CC||ebotcazou at gcc dot gnu.org
>  Ever confirmed|0   |1
> 
> --- Comment #1 from Eric Botcazou  ---
> Try removing the stamp file:
>  rm x86_64-suse-linux/libada/stamp-libada

I removed all stamp-libada* but that didn't end up working.

> or do just "make -C gcc"

I think that's done automatically via dependencies on all-gcc?

[Bug debug/77985] DW_AT_comp_dir is omitted when filename is absolute and the file does not contain a specific typedef

[infinity0 at pwned dot gg]

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

--- Comment #4 from infinity0 at pwned dot gg ---
Thanks for the quick response!

What is the reason for "absolute paths are supposed to omit it"? I'm reading
the DWARF spec and I can't find a mention of this anywhere.

Even if DW_AT_name is absolute, recording DW_AT_comp_dir is still useful
because it could be a different path and this would affect the interpretation
of -I flags and so on.

The reason I found this bug was because I am writing a patch to make GCC
produce debugging symbols that are reproducible regardless of the build path.
(I will explain it in more detail via mail soon.) This bug does not directly
affect that; however it does affect how easy it is to write tests to test my
patch.

Emitting DW_AT_comp_dir in some cases and not others, also makes it more
complex for others to write logic to deal with this attribute.

Piggybacking a slightly unrelated issue: I'm noticing that remap_debug_filename
does not get applied to DW_AT_name in certain cases. Is this intentional?
Hopefully not, since the easiest way I can write my patch is to apply it to
DW_AT_name in all cases.

[Bug ada/77986] Re-building from the toplevel doesn't work when Ada changes

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Botcazou  ---
Try removing the stamp file:
 rm x86_64-suse-linux/libada/stamp-libada
or do just "make -C gcc"

[Bug debug/77985] DW_AT_comp_dir is omitted when filename is absolute and the file does not contain a specific typedef

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
But also:

  /* Add the name for the main input file now.  We delayed this from
 dwarf2out_init to avoid complications with PCH.  */
  add_name_attribute (comp_unit_die (), remap_debug_filename (filename));
  if (!IS_ABSOLUTE_PATH (filename) || targetm.force_at_comp_dir)
add_comp_dir_attribute (comp_unit_die ());
  else if (get_AT (comp_unit_die (), DW_AT_comp_dir) == NULL)
{
  bool p = false;
  file_table->traverse ();
  if (p)
add_comp_dir_attribute (comp_unit_die ());
}

where the file table seems to contain "".

Index: dwarf2out.c
===
--- dwarf2out.c (revision 241148)
+++ dwarf2out.c (working copy)
@@ -26422,7 +26422,8 @@ int
 file_table_relative_p (dwarf_file_data **slot, bool *p)
 {
   struct dwarf_file_data *d = *slot;
-  if (!IS_ABSOLUTE_PATH (d->filename))
+  if (!IS_ABSOLUTE_PATH (d->filename)
+  && d->filename[0] != '<')
 {
   *p = true;
   return 0;

fixes this.

[Bug debug/77985] DW_AT_comp_dir is omitted when filename is absolute and the file does not contain a specific typedef

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-14
   Target Milestone|--- |6.3
 Ever confirmed|0   |1
  Known to fail||4.3.5

--- Comment #2 from Richard Biener  ---
Confirmed.  Already GCC 4.3 behaves that way.  Must be a feature ;)  (I suppose
the bug is that _with_ that typedef we emit a DW_AT_comp_dir attribute).

GCC 3.2.3 didn't do that.

We have:

/* Generate the DIE for the compilation unit.  */

static dw_die_ref
gen_compile_unit_die (const char *filename)
{
  dw_die_ref die;
  const char *language_string = lang_hooks.name;
  int language;

  die = new_die (DW_TAG_compile_unit, NULL, NULL);

  if (filename)
{
  add_name_attribute (die, filename);
  /* Don't add cwd for .  */
  if (!IS_ABSOLUTE_PATH (filename) && filename[0] != '<')
add_comp_dir_attribute (die);

thus absolute paths are supposed to omit it.

[Bug ada/77986] New: Re-building from the toplevel doesn't work when Ada changes

[rguenth at gcc dot gnu.org]

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

Bug ID: 77986
   Summary: Re-building from the toplevel doesn't work when Ada
changes
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

After updating the source tree a

> make

in the toplevel in a configured and built tree with --disable-bootstrap doesn't
work.  The build always complains about RTS files needing a re-compile.  Well,
the _do it_.  It looks there are no kind of dependencies set up or makefile
rules that would look at changed sources?

This makes updating a dev tree with ada nearly impossible.

[Bug ada/77968] [7 Regression] ICEs with -flto on gnat.dg

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #3 from Eric Botcazou  ---
Thanks for the heads-up.

[Bug debug/77985] DW_AT_comp_dir is omitted when filename is absolute and the file does not contain a specific typedef

[infinity0 at pwned dot gg]

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

--- Comment #1 from infinity0 at pwned dot gg ---
Created attachment 39811
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39811=edit
Reproduce the bug; set CC to try it with different compilers

[Bug ada/77968] [7 Regression] ICEs with -flto on gnat.dg

[ebotcazou at gcc dot gnu.org]

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

--- Comment #2 from Eric Botcazou  ---
Author: ebotcazou
Date: Fri Oct 14 10:28:27 2016
New Revision: 241154

URL: https://gcc.gnu.org/viewcvs?rev=241154=gcc=rev
Log:
PR ada/77968
* gcc-interface/utils.c (create_var_decl): Do not clear TREE_READONLY
in LTO mode for an external variable.
(can_materialize_object_renaming_p): Move up.

Added:
trunk/gcc/testsuite/gnat.dg/lto18.adb
trunk/gcc/testsuite/gnat.dg/lto18.ads
trunk/gcc/testsuite/gnat.dg/lto18_pkg.ads
trunk/gcc/testsuite/gnat.dg/lto19.adb
trunk/gcc/testsuite/gnat.dg/lto19_pkg1.adb
trunk/gcc/testsuite/gnat.dg/lto19_pkg1.ads
trunk/gcc/testsuite/gnat.dg/lto19_pkg2.adb
trunk/gcc/testsuite/gnat.dg/lto19_pkg2.ads
trunk/gcc/testsuite/gnat.dg/lto20.adb
trunk/gcc/testsuite/gnat.dg/lto20_pkg.adb
trunk/gcc/testsuite/gnat.dg/lto20_pkg.ads
Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gcc-interface/utils.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gnat.dg/lto15.adb
trunk/gcc/testsuite/gnat.dg/lto16.adb
trunk/gcc/testsuite/gnat.dg/lto17.adb

[Bug debug/77985] New: DW_AT_comp_dir is omitted when filename is absolute and the file does not contain a specific typedef

[infinity0 at pwned dot gg]

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

Bug ID: 77985
   Summary: DW_AT_comp_dir is omitted when filename is absolute
and the file does not contain a specific typedef
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: infinity0 at pwned dot gg
  Target Milestone: ---

Hi, GCC 7.0.0 (latest snapshot) and GCC 6.1.1 both exhibit the following
behaviour:

+ gcc-build/destdir/usr/local/bin/gcc --version
gcc (GCC) 7.0.0 20161009 (experimental)
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

+ cat test0.c
typedef __builtin_va_list __gnuc_va_list;
void func (void) {}
+ cat test1.c
void func (void) {}
+ gcc-build/destdir/usr/local/bin/gcc test0.c -g -dA -S -o- | grep comp_dir
.long   .LASF4  # DW_AT_comp_dir:
"/home/infinity0/var/lib/reproducible"
.uleb128 0x1b   # (DW_AT_comp_dir)
+ gcc-build/destdir/usr/local/bin/gcc test1.c -g -dA -S -o- | grep comp_dir
.long   .LASF2  # DW_AT_comp_dir:
"/home/infinity0/var/lib/reproducible"
.uleb128 0x1b   # (DW_AT_comp_dir)
+ gcc-build/destdir/usr/local/bin/gcc
/home/infinity0/var/lib/reproducible/test0.c -g -dA -S -o- | grep comp_dir
.long   .LASF4  # DW_AT_comp_dir:
"/home/infinity0/var/lib/reproducible"
.uleb128 0x1b   # (DW_AT_comp_dir)
+ gcc-build/destdir/usr/local/bin/gcc
/home/infinity0/var/lib/reproducible/test1.c -g -dA -S -o- | grep comp_dir
# exit code 1

See the attached file for a shell script where you can reproduce this yourself.

[Bug c++/77984] New: Invalid warning on templated operator= with -Weffc++

[victor at paleologue dot fr]

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

Bug ID: 77984
   Summary: Invalid warning on templated operator= with -Weffc++
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: victor at paleologue dot fr
  Target Milestone: ---

Created attachment 39810
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39810=edit
Stand-alone C++ code reproducing a false warning

In the code attached, Thing::operator= is defined as following:

struct Thing
{
  template
  Thing& operator=(const T&)
  {
return *this;
  }
};

Compiling it, I get a warning that does not seem legitimate:

$ g++ false_warning.cpp -Weffc++
false_warning.cpp: In member function ‘Thing& Thing::operator=(const T&)’:
false_warning.cpp:6:13: warning: ‘operator=’ should return a reference to
‘*this’ [-Weffc++]
 return *this;
 ^~~~

My version of gcc:

$ g++ --version
g++ (GCC) 6.2.1 20160916 (Red Hat 6.2.1-2)
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug libstdc++/77944] FAIL: 20_util/variant/compile.cc (test for excess errors)

[timshen at gcc dot gnu.org]

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

Tim Shen  changed:

   What|Removed |Added

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

--- Comment #2 from Tim Shen  ---
Mark as fixed.

[Bug libstdc++/77944] FAIL: 20_util/variant/compile.cc (test for excess errors)

[timshen at gcc dot gnu.org]

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

--- Comment #1 from Tim Shen  ---
Author: timshen
Date: Fri Oct 14 09:58:05 2016
New Revision: 241153

URL: https://gcc.gnu.org/viewcvs?rev=241153=gcc=rev
Log:
PR libstdc++/77944
* include/std/variant: include  for __try and
__catch.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/variant

[Bug bootstrap/77962] [7 Regression] Bootstrap failure on x86_64-linux starting with r241063

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Works for me now.

[Bug tree-optimization/77980] Regression in GCC-7.0.0's optimizer.

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
Note that "regression in gcc-7.0.0" would mean that gcc-6 was doing better,
which is not the case.

[Bug tree-optimization/77983] [5/6/7 Regression] destructor call optimized out

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||marxin at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Martin Liška  ---
Hi.

Please look at documentation for -flifetime-dse, btw.:

g++ pr77983.cpp -O1 -flifetime-dse=0 && ./a.out 
Before:000102030405060708090a0b0c0d0e0f10111213
After :

I'm closing as invalid.

[Bug fortran/77973] [6/7 Regression] ICE in scan_omp_1_op, at omp-low.c:3841

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.3

[Bug tree-optimization/77975] [6/7 Regression] Missed optimization for some small constants

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
> Proved that loop 1 iterates 2 times using brute force.

so the question is why that doesn't work for the new form (and this is what we
should fix).  Because

static gphi *
get_base_for (struct loop *loop, tree x)
{
...
  init = PHI_ARG_DEF_FROM_EDGE (phi, loop_preheader_edge (loop));
  next = PHI_ARG_DEF_FROM_EDGE (phi, loop_latch_edge (loop));

  if (TREE_CODE (next) != SSA_NAME)
return NULL;

Index: gcc/tree-ssa-loop-niter.c
===
--- gcc/tree-ssa-loop-niter.c   (revision 241148)
+++ gcc/tree-ssa-loop-niter.c   (working copy)
@@ -2545,13 +2551,11 @@ get_base_for (struct loop *loop, tree x)
   init = PHI_ARG_DEF_FROM_EDGE (phi, loop_preheader_edge (loop));
   next = PHI_ARG_DEF_FROM_EDGE (phi, loop_latch_edge (loop));

-  if (TREE_CODE (next) != SSA_NAME)
-return NULL;
-
   if (!is_gimple_min_invariant (init))
 return NULL;

-  if (chain_of_csts_start (loop, next) != phi)
+  if (TREE_CODE (next) == SSA_NAME
+  && chain_of_csts_start (loop, next) != phi)
 return NULL;

   return phi;
@@ -2574,6 +2578,8 @@ get_val_for (tree x, tree base)

   if (!x)
 return base;
+  else if (is_gimple_min_invariant (x))
+return x;

   stmt = SSA_NAME_DEF_STMT (x);
   if (gimple_code (stmt) == GIMPLE_PHI)


fixes it.  But I think it's not correct as it misses the intermediate stmt
evaluations.  Some more refactoring (passing in the PHI def to get_val_for)
is necessary I think.

[Bug libitm/63907] libitm/config/posix/rwlock.cc doesn't compile

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
Created attachment 39809
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39809=edit
Use default member initializers.

(In reply to Jonathan Wakely from comment #1)
> Similar problem to PR 49894 but I don't think the fix is usable by libitm as
> it depends on a C++11 language feature.

Now that libitm is built with -std=gnu++14 default member initializers can be
used, which uses the PTHREAD_xxx_INITIALIZER macros in a context where they are
syntactically valid.

[Bug tree-optimization/77983] New: [5/6/7 Regression] destructor call optimized out

[doko at gcc dot gnu.org]

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

Bug ID: 77983
   Summary: [5/6/7 Regression] destructor call optimized out
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

Created attachment 39808
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39808=edit
test case

[forwarded from https://launchpad.net/bugs/1577891]

seen with 5, 6 and trunk, works with 4.8 and 4.9.

$ g++-4.8 -O1 -g -ggdb test.cpp && ./a.out
Before:000102030405060708090a0b0c0d0e0f10111213
After :

$ g++-6 -O1 -g -ggdb test.cpp && ./a.out
Before:000102030405060708090a0b0c0d0e0f10111213
After :000102030405060708090a0b0c0d0e0f10111213

$ g++-6 -O0 -g -ggdb test.cpp && ./a.out
Before:000102030405060708090a0b0c0d0e0f10111213
After :

[Bug libitm/63907] libitm/config/posix/rwlock.cc doesn't compile

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
See https://gcc.gnu.org/bugs/

[Bug sanitizer/77982] New: deadlock in asan thread initialization/interception.

[pawel_sikora at zoho dot com]

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

Bug ID: 77982
   Summary: deadlock in asan thread initialization/interception.
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pawel_sikora at zoho dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

hi,

afaics there's a lock scenario in asan initialization code.

my application uses dlopen() to load shared lib which creates a thread at the
global initialization stage (in details, the static version of libusb linked in
a shared lib creates a thread for usb polling). this thread creation is
intercepted by asan and stuck in endless loop:

255├>while (atomic_load(_registered, memory_order_acquire) == 0)
256│   internal_sched_yield();

Thread 1 (Thread 0x7f4aee0937c0 (LWP 17702)):
#0  __sanitizer::internal_sched_yield () at
../../../../libsanitizer/sanitizer_common/sanitizer_linux.cc:304
#1  0x7f4aefafe075 in __interceptor_pthread_create (thread=0x7f4ae0ede718
, attr=, start_routine=0x7f4ae0d17285
, arg=0x0) at ../../../../libsanitizer/as
an/asan_interceptors.cc:256
#2  0x7f4ae0d1734c in my_init () from
/home/pawels/ssd/dvm/gcc-6/cmake-debug-x86_64-gnu-linux/bin64/libhesapi.so
#3  0x7f4af0a77d8a in call_init (l=, argc=argc@entry=2,
argv=argv@entry=0x7ffd27a16478, env=env@entry=0x7ffd27a16490) at dl-init.c:72
#4  0x7f4af0a77e9b in call_init (env=0x7ffd27a16490, argv=0x7ffd27a16478,
argc=2, l=) at dl-init.c:30
#5  _dl_init (main_map=main_map@entry=0x61a14a80, argc=2,
argv=0x7ffd27a16478, env=0x7ffd27a16490) at dl-init.c:120
#6  0x7f4af0a7ca91 in dl_open_worker (a=a@entry=0x7ffd27a13e60) at
dl-open.c:564
#7  0x7f4af0a77c34 in _dl_catch_error
(objname=objname@entry=0x7ffd27a13e50,
errstring=errstring@entry=0x7ffd27a13e58,
mallocedp=mallocedp@entry=0x7ffd27a13e4f, operate=operate@entry=0x7f4af0a7c640
, args=args@entry=0x7ffd27a13e60) at dl-error.c:187
#8  0x7f4af0a7bfe9 in _dl_open (file=0x61006358
"/home/pawels/ssd/dvm/gcc-6/cmake-debug-x86_64-gnu-linux/bin64/libBoardDetector.so",
mode=-2147483391, caller_dlopen=0x7f4aefb12e65 <__interceptor_dlopen(c
har const*, int)+101>, nsid=-2, argc=, argv=,
env=0x7ffd27a16490) at dl-open.c:649
#9  0x7f4aef57df09 in dlopen_doit (a=a@entry=0x7ffd27a14090) at dlopen.c:66
#10 0x7f4af0a77c34 in _dl_catch_error (objname=0x7f4af00131b0
, errstring=0x7f4af00131b8
, mallocedp=0x7f4af00131a8
, operate=0
x7f4aef57deb0 , args=0x7ffd27a14090) at dl-error.c:187
#11 0x7f4aef57e591 in _dlerror_run (operate=operate@entry=0x7f4aef57deb0
, args=args@entry=0x7ffd27a14090) at dlerror.c:163
#12 0x7f4aef57dfa2 in __dlopen (file=, mode=)
at dlopen.c:87
#13 0x7f4aefb12e65 in __interceptor_dlopen (filename=0x61006358
"/home/pawels/ssd/dvm/gcc-6/cmake-debug-x86_64-gnu-linux/bin64/libBoardDetector.so",
flag=flag@entry=257) at ../../../../libsanitizer/sanit
izer_common/sanitizer_common_interceptors.inc:4968
#14 0x7f4af0b7d1e7 in au::system::openLibrary (libname=...) at
../sources/au/auSystemUnix.cpp:69


from the others side, the asan thread initialization stuck on the internal
libc/libdl mutex:

/usr/src/debug/glibc-2.23-81-g2eda04e/elf/dl-tls.c

765├>  __rtld_lock_lock_recursive (GL(dl_load_lock));

[Switching to thread 6 (Thread 0x7f4ae0b6c700 (LWP 17707))]
(gdb) bt
#0  __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1  0x7f4aee823a76 in __GI___pthread_mutex_lock (mutex=0x7f4af0c8c908
<_rtld_local+2312>) at ../nptl/pthread_mutex_lock.c:115
#2  0x7f4af0a7a6da in tls_get_addr_tail (ti=0x7f4aefdf1b78,
dtv=0x61308c50, the_map=0x7f4af0c8a878) at dl-tls.c:765
#3  0x7f4aefafe9cb in __interceptor___tls_get_addr (arg=0x7f4aefdf1b78) at
../../../../libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:4207
#4  0x7f4aefbb0b34 in __lsan::DisabledInThisThread () at
../../../../libsanitizer/lsan/lsan_common.cc:33
#5  0x7f4aefaf8515 in __asan::Allocator::Allocate (this=0x7f4aefdf5620
<__asan::instance>, size=, alignment=,
stack=0x7f4ae0b6b430, alloc_type=, can_fill=) at ../../../../libsanitizer/asan/asan_allocator.cc:449
#6  0x7f4aefb8f062 in __interceptor_realloc (ptr=ptr@entry=0x0,
size=size@entry=32) at ../../../../libsanitizer/asan/asan_malloc_linux.cc:83
#7  0x7f4aee823035 in pthread_getattr_np (thread_id=,
attr=attr@entry=0x7f4ae0b6bd70) at pthread_getattr_np.c:161
#8  0x7f4aefba6eed in __sanitizer::GetThreadStackTopAndBottom
(at_initialization=at_initialization@entry=false,
stack_top=stack_top@entry=0x7f4ae0b6bdf0,
stack_bottom=stack_bottom@entry=0x7f4ae0b6bdf8) at ..

[Bug target/77966] Corrupt function with -fsanitize-coverage=trace-pc

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
Hello.

You are right, GCC assumes that the loop can iterate at most 1 times:

$ head pr77966.c.*ivcanon*
;; Function snic_log_q_error (snic_log_q_error, funcdef_no=0, decl_uid=2082,
cgraph_uid=0, symbol_order=0)

Induction variable (unsigned int) 0 + 1 * iteration does not wrap in statement
_6 = snic_4(D)->wq[i_13];
 in loop 1.
Statement _6 = snic_4(D)->wq[i_13];
 is executed at most 0 (bounded by 0) + 1 times in loop 1.
Loop 1 iterates at most 1 times.
snic_log_q_error (struct snic * snic)

That's because struct vnic_wq_ctrl *wq[1]; is not a trailing array in a struct.
Thus last BB contains:

  :
  __builtin___sanitizer_cov_trace_pc ();
  __builtin_unreachable ();

That's reason why no return insn is emitted (occurrence of
__builtin_unreachable).
Thus I think the PR is invalid. Please re-open if having a different opinion.

[Bug tree-optimization/77979] [7 Regression] ICE on valid code at -Os and above on x86_64-linux-gnu: Segmentation fault

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Mine.  Equivalences might be no longer valid after subtitute_and_fold as that
now releases SSA names (valid as in, contains released SSA names).  Now I
believe that jump-threading in VRP should go away but I'll fix this anyway.

[Bug tree-optimization/77980] Regression in GCC-7.0.0's optimizer.

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
Confirmed.

[Bug tree-optimization/77979] [7 Regression] ICE on valid code at -Os and above on x86_64-linux-gnu: Segmentation fault

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||6.2.0
   Keywords||ice-on-invalid-code
   Last reconfirmed||2016-10-14
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|ICE on valid code at -Os|[7 Regression] ICE on valid
   |and above on|code at -Os and above on
   |x86_64-linux-gnu:   |x86_64-linux-gnu:
   |Segmentation fault  |Segmentation fault
   Target Milestone|--- |7.0
  Known to fail||7.0

--- Comment #1 from Martin Liška  ---
Nice snippet! Started with with r241021.

[Bug c++/77976] `auto x = type{…}` initialization syntax rejects `explicit` user-defined conversion

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
Dup.

[Bug tree-optimization/77975] [6/7 Regression] Missed optimization for some small constants

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-14
 CC||law at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||6.1.0, 7.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r232361. IV canon can't identify number of iterations:

Before:
;; Function f7 (f7, funcdef_no=11, decl_uid=2279, cgraph_uid=11,
symbol_order=11)

Proved that loop 1 iterates 2 times using brute force.
Loop 1 iterates 2 times.
Loop 1 iterates at most 2 times.
Loop 1 likely iterates at most 2 times.
Added canonical iv to loop 1, 2 iterations.
f7 ()
{
  unsigned int a;
  unsigned int c;
  struct _IO_FILE * stderr.0_1;
  unsigned int ivtmp_2;
  unsigned int ivtmp_3;

  :

  :
  # c_14 = PHI 
  # a_15 = PHI 
  # ivtmp_3 = PHI 
  a_5 = a_15 >> 1;
  c_6 = c_14 + 1;
  ivtmp_2 = ivtmp_3 - 1;
  if (ivtmp_2 != 0)
goto ;
  else
goto ;

  :
  goto ;

  :
  # c_4 = PHI 
  stderr.0_1 = stderr;
  fprintf (stderr.0_1, "cnt: %d\n", c_4);
  return 0;

}


After:
;; Function f7 (f7, funcdef_no=11, decl_uid=2279, cgraph_uid=11,
symbol_order=11)

f7 ()
{
  unsigned int a;
  unsigned int c;
  struct _IO_FILE * stderr.0_1;

  :

  :
  # c_14 = PHI 
  # a_15 = PHI <1(4), 3(2)>
  a_5 = a_15 >> 1;
  c_6 = c_14 + 1;
  if (a_5 != 0)
goto ;
  else
goto ;

  :
  goto ;

  :
  # c_4 = PHI 
  stderr.0_1 = stderr;
  fprintf (stderr.0_1, "cnt: %d\n", c_4);
  return 0;
}

Diff:
  # a_15 = PHI 
  # a_15 = PHI <1(4), 3(2)>

Maybe ivcanon can handle such degenerated situation?
Thoughts?

[Bug libitm/63907] libitm/config/posix/rwlock.cc doesn't compile

[lts-rudolph at gmx dot de]

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

--- Comment #5 from Klaus Rudolph  ---
Hi Andrew,

> Andrew Pinski  changed:
> 
>What|Removed |Added
> 
>  Status|NEW |WAITING
> 
> --- Comment #4 from Andrew Pinski  ---
> How does this work for everyone else?  Can you attach the preprocessed source?

What exactly do you want to have? Complete build path after configure?

Sorry for my stupid question!

Regards
 Klaus

[Bug tree-optimization/77980] Regression in GCC-7.0.0's optimizer.

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
To simplify 1/n to 0, we would have to notice that n cannot be ±1 (the last bit
is zero since n is 2*x2), and it cannot be 0 either in that division. That
seems quite specialized, but rather easy to add to match.pd using
get_nonzero_bits if someone wants to write it... Is there anything more general
that can be done based on that?