[Bug ada/84142] Implicit_Dereference with Generic Formal Incomplete Types

[simon at pushface dot org]

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

simon at pushface dot org changed:

   What|Removed |Added

 CC||simon at pushface dot org

--- Comment #2 from simon at pushface dot org ---
With 8.0.0, 1 & 2 build OK. For 3, however,

$ gnatmake -P default.gpr 
Compile
   [Ada]  main.adb
+===GNAT BUG DETECTED==+
| 8.0.0 20171216 (experimental) (x86_64-apple-darwin15) Assert_Failure
atree.adb:979|
| Error detected at main.adb:23:7 [main.adb:47:4]  |
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

/Users/simon/tmp/bugs/84142/Implicit_Dereference3/src/main.adb

compilation abandoned

(same with 20180121).

[Bug target/84144] SSE-style intrinsics for loongson?

[arthur200126 at gmail dot com]

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

--- Comment #1 from Mingye Wang  ---
Oh, the commit's modification on line 31 also fixes a tiny bug in gcc's error
message. TARGET_LOONGSON_VECTORS -- and __mips_loongson_vector_rev -- is now
defined for 2e/2f/3a in git mirror's HEAD (r257218 as of now), but the error
message in current gcc is still stuck at "2e and 2f".

[Bug target/84144] New: SSE-style intrinsics for loongson?

[arthur200126 at gmail dot com]

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

Bug ID: 84144
   Summary: SSE-style intrinsics for loongson?
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arthur200126 at gmail dot com
  Target Milestone: ---

On MIPS systems, Firefox seem to be able to build only under loongson with the
community/vendor-modified gcc 5.5.0 as only that gcc implements SSE-style
intrinsics required by Firefox with loongson's many vector extensions. Commit
c5002cd[0], authored by ZhouXiaoyong , on their tree
contains the mock-mmintrin.h additions to loongson.h.

  [0]: https://github.com/loongson-community/gcc/commit/c5002cd

I am not sure whether I should request GCC to try to introduce those changes as
mixing up architectures is usually a bad idea. On the other hand doing so does
seem to improve software support for loongson...

[Bug target/84113] [7/8 Regression] gcc-7.3.0/libgcc/unwind.inc:136:1: internal compiler error: in extract_insn, at recog.c:2311

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org

--- Comment #5 from Segher Boessenkool  ---
Ah, thanks.

Restore world...  Darwin-specific, cc: Iain.

[Bug target/84112] [8 Regression] powerpc64le ICE in LRA on openjdk

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #3 from Jeffrey A. Law  ---
Fixed by Vlad's patch on the trunk.

[Bug fortran/84143] New: Intrinsic output of PDT incorrectly includes type parameters

[neil.n.carlson at gmail dot com]

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

Bug ID: 84143
   Summary: Intrinsic output of PDT incorrectly includes type
parameters
   Product: gcc
   Version: 8.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: ---

In the continuing theme of the PDT implementation incorrectly regarding type
parameters as components (see PR84119, PR84120, PR84122), the current
implementation includes the type parameters when outputting a PDT:

type foo(k1,l1)
  integer,kind :: k1=1
  integer,len  :: l1=2
  integer :: n=3
end type

type(foo) :: x
character(8) :: string

write(string,'(*(i0))') x ! THIS SHOULD WRITE THE SINGLE DIGIT 3
if (len_trim(string) /= 1) stop 1
end

GFortran is bailing at the STOP 1 because it gets 3 for len_trim(string).
1.3.33 and R435 (F08) define what a component is. Type parameters R431 are
something else, and not included in the intrinsic output of the derived type.

I didn't check, but I'd guess the analogous incorrect thing occurs for input.

[Bug target/84064] ICE in ix86_expand_prologue related to -fstack-clash-protection and memcpy on i686

[law at redhat dot com]

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

--- Comment #6 from Jeffrey A. Law  ---
WRT c#3, yea, that code is totally broken and probably has been since the day
it was introduced.  The good news is its fixable.

[Bug target/84064] ICE in ix86_expand_prologue related to -fstack-clash-protection and memcpy on i686

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #5 from Jeffrey A. Law  ---
Fixed on the trunk.

[Bug target/84064] ICE in ix86_expand_prologue related to -fstack-clash-protection and memcpy on i686

[law at gcc dot gnu.org]

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

--- Comment #4 from Jeffrey A. Law  ---
Author: law
Date: Wed Jan 31 05:02:30 2018
New Revision: 257217

URL: https://gcc.gnu.org/viewcvs?rev=257217=gcc=rev
Log:
PR target/84064
* i386.c (ix86_adjust_stack_and_probe_stack_clash): New argument
INT_REGISTERS_SAVED.  Check it prior to calling
get_scratch_register_on_entry.
(ix86_adjust_stack_and_probe): Similarly.
(ix86_emit_probe_stack_range): Similarly.
(ix86_expand_prologue): Corresponding changes.

PR target/84064
* gcc.target/i386/pr84064: New test.

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

[Bug tree-optimization/84005] [8 regression] gcc.dg/vect/bb-slp-1.c etc. FAIL

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org

--- Comment #2 from Alexandre Oliva  ---
Yeah, it looks like alignment.  On x86_64 -msse2, the new base alignments for
pin and pout are 32, whereas on ppc64 -maltivec they're 4, and then it says it
can't force the alignment and finally that it doesn't vectorize due to no
support for unaligned store and bad alignment in the block.  Looking into it...

[Bug middle-end/84095] [8 Regression] false-positive -Wrestrict warnings for memcpy within array

[msebor at gcc dot gnu.org]

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

--- Comment #12 from Martin Sebor  ---
(In reply to Arnd Bergmann from comment #8)

I have manually reproduced a similar false positive in the small test case
below it's not quite the same issue but I have a fix for both.  They're both
caused by similar oversights as the one in comment #0, except with slightly
different root causes.  In the translation unit from comment #8 the checker
cannot reliably distinguish between offsets into different members of the same
struct and offsets into the same member.  In the case below the checker doesn't
look deep enough through the array of arrays to see that p->a[i] need not be
the same as p->a[0].

I expect to be done testing a fix for both tomorrow.  If you have other test
case/translation units please do add them here.  This has been very helpful --
thanks again!

$ cat z.c && gcc -O2 -S -Wall z.c
struct S {
  char a[2][4];
};

void f (struct S *p, int i)
{
  __builtin_strcpy (p->a[0], "012");
  __builtin_strcpy (p->a[i] + 1, p->a[0]);
}
z.c: In function ‘f’:
z.c:8:3: warning: ‘__builtin_strcpy’ accessing 4 bytes at offsets 1 and 0
overlaps 3 bytes at offset 1 [-Wrestrict]
   __builtin_strcpy (p->a[i] + 1, p->a[0]);
   ^~~

[Bug fortran/84141] [8.0.1 regression] Internal error: type_name(): Bad type

[juergen.reuter at desy dot de]

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

--- Comment #4 from Jürgen Reuter  ---
The reproducer will build an executable ./seg_prod which generates the run time
error in the 7. unit test.

[Bug fortran/84141] [8.0.1 regression] Internal error: type_name(): Bad type

[juergen.reuter at desy dot de]

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

--- Comment #3 from Jürgen Reuter  ---
Created attachment 43304
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43304=edit
Corrected reproducer, please ignore the first one.

[Bug fortran/84141] [8.0.1 regression] Internal error: type_name(): Bad type

[juergen.reuter at desy dot de]

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

--- Comment #2 from Jürgen Reuter  ---
(In reply to Jürgen Reuter from comment #1)
> Created attachment 43303 [details]
> Reproducer for the RT error

Ooops, one correction in the makefile, system_dependencies.f90 must come before
diagnostics.f90 in the list.

[Bug fortran/84141] [8.0.1 regression] Internal error: type_name(): Bad type

[juergen.reuter at desy dot de]

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

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #1 from Jürgen Reuter  ---
Created attachment 43303
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43303=edit
Reproducer for the RT error

[Bug ada/84142] Implicit_Dereference with Generic Formal Incomplete Types

[jhb.chat at gmail dot com]

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

--- Comment #1 from Jere  ---
Created attachment 43302
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43302=edit
zip archive containing 3 separate causes

[Bug ada/84142] New: Implicit_Dereference with Generic Formal Incomplete Types

[jhb.chat at gmail dot com]

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

Bug ID: 84142
   Summary: Implicit_Dereference with Generic Formal Incomplete
Types
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jhb.chat at gmail dot com
  Target Milestone: ---
  Host: Windows 10 mingw64 from MSYS2
Target: x86_64-w64-mingw32

I've found a few different ways to crash GNAT using the Implicit_Dereference
aspect coupled with generic formal incomplete types.  I've attached 3 different
projects that all cause a GNAT crash.  It is important to note that the first
one (Implicit_Dereference1) does NOT cause GNAT GPL 2017 to crash while the
remaining two projects do crash GNAT GPL 2017.  That might indicate that it is
a different bug for the first project.  A typical crash on GNAT 7.2.0 (FSF)
results in text similar to:

$ gprbuild default.gpr
gcc -c -gnato -gnatE -fstack-check -gnat12 main.adb
+===GNAT BUG DETECTED==+
| 7.2.0 (x86_64-w64-mingw32) Segmentation fault|
| Error detected at main.adb:56:9  |
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

.\Implicit_Dereference3\src\main.adb

compilation abandoned
gprbuild: *** compilation phase failed

Just for comparison sake, I am also providing the GNAT GPL crash report as it
lists it as a different type of crash (which may help hint to the FSF version's
problem).  The GNAT GPL 2017 report is as follows:

Compile
   [Ada]  main.adb
+===GNAT BUG DETECTED==+
| GPL 2017 (20170515-63) (i686-pc-mingw32) Program_Error
EXCEPTION_ACCESS_VIOLATION|
| Error detected at s-stoele.adb:36:20 |
| Please submit a bug report by email to rep...@adacore.com.   |
| GAP members can alternatively use GNAT Tracker:  |
| http://www.adacore.com/ section 'send a report'. |
| See gnatinfo.txt for full info on procedure for submitting bugs. |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
| Use plain ASCII or MIME attachment(s).   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

.\Implicit_Dereference3\src\main.adb

compilation abandoned
gprbuild: *** compilation phase failed
[2018-01-30 20:31:25] process exited with status 4, elapsed time: 01.85s

[Bug fortran/84141] New: [8.0.1 regression] Internal error: type_name(): Bad type

[juergen.reuter at desy dot de]

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

Bug ID: 84141
   Summary: [8.0.1 regression] Internal error: type_name(): Bad
type
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juergen.reuter at desy dot de
  Target Milestone: ---

There is a bad regression in the gfortran frontend introduced between r256722
and r257194. I try to come up with a minimal reproducer as soon as possible. In
our code, this crashes at least two of our unit and 3/4 of our functional
tests. 
Internal Error: type_name(): Bad type

Error termination. Backtrace:
#0  0x10d0eb64c
#1  0x10d0ec2e5
#2  0x10d0ec79d
#3  0x10d2bde46
#4  0x10d2bdec8
#5  0x10d2c0c40
#6  0x10d2c11b4
#7  0x10d2be258
#8  0x1065a0a79
#9  0x1065a2131
#10  0x10254ff4f
#11  0x10254f823
#12  0x102551d6f
#13  0x101ce6ca6
#14  0x102808a53
#15  0x101cd8017
#16  0x1019fbc4e
#17  0x101ea6d8e
Code example will follow soon.

[Bug fortran/68746] FAIL: gfortran.dg/read_dir.f90 -O0 execution test

[dave.anglin at bell dot net]

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

--- Comment #10 from dave.anglin at bell dot net ---
On 2018-01-26 8:57 PM, dave.anglin at bell dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68746
>
> --- Comment #9 from dave.anglin at bell dot net ---
> On 2018-01-26 8:29 PM, dominiq at lps dot ens.fr wrote:
>> By the xfail? Can the PR be closed?
> I'll have to investigate...
The test still fails with gcc-8 for the same reason as reported in the 
PR, so no.

[Bug target/83926] ICE during RTL pass: ira, in elimination_costs_in_insn, at reload1.c:3633

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-30
 Ever confirmed|0   |1

--- Comment #8 from Peter Bergner  ---
A minimal test case that fails with -O[123]:

[bergner@makalu-lp1 PR83926]$ cat pr83926.i
__attribute__ ((altivec(vector__))) long long
foo (__attribute__ ((altivec(vector__))) long long a,
 __attribute__ ((altivec(vector__))) long long b)
{
  return __builtin_vec_div (a, b);
}
[bergner@makalu-lp1 PR83926]$
/home/bergner/gcc/build/gcc-fsf-mainline-pr83926-debug/gcc/xgcc
-B/home/bergner/gcc/build/gcc-fsf-mainline-pr83926-debug/gcc -S -mcpu=power8
-O1 -m32 -mno-fold-gimple pr83926.i
gimple folding of rs6000 builtins has been disabled.
pr83926.i: In function ‘foo’:
pr83926.i:6:1: error: unrecognizable insn:
 }
 ^
(insn 16 15 17 2 (set (reg:DI 127)
(div:DI (reg:DI 125)
(reg:DI 126))) "pr83926.i":6 -1
 (nil))
during RTL pass: subreg2
pr83926.i:6:1: internal compiler error: in extract_insn, at recog.c:2304
0x10ddd69f _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/bergner/gcc/gcc-fsf-mainline-pr83926/gcc/rtl-error.c:108

In reply to Segher's suggestion of doing what the 32-bit DImode divides do,
they end up emitting calls to __divdi3().

[Bug middle-end/84095] [8 Regression] false-positive -Wrestrict warnings for memcpy within array

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #11 from Martin Sebor  ---
Patch for the bug in comment #0:
https://gcc.gnu.org/ml/gcc-patches/2018-01/msg02396.html

[Bug c++/84140] New: Inline friends are not constrained by concepts

[cjdb.ns at gmail dot com]

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

Bug ID: 84140
   Summary: Inline friends are not constrained by concepts
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cjdb.ns at gmail dot com
  Target Milestone: ---

Created attachment 43301
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43301=edit
example.ii as produced by -save-temps

## Summary

Inline friends do not appear to be constrained by concepts.

## GCC version

Bugzilla report: g++-7 (Ubuntu 7.2.0-1ubuntu1~16.04) 7.2.0
Observed on:

* GCC trunk
* GCC 7.3
* GCC 7.2
* GCC 7.1
* GCC 6.3
* GCC 6.2
* GCC 6.1

## System type

Observed on:

* g++-7 (Ubuntu 7.2.0-1ubuntu1~16.04) 7.2.0
* g++.exe (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 7.2.0

## Command

g++-7 -fconcepts -std=c++17 -Wall -Wextra -Wpedantic -Wconversion -Werror
-save-temps example.cpp

## Diagnostic

example.cpp: In function ‘int main()’:
example.cpp:29:27: error: ambiguous overload for ‘operator==’ (operand types
are ‘uniform’ and ‘uniform’)
 return uniform{} == uniform{};
~~~^
example.cpp:22:16: note: candidate: bool operator==(const T2&, const
uniform&) [with T2 = uniform; T = int]
friend bool operator==(const T2&, const uniform&) noexcept
^~~~
example.cpp:15:16: note: candidate: bool operator==(const uniform&, const
uniform&) [with T2 = int; T = int]
friend bool operator==(const uniform&, const uniform&) noexcept
^~~~

[Bug debug/84131] [8 regression] Fortran dynamical array debug info

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/84139] C++17 Filesystem/Filesystem TS + cmcstl2 = GCC ICE

[cjdb.ns at gmail dot com]

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

--- Comment #2 from Christopher Di Bella  ---
An observation by Casey Carter (maintainer for cmcstl2) was made over at
cpplang.slack.org#concepts:

> Presumably a concepts bug being triggered in the 
> `std::iterator_traits`-hooking code at 
> https://github.com/CaseyCarter/cmcstl2/blob/master/include/stl2/detail/iterator/concepts.hpp#L781

[Bug debug/84131] [8 regression] Fortran dynamical array debug info

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jan 30 22:57:51 2018
New Revision: 257212

URL: https://gcc.gnu.org/viewcvs?rev=257212=gcc=rev
Log:
PR debug/84131
* trans-array.c (gfc_get_descriptor_offsets_for_info): Set *data_off
to DATA_FIELD's offset rather than OFFSET_FIELD's offset.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c

[Bug c++/84136] [6/7/8 Regression] ICE with goto to an && label in another function

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
Summary|[6/7/8 Regression] ICE when |[6/7/8 Regression] ICE with
   |woking with labels as   |goto to an && label in
   |values  |another function

--- Comment #2 from David Malcolm  ---
Note that the code in question is not a valid use of this extension; the docs
say:
  You can get the address of a label defined in the current function (or a
containing function) with the unary operator '&&'.
  [...snip...]
  You may not use this mechanism to jump to code in a different function. If
you do that, totally unpredictable things happen. The best way to avoid this is
to store the label address only in automatic variables and never pass it as an
argument.

i.e. storing a label within "foo" in a global and goto-ing to it in main is a
no-no.

Still, we shouldn't ICE on it.

[Bug c++/84139] C++17 Filesystem/Filesystem TS + cmcstl2 = GCC ICE

[cjdb.ns at gmail dot com]

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

--- Comment #1 from Christopher Di Bella  ---
Created attachment 43300
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43300=edit
example.ii as produced by -save-temps (compressed)

[Bug c++/84139] New: C++17 Filesystem/Filesystem TS + cmcstl2 = GCC ICE

[cjdb.ns at gmail dot com]

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

Bug ID: 84139
   Summary: C++17 Filesystem/Filesystem TS + cmcstl2 = GCC ICE
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cjdb.ns at gmail dot com
  Target Milestone: ---

## Summary

It is possible to cause an ICE on GCC 7 and GCC trunk with this simple example.
https://godbolt.org/g/RYBwaV. Please let me know if the issue should be
resubmitted for each version of GCC that it affects.

## GCC version

Version for bug report: GCC 7.2
Present on: GCC 7.1, GCC 7.2, GCC 7.3, GCC trunk

## System type

This has been observed on:

* g++-7 (Ubuntu 7.2.0-1ubuntu1~16.04) 7.2.0 
* gcc.exe (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 7.2.0

## Command

g++-7 -fconcepts -std=c++17 -save-temps example.cpp -lstdc++fs

## Diagnostic (Ubuntu)

In file included from /usr/include/c++/7/bits/stl_algobase.h:65:0,
 from /usr/include/c++/7/bits/char_traits.h:39,
 from /usr/include/c++/7/string:40,
 from /usr/include/c++/7/stdexcept:39,
 from /usr/include/c++/7/array:39,
 from /usr/include/c++/7/tuple:39,
 from /usr/include/c++/7/functional:54,
 from /usr/local/include/stl2/functional.hpp:16,
 from /usr/local/include/stl2/detail/concepts/algorithm.hpp:15,
 from /usr/local/include/stl2/concepts.hpp:16,
 from /usr/local/include/experimental/ranges/concepts:12,
 from example.cpp:1:
/usr/include/c++/7/bits/stl_iterator_base_types.h: In instantiation of ‘struct
std::iterator_traits’:
/usr/include/c++/7/bits/stl_iterator.h:769:57:   required from ‘class
__gnu_cxx::__normal_iterator >’
/usr/include/c++/7/experimental/bits/fs_path.h:752:33:   required from here
/usr/include/c++/7/bits/stl_iterator_base_types.h:190:5: internal compiler
error: in finish_member_declaration, at cp/semantics.c:2976
 {
 ^
0x68ffab finish_member_declaration(tree_node*)
../../src/gcc/cp/semantics.c:2976
0x5fefca instantiate_class_template_1
../../src/gcc/cp/pt.c:10663
0x5fefca instantiate_class_template(tree_node*)
../../src/gcc/cp/pt.c:10880
0x662305 complete_type(tree_node*)
../../src/gcc/cp/typeck.c:133
0x5e4961 tsubst(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.c:14057
0x5f6d41 tsubst_decl
../../src/gcc/cp/pt.c:12899
0x5e3e6f tsubst(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.c:13404
0x5fef75 instantiate_class_template_1
../../src/gcc/cp/pt.c:10596
0x5fef75 instantiate_class_template(tree_node*)
../../src/gcc/cp/pt.c:10880
0x662305 complete_type(tree_node*)
../../src/gcc/cp/typeck.c:133
0x5cea01 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
../../src/gcc/cp/decl.c:12043
0x61e302 grokfield(cp_declarator const*, cp_decl_specifier_seq*, tree_node*,
bool, tree_node*, tree_node*)
../../src/gcc/cp/decl2.c:806
0x63343b cp_parser_member_declaration
../../src/gcc/cp/parser.c:23419
0x633e0a cp_parser_member_specification_opt
../../src/gcc/cp/parser.c:22968
0x633e0a cp_parser_class_specifier_1
../../src/gcc/cp/parser.c:22121
0x635a61 cp_parser_class_specifier
../../src/gcc/cp/parser.c:22373
0x635a61 cp_parser_type_specifier
../../src/gcc/cp/parser.c:16446
0x63661c cp_parser_decl_specifier_seq
../../src/gcc/cp/parser.c:13349
0x657b41 cp_parser_simple_declaration
../../src/gcc/cp/parser.c:12664
0x658995 cp_parser_block_declaration
../../src/gcc/cp/parser.c:12611
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/84138] [8 Regression] ICE folding broken constant

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
--- a/gcc/cp/cp-gimplify.c
+++ b/gcc/cp/cp-gimplify.c
@@ -2356,6 +2356,7 @@ cp_fold (tree x)
   /* A COND_EXPR might have incompatible types in branches if one or both
 arms are bitfields.  If folding exposed such a branch, fix it up.  */
   if (TREE_CODE (x) != code
+ && x != error_mark_node
  && !useless_type_conversion_p (TREE_TYPE (org_x), TREE_TYPE (x)))
x = fold_convert (TREE_TYPE (org_x), x);

[Bug fortran/84134] [8 Regression] ICE: Floating point exception

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #4 from Thomas Koenig  ---
Fixed.

[Bug middle-end/84095] [8 Regression] false-positive -Wrestrict warnings for memcpy within array

[msebor at gcc dot gnu.org]

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

--- Comment #10 from Martin Sebor  ---
Created attachment 43299
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43299=edit
Patch under test.

I think that false positive is already being tracked in bug 83456.  Let me add
the test case to it.

I'm testing the attached patch (it's an aggregate of the one posted here and
the one posted for bug 83698 which is still waiting to be approved).

Until I've verified the patch please add new test cases here and I'll triage
them.

[Bug fortran/84134] [8 Regression] ICE: Floating point exception

[tkoenig at gcc dot gnu.org]

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

--- Comment #3 from Thomas Koenig  ---
Author: tkoenig
Date: Tue Jan 30 22:35:34 2018
New Revision: 257211

URL: https://gcc.gnu.org/viewcvs?rev=257211=gcc=rev
Log:
2017-01-30  Thomas Koenig  

PR fortran/84134
* array.c (gfc_ref_dimen_size): Whitespace fixes.  If stride is
zero, return false.

2017-01-30  Thomas Koenig  

PR fortran/84134
* gfortran.dg/data_implied_do_2.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/data_implied_do_2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/array.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/84089] [8 Regression] FAIL: g++.dg/cpp1y/lambda-generic-x.C -std=gnu++14 (internal compiler error)

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #3 from Aldy Hernandez  ---
Confirmed on cross build with a simple ./cc1plus -O0.

Looks like a PA backend problem:

 switch (mode)
{
case E_BLKmode:
case E_QImode:
case E_HImode:
  return true;  

default:
=>return (INTVAL (op) % GET_MODE_SIZE (mode)) == 0; 
}

(gdb) print mode
$7 = E_VOIDmode
(gdb) print mode
$8 = E_VOIDmode
(gdb) print mode_size[mode].coeffs[0]
$9 = 0

[Bug c++/84138] [8 Regression] ICE folding broken constant

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-30
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug c++/84138] New: [8 Regression] ICE folding broken constant

[reichelt at gcc dot gnu.org]

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

Bug ID: 84138
   Summary: [8 Regression] ICE folding broken constant
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: error-recovery, ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
CC: mpolacek at gcc dot gnu.org
  Target Milestone: ---

The following invalid code snippet triggers an ICE on trunk:

==
char foo()
{
  const int i = 0 = 0;
  return 1 ? 0 : (char)i;
}
==

bug.cc: In function 'char foo()':
bug.cc:3:21: error: lvalue required as left operand of assignment
   const int i = 0 = 0;
 ^
bug.cc:4:24: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.c:86
   return 1 ? 0 : (char)i;
^
0x788ca8 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/gcc/tree.c:9375
0x6cb04c tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../gcc/gcc/tree.h:3255
0x6cb04c useless_type_conversion_p(tree_node*, tree_node*)
../../gcc/gcc/gimple-expr.c:86
0x865fb4 cp_fold
../../gcc/gcc/cp/cp-gimplify.c:2359
0x8671cc cp_fold_maybe_rvalue
../../gcc/gcc/cp/cp-gimplify.c:2006
0x865872 cp_fold_maybe_rvalue
../../gcc/gcc/cp/cp-gimplify.c:2137
0x865872 cp_fold
../../gcc/gcc/cp/cp-gimplify.c:2137
0x8671cc cp_fold_maybe_rvalue
../../gcc/gcc/cp/cp-gimplify.c:2006
0x9e2202 maybe_warn_about_returning_address_of_local
../../gcc/gcc/cp/typeck.c:8995
0x9e2202 check_return_expr(tree_node*, bool*)
../../gcc/gcc/cp/typeck.c:9385
0x99cdfe finish_return_stmt(tree_node*)
../../gcc/gcc/cp/semantics.c:890
0x919fa4 cp_parser_jump_statement
../../gcc/gcc/cp/parser.c:12368
0x919fa4 cp_parser_statement
../../gcc/gcc/cp/parser.c:10773
0x91ad20 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:11218
0x91adf7 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:11172
0x931580 cp_parser_function_body
../../gcc/gcc/cp/parser.c:21710
0x931580 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:21747
0x931e30 cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:26648
0x932b47 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:26564
0x932b47 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:19436
Please submit a full bug report, [etc.]

The regression was introduced between 2017-07-31 and 2017-08-09.

Marek, I suspect that your patch

> 2017-08-08  Marek Polacek  
>
>   PR c++/81607
>   * cp-gimplify.c (cp_fold): If folding exposed a branch of
>   a COND_EXPR, convert it to the original type of the COND_EXPR, if
>   they differ.   

might be responsible. Would you mind having a look?

[Bug c++/84127] pragmas to disable -Wexpansion-to-defined compiler warnings seems to be broken since 7.x

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
(In reply to Martin Sebor from comment #1)
> I can confirm that diagnostic pragmas that affect the preprocessor have no
> effect in C++.  When compiled in C mode all warnings are suppressed.
> In C++ mode none is.

(In reply to Jakub Jelinek from comment #2)
> The reason why the GCC diagnostic ignore pragma works for this warning in C
> and doesn't in C++ is that in C++ we preprocess/tokenize everything first
> and only then start parsing it.  The pragmas are handled while parsing
> stuff, after all the preprocessing and thus also preprocessor diagnostics is
> emitted.
> 
> To handle what you want would require that we handle GCC diagnostic pragmas
> twice, once during preprocessing using preprocessor tokenization
> infrastructure first and then once again after the preprocessing.

I think there's some other bug open about this, but I forget which it is...

[Bug c++/82658] Suboptimal codegen on AVR when right-shifting 8-bit unsigned integers.

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

  Component|middle-end  |c++

--- Comment #3 from Georg-Johann Lay  ---
According to comment 1, a C++ FE issue

[Bug target/84113] [7/8 Regression] gcc-7.3.0/libgcc/unwind.inc:136:1: internal compiler error: in extract_insn, at recog.c:2311

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
(In reply to Segher Boessenkool from comment #2)
> You cut away the most interesting part: the insn pattern that does not exist.
> Could you show us?

It is in the #c0 attachment:
(jump_insn/f 178 177 179 14 (parallel [
(return)
(use (symbol_ref:SI ("*eh_rest_world_r10")))
(clobber (reg:SI 11 r11))
(set (reg:SI 70 cr2)
(mem/c:SI (plus:SI (reg/f:SI 1 r1)
(const_int 4 [0x4])) [29  S4 A8]))
(set (reg:SI 13 r13)
(mem/c:SI (plus:SI (reg/f:SI 1 r1)
(const_int -220 [0xff24])) [29  S4 A8]))
(set (reg:SI 14 r14)
(mem/c:SI (plus:SI (reg/f:SI 1 r1)
(const_int -216 [0xff28])) [29  S4 A8]))
(set (reg:SI 15 r15)
(mem/c:SI (plus:SI (reg/f:SI 1 r1)
(const_int -212 [0xff2c])) [29  S4 A8]))
(set (reg:SI 16 r16)
(mem/c:SI (plus:SI (reg/f:SI 1 r1)
(const_int -208 [0xff30])) [29  S4 A8]))
(set (reg:SI 17 r17)
(mem/c:SI (plus:SI (reg/f:SI 1 r1)
(const_int -204 [0xff34])) [29  S4 A8]))
(set (reg:SI 18 r18)
(mem/c:SI (plus:SI (reg/f:SI 1 r1)
(const_int -200 [0xff38])) [29  S4 A8]))
(set (reg:SI 19 r19)
(mem/c:SI (plus:SI (reg/f:SI 1 r1)
(const_int -196 [0xff3c])) [29  S4 A8]))
(set (reg:SI 20 r20)
(mem/c:SI (plus:SI (reg/f:SI 1 r1)
(const_int -192 [0xff40])) [29  S4 A8]))
(set (reg:SI 21 r21)
(mem/c:SI (plus:SI (reg/f:SI 1 r1)
(const_int -188 [0xff44])) [29  S4 A8]))
(set (reg:SI 22 r22)
(mem/c:SI (plus:SI (reg/f:SI 1 r1)
(const_int -184 [0xff48])) [29  S4 A8]))
(set (reg:SI 23 r23)
(mem/c:SI (plus:SI (reg/f:SI 1 r1)
(const_int -180 [0xff4c])) [29  S4 A8]))
(set (reg:SI 24 r24)
(mem/c:SI (plus:SI (reg/f:SI 1 r1)
(const_int -176 [0xff50])) [29  S4 A8]))
(set (reg:SI 25 r25)
(mem/c:SI (plus:SI (reg/f:SI 1 r1)
(const_int -172 [0xff54])) [29  S4 A8]))
(set (reg:SI 26 r26)
(mem/c:SI (plus:SI (reg/f:SI 1 r1)
(const_int -168 [0xff58])) [29  S4 A8]))
(set (reg:SI 27 r27)
(mem/c:SI (plus:SI (reg/f:SI 1 r1)
(const_int -164 [0xff5c])) [29  S4 A8]))
(set (reg:SI 28 r28)
(mem/c:SI (plus:SI (reg/f:SI 1 r1)
(const_int -160 [0xff60])) [29  S4 A8]))
(set (reg:SI 29 r29)
(mem/c:SI (plus:SI (reg/f:SI 1 r1)
(const_int -156 [0xff64])) [29  S4 A8]))
(set (reg:SI 30 r30)
(mem/c:SI (plus:SI (reg/f:SI 1 r1)
(const_int -152 [0xff68])) [29  S4 A8]))
(set (reg:SI 31 r31)
(mem/c:SI (plus:SI (reg/f:SI 1 r1)
(const_int -148 [0xff6c])) [29  S4 A8]))
(set (reg:V4SI 97 v20)
(mem/c:V4SI (plus:SI (reg/f:SI 1 r1)
(const_int -416 [0xfe60])) [29  S16 A8]))
(set (reg:V4SI 98 v21)
(mem/c:V4SI (plus:SI (reg/f:SI 1 r1)
(const_int -400 [0xfe70])) [29  S16 A8]))
(set (reg:V4SI 99 v22)
(mem/c:V4SI (plus:SI (reg/f:SI 1 r1)
(const_int -384 [0xfe80])) [29  S16 A8]))
(set (reg:V4SI 100 v23)
(mem/c:V4SI (plus:SI (reg/f:SI 1 r1)
(const_int -368 [0xfe90])) [29  S16 A8]))
(set (reg:V4SI 101 v24)
(mem/c:V4SI (plus:SI (reg/f:SI 1 r1)
(const_int -352 [0xfea0])) [29  S16 A8]))
(set (reg:V4SI 102 v25)
(mem/c:V4SI (plus:SI (reg/f:SI 1 r1)
(const_int -336 [0xfeb0])) [29  S16 A8]))
(set (reg:V4SI 103 v26)
(mem/c:V4SI (plus:SI (reg/f:SI 1 r1)
(const_int -320 [0xfec0])) [29  S16 A8]))
(set (reg:V4SI 104 v27)
(mem/c:V4SI (plus:SI (reg/f:SI 1 r1)
(const_int -304 [0xfed0])) [29  S16 A8]))
(set (reg:V4SI 105 v28)
 

[Bug rtl-optimization/84068] [8 Regression] ICE: qsort checking failed: qsort comparator non-negative on sorted output: 1 with -fno-sched-critical-path-heuristic --param=max-sched-extend-regions-iters

[aldyh at redhat dot com]

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

--- Comment #4 from Aldy Hernandez  ---
> Yes it's latent and the fix is trivial. Testing to see whether it affects
> codequality.

Thanks Wilco, I appreciate it.  Errr, we all do :).

[Bug target/84113] [7/8 Regression] gcc-7.3.0/libgcc/unwind.inc:136:1: internal compiler error: in extract_insn, at recog.c:2311

[dougmencken at gmail dot com]

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

--- Comment #3 from Douglas Mencken  ---
(In reply to Segher Boessenkool from comment #2)
> You cut away the most interesting part: the insn pattern that does not exist.
> Could you show us?

Sure, but how?

[Bug target/82641] Unable to enable crc32 for a certain function with target attribute on ARM (aarch32)

[arnd at linaro dot org]

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

--- Comment #23 from Arnd Bergmann  ---
I've done some more testing with '#pragma GCC target("arch=armv5te")' in place,
but ran into another problem:

: note: this is the location of the previous definition
In file included from /git/arm-soc/include/linux/thread_info.h:38,
 from /git/arm-soc/include/asm-generic/current.h:5,
 from ./arch/arm/include/generated/asm/current.h:1,
 from /git/arm-soc/include/linux/sched.h:12,
 from /git/arm-soc/arch/arm/kernel/xscale-cp0.c:14:
/git/arm-soc/arch/arm/kernel/xscale-cp0.c: In function 'dsp_do':
/git/arm-soc/arch/arm/include/asm/thread_info.h:88:35: error: inlining failed
in call to always_inline 'current_thread_info': target specific option mismatch
 static inline struct thread_info *current_thread_info(void)
   ^~~
/git/arm-soc/arch/arm/kernel/xscale-cp0.c:48:18: note: called from here
   dsp_save_state(current_thread_info()->cpu_context.extra);
  ^

I've worked around that now by separating the parts that use inline assembly
into standalone functions with GCC push_options/pop_options around them, so
they are not mixed with normal code that might call an inline function, but
this is getting increasingly ugly.

[Bug middle-end/84095] [8 Regression] false-positive -Wrestrict warnings for memcpy within array

[arnd at linaro dot org]

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

--- Comment #9 from Arnd Bergmann  ---
I found another false-positive -Wrestrict warning, did a manual reduction. Let
me know if I should better open separate bugs for each test case, or you prefer
to have them all here.

$ aarch64-linux-gcc-8.0.1 -Wall -O2 -c sit.i 
sit.i: In function 'sit_init_net':
sit.i:29:2: warning: 'memcpy' source argument is the same as destination
[-Wrestrict]
  memcpy(>ip6rd, >ip6rd, sizeof(t->ip6rd));
  ^~~

void *memcpy(void *, const void *, unsigned long );
struct ip_tunnel_6rd_parm {
int relay_prefix;
int prefixlen;
int relay_prefixlen;
};
struct netdevice {
void *priv;
};
struct ip_tunnel {
struct netdevice *dev;
struct ip_tunnel_6rd_parm ip6rd;
};
struct sit_net {
struct netdevice *fb_tunnel_dev;
};
void ipip6_tunnel_clone_6rd(struct netdevice *dev, struct sit_net *sitn)
{
struct ip_tunnel *t = dev->priv;
if (t->dev == sitn->fb_tunnel_dev)
return;
struct ip_tunnel *t0 = sitn->fb_tunnel_dev->priv;
memcpy(>ip6rd, >ip6rd, sizeof(t->ip6rd));
}
int sit_init_net(struct sit_net *sitn, struct netdevice *fb_tunnel_dev) 
{
sitn->fb_tunnel_dev = fb_tunnel_dev;
ipip6_tunnel_clone_6rd(sitn->fb_tunnel_dev, sitn);
return 0;
}

[Bug c++/84127] pragmas to disable -Wexpansion-to-defined compiler warnings seems to be broken since 7.x

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
I don't see what kind of change you are talking about, except that the
-Wexpansion-to-defined warning has been added in 7.x.

The reason why the GCC diagnostic ignore pragma works for this warning in C and
doesn't in C++ is that in C++ we preprocess/tokenize everything first and only
then start parsing it.  The pragmas are handled while parsing stuff, after all
the preprocessing and thus also preprocessor diagnostics is emitted.

To handle what you want would require that we handle GCC diagnostic pragmas
twice, once during preprocessing using preprocessor tokenization infrastructure
first and then once again after the preprocessing.

[Bug fortran/84134] [8 Regression] ICE: Floating point exception

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #2 from Thomas Koenig  ---
Looks doable...

[Bug target/40411] -std=c99 does not enable c99 mode in Solaris C library

[ro at gcc dot gnu.org]

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

--- Comment #38 from Rainer Orth  ---
Author: ro
Date: Tue Jan 30 21:18:40 2018
New Revision: 257209

URL: https://gcc.gnu.org/viewcvs?rev=257209=gcc=rev
Log:
Fix use of Solaris values-Xc.o (PR target/40411)

PR target/40411
* config/sol2.h (STARTFILE_ARCH_SPEC): Use -std=c*,
-std=iso9899:199409 instead of -pedantic to select values-Xc.o.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sol2.h

[Bug debug/84131] [8 regression] Fortran dynamical array debug info

[qiyao at gcc dot gnu.org]

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

--- Comment #4 from Yao Qi  ---
(In reply to Yao Qi from comment #3)
> Thanks for the quick fix, Jakub.  It fixes 100 FAILs in gdb.fortran tests.
> 
> === gdb Summary ===
>  
> -# of expected passes   388
> -# of unexpected failures   165
> +# of expected passes   488
> +# of unexpected failures   65

Something wrong in my last gdb.fortran run.  I run it again, 103 FAILs in
gdb.fotran tests are fixed.

=== gdb Summary ===

-# of expected passes   456
-# of unexpected failures   103
+# of expected passes   559

[Bug c++/84136] [6/7/8 Regression] ICE when woking with labels as values

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-01-30
 CC||dmalcolm at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
Summary|Compilation aborted when|[6/7/8 Regression] ICE when
   |woking with labels as   |woking with labels as
   |values  |values
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Thanks for filing this bug report.

Confirmed; affects both C and C++ FEs.

This assertion is failing in find_taken_edge_computed_goto:

2384  gcc_assert (e != NULL);

(gdb) p val
$3 = 
(gdb) p dest
$4 = 
(gdb) p e
$5 = 

Started with r210492 (and hence affects from gcc 8 back to at least gcc 5).

Am investigating.

[Bug fortran/84133] [8 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.c:2706

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #4 from Thomas Koenig  ---
Fixed, closing.

[Bug fortran/84133] [8 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.c:2706

[tkoenig at gcc dot gnu.org]

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

--- Comment #3 from Thomas Koenig  ---
Author: tkoenig
Date: Tue Jan 30 20:49:49 2018
New Revision: 257206

URL: https://gcc.gnu.org/viewcvs?rev=257206=gcc=rev
Log:
2018-01-30  Thomas Koenig  

PR fortran/84133
* frontend-passes (matmul_to_var_expr): Return early if
in association list.
(inline_matmul_assign): Likewise.

2018-01-30  Thomas Koenig  

PR fortran/84133
* gfortran.dg/inline_matmul_21.f90: New test case.


Added:
trunk/gcc/testsuite/gfortran.dg/inline_matmul_21.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/testsuite/ChangeLog

[Bug debug/84131] [8 regression] Fortran dynamical array debug info

[qiyao at gcc dot gnu.org]

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

--- Comment #3 from Yao Qi  ---
Thanks for the quick fix, Jakub.  It fixes 100 FAILs in gdb.fortran tests.

=== gdb Summary ===

-# of expected passes   388
-# of unexpected failures   165
+# of expected passes   488
+# of unexpected failures   65

[Bug fortran/84133] [8 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.c:2706

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #2 from Thomas Koenig  ---
Gerhard, this makes me wonder where you get your test cases from :-)

[Bug c++/83583] ICE in synthesize_implicit_template_parm, at cp/parser.c:38794

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-30
 CC||dmalcolm at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Confirmed for trunk, gcc 7 and gcc 6; gcc 5 didn't have -fconcepts.

This assertion in synthesize_implicit_template_parm is failing:

38848 gcc_assert (current_binding_level->kind == sk_function_parms);

(gdb) p cfun
$1 = (function *) 0x0

(gdb) p scope_chain->bindings->kind
$4 = sk_block

(gdb) call debug_tree (constr)
 >
VOID /tmp/test.cc:8:8
unit-size 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x71a07930 precision:1 min  max >
constant static tree_2 tree_3 unsigned decl_5 decl_6 QI
/tmp/test.cc:2:18 size  unit-size 
align:8 warn_if_not_align:0 context  initial 
template-info 0x71a187c0>
align:1 warn_if_not_align:0 initial >

[Bug target/84112] [8 Regression] powerpc64le ICE in LRA on openjdk

[vmakarov at gcc dot gnu.org]

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

--- Comment #2 from Vladimir Makarov  ---
Author: vmakarov
Date: Tue Jan 30 20:28:59 2018
New Revision: 257204

URL: https://gcc.gnu.org/viewcvs?rev=257204=gcc=rev
Log:
2018-01-30  Vladimir Makarov  

PR target/84112
* lra-constraints.c (curr_insn_transform): Process AND in the
address.

2018-01-30  Vladimir Makarov  

PR target/84112
* pr84112.c: New.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr84112.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-constraints.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/84115] [8 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'indirect_ref' in add_decl_as_local, at fortran/trans-decl.c:256

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-30
 CC||dmalcolm at gcc dot gnu.org,
   ||pault at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from David Malcolm  ---
Confirmed.

Appears to have started with r253400.

Happens here:
250   DECL_CONTEXT (decl) = current_function_decl;

within:
245 static void
246 add_decl_as_local (tree decl)
247 {
248   gcc_assert (decl);
249   TREE_USED (decl) = 1;
250   DECL_CONTEXT (decl) = current_function_decl;
251   DECL_CHAIN (decl) = saved_local_decls;
252   saved_local_decls = decl;
253 }

with:
(gdb) call debug_tree (decl)
 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x718c1738 precision:64 min  max 
pointer_to_this >
used
arg:0 
unsigned DI size  unit-size

align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x718f5888>
readonly used unsigned DI /tmp/test.f90:1:0 size  unit-size 
align:64 warn_if_not_align:0 context 
arg-type >
/tmp/test.f90:1:0 start: /tmp/test.f90:1:0 finish: /tmp/test.f90:1:0>

[Bug c++/84125] [8 Regression] ICE in generic lambda when static_assert argument is implicitly converted to bool

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Patch posted but I'm not sure about it:
https://gcc.gnu.org/ml/gcc-patches/2018-01/msg02377.html

[Bug target/84039] x86 retpolines and CFI

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
A patch is posted at

https://gcc.gnu.org/ml/gcc-patches/2018-01/msg02233.html

[Bug tree-optimization/84106] gcc is not able to vectorize code for 1D array, but does so for 2D array of the same size

[bugzi...@poradnik-webmastera.com]

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

--- Comment #4 from Daniel Fruzynski  ---
Here are results of small benchmark executed on Xeon E5-2683 v3. Code was
compiled using gcc 4.8.5. This gcc version also splits loops. Manually
vectorized code is 3.5 times faster:

[out]
--
Benchmark   Time   CPU Iterations
--
BM_test1   25 ns 25 ns   26989634
BM_test27 ns  7 ns   94495591
[/out]

Benchmarko code:

[code]
#include 
#include "immintrin.h"

#define N 81

int a1[N] __attribute__((aligned(32)));
int a2[N] __attribute__((aligned(32)));
int a3[N] __attribute__((aligned(32)));

class Init
{
public:
Init()
{
for (int n = 0; n < N; n++)
{
a1[n] = n % 32;
}
}
} init;


static void BM_test1(benchmark::State& state)
{
for (auto _ : state)
{
for (int n = 0; n < N; n++)
{
a2[n] = a1[n];
a3[n] = 1 << a1[n];
}
benchmark::ClobberMemory();
}
}
BENCHMARK(BM_test1);

static void BM_test2(benchmark::State& state)
{
for (auto _ : state)
{
int n = 0;
for (; n < N - 7; n += 8)
{
__m256i v = _mm256_load_si256((__m256i*)([0] + n));
_mm256_store_si256((__m256i*)([0] + n), v);

v = _mm256_sllv_epi32(_mm256_set1_epi32(1), v);
_mm256_store_si256((__m256i*)([0] + n), v);
}
for (; n < N; n++)
{
a2[n] = a1[n];
a3[n] = 1 << a1[n];
}
benchmark::ClobberMemory();
}
}
BENCHMARK(BM_test2);

BENCHMARK_MAIN();
[/code]

[Bug fortran/84133] [8 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.c:2706

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-30
 CC||dmalcolm at gcc dot gnu.org,
   ||tkoenig at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Confirmed.  Appears to have started with r247755.

Fails on this assertion:

2706  gcc_assert (seen_error ());

here in gimplify.c:

2701  if (VAR_P (decl)
2702  && !DECL_SEEN_IN_BIND_EXPR_P (decl)
2703  && !TREE_STATIC (decl) && !DECL_EXTERNAL (decl)
2704  && decl_function_context (decl) == current_function_decl)
2705{
2706  gcc_assert (seen_error ());
2707  return GS_ERROR;
2708}

(gdb) call debug_tree (decl)
 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x718c8348 precision:32
pointer_to_this  reference_to_this
>
type_2 TI
size 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x71a73000
domain 
DI
size 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x71a6d7e0 precision:64 min  max >
pointer_to_this >
addressable used decl_0 TI /tmp/test.f90:1:0 size  unit-size 
align:32 warn_if_not_align:0 context >

[Bug tree-optimization/84117] [8 Regression] ICE in gimplify_modify_expr, at gimplify.c:5798

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
I think we haven't fixed that.  I think we just want to transform -ftrapv to
ubsan-like trapping internal fns, but it is too late for that for GCC8.

[Bug target/83986] [6/7 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2348

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[6/7/8 Regression] ICE in   |[6/7 Regression] ICE in
   |maybe_record_trace_start,   |maybe_record_trace_start,
   |at dwarf2cfi.c:2348 |at dwarf2cfi.c:2348

--- Comment #5 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug target/83986] [6/7/8 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2348

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jan 30 20:03:04 2018
New Revision: 257203

URL: https://gcc.gnu.org/viewcvs?rev=257203=gcc=rev
Log:
PR rtl-optimization/83986
* sched-deps.c (sched_analyze_insn): For frame related insns, add anti
dependence against last_pending_memory_flush in addition to
pending_jump_insns.

* gcc.dg/pr83986.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr83986.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/sched-deps.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/78809] Inline strcmp with small constant strings

[qing.zhao at oracle dot com]

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

--- Comment #33 from Qing Zhao  ---
with SPEC2017 on X86, I didn't see any run-time performance change as expected.
due to the date I collected for code size change, looks like that n=3 or n=4
might be a reasonable default. n=3 might be safer.

[Bug c++/84091] [8 Regression] ICE on valid C++ code: Segmentation fault

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Tue Jan 30 20:01:36 2018
New Revision: 257202

URL: https://gcc.gnu.org/viewcvs?rev=257202=gcc=rev
Log:
PR c++/84091 - ICE with local class in lambda in template.

* decl2.c (determine_visibility): Look for outer containing template
instantiation.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-local1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl2.c

[Bug c++/84126] [8 Regression] ICE in variadic generic lambda inside a template function calling a function with arguments by reference

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
C++14 version:

template 
void sink(Ts...);

template 
int bar(T&); // ICE with reference, work with just T

template 
void foo(T){
  [](auto ... k){
sink (bar(k) ...);
  }(0);
}

int main() {
  foo(0);
}

[Bug c++/84091] [8 Regression] ICE on valid C++ code: Segmentation fault

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  ---
Fixed.

[Bug fortran/84134] [8 Regression] ICE: Floating point exception

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-30
 CC||dmalcolm at gcc dot gnu.org,
   ||koenigni at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Confirmed.

Appears to have started with r248012.

With r248009 I get:

/tmp/dmalcolm/test.f90:3:9:

data (x(i+1:i+2:i),i=0,1) /1,2,3/
 1
Error: Nonconstant array section at (1) in DATA statement

With r248012 I get the ICE.

[Bug middle-end/78809] Inline strcmp with small constant strings

[qing.zhao at oracle dot com]

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

--- Comment #32 from Qing Zhao  ---
Created attachment 43298
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43298=edit
code size impact from inlining str(n)cmp with different n on X86

[Bug fortran/84135] [8 Regression] ICE in gfc_trans_array_cobounds, at fortran/trans-array.c:6033

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
Segfault reading through a NULL value for ubound here:

6032  ubound = GFC_TYPE_ARRAY_UBOUND (type, dim);
6033  if (as->upper[dim] && !INTEGER_CST_P (ubound))

Program received signal SIGSEGV, Segmentation fault.
0x0093befa in gfc_trans_array_cobounds (type=, pblock=0x7fffdad0, sym=0x2baaea0)
at ../../src/gcc/fortran/trans-array.c:6033
6033  if (as->upper[dim] && !INTEGER_CST_P (ubound))
(gdb) p as
$1 = (gfc_array_spec *) 0x2ba9af0
(gdb) p ubound
$2 = 

[Bug fortran/84135] [8 Regression] ICE in gfc_trans_array_cobounds, at fortran/trans-array.c:6033

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-30
 CC||dmalcolm at gcc dot gnu.org,
   ||koenigni at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from David Malcolm  ---
Confirmed.

Appears to have started with r248012.

With r248009 I get:

f951.248009: Warning: Reading file ‘/tmp/dmalcolm/test.f90’ as free form
/tmp/dmalcolm/test.f90:4:9:

data (x(i:i+2:i+1), i=1,2) /1,2,3/
 1
Error: Nonconstant array section at (1) in DATA statement

With r248012 I get the ICE.

[Bug fortran/84120] Syntax for used for PDT constructors is incorrect

[neil.n.carlson at gmail dot com]

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

--- Comment #1 from Neil Carlson  ---
This explains the problem underlying PR82205

[Bug rtl-optimization/83530] [8 Regression] ICE in reset_sched_cycles_in_current_ebb, at sel-sched.c:7150

[pthaugen at gcc dot gnu.org]

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

--- Comment #7 from Pat Haugen  ---
Assuming this is a latent selective scheduling bug since I can reproduce with
r243865 by adding -fsched-pressure --param sched-pressure-algorithm=2.
Looking...

[Bug c++/84126] [8 Regression] ICE in variadic generic lambda inside a template function calling a function with arguments by reference

[jason at gcc dot gnu.org]

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

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

[Bug c++/84098] [8 Regression] ICE when using a lambda in a in-class static member initialization

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #5 from Jason Merrill  ---
Fixed.

[Bug target/84113] [7/8 Regression] gcc-7.3.0/libgcc/unwind.inc:136:1: internal compiler error: in extract_insn, at recog.c:2311

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #2 from Segher Boessenkool  ---
You cut away the most interesting part: the insn pattern that does not exist.
Could you show us?

[Bug gcov-profile/84137] New: Typo in gcov online documentation

[peter.klotz99 at gmail dot com]

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

Bug ID: 84137
   Summary: Typo in gcov online documentation
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter.klotz99 at gmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

There is a typo on this page of the gcov online documentation:

  https://gcc.gnu.org/onlinedocs/gcc/Invoking-Gcov.html

It states:

"Unexecuted lines are marked ‘#’ or ‘’, depending on whether..."


It should be "=" (five consecutive equal signs instead of four).

This simple test program shows that 5 is correct:

--
int main()
{
int i=0;
try {
if (i==4)
throw 7;
}
catch (...) {
i=5;
}
return 0;
}
--

g++ -Wall -Wextra -g -fprofile-arcs -ftest-coverage coverage.cpp -o coverage
gcov coverage.gcda

--
-:0:Source:coverage.cpp
-:0:Graph:coverage.gcno
-:0:Data:coverage.gcda
-:0:Runs:1
-:0:Programs:1
1:1:int main()
-:2:{
1:3:int i=0;
-:4:try {
1:5:if (i==4)
#:6:throw 7;
-:7:}
=:8:catch (...) {
=:9:i=5;
-:   10:}
1:   11:return 0;
-:   12:}
--

[Bug c++/84136] New: Compilation aborted when woking with labels as values

[udalovilia at yandex dot ru]

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

Bug ID: 84136
   Summary: Compilation aborted when woking with labels as values
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: udalovilia at yandex dot ru
  Target Milestone: ---

Created attachment 43297
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43297=edit
Minimal reproducible sample

I used to play with labels as values
(https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html) and discovered
compiler error.

Following code leads to compiler segfault when compiling with -O1, -O2 or -O3.
Affected all versions from gcc5.0 to gcc7.3. I have tested on Mac OS (10.13.2)
and Linux (3.18.19-24). 

void* a;

void foo() {
if ((a = &))
return;

l:;
}

int main() {
foo();
goto *a;

return 0;
}


bash$ g++-7 -v -save-temps gcc-bug.cpp -O1 

Using built-in specs.
COLLECT_GCC=g++-7
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/7.3.0/libexec/gcc/x86_64-apple-darwin17.3.0/7.3.0/lto-wrapper
Target: x86_64-apple-darwin17.3.0
Configured with: ../configure --build=x86_64-apple-darwin17.3.0
--prefix=/usr/local/Cellar/gcc/7.3.0
--libdir=/usr/local/Cellar/gcc/7.3.0/lib/gcc/7
--enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-7
--with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr
--with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl
--with-system-zlib --enable-checking=release --with-pkgversion='Homebrew GCC
7.3.0' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues
--disable-nls
Thread model: posix
gcc version 7.3.0 (Homebrew GCC 7.3.0) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-mmacosx-version-min=10.13.3'
'-asm_macosx_version_min=10.13' '-shared-libgcc' '-mtune=core2'

/usr/local/Cellar/gcc/7.3.0/libexec/gcc/x86_64-apple-darwin17.3.0/7.3.0/cc1plus
-E -quiet -v -D__DYNAMIC__ gcc-bug.cpp -fPIC -mmacosx-version-min=10.13.3
-mtune=core2 -O1 -fpch-preprocess -o gcc-bug.ii
ignoring nonexistent directory
"/usr/local/Cellar/gcc/7.3.0/lib/gcc/7/gcc/x86_64-apple-darwin17.3.0/7.3.0/../../../../../../x86_64-apple-darwin17.3.0/include"
#include "..." search starts here:
#include <...> search starts here:

/usr/local/Cellar/gcc/7.3.0/lib/gcc/7/gcc/x86_64-apple-darwin17.3.0/7.3.0/../../../../../../include/c++/7.3.0

/usr/local/Cellar/gcc/7.3.0/lib/gcc/7/gcc/x86_64-apple-darwin17.3.0/7.3.0/../../../../../../include/c++/7.3.0/x86_64-apple-darwin17.3.0

/usr/local/Cellar/gcc/7.3.0/lib/gcc/7/gcc/x86_64-apple-darwin17.3.0/7.3.0/../../../../../../include/c++/7.3.0/backward

/usr/local/Cellar/gcc/7.3.0/lib/gcc/7/gcc/x86_64-apple-darwin17.3.0/7.3.0/include
 /usr/local/include
 /usr/local/Cellar/gcc/7.3.0/include

/usr/local/Cellar/gcc/7.3.0/lib/gcc/7/gcc/x86_64-apple-darwin17.3.0/7.3.0/include-fixed
 /usr/include
 /System/Library/Frameworks
 /Library/Frameworks
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-mmacosx-version-min=10.13.3'
'-asm_macosx_version_min=10.13' '-shared-libgcc' '-mtune=core2'

/usr/local/Cellar/gcc/7.3.0/libexec/gcc/x86_64-apple-darwin17.3.0/7.3.0/cc1plus
-fpreprocessed gcc-bug.ii -fPIC -quiet -dumpbase gcc-bug.cpp
-mmacosx-version-min=10.13.3 -mtune=core2 -auxbase gcc-bug -O1 -version -o
gcc-bug.s
GNU C++14 (Homebrew GCC 7.3.0) version 7.3.0 (x86_64-apple-darwin17.3.0)
compiled by GNU C version 7.3.0, GMP version 6.1.2, MPFR version 4.0.0,
MPC version 1.1.0, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++14 (Homebrew GCC 7.3.0) version 7.3.0 (x86_64-apple-darwin17.3.0)
compiled by GNU C version 7.3.0, GMP version 6.1.2, MPFR version 4.0.0,
MPC version 1.1.0, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: e842f18ce880f3211760ed17476e01db
gcc-bug.cpp: In function 'int main()':
gcc-bug.cpp:10:5: internal compiler error: in find_taken_edge_computed_goto, at
tree-cfg.c:2254
 int main() {
 ^~~~

gcc-bug.cpp:10:5: internal compiler error: Abort trap: 6
g++-7: internal compiler error: Abort trap: 6 (program cc1plus)

It seems to be reproducible for all

[Bug c++/84098] [8 Regression] ICE when using a lambda in a in-class static member initialization

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Tue Jan 30 19:05:12 2018
New Revision: 257199

URL: https://gcc.gnu.org/viewcvs?rev=257199=gcc=rev
Log:
PR c++/84098 - ICE with lambda in template NSDMI.

* pt.c (instantiate_class_template_1): Ignore more lambdas.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/constexpr-lambda19.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug debug/84131] [8 regression] Fortran dynamical array debug info

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 43296
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43296=edit
gcc8-pr84131.patch

Untested fix.

[Bug debug/84131] [8 regression] Fortran dynamical array debug info

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-01-30
Summary|[8 regression FORTRAN   |[8 regression] Fortran
   |dynamical array debug info  |dynamical array debug info
 Ever confirmed|0   |1

[Bug libgomp/84088] [8 Regression][nvptx] libgomp.oacc-fortran/declare-*.f90 execution fails

[paul.richard.thomas at gmail dot com]

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

--- Comment #9 from paul.richard.thomas at gmail dot com  ---
Ha! Thanks...

In the main programme:
struct array00_integer(kind=4) desc.3;

desc.3.dtype = {.elem_len=8, .rank=0, .type=11};
desc.3.data = (void * restrict) 
foo ();

At least foo is reporting the correct result. I'm onto it.

Paul


On 30 January 2018 at 10:59, vries at gcc dot gnu.org
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84088
>
> --- Comment #8 from Tom de Vries  ---
>> > am unable to reproduce it and do not have access to the target you are
>> > using.
>
>> I may have found a way to reproduce the problem without libgomp
>
> Forgot to mention: on x86_64, so you should be able to reproduce this.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug fortran/84135] [8 Regression] ICE in gfc_trans_array_cobounds, at fortran/trans-array.c:6033

[gs...@t-online.de]

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

--- Comment #1 from G. Steinmetz  ---

These analogous cases compile and work :


$ cat z2.f90
program p
   integer :: i
   integer :: x(3)[2,*]
   data (x(i:i+2:i+1), i=1,2) /1,2,3/
   print *, x
end


$ cat z3.f90
program p
   integer :: i
   integer :: x(3)
   data (x(i:i+2:i+1), i=1,2) /1,2,3/
   print *, x
end


$ gfortran-8-20180128 z2.f90 -static-libgfortran -fcoarray=single
$ a.out
   1   3   2


$ gfortran-8-20180128 z3.f90 -static-libgfortran
$ a.out
   1   3   2
$

[Bug fortran/84135] New: [8 Regression] ICE in gfc_trans_array_cobounds, at fortran/trans-array.c:6033

[gs...@t-online.de]

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

Bug ID: 84135
   Summary: [8 Regression] ICE in gfc_trans_array_cobounds, at
fortran/trans-array.c:6033
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed before 20170820. No ICE with version 6 or 7.
In combination with -fcoarray=single or -fcoarray=lib.


$ cat z1.f90
program p
   integer :: i
   integer, dimension(3) :: x[2,*]
   data (x(i:i+2:i+1), i=1,2) /1,2,3/
   print *, x
end


$ gfortran-8-20180128 z1.f90 -c -fcoarray=single
z1.f90:6:0:

 end

internal compiler error: Segmentation fault
0xb94e5f crash_signal
../../gcc/toplev.c:325
0x755e8b gfc_trans_array_cobounds(tree_node*, stmtblock_t*, gfc_symbol const*)
../../gcc/fortran/trans-array.c:6033
0x76e50d gfc_trans_deferred_vars(gfc_symbol*, gfc_wrapped_block*)
../../gcc/fortran/trans-decl.c:4527
0x770533 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6594
0x6ffde0 translate_all_program_units
../../gcc/fortran/parse.c:6121
0x6ffde0 gfc_parse_file()
../../gcc/fortran/parse.c:6324
0x7464ff gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/84134] New: [8 Regression] ICE: Floating point exception

[gs...@t-online.de]

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

Bug ID: 84134
   Summary: [8 Regression] ICE: Floating point exception
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Following invalid code affects version 8.
Behavior changed before 20170820.


$ cat z1.f90
program p
   integer :: i, x(3)
   data (x(i+1:i+2:i),i=0,1) /1,2,3/
end


$ gfortran-7-20180125 -c z1.f90
z1.f90:3:9:

data (x(i+1:i+2:i),i=0,1) /1,2,3/
 1
Error: Nonconstant array section at (1) in DATA statement


$ gfortran-8-20180128 -c z1.f90
f951: internal compiler error: Floating point exception
0xb94e5f crash_signal
../../gcc/toplev.c:325
0x67a975 gfc_ref_dimen_size(gfc_array_ref*, int, __mpz_struct (*) [1],
__mpz_struct (*) [1])
../../gcc/fortran/array.c:2286
0x70b39a expression_shape
../../gcc/fortran/resolve.c:5085
0x70b39a expression_rank(gfc_expr*)
../../gcc/fortran/resolve.c:5165
0x70dc90 resolve_variable
../../gcc/fortran/resolve.c:5572
0x70dc90 gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.c:6708
0x70fbde check_data_variable
../../gcc/fortran/resolve.c:15254
0x710172 traverse_data_var
../../gcc/fortran/resolve.c:15539
0x710376 traverse_data_list
../../gcc/fortran/resolve.c:15495
0x710376 traverse_data_var
../../gcc/fortran/resolve.c:15537
0x71aba1 resolve_data
../../gcc/fortran/resolve.c:15594
0x71aba1 resolve_types
../../gcc/fortran/resolve.c:16412
0x7162dc gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:16501
0x6ffc0a resolve_all_program_units
../../gcc/fortran/parse.c:6060
0x6ffc0a gfc_parse_file()
../../gcc/fortran/parse.c:6310
0x7464ff gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug tree-optimization/81635] [8 Regression] nvptx SLP test cases regressions

[rsandifo at gcc dot gnu.org]

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

--- Comment #12 from rsandifo at gcc dot gnu.org  
---
In the end I agree using range info in split_constant_offset is the right way
to go -- sorry for the runaround.  Testing a patch for that.

I'll see if that triggers the same predcom problem I saw with the original
patch.

[Bug fortran/84133] New: [8 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.c:2706

[gs...@t-online.de]

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

Bug ID: 84133
   Summary: [8 Regression] ICE in gimplify_var_or_parm_decl, at
gimplify.c:2706
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects only version 8 at -Og, -Os, -O1 or higher.
Changed before 20170820.


$ cat z1.f90
program p
   real :: x(2,2) = 1.0
   real :: z(2,2)
   associate (y => matmul(x,x))
  z = y
   end associate
   print *, z
end


$ gfortran-7-20180125 z1.f90 -O2 -static-libgfortran
$ a.out
   2.   2.   2.   2.


$ gfortran-8-20180128 z1.f90 -O0 -static-libgfortran
$ a.out
   2.   2.   2.   2.


$ gfortran-8-20180128 z1.f90 -O2 -c
z1.f90:5:0:

   z = y

internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:2706
0x972641 gimplify_var_or_parm_decl
../../gcc/gimplify.c:2706
0x975667 gimplify_compound_lval
../../gcc/gimplify.c:2857
0x975667 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11387
0x9754c9 gimplify_addr_expr
../../gcc/gimplify.c:6030
0x9754c9 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11481
0x97dbf2 gimplify_modify_expr
../../gcc/gimplify.c:5626
0x974a4b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11435
0x976d76 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6658
0x974103 gimplify_statement_list
../../gcc/gimplify.c:1767
0x974103 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11863
0x976d76 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6658
0x97785f gimplify_bind_expr
../../gcc/gimplify.c:1335
0x9743b6 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11635
0x976d76 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6658
0x97785f gimplify_bind_expr
../../gcc/gimplify.c:1335
0x9743b6 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11635
0x976d76 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6658
0x9780ab gimplify_body(tree_node*, bool)
../../gcc/gimplify.c:12635
0x9784c5 gimplify_function_tree(tree_node*)
../../gcc/gimplify.c:12800
0x838b27 cgraph_node::analyze()
../../gcc/cgraphunit.c:670

[Bug c++/84127] pragmas to disable -Wexpansion-to-defined compiler warnings seems to be broken since 7.x

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-30
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
I can confirm that diagnostic pragmas that affect the preprocessor have no
effect in C++.  I can reproduce the same behavior with GCC 6.x as well as 7.x
and 8.0 so it doesn't seem like a recent regression.

Here's an expanded test case.  When compiled in C mode all warnings are
suppressed.  In C++ mode none is.

$ cat pr84127.c && gcc -S -Wall -Wdate-time -Wempty-body -Wexpansion-to-defined
-trigraphs -o/dev/null -xc++ pr84127.c
_Pragma ("GCC diagnostic ignored \"-Wcomment\"")
/* /* */   // -Wcomment not suppressed

_Pragma ("GCC diagnostic ignored \"-Wtrigraphs\"")
int a??(1??);  // -Wtrigraphs not suppressed

_Pragma ("GCC diagnostic ignored \"-Wdate-time\"")
const char date[] =  __DATE__;   // -Wdate-time not suppressed

_Pragma ("GCC diagnostic ignored \"-Wendif-labels\"")
_Pragma ("GCC diagnostic ignored \"-Wexpansion-to-defined\"")

#define BLA defined(FOO)
#if BLA// -Wexpansion-to-defined not suppressed
#endif BLA // -Wendif-labels not suppressed

void f (void)
{
  _Pragma ("GCC diagnostic ignored \"-Wempty-body\"")
  if (0) { }   // -Wempty-body suppressed (good)
}
pr84127.c:2:4: warning: "/*" within comment [-Wcomment]
 /* /* */   // -Wcomment not suppressed

pr84127.c:5:6: warning: trigraph ??( converted to [ [-Wtrigraphs]
 int a??(1??);  // -Wtrigraphs not suppressed

pr84127.c:5:8: warning: trigraph ??) converted to ] [-Wtrigraphs]
pr84127.c:8:22: warning: macro "__DATE__" might prevent reproducible builds
[-Wdate-time]
 const char date[] =  __DATE__;   // -Wdate-time not suppressed
  ^~~~
pr84127.c:14:5: warning: this use of "defined" may not be portable
[-Wexpansion-to-defined]
 #if BLA// -Wexpansion-to-defined not suppressed
 ^~~
pr84127.c:15:8: warning: extra tokens at end of #endif directive
[-Wendif-labels]
 #endif BLA // -Wendif-labels not suppressed
^~~

[Bug fortran/56818] [meta-bug] fortran-dev bugs

[tkoenig at gcc dot gnu.org]

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

Bug 36825 Summary: [F08] Rank > 7 arrays  [will break library ABI]  libgfortran 
I/O+intrinsics:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36825

   What|Removed |Added

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

[Bug fortran/39627] [meta-bug] Fortran 2008 support

[tkoenig at gcc dot gnu.org]

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

Bug 36825 Summary: [F08] Rank > 7 arrays  [will break library ABI]  libgfortran 
I/O+intrinsics:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36825

   What|Removed |Added

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

[Bug fortran/45424] [F08] Add IS_CONTIGUOUS intrinsic

[tkoenig at gcc dot gnu.org]

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

Bug 36825 Summary: [F08] Rank > 7 arrays  [will break library ABI]  libgfortran 
I/O+intrinsics:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36825

   What|Removed |Added

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

[Bug fortran/39178] Generate main() rather than using a main in libgfortran/fmain.c

[tkoenig at gcc dot gnu.org]

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

Bug 36825 Summary: [F08] Rank > 7 arrays  [will break library ABI]  libgfortran 
I/O+intrinsics:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36825

   What|Removed |Added

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

[Bug fortran/36825] [F08] Rank > 7 arrays [will break library ABI] libgfortran I/O+intrinsics:

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #13 from Thomas Koenig  ---
This is now fixed after Paul's patch for PR 37377.

Closing.

[Bug fortran/37577] [meta-bug] change internal array descriptor format for better syntax, C interop TR, rank 15

[tkoenig at gcc dot gnu.org]

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

--- Comment #8 from Thomas Koenig  ---
Author: tkoenig
Date: Tue Jan 30 18:20:27 2018
New Revision: 257195

URL: https://gcc.gnu.org/viewcvs?rev=257195=gcc=rev
Log:
2018-01-30  Thomas Koenig  

PR fortran/37577
* libgfortran.h: Remove GFC_DTYPE_DERIVED_1, GFC_DTYPE_DERIVED_2,
GFC_DTYPE_DERIVED_4, GFC_DTYPE_DERIVED_8 and GFC_DTYPE_DERIVED_16.
* m4/cshift1.m4: Remove GFC_DTYPE_DERIVED_1.
* generated/cshift1_16.c: Regenerated.
* generated/cshift1_4.c: Regenerated.
* generated/cshift1_8.c: Regenerated.
* intrinsics/cshift0.c: Remove GFC_DTYPE_DERIVED_1.
* intrinsics/pack_generic.c (pack): Move handling of other types
into separate switch statement.
* intrinsics/spread_generic.c (spread): Likewise.
(spread_scalar): Likewise.
* intrinsics/unpack_generic.c (unpack1): Likewise.
(unpack0): Likewise.
* runtime/in_pack_generic.c (internal_pack): Likewise.
* runtime/in_unpack_generic.c (internal_unpack): Likewise.


Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/generated/cshift1_16.c
trunk/libgfortran/generated/cshift1_4.c
trunk/libgfortran/generated/cshift1_8.c
trunk/libgfortran/intrinsics/cshift0.c
trunk/libgfortran/intrinsics/pack_generic.c
trunk/libgfortran/intrinsics/spread_generic.c
trunk/libgfortran/intrinsics/unpack_generic.c
trunk/libgfortran/libgfortran.h
trunk/libgfortran/m4/cshift1.m4
trunk/libgfortran/runtime/in_pack_generic.c
trunk/libgfortran/runtime/in_unpack_generic.c

[Bug c++/84076] [6/7/8 Regression] Warning about objects through POD mistakenly claims the object is a pointer

[sgunderson at bigfoot dot com]

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

--- Comment #5 from sgunderson at bigfoot dot com ---
Ah, so it's allowed to send structs and classes, just not non-PODs. So that's
why the conversion to a pointer happens.

[Bug middle-end/84095] [8 Regression] false-positive -Wrestrict warnings for memcpy within array

[arnd at linaro dot org]

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

--- Comment #8 from Arnd Bergmann  ---
Created attachment 43295
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43295=edit
linux/drivers/isdn/isdnloop/isdnloop.c, preprocessed, compressed

This is the preprocessed file that showed the funky -Wrestrict warning message:

$ x86_64-linux-gcc-8.0.1 -Wall -O2 isdnloop.i -c -m32 -Wno-pointer-sign
-Wno-unused
In file included from /git/arm-soc/arch/x86/include/asm/page_32.h:35,
 from /git/arm-soc/arch/x86/include/asm/page.h:14,
 from /git/arm-soc/arch/x86/include/asm/thread_info.h:12,
 from /git/arm-soc/include/linux/thread_info.h:38,
 from /git/arm-soc/arch/x86/include/asm/preempt.h:7,
 from /git/arm-soc/include/linux/preempt.h:81,
 from /git/arm-soc/include/linux/spinlock.h:51,
 from /git/arm-soc/include/linux/seqlock.h:36,
 from /git/arm-soc/include/linux/time.h:6,
 from /git/arm-soc/include/linux/stat.h:22,
 from /git/arm-soc/include/linux/module.h:10,
 from /git/arm-soc/drivers/isdn/isdnloop/isdnloop.c:12:
In function 'strcpy',
inlined from 'isdnloop_parse_cmd' at
/git/arm-soc/drivers/isdn/isdnloop/isdnloop.c:900:3,
inlined from 'isdnloop_writecmd' at
/git/arm-soc/drivers/isdn/isdnloop/isdnloop.c:989:5:
/git/arm-soc/include/linux/string.h:437:10: warning: '__builtin_strcpy'
accessing 0 or more bytes at offsets [36, 25] and 446 may overlap up to 0 bytes
at offset [9223372036854775807, -9223372036854775808] [-Wrestrict]
   return __builtin_strcpy(p, q);
  ^~

I did not try to reduce the test case.

[Bug rtl-optimization/84071] [7/8 regression] wrong elimination of zero-extension after sign-extended load

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

  Component|middle-end  |rtl-optimization

--- Comment #11 from Eric Botcazou  ---
Recategorizing.

[Bug tree-optimization/81611] [8 Regression] gcc un-learned loop / post-increment optimization

[aoliva at gcc dot gnu.org]

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

--- Comment #21 from Alexandre Oliva  ---
Author: aoliva
Date: Tue Jan 30 17:40:50 2018
New Revision: 257194

URL: https://gcc.gnu.org/viewcvs?rev=257194=gcc=rev
Log:
[PR81611] accept copies in simple_iv_increment_p

If there are copies between the GIMPLE_PHI at the loop body and the
increment that reaches it (presumably through a back edge), still
regard it as a simple_iv_increment, so that we won't consider the
value in the back edge eligible for forwprop.  Doing so would risk
making the phi node and the incremented conflicting value live
within the loop, and the phi node to be preserved for propagated
uses after the loop.

for  gcc/ChangeLog

PR tree-optimization/81611
* tree-ssa-dom.c (simple_iv_increment_p): Skip intervening
copies.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-dom.c

[Bug debug/83758] ICE building gccgo on powerpc64le --with-cpu=power8

[acsawdey at gcc dot gnu.org]

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

acsawdey at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #32 from acsawdey at gcc dot gnu.org ---
This fix committed to trunk as 257193:

Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 257188)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -29602,8 +29602,9 @@
  emit_insn_after (pat, get_insns ());
  pop_topmost_sequence ();
}
-  return plus_constant (Pmode, cfun->machine->split_stack_arg_pointer,
-   FIRST_PARM_OFFSET (current_function_decl));
+  rtx ret = plus_constant (Pmode, cfun->machine->split_stack_arg_pointer,
+  FIRST_PARM_OFFSET (current_function_decl));
+  return copy_to_reg (ret);
 }
   return virtual_incoming_args_rtx;
 }

[Bug c++/84132] [8 Regression] tree-data-ref.c:3938: poor coding ?

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
The change caused chrec_a now being possibly a NOP_EXPR around a
POLYNOMIAL_CHREC, while gcd_of_steps_may_divide_p relies on the passed chrec to
be POLYNOMIAL_CHREC.

So, the question is if we can ignore the NOP_EXPR or not (and if yes, if we
could look through it in gcd_of_steps_may_divide_p or in the caller), or if we
just should return true from the function if chrec is not a POLYNOMIAL_CHREC
(== cd at the end is 0).

Richard?

[Bug c++/84132] [8 Regression] tree-data-ref.c:3938: poor coding ?

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |8.0
Summary|tree-data-ref.c:3938: poor  |[8 Regression]
   |coding ?|tree-data-ref.c:3938: poor
   ||coding ?

--- Comment #2 from Jakub Jelinek  ---
Started with r257013.

[Bug preprocessor/69869] [6/7/8 Regression] internal compiler error: Segmentation fault in call to skip_macro_block_comment when using '-traditional-cpp'

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested patch that restores the gcc 3.3 behavior (rejects it, because the
comment in the macro formed with token pasting is unterminated).