[Bug ada/68171] Default value in record for component with predicate causes bug box

[gcc at gyw dot com]

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

--- Comment #1 from Troy  ---
As an aside, the test is based on an example in the Ada 2012 Rationale. The
original uses Static_Predicate, but fails to compile with gnat 4.9.2. That is
why I used Dynamic_Predicate instead.

[Bug libfortran/51119] MATMUL slow for large matrices

[tkoenig at gcc dot gnu.org]

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

--- Comment #15 from Thomas Koenig  ---
Another issue:  What should we do if the user supplies an external subroutine
DGEMM which does something unrelated?

I suppose we should then make DGEMM (and SGEMM) an intrinsic subroutine.

[Bug target/66033] rs6000 nops removed by rtl_dce

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

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

--- Comment #4 from Alan Modra  ---
Fixed gcc-5 too with git commit 0012c439

[Bug target/68172] New: [6 Regression] LTO/PGO bootstrapped compiler is miscompiled (looping in sched_rgn_init)

[trippels at gcc dot gnu.org]

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

Bug ID: 68172
   Summary: [6 Regression] LTO/PGO bootstrapped compiler is
miscompiled (looping in sched_rgn_init)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---
  Host: powerpc64le-unknown-linux-gnu
Target: powerpc64le-unknown-linux-gnu
 Build: powerpc64le-unknown-linux-gnu

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

On ppc64le gcc gets miscompiled when configured and built like this:

--with-build-config="bootstrap-lto bootstrap-O3"
make profiledbootstrap

The resulting compiler loops in sched_rgn_init on the attached testcase.

 % gcc -c -O3 warped_autocorrelation_FLP.i

Overhead  Command  Shared Object  Symbol
  98.23%  cc1  cc1[.] sched_rgn_init 
   0.10%  cc1  libc-2.20.so   [.] free
   0.09%  cc1  libc-2.20.so   [.] _int_malloc

   │   becomes zero.  Repeat until no blocks are
left on the
   │   list.  This produces a topological list of
blocks in
   │   the region.  */
   │while (tail >= 0)
   │  {
   │if (head < 0) 
  4.33 │cmpwi  cr5,r6,-1 
   │beq-   cr5,10c8b4d8 
   │  head = tail;
   │child = queue[head]; 
 10.06 │rldicr r0,r6,2,61
 47.05 │lwax   r11,r22,r0
   │if (degree[child] == 0)
   │rldicr r4,r11,2,61
  1.11 │lwzx   r8,r31,r4
   │cmpwi  cr7,r8,0
   │bnecr7,10c8adc0 
   │  { 
   │edge e;
   │   
   │degree[child] = -1;
   │rgn_bb_table[idx++] = child;
   │lwar16,40(r1)

[Bug c/68173] New: gcc does not terminate with -O0 on source file with a very large expression

[fuz at fuz dot su]

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

Bug ID: 68173
   Summary: gcc does not terminate with -O0 on source file with a
very large expression
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fuz at fuz dot su
  Target Milestone: ---

Created attachment 36632
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36632=edit
Testcase (file expands to a 20 MiB C source code form)

In this Stack Overflow question [1] OP has trouble compiling a 20 MiB source
file with gcc. Testing reveals that the source file compiles in roughly 1½
minutes when compiled with -O3 but the compiler doesn't terminate in 8 hours
when compiling with -O0. A reduced and self-contained variation of the source
code is attached. Due to its large size, it has been xz-compressed. Other
compilers (tested: tcc, clang) do not exhibit this problem and manage to
compile the source file within about a minute.

The source code comprises a single function with one arithmetic expression
making up 99.9% of the entire source file. Please have caution when opening
this file with an editor, some editors like nano become unresponsive when
reaching the line containing that expression.

I'm compiling on amd64 Linux for amd64 Linux with a gcc 5.1 RC1. I do not know
if this issue pertains trunk.


[1]: http://stackoverflow.com/q/33443626/417501

[Bug pch/68176] [4.8/4.9 Regression] all pch tests fail on eglibc systems (with bits/predefs.h)

[nix at esperi dot org.uk]

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

--- Comment #1 from Nix  ---
I can confirm that reverting the fix for bug 65550 makes the pch failures go
away on my increasingly creaky eglibc 2.18 systems. So that's the smoking gun.

[Bug fortran/68174] New: Length parameter in character allocation not recognized as a scalar (regression from 5.2)

[neil.n.carlson at gmail dot com]

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

Bug ID: 68174
   Summary: Length parameter in character allocation not
recognized as a scalar (regression from 5.2)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: neil.n.carlson at gmail dot com
  Target Milestone: ---

The following example is rejected by 6.0.0 20151025, but is accepted by 6.0.0
20150906 and 5.2.0.  It is valid Fortran.

% gfortran -c gfortran-bug-20151101A.f90 
gfortran-bug-20151101A.f90:15:25:

   allocate(character(this%maxlen) :: this%mold)
 1
Error: Scalar INTEGER expression expected at (1)

module example

  type :: foo
class(*), allocatable :: mold
integer :: maxlen
  end type

contains

  subroutine pop (this)
class(foo), intent(inout) :: this
select type (uptr => this%mold)
type is (character(*))
  deallocate(this%mold)
  allocate(character(this%maxlen) :: this%mold)
end select
  end subroutine

end module

[Bug fortran/36854] [meta-bug] fortran front-end optimization

[tkoenig at gcc dot gnu.org]

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

Bug 45676 Summary: Move array assignments out of loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45676

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

[Bug fortran/30409] [fortran] missed optimization with pure function arguments

[tkoenig at gcc dot gnu.org]

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

--- Comment #6 from Thomas Koenig  ---
*** Bug 45676 has been marked as a duplicate of this bug. ***

[Bug fortran/45676] Move array assignments out of loop

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #6 from Thomas Koenig  ---
Closing as duplicate.

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

[Bug c++/68177] New: Lambda capture doesn't work correctly when lambda is used in a pack expansion

[rs2740 at gmail dot com]

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

Bug ID: 68177
   Summary: Lambda capture doesn't work correctly when lambda is
used in a pack expansion
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

Repro:

void swallow(...) {}
template
void foo() {
  int t = 0;
  swallow(
   ([]{return 0;}(), Is)...
  );
}


int main()
{
  foo<1, 2>();
  return 0;
}

gcc HEAD 6.0.0 20151031 (experimental) reports:

prog.cc: In instantiation of 'void foo() [with int ...Is = 1, 2]':
prog.cc:13:13:   required from here
prog.cc:6:5: error: member 'foo() [with int ...Is = 1, 2]::::' is uninitialized reference
([]{return 0;}(), Is)...
 ^

It appears that only the capture in the first element in the pack expansion
gets initialized correctly.

Clang accepts this code, as does MSVC.

[Bug pch/68176] New: [4.8/4.9 Regression] all pch tests fail on eglibc systems (with bits/predefs.h)

[nix at esperi dot org.uk]

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

Bug ID: 68176
   Summary: [4.8/4.9 Regression] all pch tests fail on eglibc
systems (with bits/predefs.h)
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: pch
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nix at esperi dot org.uk
  Target Milestone: ---

Since the fix to bug 65550, more or less all pch tests fail, with symptoms
identical to those reported in bug 55399:

FAIL: gcc.dg/pch/common-1.c  -O0 -g -I. -Dwith_PCH (test for excess errors)
FAIL: gcc.dg/pch/common-1.c -O0 -g assembly comparison
FAIL: gcc.dg/pch/common-1.c   -O0  -I. -Dwith_PCH (test for excess errors)
FAIL: gcc.dg/pch/common-1.c  -O0  assembly comparison
FAIL: gcc.dg/pch/common-1.c   -O1  -I. -Dwith_PCH (test for excess errors)
FAIL: gcc.dg/pch/common-1.c  -O1  assembly comparison
FAIL: gcc.dg/pch/common-1.c   -O2  -I. -Dwith_PCH (test for excess errors)
FAIL: gcc.dg/pch/common-1.c  -O2  assembly comparison
FAIL: gcc.dg/pch/common-1.c   -O3 -fomit-frame-pointer  -I. -Dwith_PCH (test
for excess errors)
FAIL: gcc.dg/pch/common-1.c  -O3 -fomit-frame-pointer  assembly comparison
FAIL: gcc.dg/pch/common-1.c   -O3 -g  -I. -Dwith_PCH (test for excess errors)
FAIL: gcc.dg/pch/common-1.c  -O3 -g  assembly comparison
FAIL: gcc.dg/pch/common-1.c   -Os  -I. -Dwith_PCH (test for excess errors)
FAIL: gcc.dg/pch/common-1.c  -Os  assembly comparison
FAIL: gcc.dg/pch/counter-1.c  -O0 -g -I. -Dwith_PCH (test for excess errors)
FAIL: gcc.dg/pch/counter-1.c -O0 -g assembly comparison
FAIL: gcc.dg/pch/counter-1.c   -O0  -I. -Dwith_PCH (test for excess errors)
FAIL: gcc.dg/pch/counter-1.c  -O0  assembly comparison
FAIL: gcc.dg/pch/counter-1.c   -O1  -I. -Dwith_PCH (test for excess errors)
FAIL: gcc.dg/pch/counter-1.c  -O1  assembly comparison
FAIL: gcc.dg/pch/counter-1.c   -O2  -I. -Dwith_PCH (test for excess errors)
FAIL: gcc.dg/pch/counter-1.c  -O2  assembly comparison
FAIL: gcc.dg/pch/counter-1.c   -O3 -fomit-frame-pointer  -I. -Dwith_PCH (test
for excess errors)
FAIL: gcc.dg/pch/counter-1.c  -O3 -fomit-frame-pointer  assembly comparison
FAIL: gcc.dg/pch/counter-1.c   -O3 -g  -I. -Dwith_PCH (test for excess errors)
FAIL: gcc.dg/pch/counter-1.c  -O3 -g  assembly comparison
FAIL: gcc.dg/pch/counter-1.c   -Os  -I. -Dwith_PCH (test for excess errors)
FAIL: gcc.dg/pch/counter-1.c  -Os  assembly comparison
[etc etc ad nauseam]

The failures are all identical in the logs: a refusal to use common-1.h.gch,
thus an attempt to find common-1.h, which has specifically been removed to
ensure that PCH is used.

The underlying cause of this is that on eglibc -- but not glibc -- systems,
/usr/include/stdc-predef.h itself includes , and that
inclusion, being done by a normal #include, does not get implicit_preinclude
set. So all PCH inclusion fails, spuriously.

eglibc is pretty dead by now: it may be that we don't care about this. But
there are still systems using it, and they were broken by this change.

[Bug c++/68177] Lambda capture doesn't work correctly when lambda is used in a pack expansion

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-01
 CC||trippels at gcc dot gnu.org
 Blocks||54367
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
EDG also accepts tho code.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367
[Bug 54367] [meta-bug] lambda expressions

[Bug fortran/68108] [6 regression] erroneous error message 'scalar integer expression expected'

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||neil.n.carlson at gmail dot com

--- Comment #10 from Dominique d'Humieres  ---
*** Bug 68174 has been marked as a duplicate of this bug. ***

[Bug c/68173] gcc does not terminate with -O0 on source file with a very large expression

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #2 from Markus Trippelsdorf  ---
It compiles fine with trunk. ~16GB peak memory and it takes ~15 minutes on
POWER8.
clang hits an assertion very quickly.

[Bug c/68173] gcc does not terminate with -O0 on source file with a very large expression

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||memory-hog

--- Comment #3 from Andrew Pinski  ---
(In reply to Markus Trippelsdorf from comment #2)
> It compiles fine with trunk. ~16GB peak memory and it takes ~15 minutes on
> POWER8.

So yes it was most likely swapping on the reporter machine which is why it was
taking so long.

[Bug fortran/54070] [4.9/5/6 Regression] Wrong code with allocatable deferred-length (array) function results

[dominiq at lps dot ens.fr]

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

--- Comment #21 from Dominique d'Humieres  ---
*** Bug 66065 has been marked as a duplicate of this bug. ***

[Bug fortran/66065] ICE on assignment to deferred-length character array

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Dominique d'Humieres  ---
Likely a duplicate of pr54070.

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

[Bug fortran/54070] [4.9/5/6 Regression] Wrong code with allocatable deferred-length (array) function results

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #20 from kargl at gcc dot gnu.org ---
(In reply to neil.n.carlson from comment #19)
> What is the status of this issue? 

It appears to not be completely fixed.

[Bug fortran/54070] [4.9/5/6 Regression] Wrong code with allocatable deferred-length (array) function results

[neil.n.carlson at gmail dot com]

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

neil.n.carlson at gmail dot com changed:

   What|Removed |Added

 CC||neil.n.carlson at gmail dot com

--- Comment #19 from neil.n.carlson at gmail dot com ---
What is the status of this issue?  It would appear from comment 18 to be
"fixed" insofar as the the provided examples compile, but is the compiled code
correct?

I'd report the following example as a new bug, but I know it would be
immediately dismissed as a duplicate of this bug.  This dumb little example
compiles with 5.2 and the 20151025 snapshot of 6.0, but in both cases the
generated code is bad as it segfaults on a clearly valid assignment statement.

program main
  character(:), allocatable :: string(:)
  call fubar (string)
contains
  subroutine fubar (string)
character(:), allocatable, intent(out) :: string(:)
allocate(character(5) :: string(2))
print *, 'len(string)=', len(string), ', size(string)=', size(string)
string = 'fubar' ! <== SEGMENTATION FAULT HERE
  end subroutine
end program

Produces this output:

 len(string)=   5 , size(string)=   2

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x7FFB05C4E517
#1  0x7FFB05C4EB5E
#2  0x7FFB0514F95F
#3  0x7FFB051B6EC8
#4  0x400D23 in fubar.3417 at fubar.f90:?
#5  0x400DC9 in MAIN__ at fubar.f90:?
Segmentation fault (core dumped)

[Bug fortran/54070] [4.9/5/6 Regression] Wrong code with allocatable deferred-length (array) function results

[dominiq at lps dot ens.fr]

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

--- Comment #22 from Dominique d'Humieres  ---
> What is the status of this issue?  It would appear from comment 18
> to be "fixed" insofar as the the provided examples compile, but is
> the compiled code correct?

This a wrong interpretation: most of the tests used to compile (with r188654,
hence the regression), at some point compiling most of them gave an ICE, now
two of them compiles. I never said that the compiled codes were correct, they
are all missing a test for that. In top of that this PR is still opened. 

Now the following variant of 'b' ('a' being the original test, i.e., the third
in comment 0):

print *, "'", f(), "'"

contains
function f()
  character(len=:),allocatable :: f
  f ="ABC"
end function
end

compiles and outputs

 'ABC'

Now tha problem is that there are several PRs opened for deferred-length (at
least nine, eight now!-) and so far nobody care to check for duplicates.

Note that comment 18 was an answer to comment 17

> I found it fixed in 5.2.0

[Bug go/67968] go1: internal compiler error: in write_specific_type_functions, at go/gofrontend/types.cc:1812

[ian at gcc dot gnu.org]

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

--- Comment #15 from ian at gcc dot gnu.org  ---
Author: ian
Date: Sun Nov  1 20:46:21 2015
New Revision: 229643

URL: https://gcc.gnu.org/viewcvs?rev=229643=gcc=rev
Log:
PR go/67968
compiler: Traverse types of call expressions.

https://gcc.gnu.org/PR67968 provides a test case that causes a gccgo
crash on valid code.  The compiler failed to build the hash and equality
functions required for a type descriptor.  The descriptor is for an
unnamed type that is being returned by a function imported from a
different package.  The unnamed type is being implicitly converted to an
interface type by a return statement.  The fix is to ensure that the
type of a call expression is always traversed.

Test case sent out for the master testsuite as
https://golang.org/cl/16532 .

Modified:
branches/gcc-5-branch/gcc/go/gofrontend/expressions.cc

[Bug go/67968] go1: internal compiler error: in write_specific_type_functions, at go/gofrontend/types.cc:1812

[ian at gcc dot gnu.org]

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

--- Comment #16 from ian at gcc dot gnu.org  ---
Author: ian
Date: Sun Nov  1 20:46:37 2015
New Revision: 229644

URL: https://gcc.gnu.org/viewcvs?rev=229644=gcc=rev
Log:
PR go/67968
compiler: Traverse types of call expressions.

https://gcc.gnu.org/PR67968 provides a test case that causes a gccgo
crash on valid code.  The compiler failed to build the hash and equality
functions required for a type descriptor.  The descriptor is for an
unnamed type that is being returned by a function imported from a
different package.  The unnamed type is being implicitly converted to an
interface type by a return statement.  The fix is to ensure that the
type of a call expression is always traversed.

Test case sent out for the master testsuite as
https://golang.org/cl/16532 .

Modified:
branches/gcc-4_9-branch/gcc/go/gofrontend/expressions.cc

[Bug go/67968] go1: internal compiler error: in write_specific_type_functions, at go/gofrontend/types.cc:1812

[ian at gcc dot gnu.org]

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

--- Comment #14 from ian at gcc dot gnu.org  ---
Author: ian
Date: Sun Nov  1 20:46:04 2015
New Revision: 229642

URL: https://gcc.gnu.org/viewcvs?rev=229642=gcc=rev
Log:
PR go/67968
compiler: Traverse types of call expressions.

https://gcc.gnu.org/PR67968 provides a test case that causes a gccgo
crash on valid code.  The compiler failed to build the hash and equality
functions required for a type descriptor.  The descriptor is for an
unnamed type that is being returned by a function imported from a
different package.  The unnamed type is being implicitly converted to an
interface type by a return statement.  The fix is to ensure that the
type of a call expression is always traversed.

Test case sent out for the master testsuite as
https://golang.org/cl/16532 .

Modified:
trunk/gcc/go/gofrontend/MERGE
trunk/gcc/go/gofrontend/expressions.cc

[Bug fortran/68174] Length parameter in character allocation not recognized as a scalar (regression from 5.2)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Duplicate of pr68108, try newer revisions.

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

[Bug c/68173] gcc does not terminate with -O0 on source file with a very large expression

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Can you check if you are swapping (that is if the memory usage is high).

[Bug ipa/68175] New: g++ 5.2.1 produces broken executables with devirtualization enabled

[bnagaev at gmail dot com]

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

Bug ID: 68175
   Summary: g++ 5.2.1 produces broken executables with
devirtualization enabled
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bnagaev at gmail dot com
  Target Milestone: ---

The following code compiles to a broken executable:

```cpp
#include 

const int BUFFER_SIZE = 4096;
char buffer_[BUFFER_SIZE];

struct BufferedIfstream : public std::ifstream {
BufferedIfstream() {
rdbuf()->pubsetbuf(buffer_, BUFFER_SIZE);
}
};

int main() {
BufferedIfstream fff;
return 0;
}
```

Compilation command:

$ g++-5 bug.cpp -O2 -o bug.exe

Run it:

$ ./bug.exe
Segmentation fault

Options `-Wall -Wextra` produce no warnings.
Options `-fno-strict-aliasing -fwrapv` change nothing.

Without `-O2` (or `-O3`) the bug disappears.
With `-fno-devirtualize` the bug disappears.
With `-O1` the bug disappears but with `-O1 -fdevirtualize` appears again.

Without a class the bug disappears. The following code works correctly:

```cpp
#include 

const int BUFFER_SIZE = 4096;
char buffer_[BUFFER_SIZE];

int main() {
std::ifstream fff;
fff.rdbuf()->pubsetbuf(buffer_, BUFFER_SIZE);
return 0;
}
```

I have reproduced this bug in gcc 5.1.0, 5.2.0 (MXE build, MinGW-w64 [1]) and
in gcc 5.2.1 (Debian Stretch, amd64 Linux, 5.2.1-22). I believe this bug was
introduced in gcc 5, when devirtualization was refactored [2].

The issue seems to be related to the mailing thread about -O3 (MXE): stack
smashing on i686 with -O3 since da82d07dbe [3].

[1] https://github.com/mxe/mxe/issues/964
[2] https://gcc.gnu.org/gcc-5/changes.html
[3]
http://lists.nongnu.org/archive/html/mingw-cross-env-list/2015-10/msg00020.html

[Bug fortran/67982] Incorrect -Wunused-function warning

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #6 from Thomas Koenig  ---
(In reply to Joost VandeVondele from comment #5)

> Let's leave it open for a while, it would be good to commit a testcase to
> trunk to make sure this doesn't regress. As it seems fixed 'accidentally'
> this might be a good idea. I might do this, even though it will take a while
> (it is a bit unfortunate that the time overhead of submitting & committing a
> patch is not small).

Committing a valid test case for something that has been fixed
by something unknown falls under the "obviously correct" category,
so it can be done without a review.  Just drop a mail to fortran@
and gcc-patches@ after committing with the details.

[Bug c/68173] gcc does not terminate with -O0 on source file with a very large expression

[fuz at fuz dot su]

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

--- Comment #4 from Robert Clausecker  ---
No, it wasn't swapping, although I probably didn't let it run long enough to
exhaust all my memory (8 GiB). Either way, the file compiles pretty quickly
with -O3 so something seems to be wrong when no optimizations (-O0) take
considerably longer than many optimizations (-O3).

[Bug target/68178] New: [arm] Relative address expressions bind at as-time, even if symbol is weak

[bugdal at aerifal dot cx]

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

Bug ID: 68178
   Summary: [arm] Relative address expressions bind at as-time,
even if symbol is weak
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugdal at aerifal dot cx
  Target Milestone: ---

This bug is almost identical to #66609 for [sh], except the conditions needed
to trigger it are slightly different. Minimal test case (compile with -fPIC; -O
level does not matter):

__attribute__((__weak__,__visibility__("hidden"))) void foo()
{
}

void *bar()
{
return (void *)foo;
}

The expected output should have a relocation for foo, since the weak definition
is replaceable by a strong definition from another TU. The actual output has a
PC-relative constant pointing to the weak definition.

This bug seriously broke musl libc's pthread_cancel.c, where the weak version
of the symbol used for updating PC upon cancellation has the wrong contract for
stack state, and the strong version from arm-specific asm needs to be used.

I still question whether this issue should be fixed on the binutils side for
all targets; see: https://sourceware.org/bugzilla/show_bug.cgi?id=18561

[Bug fortran/68151] ICE on using select case with function of wrong type

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org
   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.

[Bug fortran/68153] ICE for intrinsic reshape with negative dim in effective shape

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

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

[Bug go/67508] [aarch64] gccgo runtime crashes with CONFIG_ARM64_PGTABLE_LEVELS=4 (48bit VMA)

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #1 from Ian Lance Taylor  ---
The proposed fix was merged into mainline on September 23.  I assume that this
problem is now fixed.

[Bug go/67968] go1: internal compiler error: in write_specific_type_functions, at go/gofrontend/types.cc:1812

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #17 from Ian Lance Taylor  ---
Dominik, thanks very much for reducing the problem to a simple test case.  That
was a great help.

I've committed the fix to mainline, GCC 5 branch, and GCC 4.9 branch.

[Bug sanitizer/68100] runtime segfault ARM boost::regex_replace -fsanitize=undefined member access within misaligned address

[yba at tkos dot co.il]

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

--- Comment #1 from Jonathan Ben-Avraham  ---
jonathana@orcam81:~/pub/gcc/bugs$
/homes/jonathana/pub/mxs/tc/2015092100/arm-mxs-linux-gnueabihf/bin/arm-mxs-linux-gnueabihf-gcc
-v
Using built-in specs.
COLLECT_GCC=/homes/jonathana/pub/mxs/tc/2015092100/arm-mxs-linux-gnueabihf/bin/arm-mxs-linux-gnueabihf-gcc
COLLECT_LTO_WRAPPER=/homes/jonathana/pub/mxs/tc/2015092100/arm-mxs-linux-gnueabihf/bin/../libexec/gcc/arm-mxs-linux-gnueabihf/5.1.0/lto-wrapper
Target: arm-mxs-linux-gnueabihf
Configured with: /home/yba/crosstool-ng-1.21.0/.build/src/gcc-5.1.0/configure
--build=x86_64-build_unknown-linux-gnu --host=x86_64-build_unknown-linux-gnu
--target=arm-mxs-linux-gnueabihf
--prefix=/home/yba/crosstool-ng-1.21.0/x-tools/arm-mxs-linux-gnueabihf
--with-sysroot=/home/yba/crosstool-ng-1.21.0/x-tools/arm-mxs-linux-gnueabihf/arm-mxs-linux-gnueabihf/sysroot
--enable-languages=c,c++ --with-cpu=cortex-a9 --with-fpu=neon --with-float=hard
--with-pkgversion='crosstool-NG ' --enable-__cxa_atexit --disable-libmudflap
--disable-libgomp --disable-libssp --disable-libquadmath
--disable-libquadmath-support --enable-libsanitizer
--with-gmp=/home/yba/crosstool-ng-1.21.0/.build/arm-mxs-linux-gnueabihf/buildtools
--with-mpfr=/home/yba/crosstool-ng-1.21.0/.build/arm-mxs-linux-gnueabihf/buildtools
--with-mpc=/home/yba/crosstool-ng-1.21.0/.build/arm-mxs-linux-gnueabihf/buildtools
--with-isl=/home/yba/crosstool-ng-1.21.0/.build/arm-mxs-linux-gnueabihf/buildtools
--with-cloog=/home/yba/crosstool-ng-1.21.0/.build/arm-mxs-linux-gnueabihf/buildtools
--with-libelf=/home/yba/crosstool-ng-1.21.0/.build/arm-mxs-linux-gnueabihf/buildtools
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--enable-threads=posix --enable-target-optspace --disable-nls
--disable-multilib
--with-local-prefix=/home/yba/crosstool-ng-1.21.0/x-tools/arm-mxs-linux-gnueabihf/arm-mxs-linux-gnueabihf/sysroot
--enable-long-long
Thread model: posix
gcc version 5.1.0 (crosstool-NG )

[Bug sanitizer/68099] arm-*-linux-gnueabihf -fsanitize=undefined warning: '' is used uninitialized in this function

[yba at tkos dot co.il]

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

--- Comment #8 from Jonathan Ben-Avraham  ---
(In reply to Richard Earnshaw from comment #1)
> The gcc developers do not use crosstool, so providing us with a config for
> it is of no help.  Furthermore, un-preprocessed source means we are unlikely
> to be able to reproduce the exact conditions leading up to the failure you
> see.
> 
> What we do need are:
> 
> 1) The output of "gcc -v", showing how the compiler was actually configured.
> 2) *Pre-processed* source that we can feed into our own builds of the
> compiler to try to reproduce the problem

See attached test.i preprocesor output

[Bug middle-end/68166] [6 regression] fold-const.c:12040:18: error: aggregate 'md5_ctx ctx' has incomplete type and cannot be defined

[tschwinge at gcc dot gnu.org]

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

--- Comment #2 from Thomas Schwinge  ---
Author: tschwinge
Date: Mon Nov  2 07:42:04 2015
New Revision: 229652

URL: https://gcc.gnu.org/viewcvs?rev=229652=gcc=rev
Log:
[PR middle-end/68166] Restore build with fold checking enabled

gcc/
PR middle-end/68166
* fold-const.c: Include "md5.h".

Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c

[Bug c++/68164] Destructor side effect unexpectedly elided

[webrown.cpp at gmail dot com]

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

--- Comment #2 from W E Brown  ---
(In reply to Casey Carter from comment #1)
> [basic.life]/5 says:
> 
> Before the lifetime of an object has started ... or, after the lifetime of
> an object has ended and before the storage which the object occupied is
> reused or released, any pointer that refers to the storage location where
> the object will be or was located may be used but only in limited ways. ...
> Indirection through such a pointer is permitted but the resulting lvalue may
> only be used in limited ways, as described below. The program has undefined
> behavior if:
> 
> (5.1) — ...
> 
> (5.2) — the pointer is used to access a non-static data member or call a
> non-static member function of the object, or
> 
> ...
> 
> This looks like straight-forward violation of 5.2 resulting in UB.

By this reasoning, no c'tor or d'tor would be allowed, in its body, to access
any of its non-static data members or call any of its non-static member
functions.  There must be more to it, and indeed IMO there is.

According to the second sentence of [class.cdtor]/3:

"To ... access the value of ... a direct non-static member of an object obj,
the construction of obj shall have started and its destruction shall not have
completed, otherwise ... accessing the member value ... results in undefined
behavior."

Moreover, according to the first sentence of the next paragraph
([class.cdtor]/4), "Member functions, including virtual functions, can be
called during construction or destruction" [cross-references elided].

I conclude that the access in the test program's d'tor does not qualify as
undefined behavior and is therefore permissible.

Accordingly, I recommend further analysis of the original report.

[Bug middle-end/68166] [6 regression] fold-const.c:12040:18: error: aggregate 'md5_ctx ctx' has incomplete type and cannot be defined

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||tschwinge at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |tschwinge at gcc dot 
gnu.org

--- Comment #3 from Thomas Schwinge  ---
Presumed fixed in r229652,
.
 Please re-open and provide your configure/build flags if you're still seeing
this.

[Bug sanitizer/68099] arm-*-linux-gnueabihf -fsanitize=undefined warning: '' is used uninitialized in this function

[yba at tkos dot co.il]

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

--- Comment #7 from Jonathan Ben-Avraham  ---
Created attachment 36633
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36633=edit
The preprocessed source code

[Bug c++/68061] Can't use [[deprecated]] with requires clause

[Casey at Carter dot net]

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

Casey Carter  changed:

   What|Removed |Added

 CC||Casey at Carter dot net

--- Comment #2 from Casey Carter  ---
Reduced test case:

template 
  requires true
[[deprecated]] void f(T);

[Bug c++/68164] Destructor side effect unexpectedly elided

[Casey at Carter dot net]

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

--- Comment #3 from Casey Carter  ---
Apologies for the vagueness of my response; I actually needed your quote from
[class.cdtor]/3 to complete it:

"To ... access the value of ... a direct non-static member of an object obj,
the construction of obj shall have started and its destruction shall not have
completed, otherwise ... accessing the member value ... results in undefined
behavior."

The access to bp[i].data in the for loop inside the catch clause is the access
to which I was referring. This access clearly happens outside the lifetime of
any of the B objects. The destruction of bp[i] has completed for i in [0, 2) -
so these accesses are UB per [class.cdtor]/3 - and the lifetime of bp[i] for i
in [2, N) has not yet begun - these accesses are UB per [basic.life]/5.2.

[Bug fortran/54070] [4.9/5/6 Regression] Wrong code with allocatable deferred-length (array) function results

[neil.n.carlson at gmail dot com]

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

--- Comment #23 from neil.n.carlson at gmail dot com ---
Here's an even simpler example with the deferred length character array as a
local variable -- not a function result or dummy argument.  Sure seems as
though the allocate statement itself is what is being mishandled:

program main
  character(:), pointer :: s(:)
  allocate(character(3)::s(2))
  s(1) = 'foo'; s(2) = 'bar'
  print *, s, ' (expect "foobar")'
end program

Compiles with both 5.2 and 6.0 20151025, but both return the wrong result:

 barbar (expect "foobar")

[Bug sanitizer/68099] arm-*-linux-gnueabihf -fsanitize=undefined warning: '' is used uninitialized in this function

[yba at tkos dot co.il]

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

--- Comment #6 from Jonathan Ben-Avraham  ---
(In reply to Richard Earnshaw from comment #1)
> The gcc developers do not use crosstool, so providing us with a config for
> it is of no help.  Furthermore, un-preprocessed source means we are unlikely
> to be able to reproduce the exact conditions leading up to the failure you
> see.
> 
> What we do need are:
> 
> 1) The output of "gcc -v", showing how the compiler was actually configured.
> 2) *Pre-processed* source that we can feed into our own builds of the
> compiler to try to reproduce the problem

jonathana@orcam81:~/pub/gcc/bugs$
/homes/jonathana/pub/mxs/tc/2015092100/arm-mxs-linux-gnueabihf/bin/arm-mxs-linux-gnueabihf-gcc
-v
Using built-in specs.
COLLECT_GCC=/homes/jonathana/pub/mxs/tc/2015092100/arm-mxs-linux-gnueabihf/bin/arm-mxs-linux-gnueabihf-gcc
COLLECT_LTO_WRAPPER=/homes/jonathana/pub/mxs/tc/2015092100/arm-mxs-linux-gnueabihf/bin/../libexec/gcc/arm-mxs-linux-gnueabihf/5.1.0/lto-wrapper
Target: arm-mxs-linux-gnueabihf
Configured with: /home/yba/crosstool-ng-1.21.0/.build/src/gcc-5.1.0/configure
--build=x86_64-build_unknown-linux-gnu --host=x86_64-build_unknown-linux-gnu
--target=arm-mxs-linux-gnueabihf
--prefix=/home/yba/crosstool-ng-1.21.0/x-tools/arm-mxs-linux-gnueabihf
--with-sysroot=/home/yba/crosstool-ng-1.21.0/x-tools/arm-mxs-linux-gnueabihf/arm-mxs-linux-gnueabihf/sysroot
--enable-languages=c,c++ --with-cpu=cortex-a9 --with-fpu=neon --with-float=hard
--with-pkgversion='crosstool-NG ' --enable-__cxa_atexit --disable-libmudflap
--disable-libgomp --disable-libssp --disable-libquadmath
--disable-libquadmath-support --enable-libsanitizer
--with-gmp=/home/yba/crosstool-ng-1.21.0/.build/arm-mxs-linux-gnueabihf/buildtools
--with-mpfr=/home/yba/crosstool-ng-1.21.0/.build/arm-mxs-linux-gnueabihf/buildtools
--with-mpc=/home/yba/crosstool-ng-1.21.0/.build/arm-mxs-linux-gnueabihf/buildtools
--with-isl=/home/yba/crosstool-ng-1.21.0/.build/arm-mxs-linux-gnueabihf/buildtools
--with-cloog=/home/yba/crosstool-ng-1.21.0/.build/arm-mxs-linux-gnueabihf/buildtools
--with-libelf=/home/yba/crosstool-ng-1.21.0/.build/arm-mxs-linux-gnueabihf/buildtools
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--enable-threads=posix --enable-target-optspace --disable-nls
--disable-multilib
--with-local-prefix=/home/yba/crosstool-ng-1.21.0/x-tools/arm-mxs-linux-gnueabihf/arm-mxs-linux-gnueabihf/sysroot
--enable-long-long
Thread model: posix
gcc version 5.1.0 (crosstool-NG )

[Bug c++/68164] Destructor side effect unexpectedly elided

[Casey at Carter dot net]

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

Casey Carter  changed:

   What|Removed |Added

 CC||Casey at Carter dot net

--- Comment #1 from Casey Carter  ---
[basic.life]/5 says:

Before the lifetime of an object has started ... or, after the lifetime of an
object has ended and before the storage which the object occupied is reused or
released, any pointer that refers to the storage location where the object will
be or was located may be used but only in limited ways. ... Indirection through
such a pointer is permitted but the resulting lvalue may only be used in
limited ways, as described below. The program has undefined behavior if:

(5.1) — ...

(5.2) — the pointer is used to access a non-static data member or call a
non-static member function of the object, or

...

This looks like straight-forward violation of 5.2 resulting in UB.