[Bug tree-optimization/71311] [7 Regression] spec2006 test case 416.gamess fails since r235817

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #8 from prathamesh3492 at gcc dot gnu.org ---
(In reply to prathamesh3492 from comment #7)
> Not sure if it's the same issue, however I am seeing miscompare for
> 416.gamess again with r241197.
The above suggested workaround to disable vectorization fixes it.

Thanks,
Prathamesh
> 
> Thanks,
> Prathamesh

[Bug middle-end/77996] Miscompilation due to LTO on aarch64

[yyc1992 at gmail dot com]

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

--- Comment #10 from Yichao Yu  ---
That does look like an violation (this particular one should be hidden behind
shared library boundary in the reduced case though). Reported to LLVM at
https://llvm.org/bugs/show_bug.cgi?id=30711 .

[Bug tree-optimization/71311] [7 Regression] spec2006 test case 416.gamess fails since r235817

[prathamesh3492 at gcc dot gnu.org]

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

prathamesh3492 at gcc dot gnu.org changed:

   What|Removed |Added

 CC||prathamesh3492 at gcc dot 
gnu.org

--- Comment #7 from prathamesh3492 at gcc dot gnu.org ---
Not sure if it's the same issue, however I am seeing miscompare for 416.gamess
again with r241197.

Thanks,
Prathamesh

[Bug middle-end/77996] Miscompilation due to LTO on aarch64

[pinskia at gcc dot gnu.org]

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

--- Comment #9 from Andrew Pinski  ---
here is one example where LLVM could be violating C aliasing rules:
void FoldingSetNodeID::AddPointer(const void *Ptr) {
  Bits.append(reinterpret_cast(),
  reinterpret_cast(+1));
}

There could be others.

[Bug middle-end/77996] Miscompilation due to LTO on aarch64

[yyc1992 at gmail dot com]

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

--- Comment #8 from Yichao Yu  ---
> Can you try with -fno-strict-aliasing ?

That seems to fix it for both the original case (LLVM) and the reduced case
(the linked tarball). Is there a way to figure out the problematic (either bug
in LLVM's code or gcc's alias detection) aliasing assumption?

[Bug middle-end/77996] Miscompilation due to LTO on aarch64

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski  ---
Can you try with -fno-strict-aliasing ?

[Bug middle-end/77996] Miscompilation due to LTO on aarch64

[yyc1992 at gmail dot com]

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

--- Comment #6 from Yichao Yu  ---
I've compiled a gcc at 951db45 using the same configuration as archlinux arm
PKGBUILD and I can reproduce the problem using the `code/` in
https://gist.github.com/yuyichao/6c24d4a4bc374425906138359a44479c/raw/f5edb6ae8205d5e4d1eb03a7fb900f15711f/gcc-debug.tar.bz2

[Bug middle-end/77996] Miscompilation due to LTO on aarch64

[yyc1992 at gmail dot com]

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

--- Comment #5 from Yichao Yu  ---
Compiling current llvm trunk (r284322) still shows the same error. The script I
used to compile LLVM is here
https://github.com/yuyichao/arch-pkg/blob/master/pkg/all/llvm-svn/PKGBUILD.


Compiling gcc 951db45 now.

[Bug middle-end/77996] Miscompilation due to LTO on aarch64

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
# Arch Linux installs 64bit libraries /lib

So non-standard (but that is not an issue here).

[Bug middle-end/77996] Miscompilation due to LTO on aarch64

[yyc1992 at gmail dot com]

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

--- Comment #3 from Yichao Yu  ---
> What exact version of LLVM are you trying to compile?  Revision of the LLVM 
> sources including revision of clang, etc.

I was compiling the trunk version. The version I started reducing from was
https://github.com/llvm-mirror/llvm/commit/0885462106134999f8aa80a3a71bfed160910248
but it happens on at least 3 different version I've tried before this commit.

> Can you try compile GCC from the 6 branch and try again because having just a 
> date might not be enough to reproduce the problem.

The script used to compile GCC is
https://github.com/archlinuxarm/PKGBUILDs/blob/master/core/gcc/PKGBUILD so it
seems to be using commit `c2103c17` I can also try to compile a more recent
version locally (will take some time).

[Bug lto/77997] Miscompilation due to LTO on aarch64

[yyc1992 at gmail dot com]

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

--- Comment #2 from Yichao Yu  ---
. Sorry the first submission gave me a time out so I did again..

[Bug middle-end/77996] Miscompilation due to LTO on aarch64

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
*** Bug 77997 has been marked as a duplicate of this bug. ***

[Bug lto/77997] Miscompilation due to LTO on aarch64

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup.

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

[Bug lto/77996] Miscompilation due to LTO on aarch64

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-10-16
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
What exact version of LLVM are you trying to compile?  Revision of the LLVM
sources including revision of clang, etc.

>6.2.1 20160830

Can you try compile GCC from the 6 branch and try again because having just a
date might not be enough to reproduce the problem.

[Bug lto/77997] New: Miscompilation due to LTO on aarch64

[yyc1992 at gmail dot com]

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

Bug ID: 77997
   Summary: Miscompilation due to LTO on aarch64
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yyc1992 at gmail dot com
  Target Milestone: ---

I'm seeing a miscompilation of LLVM's tablegen on AArch64 by gcc 6.2.1 when LTO
is enabled. I've tried very hard to reduce it but unfortunately it wasn't very
successful this time and the current repro is still 8000 lines of code.

Attached are the source and resulting binaries. (Edit: the tarball is too big
(3M) so I uploaded to gist instead. Please find it here
https://gist.githubusercontent.com/yuyichao/6c24d4a4bc374425906138359a44479c/raw/f5edb6ae8205d5e4d1eb03a7fb900f15711f/report.md)

The `code/` directory has a simple cmake projects reduced from the LLVM one (I
can turn that into a makefile or a shell script on request but the current form
should be pretty simple already). To reproduce make a `build/` directory in
`code/` and run `CFLAGS='-flto -O3' CXXFLAGS='-flto -O3' LDFLAGS='-O3 -flto'
cmake .. -DCMAKE_BUILD_TYPE=Release; make llvm-tblgen; bin/llvm-tblgen`. Remove
the `-flto` should get rid of the error in the last command.

Changes in seemingly unrelated lines can also make the error go away. (If
there's anything I learnt from reducing it, the error seems to appear only when
the code is complex). One of such changes is commenting out
`SCTrans.PredTerm = Preds;` close to the end of `CodeGenSchedule.cpp` (used to
generate the `good/` version included). In fact, removing almost any lines in
this file can make the error go away even though not a single line of code
there should be executed.

The `bad/` and the `good/` directories conatins compilation results using the
flags mentioned above with the unmodified code and the code with the one line
commented out. They have all the object files, binary files and the disassemble
of the resulting executable/the bad function. The asm's are disassembled from
the final binary since I don't know how to get it directly when compiling with
LTO.

The direct error seems to be in `CodeGenRegister::computeSubRegs` in the branch
before the `printf("5\n")`. The `DenseMap::insert` method (which is called
twice in this function and nowhere else) is inlined but returns corrupted
iterator sometimes when the inserted key already exists in the map causing the
check to fail. The difference of asm of this function is in the toplevel of the
tarball.

Original repro is compiling LLVM with LTO on on AArch64. The compilation should
fail when generating target information for AArch64.

GCC version is GCC binary package from ArchLinux ARM repo. `gcc --version`
gives `gcc (GCC) 6.2.1 20160830`

[Bug lto/77996] New: Miscompilation due to LTO on aarch64

[yyc1992 at gmail dot com]

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

Bug ID: 77996
   Summary: Miscompilation due to LTO on aarch64
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yyc1992 at gmail dot com
  Target Milestone: ---

I'm seeing a miscompilation of LLVM's tablegen on AArch64 by gcc 6.2.1 when LTO
is enabled. I've tried very hard to reduce it but unfortunately it wasn't very
successful this time and the current repro is still 8000 lines of code.

Attached are the source and resulting binaries.

The code/ directory has a simple cmake projects reduced from the LLVM one (I
can turn that into a makefile or a shell script on request but the current form
should be pretty simple already). To reproduce make a `build/` directory in
`code/` and run `CFLAGS='-flto -O3' CXXFLAGS='-flto -O3' LDFLAGS='-O3 -flto'
cmake .. -DCMAKE_BUILD_TYPE=Release; make llvm-tblgen; bin/llvm-tblgen`. Remove
the `-flto` should get rid of the error in the last command.

Changes in seemingly unrelated lines can also make the error go away. (If
there's anything I learnt from reducing it, the error seems to appear only when
the code is complex). One of such changes is commenting out
`SCTrans.PredTerm = Preds;` close to the end of `CodeGenSchedule.cpp` (used to
generate the good/ version included). In fact, removing almost any lines in
this file can make the error go away even though not a single line of code
there should be executed.

The bad/ and the good/ directories conatins compilation results using the flags
mentioned above with the unmodified code and the code with the one line
commented out. They have all the object files, binary files and the disassemble
of the resulting executable/the bad function. The asm's are disassembled from
the final binary since I don't know how to get it directly when compiling with
LTO.

The direct error seems to be in `CodeGenRegister::computeSubRegs` in the branch
before the `printf("5\n")`. The `DenseMap::insert` method (which is called
twice in this function and nowhere else) is inlined but returns corrupted
iterator sometimes when the inserted key already exists in the map causing the
check to fail. The difference of asm of this function is in the toplevel of the
tarball.

Original repro is compiling LLVM with LTO on on AArch64. The compilation should
fail when generating target information for AArch64.

GCC version is GCC binary package from ArchLinux ARM repo. `gcc --version`
gives `gcc (GCC) 6.2.1 20160830`

[Bug c++/77945] GCC generates invalid constexpr copy/move assignment operators for types with trailing padding.

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #7 from Jason Merrill  ---
Fixed for GCC 7.

[Bug testsuite/65938] FAIL: gcc.target/i386/pr56114.c: ambiguous operand size or operands invalid for movabs

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |MOVED

--- Comment #1 from Andrew Pinski  ---
This was a bug in binutils which has been fixed now the testcase is testing
that :).

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

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Jonathan Wakely from comment #7)
> Created attachment 39809 [details]
> Use default member initializers.

You attached the wrong patch?

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

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |7.0
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:
   |verify_gimple failed|verify_gimple failed

[Bug target/77991] ['7 Regression] ICE on x32 in plus_constant, at explow.c:87

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Target||x86_64-*-*
  Component|middle-end  |target
   Target Milestone|--- |7.0
Summary|ICE on x32 in   |['7 Regression] ICE on x32
   |plus_constant, at   |in plus_constant, at
   |explow.c:87 |explow.c:87

[Bug c++/77945] GCC generates invalid constexpr copy/move assignment operators for types with trailing padding.

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Sat Oct 15 21:25:55 2016
New Revision: 241204

URL: https://gcc.gnu.org/viewcvs?rev=241204=gcc=rev
Log:
PR c++/77945 - constexpr and trivial copy

* constexpr.c (maybe_simplify_trivial_copy): New.
(cxx_eval_store_expression): Call it.
* call.c (build_over_call): Use unsigned char for trivial copy.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-trivial2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/constexpr.c

[Bug bootstrap/77995] gcc 6.2.0 failed on somparison stage 2 & 3

[ikozhukhov at gmail dot com]

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

--- Comment #5 from Igor Kozhukhov  ---
thanks, i'll try and let you know.

i tried search it on config.log and i can see:

configure:7076: checking for default BUILD_CONFIG
configure:7108: result:

nothing in this field.

[Bug bootstrap/77995] gcc 6.2.0 failed on somparison stage 2 & 3

[ebotcazou at gcc dot gnu.org]

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

--- Comment #4 from Eric Botcazou  ---
If BUILD_CONFIG is empty, then a possible fix is at:
  https://gcc.gnu.org/ml/gcc-cvs/2016-10/msg00278.html

[Bug c++/77945] GCC generates invalid constexpr copy/move assignment operators for types with trailing padding.

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #5 from Jason Merrill  ---
Yeah, implementing trivial copy with the equivalent of memcpy is fine normally,
but not in constexpr evaluation.

[Bug fortran/77972] ICE on broken character continuation with -Wall etc.

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #5 from Jerry DeLisle  ---
Fixed and closing

[Bug fortran/77972] ICE on broken character continuation with -Wall etc.

[jvdelisle at gcc dot gnu.org]

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

--- Comment #4 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sat Oct 15 18:38:54 2016
New Revision: 241201

URL: https://gcc.gnu.org/viewcvs?rev=241201=gcc=rev
Log:
2016-10-15  Jerry DeLisle  

PR fortran/77972
* scanner.c (gfc_next_char_literal): If nextc is null do not
decrement the pointer and call the diagnostics.

PR fortran/77972
* gfortran.dg/unexpected_eof_4.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/unexpected_eof_4.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/scanner.c
trunk/gcc/testsuite/ChangeLog

[Bug bootstrap/77995] gcc 6.2.0 failed on somparison stage 2 & 3

[ikozhukhov at gmail dot com]

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

--- Comment #3 from Igor Kozhukhov  ---
it is x86_64 - intel, 64bit bootstrap for target x86_64-pc-solaris2.11

$ ../configure --prefix=/usr/gcc/6 --build=x86_64-pc-solaris2.11
--bindir=/usr/gcc/6/bin --sbindir=/usr/gcc/6/sbin --libdir=/usr/gcc/6/lib
--libexecdir=/usr/gcc/6/lib --infodir=/usr/gcc/6/share/info
--mandir=/usr/gcc/6/share/man --target=x86_64-pc-solaris2.11
--enable-targets=i386-pc-solaris2.11 --enable-shared --enable-plugins
--enable-lto --enable-initfini-array --enable-tls --enable-threads=posix
--without-gnu-ld --with-ld=/usr/bin/ld gcc_cv_ld_as_needed=no
--enable-languages=c,c++,fortran,objc,go --with-gnu-as --with-as=/usr/bin/gas

[Bug bootstrap/77995] gcc 6.2.0 failed on somparison stage 2 & 3

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Botcazou  ---
And can you report the value of BUILD_CONFIG in the toplevel config.log?

[Bug bootstrap/77995] gcc 6.2.0 failed on somparison stage 2 & 3

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||solaris

--- Comment #1 from Andrew Pinski  ---
Is this sparc or x86_64?

[Bug bootstrap/77995] New: gcc 6.2.0 failed on somparison stage 2 & 3

[ikozhukhov at gmail dot com]

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

Bug ID: 77995
   Summary: gcc 6.2.0 failed on somparison stage 2 & 3
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ikozhukhov at gmail dot com
  Target Milestone: ---

bootstrap of gcc-5.4 with binutils 2.27 is fine on DilOS (illumos based
platform)

but, 6.2.0 bootstrap failed with:

gmake[4]: Leaving directory
'/myshare/builds7/dilos/dg-git/components/gcc-6/d/gcc-6.2.0/build'
Comparing stages 2 and 3
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
gcc/tree-ssa-uninit.o differs
gcc/ipa-icf.o differs
gcc/tree-eh.o differs
libcpp/expr.o differs
Makefile:22475: recipe for target 'compare' failed
gmake[3]: *** [compare] Error 1
gmake[3]: Leaving directory
'/myshare/builds7/dilos/dg-git/components/gcc-6/d/gcc-6.2.0/build'

[Bug libstdc++/77994] std::sample uses incorrect integer types internally

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug libstdc++/77994] New: std::sample uses incorrect integer types internally

[gcc-bugzilla at contacts dot eelis.net]

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

Bug ID: 77994
   Summary: std::sample uses incorrect integer types internally
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugzilla at contacts dot eelis.net
  Target Milestone: ---

Both the reservoir sampling and the selection sampling implementations use a
uniform_int_distribution<_Size> to generate integers distributed over the
population size, but _Size is merely the type of the user-supplied argument
specifying the desired selection size, and that type may not be large enough to
represent integers distributed over the population size.

The selection sampling implementation also uses _Size for __unsampled_sz, which
is incorrect for the same reason.

[Bug libfortran/48587] Avoid exhausting unit number with NEWUNIT=

[jb at gcc dot gnu.org]

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

--- Comment #9 from Janne Blomqvist  ---
Author: jb
Date: Sat Oct 15 13:15:26 2016
New Revision: 241200

URL: https://gcc.gnu.org/viewcvs?rev=241200=gcc=rev
Log:
PR 48587 Newunit allocator

2016-10-15  Janne Blomqvist  

PR libfortran/48587
* gfortran.dg/negative_unit2.f90: New testcase.

Added:
trunk/gcc/testsuite/gfortran.dg/negative_unit2.f90

[Bug libfortran/48587] Avoid exhausting unit number with NEWUNIT=

[jb at gcc dot gnu.org]

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

--- Comment #8 from Janne Blomqvist  ---
Author: jb
Date: Sat Oct 15 13:14:15 2016
New Revision: 241199

URL: https://gcc.gnu.org/viewcvs?rev=241199=gcc=rev
Log:
PR 48587 Newunit allocator

Currently GFortran newer reuses unit numbers allocated with NEWUNIT=,
instead having a simple counter that is decremented each time such a
unit is opened.  For a long running program which repeatedly opens
files with NEWUNIT= and closes them, the counter can wrap around and
cause an abort.  This patch replaces the counter with an allocator
that keeps track of which units numbers are allocated, and can reuse
them once they have been deallocated.  Since operating systems tend to
limit the number of simultaneous open files for a process to a
relatively modest number, a relatively simple approach with a linear
scan through an array suffices.  Though as a small optimization there
is a low water indicator keeping track of the index for which all unit
numbers below are already allocated.  This linear scan also ensures
that we always allocate the smallest available unit number.

2016-10-15  Janne Blomqvist  

PR libfortran/48587
* io/io.h (get_unique_unit_number): Remove prototype.
(newunit_alloc): New prototype.
* io/open.c (st_open): Call newunit_alloc.
* io/unit.c (newunits,newunit_size,newunit_lwi): New static
variables.
(GFC_FIRST_NEWUNIT): Rename to NEWUNIT_START.
(next_available_newunit): Remove variable.
(get_unit): Call newunit_alloc, don't try to create negative
external unit.
(close_unit_1): Call newunit_free.
(close_units): Free newunits array.
(get_unique_number): Remove function.
(newunit_alloc): New function.
(newunit_free): New function.
* io/transfer.c (data_transfer_init): Check for invalid unit
number.

testsuite ChangeLog:

2016-10-15  Janne Blomqvist  

PR libfortran/48587
* gfortran.dg/negative_unit2.f90: New testcase.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/io.h
trunk/libgfortran/io/open.c
trunk/libgfortran/io/transfer.c
trunk/libgfortran/io/unit.c

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

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org
 Resolution|FIXED   |DUPLICATE

--- Comment #3 from Markus Trippelsdorf  ---


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

[Bug c++/63999] Explicit conversion operators are not considered for explicit cast using braces

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||vittorio.romeo at outlook dot 
com

--- Comment #3 from Markus Trippelsdorf  ---
*** Bug 77976 has been marked as a duplicate of this bug. ***

[Bug bootstrap/77993] [7 regression] bootstrap failure on PowerPC/Linux

[ebotcazou at gcc dot gnu.org]

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

--- Comment #1 from Eric Botcazou  ---
Created attachment 39818
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39818=edit
Preprocessed testcase (compressed)

[Bug bootstrap/77993] New: [7 regression] bootstrap failure on PowerPC/Linux

[ebotcazou at gcc dot gnu.org]

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

Bug ID: 77993
   Summary: [7 regression] bootstrap failure on PowerPC/Linux
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: major
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ebotcazou at gcc dot gnu.org
  Target Milestone: ---
  Host: powerpc-linux-gnu
Target: powerpc-linux-gnu
 Build: powerpc-linux-gnu

Bootstrap is broken on PowerPC/Linux:

/mystic.a/users/botcazou/gcc-head/./gcc/xgcc
-B/mystic.a/users/botcazou/gcc-head/./gcc/
-B/work/botcazou/gcc-head/install_ppc/powerpc-linux-gnu/bin/
-B/work/botcazou/gcc-head/install_ppc/powerpc-linux-gnu/lib/ -isystem
/work/botcazou/gcc-head/install_ppc/powerpc-linux-gnu/include -isystem
/work/botcazou/gcc-head/install_ppc/powerpc-linux-gnu/sys-include-g -O2
-msoft-float -fPIC -mstrict-align -O2  -g -O2 -DIN_GCC-W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include   -fPIC
-mlong-double-128 -mno-minimal-toc -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector   -fPIC -mlong-double-128 -mno-minimal-toc -I. -I.
-I../../.././gcc -I/work/botcazou/gcc-head/src/libgcc
-I/work/botcazou/gcc-head/src/libgcc/.
-I/work/botcazou/gcc-head/src/libgcc/../gcc
-I/work/botcazou/gcc-head/src/libgcc/../include
-I/work/botcazou/gcc-head/src/libgcc/../libdecnumber/dpd
-I/work/botcazou/gcc-head/src/libgcc/../libdecnumber -DHAVE_CC_TLS  -o
_mulsc3.o -MT _mulsc3.o -MD -MP -MF _mulsc3.dep -DL_mulsc3 -c
/work/botcazou/gcc-head/src/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS
In file included from /work/botcazou/gcc-head/src/libgcc/libgcc2.c:56:0:
/work/botcazou/gcc-head/src/libgcc/libgcc2.c: In function '__mulsc3':
/work/botcazou/gcc-head/src/libgcc/libgcc2.h:256:16: internal compiler error:
Segmentation fault
 #define __N(a) __ ## a
^
/work/botcazou/gcc-head/src/libgcc/libgcc2.h:350:19: note: in expansion of
macro '__N'
 #define __mulsc3  __N(mulsc3)
   ^~~
/work/botcazou/gcc-head/src/libgcc/libgcc2.c:1900:25: note: in expansion of
macro '__mulsc3'
 #define _CONCAT3(A,B,C) A##B##C
 ^
/work/botcazou/gcc-head/src/libgcc/libgcc2.c:1899:24: note: in expansion of
macro '_CONCAT3'
 #define CONCAT3(A,B,C) _CONCAT3(A,B,C)
^~~~
/work/botcazou/gcc-head/src/libgcc/libgcc2.c:1936:1: note: in expansion of
macro 'CONCAT3'
 CONCAT3(__mul,MODE,3) (MTYPE a, MTYPE b, MTYPE c, MTYPE d)
 ^~~
0x1085368f crash_signal
/work/botcazou/gcc-head/src/gcc/toplev.c:338
0x104cf7a8 aggregate_value_p(tree_node const*, tree_node const*)
/work/botcazou/gcc-head/src/gcc/function.c:2019
0x102da197 emit_library_call_value_1
/work/botcazou/gcc-head/src/gcc/calls.c:4044
0x102db9ab emit_library_call_value(rtx_def*, rtx_def*, libcall_type,
machine_mode, int, ...)
/work/botcazou/gcc-head/src/gcc/calls.c:4748
0x1045a09f convert_move(rtx_def*, rtx_def*, int)
/work/botcazou/gcc-head/src/gcc/expr.c:313
0x1045b0c7 convert_modes(machine_mode, machine_mode, rtx_def*, int)
/work/botcazou/gcc-head/src/gcc/expr.c:684
0x1070c7db prepare_operand(insn_code, rtx_def*, int, machine_mode,
machine_mode, int)
/work/botcazou/gcc-head/src/gcc/optabs.c:3955
0x1070cf93 prepare_cmp_insn
/work/botcazou/gcc-head/src/gcc/optabs.c:3865
0x1070d67f emit_cmp_and_jump_insns(rtx_def*, rtx_def*, rtx_code, rtx_def*,
machine_mode, int, rtx_def*, int)
/work/botcazou/gcc-head/src/gcc/optabs.c:4043
0x10397323 do_compare_rtx_and_jump(rtx_def*, rtx_def*, rtx_code, int,
machine_mode, rtx_def*, rtx_code_label*, rtx_code_label*, int)
/work/botcazou/gcc-head/src/gcc/dojump.c:1144
0x10398257 do_compare_and_jump
/work/botcazou/gcc-head/src/gcc/dojump.c:1223
0x1039a763 do_jump_1(tree_code, tree_node*, tree_node*, rtx_code_label*,
rtx_code_label*, int)
/work/botcazou/gcc-head/src/gcc/dojump.c:253
0x1039af23 jumpifnot_1(tree_code, tree_node*, tree_node*, rtx_code_label*, int)
/work/botcazou/gcc-head/src/gcc/dojump.c:140
0x102f90c7 expand_gimple_cond
/work/botcazou/gcc-head/src/gcc/cfgexpand.c:2489
0x102fa96f expand_gimple_basic_block
/work/botcazou/gcc-head/src/gcc/cfgexpand.c:5621
0x102ff6ff execute
/work/botcazou/gcc-head/src/gcc/cfgexpand.c:6367
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[5]: *** [_mulsc3.o] Error 1

Preprocessed testcase attached, compile with -msoft-float -mlong-double-128.

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

[victor at paleologue dot fr]

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

--- Comment #2 from Victor Paléologue  ---
Right, thanks for the reply.
But the, may it be fixed, or did the GCC project officially announce they
stopped supporting it?

[Bug tree-optimization/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

 Target||x86_64-pc-linux-gnu
 CC||amker at gcc dot gnu.org
  Component|middle-end  |tree-optimization

--- Comment #2 from Markus Trippelsdorf  ---
Started with r241099:

commit 6c6a3430a964029115993155382aa47453f76eb5
Author: amker 
Date:   Thu Oct 13 11:03:31 2016 +

* tree-vect-loop-manip.c (adjust_vec_debug_stmts): Don't release
adjust_vec automatically.
...