[Bug target/78118] xtensa: ICE in gcc-6.1.0/libgcc/libgcc2.c:1992:1: error: unrecognizable insn

[jcmvbkbc at gcc dot gnu.org]

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

--- Comment #3 from jcmvbkbc at gcc dot gnu.org ---
Created attachment 39936
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39936=edit
tentative patch

[Bug libstdc++/78167] experimental/filesystem calls behave differently between Linux gcc 5.3.0 and Windows Visual Studio 2015

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.2

--- Comment #3 from Andrew Pinski  ---
(In reply to David Bjornbak from comment #2)
> gcc 6.2.0 is Ok for this issue, my unit tests pass.
> 
> Is there's patch available to address this issue with the 5.x versions of
> gcc?

You can dig into what changes happened to this source but since this is an
experimental part of the libstdc++ library I doubt we are going to fix it.  We
have no guarantees that this library part will even be part of C++17.

[Bug go/78172] gen-sysinfo.go vs AIX cred.h

[ian at airs dot com]

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

--- Comment #3 from Ian Lance Taylor  ---
If that is the complete line, then something has gone badly wrong.

Can you get a copy of the complete generated sysinfo.go file?

[Bug go/78172] gen-sysinfo.go vs AIX cred.h

[dje at gcc dot gnu.org]

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

--- Comment #2 from David Edelsohn  ---
The error message is the complete line -- or at least the entire line that was
communicated to me.

priv_t is a type defined in AIX /usr/include/priv.h, which is included by
cred.h.  uid_t, gid_t and pid_t all are defined in types.h, as on Linux.

[Bug middle-end/78174] out of bounds array subscript in rtl.h NOTE_DATA macro

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
Yes, rtx_note derives from rtx_insn which derives from rtx_def which is where
the union containing the one-element fld array is defined.

[Bug go/78172] gen-sysinfo.go vs AIX cred.h

[ian at airs dot com]

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

--- Comment #1 from Ian Lance Taylor  ---
What does that whole line look like?  It seems to be truncated in the output
for some reason.

Is _priv_t defined elsewhere in the file?  That is, is there a line that starts
with "type _priv_t "?  If not, that will be a problem.

[Bug middle-end/78174] out of bounds array subscript in rtl.h NOTE_DATA macro

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Martin Sebor from comment #2)
>  I realize
> that GCC sometimes treats even one element arrays (and even bigger if
> they're last) as zero-length even though that's not documented anywhere
> (AFAIK), but it would be nice to get away from that.

It was a decision not to document it as it was more of an extension which does
not need to be documented (maybe it should be documented in an internals GCC
documentation but it should not be documented in an external facing one as it
is not recommended one to do).  Also the other reason why it needs to be work
still is that old code needs to work and we support many other code.


Do we really have a class structure here in GCC's code?

[Bug middle-end/78174] out of bounds array subscript in rtl.h NOTE_DATA macro

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
The problem can be reduced to the following test case that triggers the warning
even with unpatched GCC (and prior releases).

$ cat b.c && g++ -O2 -S -Wall b.c
struct A { int i, j; };
struct B { int i0, j0, i1, j1, i2, j2, i3, j3, i4, j4; };

struct C {
  union {
struct A a[1];
struct B b;
  } u;
};

struct D: C { };

void f (struct D *d)
{
  struct A *p = >u.a[3];
  __builtin___memset_chk (p, 0, sizeof *p, __builtin_object_size (p, 1));
}
b.c: In function ‘void f(D*)’:
b.c:17:73: warning: call to void* __builtin___memset_chk(void*, int, long
unsigned int, long unsigned int) will always overflow destination buffer
   __builtin___memset_chk (p, 0, sizeof *p, __builtin_object_size (p, 1));
 ^
Such code is undefined under the C++ (and C) standard rules.  (Curiously, GCC
doesn't issue the warning for an equivalent function that takes struct C* as an
argument.)

The same warning is also emitted when the memset call in emit-rtl.c is replaced
with a __builtin___memset_chk call corresponding to the one above.  The patch
that triggers the warning simply enables the same compile-time checking for
memset as is done by __builtin___memset_chk with type-1 object size checking.

I see that Glibc uses type-0 checking for memset even with _FORTIFY_SOURCE=2,
so the patch could either be changed to do the same or enhanced to let users
specify the __builtin_object_size checking type, and perhaps even a different
type for raw memory functions like memset and for string functions, to make it
possible to fine-tune the checking to the state of the code base and avoid
issuing warnings for this kind of code in legacy software.  I think those would
be enhancements worth considering, but I also think that GCC itself should try
to avoid relying on undefined behavior.

GCC provides zero-length arrays as a substitute for flexible array members.  In
this case, the array has one (not zero) element.  It would be nice if changing
it to a zero-element array would let GCC treat it as a flexible array member on
steroids so that users would have to opt in to relying on an extension to avoid
the warning here, but that's not the case.  I realize that GCC sometimes treats
even one element arrays (and even bigger if they're last) as zero-length even
though that's not documented anywhere (AFAIK), but it would be nice to get away
from that.

[Bug libfortran/78123] Short reads with T edit descriptor not padding correctly

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #7 from Jerry DeLisle  ---
Fixed on 5, 6, and 7, Closing, thanks for the report

[Bug libfortran/78123] Short reads with T edit descriptor not padding correctly

[jvdelisle at gcc dot gnu.org]

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

--- Comment #6 from Jerry DeLisle  ---
Author: jvdelisle
Date: Mon Oct 31 23:40:40 2016
New Revision: 241727

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

Backport from trunk
PR libgfortran/78123
* io/transfer.c (formatted_transfer_scalar_read): Clear seen_eor
only if we have tabbed to left of current position.
Backport from trunk
PR fortran/78123
* gfortran.dg/fmt_t_9.f: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/fmt_t_9.f
Modified:
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/libgfortran/ChangeLog
branches/gcc-5-branch/libgfortran/io/transfer.c

[Bug ada/78175] New: [Ada] Storage_Error stack overflow or erroneous memory access

[kendall at bellsoft dot net]

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

Bug ID: 78175
   Summary: [Ada] Storage_Error stack overflow or erroneous memory
access
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kendall at bellsoft dot net
  Target Milestone: ---

Created attachment 39935
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39935=edit
bug source

gnatmake -gnatwa -I../src list_words
gcc-5 -c -gnatwa -I../src list_words.adb
+===GNAT BUG DETECTED==+
| 5.2.1 20151010 (x86_64-linux-gnu) Storage_Error stack overflow or erroneous
memory access|
| Error detected at list_words.adb:25:4|
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| 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).

list_words.adb
../src/bragi.ads
../src/bragi-translate_words.ads

compilation abandoned
gnatmake: "list_words.adb" compilation error


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

[Bug middle-end/78174] out of bounds array subscript in rtl.h NOTE_DATA macro

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
I think the warning is not called for and here is why.  There is no way in both
C89 and C++ (in C99 there is) to say the array at the end of a struct (even
inside an union) is a variable length.  So GCC decided that any array at the
end of a structure (even inside an union or another stucture) can be considered
a variable length array.

See https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Zero-Length.html .

[Bug c/78174] New: out of bounds array subscript in rtl.h NOTE_DATA macro

[msebor at gcc dot gnu.org]

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

Bug ID: 78174
   Summary: out of bounds array subscript in rtl.h NOTE_DATA macro
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

As discussed in https://gcc.gnu.org/ml/gcc-patches/2016-10/msg02498.html:

A patch to enhance buffer overflow warnings (and c/53562) exposed a problem in
the definition of the NOTE_DATA macro defined in the GCC rtl.h header.  The
macro expands to a reference to a non-existent element 3 of the one-element
rtx_note::rtx_insn::rtx_def::u.fld array, like so:

  memset (&((note)->u.fld[3]), 0, sizeof (((note)->u.fld[3])));

note is a pointer to rtx_note.

The computed address, while outside the array, is within the boundaries of the
larger rtx_note object in which the array is declared and so it is not invalid
in and of itself, but deriving the address this way is undefined.  The patch,
which enhances memcpy and other functions to detect and warn on writes past the
end of an object (similarly to __builtin___memcpy_chk et al.), detects that the
subscript is out of bounds of the array from which it was derived and issues a
warning.  To avoid the warning the address should be computed/derived not from
the array but rather from the surrounding object, for example like so:

  char *p = (char*) &(note)->u.fld[0];
  p += sizeof (((note)->u.fld[0])) * 3;
  memset (p, 0, sizeof *p);

[Bug preprocessor/78169] internal compiler error: in get_substring_ranges_for_loc, at input.c:1379

[daniel.black at au dot ibm.com]

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

Daniel Black  changed:

   What|Removed |Added

 Target||x86_64-unknown-linux-gnu-gc
   ||c /
   ||powerpc64le-unknown-linux-g
   ||nu-gcc

--- Comment #3 from Daniel Black  ---
also fails in powerpc64le (cross compile to same arch)

[Bug preprocessor/78169] internal compiler error: in get_substring_ranges_for_loc, at input.c:1379

[daniel.black at au dot ibm.com]

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

--- Comment #2 from Daniel Black  ---
Yes, using a x86_84 -> x86_64 cross compiler. Built with `ct-ng
x86_64-unknown-linux-gnu`

[Bug libfortran/78123] Short reads with T edit descriptor not padding correctly

[jvdelisle at gcc dot gnu.org]

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

--- Comment #5 from Jerry DeLisle  ---
Author: jvdelisle
Date: Mon Oct 31 20:57:16 2016
New Revision: 241722

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

Backport from trunk
PR libgfortran/78123
* io/transfer.c (formatted_transfer_scalar_read): Clear seen_eor
only if we have tabbed to left of current position.
Backport from trunk
PR fortran/78123
* gfortran.dg/fmt_t_9.f: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/fmt_t_9.f
Modified:
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/libgfortran/ChangeLog
branches/gcc-6-branch/libgfortran/io/transfer.c

[Bug target/77308] surprisingly large stack usage for sha512 on arm

[wdijkstr at arm dot com]

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

--- Comment #32 from Wilco  ---
(In reply to Bernd Edlinger from comment #31)
> Sure, combine cant help, especially because it runs before split1.
> 
> But I wondered why this peephole2 is not enabled:
> 
> (define_peephole2 ; ldrd
>   [(set (match_operand:SI 0 "arm_general_register_operand" "")
> (match_operand:SI 2 "memory_operand" ""))
>(set (match_operand:SI 1 "arm_general_register_operand" "")
> (match_operand:SI 3 "memory_operand" ""))]
>   "TARGET_LDRD
>  && current_tune->prefer_ldrd_strd
>  && !optimize_function_for_size_p (cfun)"
>   [(const_int 0)]
> 
> 
> I have -march=armv7-a / -mcpu=cortex-a9 and thus for me
> current_tune-> prefer_ldrd_strd is FALSE.
> 
> Furthermore, if I want to do -Os the third condition is FALSE too.
> But one ldrd must be shorter than two ldr ?
> 
> That seems wrong...

Indeed, on a target that supports LDRD you want to use LDRD if legal. LDM
should only be tried on Thumb-1. Emitting LDRD from a peephole when the offset
is in range will never increase code size so should always be enabled.

[Bug debug/77315] emit DW_OP_form_tls_address

[tromey at gcc dot gnu.org]

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

Tom Tromey  changed:

   What|Removed |Added

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

--- Comment #3 from Tom Tromey  ---
Fixed.

[Bug c++/55958] vtable hidden when compiling with -fvisibility-ms-compat

[andrew.sayman at gmail dot com]

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

Andrew Sayman  changed:

   What|Removed |Added

 CC||andrew.sayman at gmail dot com

--- Comment #3 from Andrew Sayman  ---
I can confirm that this is still an issue with GCC 6.1. The default behavior in
visibility-ms-compat is not compatible with visual studio. It should not be
required to annotate the class when in this mode.

[Bug debug/77315] emit DW_OP_form_tls_address

[tromey at gcc dot gnu.org]

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

--- Comment #2 from Tom Tromey  ---
Author: tromey
Date: Mon Oct 31 20:08:44 2016
New Revision: 241721

URL: https://gcc.gnu.org/viewcvs?rev=241721=gcc=rev
Log:
PR debug/77315:
* dwarf2out.c (mem_loc_descriptor): Use DW_OP_form_tls_address.
(resolve_args_picking_1): Move DW_OP_form_tls_address case next to
DW_OP_GNU_push_tls_address case.
(loc_list_from_tree_1): Use DW_OP_form_tls_address.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c

[Bug libstdc++/78167] experimental/filesystem calls behave differently between Linux gcc 5.3.0 and Windows Visual Studio 2015

[david_bjornbak at keysight dot com]

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

--- Comment #2 from David Bjornbak  ---
gcc 6.2.0 is Ok for this issue, my unit tests pass.

Is there's patch available to address this issue with the 5.x versions of gcc?

[Bug fortran/54679] Erroneous "Expected P edit descriptor" in conjunction with L descriptor

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #8 from Jerry DeLisle  ---
Closing, fixed on trunk. I dont see a strong need to backport this, but if
someelse does, just let me know.

[Bug fortran/54679] Erroneous "Expected P edit descriptor" in conjunction with L descriptor

[jvdelisle at gcc dot gnu.org]

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

--- Comment #7 from Jerry DeLisle  ---
Author: jvdelisle
Date: Mon Oct 31 19:59:04 2016
New Revision: 241720

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

PR fortran/54679
* io.c (check_format): Adjust checks for FMT_L to treat a zero
width as an extension, giving warnings or error as appropriate.
Improve messages.
PR libgfortran/54679
* io/format.c (parse_format_list): Adjust checks for FMT_L to
treat a zero width as an extension, giving warnings or error
as appropriate. Improve messages.
PR fortran/54679
* gfortran.dg/fmt_l.f90: Update test.
* gfortran.dg/fmt_l0.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/fmt_l0.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/io.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/fmt_l.f90
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/format.c

[Bug target/68752] PowerPC: vector reciprocal square root estimate missed optimisations

[carll at gcc dot gnu.org]

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

Carl Love  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #6 from Carl Love  ---
Closing issue

[Bug target/68752] PowerPC: vector reciprocal square root estimate missed optimisations

[carll at gcc dot gnu.org]

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

Carl Love  changed:

   What|Removed |Added

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

--- Comment #5 from Carl Love  ---
Issue is resolved.  Closing bug.

[Bug target/77308] surprisingly large stack usage for sha512 on arm

[bernd.edlinger at hotmail dot de]

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

--- Comment #31 from Bernd Edlinger  ---
Sure, combine cant help, especially because it runs before split1.

But I wondered why this peephole2 is not enabled:

(define_peephole2 ; ldrd
  [(set (match_operand:SI 0 "arm_general_register_operand" "")
(match_operand:SI 2 "memory_operand" ""))
   (set (match_operand:SI 1 "arm_general_register_operand" "")
(match_operand:SI 3 "memory_operand" ""))]
  "TARGET_LDRD
 && current_tune->prefer_ldrd_strd
 && !optimize_function_for_size_p (cfun)"
  [(const_int 0)]


I have -march=armv7-a / -mcpu=cortex-a9 and thus for me
current_tune-> prefer_ldrd_strd is FALSE.

Furthermore, if I want to do -Os the third condition is FALSE too.
But one ldrd must be shorter than two ldr ?

That seems wrong...

[Bug fortran/78171] example with undefined symbol compiles with '-O1 -fcheck=pointer'

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #2 from Jerry DeLisle  ---
Just for clarification, since checking was called for, internally gfortran
generates the following:

  array.data = 0B;
  if ((integer(kind=8)) ((real(kind=4)[0:] * restrict) array.data == 0B))
{
  _gfortran_runtime_error_at (&"At line 4 of file pr78171.f90"[1]{lb: 1 sz:
1}, &"Allocatable actual argument \'array\' is not allocated"[1]{lb: 1 sz: 1});
}
  foo ((real(kind=4)[0:] * restrict) array.data);

The optimizer, which comes after, knows array.dat is NULL. Therefore, no matter
what, _gfortran_runtime_error_at will always be executed. The optimizer also
knows that _gfortran_runtime_error_at does not return, it exits with a status
value of 2.

As a consequence, foo will never be called and it is optimized away.

So this is really not a bug in the compiler.

[Bug fortran/71902] [5/6 Regression] Unneeded temporary on reallocatable character assignment

[tkoenig at gcc dot gnu.org]

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

--- Comment #10 from Thomas Koenig  ---
Author: tkoenig
Date: Mon Oct 31 18:28:11 2016
New Revision: 241717

URL: https://gcc.gnu.org/viewcvs?rev=241717=gcc=rev
Log:
2016-10-31  Thomas Koenig  

Backport from trunk
PR fortran/71902
* frontend-passes.c (realloc_string_callback): Also check for the
lhs being deferred.  Name temporary variable "realloc_string".

2016-10-31  Thomas Koenig  

Backport from trunk
PR fortran/71902
* gfortran.dg/dependency_47.f90:  New test.
* gfortran.dg/dependency_49.f90:  New test


Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/dependency_47.f90
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/dependency_49.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/frontend-passes.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug target/78166] [6/7 Regression] hash.c:1887:1: error: unrecognizable insn

[dave.anglin at bell dot net]

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

--- Comment #4 from dave.anglin at bell dot net ---
On 2016-10-31 1:32 PM, law at redhat dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78166
>
> --- Comment #3 from Jeffrey A. Law  ---
> Hmm, clearly it helps to read the old thread.
>
> Canonicalization rules are that outside a MEM we use ASHIFT and within a MEM 
> we
> use MULT.  So recognizing the MULT seems reasonable.  So presumably what's
> happening is we want to reload the address expression.  That means emitting
> something like
Currently,we allow scaled-indexed DFmode memory operands for 32-bit targets.
So, the address needs reloading when the value needs loading to an 
integer register.

We don't allow these for DImode as reloading would almost always be 
needed.  Still,
we have the shift-add instructions to handle this case, so maybe this 
would generate
better code in the end.

Probably, I changed this causing the regression.

>
> (set (temp) (address expression))
We could change pa_emit_move_sequence, but it's already very complex.  
Essentially,
the stuff that you added to hppa_legitimize_address would be needed
>
> Which means we want to emit using the ASHIFT rather than the MULT form.  Ugh.
> I'm not sure teaching reload about that is wise.   Let me think a bit.  And, 
> no
> LEGITIMIZE_RELOAD_ADDRESS is not the answer ;-)
>
Thought's what I thought.  I  don't know how to direct reload to 
generate ASHIFT instead of
MULT.

Adding the MULT patterns fixes the compile error.

Dave

[Bug fortran/78171] example with undefined symbol compiles with '-O1 -fcheck=pointer'

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to Patrick Seewald from comment #0)
> This should not compile because 'foo' is undefined:
> 
> PROGRAM example
> IMPLICIT NONE
> REAL, ALLOCATABLE, DIMENSION(:) :: array
> CALL foo(array)
> END PROGRAM example
> 
> However it compiles with 'gfortran -O1 -fcheck=pointer example.f90'. If I
> run the executable, I get:
> 
> At line 4 of file example.f90
> Fortran runtime error: Allocatable actual argument 'array' is not allocated

A Fortran processor is not required to diagnosis this problem.
It is the programmers responsibility to ensure that 'array' has
been allocated before it is referenced.

  F2008, p. 129

  An allocatable variable has a status of "unallocated" if
  it is not allocated.  The status of an allocatable variable
  becomes unallocated if it is deallocated (6.7.3) or if it
  is given that status by the allocation transfer procedure.
  An allocatable variable with this status shall not be
  referenced or defined.  It shall not be supplied as an actual
  argument corresponding to a nonallocatable dummy argument,
  except to certain intrinsic inquiry functions.

Those "shall not"s in the above passage from the standard are
prohibitions on the programmer.  While the above code is trivial
and doing a compile-time check may seem easy, it is rather
daunting in a general case and can to lead to a substantial
performance impact for correctly written code.  This is why
'-fcheck = ' exists.  It allows a programmer to turn on additional
checking, and should be used during development and testing.

[Bug target/77308] surprisingly large stack usage for sha512 on arm

[rearnsha at gcc dot gnu.org]

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

--- Comment #30 from Richard Earnshaw  ---
(In reply to wilco from comment #29)
>  Combine could help with
> merging 2 loads/stores into a single instruction.

No, combine works strictly on dataflow dependencies.  Two stores cannot be
dataflow related so won't be combined.  Loads would only be dataflow related if
both loads fed into *exactly* one data-processing instruction after the split. 
That's unlikely to happen so I very much dobut it would happen there either.

[Bug target/78166] [6/7 Regression] hash.c:1887:1: error: unrecognizable insn

[law at redhat dot com]

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

--- Comment #3 from Jeffrey A. Law  ---
Hmm, clearly it helps to read the old thread.

Canonicalization rules are that outside a MEM we use ASHIFT and within a MEM we
use MULT.  So recognizing the MULT seems reasonable.  So presumably what's
happening is we want to reload the address expression.  That means emitting
something like

(set (temp) (address expression))

Which means we want to emit using the ASHIFT rather than the MULT form.  Ugh. 
I'm not sure teaching reload about that is wise.   Let me think a bit.  And, no
LEGITIMIZE_RELOAD_ADDRESS is not the answer ;-)

[Bug target/78166] [6/7 Regression] hash.c:1887:1: error: unrecognizable insn

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com
Summary|[6 Regression]  |[6/7 Regression]
   |hash.c:1887:1: error:   |hash.c:1887:1: error:
   |unrecognizable insn |unrecognizable insn

--- Comment #2 from Jeffrey A. Law  ---
ISTM this fails on the trunk as well and thus is a regression for gcc-7 as
well.  I think tracking down why we generate the (plus (mult)) variant is
probably wiser than adding the patterns back.

Based on insn 424 being recognized, I would hazard a guess it's something in
the predicate that didn't get changed/fixed during the transition.

[Bug c++/78173] New: Hard error subtracting pointers to incomplete type in SFINAE context

[Casey at Carter dot net]

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

Bug ID: 78173
   Summary: Hard error subtracting pointers to incomplete type in
SFINAE context
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Casey at Carter dot net
  Target Milestone: ---

Created attachment 39934
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39934=edit
Minimal repro

This TU, which should compile without errors:

template
T&& declval();

template
using void_t = void;

template
struct foo { static const bool value = false; };
template
struct foo> {
static const bool value = true;
};

struct A;

#define STATIC_ASSERT(...) static_assert(__VA_ARGS__, #__VA_ARGS__)

STATIC_ASSERT(!foo::value); // error: invalid use of 'void'
STATIC_ASSERT(!foo::value); // error: invalid use of incomplete type
'struct A'

instead produces diagnostics
(http://melpon.org/wandbox/permlink/EwcDiz7ZuqpFXdHZ):

prog.cc: In substitution of 'template struct foo > [with T = void*]':
prog.cc:22:1:   required from here
prog.cc:10:44: error: invalid use of 'void'
 struct foo> {
   ~^~
prog.cc: In substitution of 'template struct foo > [with T = A*]':
prog.cc:23:1:   required from here
prog.cc:10:44: error: invalid use of incomplete type 'struct A'
prog.cc:14:8: note: forward declaration of 'struct A'
 struct A;
^

[Bug c++/77886] -Wimplicit-fallthrough: breaks duff's device (in function templates)

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
Author: jakub
Date: Mon Oct 31 17:10:30 2016
New Revision: 241711

URL: https://gcc.gnu.org/viewcvs?rev=241711=gcc=rev
Log:
PR c++/77886
* pt.c (tsubst_expr)  Copy over
FALLTHROUGH_LABEL_P flag to the new LABEL_DECL.
(tsubst_expr) : Likewise.

* g++.dg/warn/Wimplicit-fallthrough-2.C: New test.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/ChangeLog
trunk/gcc/testsuite/ChangeLog

[Bug c++/78089] __builtin_shuffle parsing bug

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Author: jakub
Date: Mon Oct 31 17:08:36 2016
New Revision: 241710

URL: https://gcc.gnu.org/viewcvs?rev=241710=gcc=rev
Log:
PR c++/78089
* parser.c (cp_parser_postfix_expression): Replace return statement in
the first switch with setting postfix_expression to the return
expression and break;.

* c-c++-common/builtin-shuffle-1.c: New test.
* g++.dg/cpp0x/addressof3.C: New test.

Added:
trunk/gcc/testsuite/c-c++-common/builtin-shuffle-1.c
trunk/gcc/testsuite/g++.dg/cpp0x/addressof3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/77948] Option processing of -std=c++11 -std=gnu++11 doesn't reset ext_numeric_literals

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Mon Oct 31 16:38:21 2016
New Revision: 241707

URL: https://gcc.gnu.org/viewcvs?rev=241707=gcc=rev
Log:
PR c++/77948
* c.opt (fext-numeric-literals): Add Var and Init.
* c-opts.c (c_common_handle_option): Don't clear
cpp_opts->ext_numeric_literals for -std=c++{11,14,1z}.
(c_common_post_options): Clear it here if not set
explicitly.

* g++.dg/cpp0x/pr77948-1.C: New test.
* g++.dg/cpp0x/pr77948-2.C: New test.
* g++.dg/cpp0x/pr77948-3.C: New test.
* g++.dg/cpp0x/pr77948-4.C: New test.
* g++.dg/cpp0x/pr77948-5.C: New test.
* g++.dg/cpp0x/pr77948-6.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr77948-1.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr77948-2.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr77948-3.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr77948-4.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr77948-5.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr77948-6.C
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-opts.c
trunk/gcc/c-family/c.opt
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/77860] [7 Regression] ICE in gimple_build_assign_1, at gimple.c:420

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Mon Oct 31 16:36:53 2016
New Revision: 241706

URL: https://gcc.gnu.org/viewcvs?rev=241706=gcc=rev
Log:
PR tree-optimization/77860
* tree-ssa-reassoc.c (eliminate_using_constants): Handle
also integral complex and vector constants.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr77860.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-reassoc.c

[Bug fortran/61376] Error using private statement in polymorphic derived type

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from vehre at gcc dot gnu.org ---
No complaints so far, closing.

[Bug fortran/61337] Wrong indexing and runtime crash with unlimited polymorphic array.

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from vehre at gcc dot gnu.org ---
No complaints so far, closing.

[Bug fortran/57117] [OOP] ICE for sourced allocation of a polymorphic entity using TRANSPOSE

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #17 from vehre at gcc dot gnu.org ---
No complaints so far, closing.

[Bug fortran/51864] [OOP] ALLOCATE with polymorphic array constructor as SOURCE=

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from vehre at gcc dot gnu.org ---
No complaints so far, closing.

[Bug fortran/72832] [6/7 Regression] [OOP] ALLOCATE with SOURCE fails to allocate requested dimensions

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #14 from vehre at gcc dot gnu.org ---
Now closing.

[Bug c/78000] -Wimplicit-function-declaration inhibited with macro from system headers

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
No, that won't work, there are some fails.

[Bug target/78168] [7 Regression] Second ICE in maybe_record_trace_start, at dwarf2cfi.c:2285

[segher at gcc dot gnu.org]

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

--- Comment #10 from Segher Boessenkool  ---
Doesn't fail with powerpc-rtems4.12 either.  Are you sure you built trunk?
A clean build?

[Bug fortran/77872] [5/6/7 Regression] ICE in gfc_conv_descriptor_token, at fortran/trans-array.c:305

[vehre at gcc dot gnu.org]

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

--- Comment #5 from vehre at gcc dot gnu.org ---
Created attachment 39933
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39933=edit
Fix the ICE

The patch fixes the ICE. Albeit I am not happy with it. I fear it is too short
and will open other deficiencies.

[Bug target/78168] [7 Regression] Second ICE in maybe_record_trace_start, at dwarf2cfi.c:2285

[segher at gcc dot gnu.org]

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

--- Comment #9 from Segher Boessenkool  ---
Ah, that might be the difference.  My powerpc-elf build worked just fine;
trying to build powerpc-rtems4.12 now.

[Bug go/78172] New: gen-sysinfo.go vs AIX cred.h

[dje at gcc dot gnu.org]

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

Bug ID: 78172
   Summary: gen-sysinfo.go vs AIX cred.h
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: dje at gcc dot gnu.org
CC: cmang at google dot com
  Target Milestone: ---
Target: powerpc-ibm-aix*

Linux has a fairly simple ucred, but AIX has a large, complicated one
with multiple variations that appears to be too much for sysinfo.go.

/opt/freeware/src/packages/BUILD/gcc-build-6.2.0/./gcc/gccgo 
   -B/opt/freeware/src/packages/BUILD/gcc-build-6.2.0/./gcc/ 
   -B/opt/freeware/powerpc-ibm-aix6.1.0.0/bin/ 
   -B/opt/freeware/powerpc-ibm-aix6.1.0.0/lib/ 
   -isystem /opt/freeware/powerpc-ibm-aix6.1.0.0/include 
   -isystem /opt/freeware/powerpc-ibm-aix6.1.0.0/sys-include 
   -g 
   -O2 
   -I. 
   -c 
   -fgo-pkgpath=syscall 
   ../../../gcc-6.2.0/libgo/go/syscall/env_unix.go 
   ../../../gcc-6.2.0/libgo/go/syscall/syscall_errno.go 
   ../../../gcc-6.2.0/libgo/go/syscall/libcall_support.go 
   ../../../gcc-6.2.0/libgo/go/syscall/libcall_posix.go 
   ../../../gcc-6.2.0/libgo/go/syscall/msan0.go 
   ../../../gcc-6.2.0/libgo/go/syscall/socket.go 
   ../../../gcc-6.2.0/libgo/go/syscall/sockcmsg_unix.go 
   ../../../gcc-6.2.0/libgo/go/syscall/str.go 
   ../../../gcc-6.2.0/libgo/go/syscall/syscall.go 
   ../../../gcc-6.2.0/libgo/go/syscall/syscall_stubs.go 
   ../../../gcc-6.2.0/libgo/go/syscall/exec_unix.go 
   ../../../gcc-6.2.0/libgo/go/syscall/exec_bsd.go 
   ../../../gcc-6.2.0/libgo/go/syscall/libcall_wait4.go 
   ../../../gcc-6.2.0/libgo/go/syscall/sleep_select.go 
   ../../../gcc-6.2.0/libgo/go/syscall/errstr.go 
   ../../../gcc-6.2.0/libgo/go/syscall/libcall_posix_regfile.go 
   ../../../gcc-6.2.0/libgo/go/syscall/libcall_bsd.go 
   ../../../gcc-6.2.0/libgo/go/syscall/socket_bsd.go 
   ../../../gcc-6.2.0/libgo/go/syscall/socket_posix.go 
   ../../../gcc-6.2.0/libgo/go/syscall/libcall_uname.go 
   ../../../gcc-6.2.0/libgo/go/syscall/libcall_posix_utimesnano.go 
   libcalls.go 
   sysinfo.go 
   syscall_arch.go 
   -fPIC 
   -o .libs/syscall.o 
sysinfo.go:10171:307: error: expected ';' or newline after top level
declaration
id uint32; Cr_sgid uint32; Cr_ngrps int16; Cr_caps int16; Cr_groupset
_groupset_t; Cr_mpriv _priv_t; Cr_ipriv _priv_t; Cr_epriv _priv_t;
Cr_bpriv _priv_t; Cr_pag int32; } type _ucred_43 struct { ocr_ref
int32; Ocr_ruid uint32; Ocr_uid uint32; Ocr_suid uint32; Ocr_luid
uint32; Ocr_acctid uint32; Ocr_gid uint32; Ocr_rgid uint32; Ocr_sgid
uint32; Ocr_ngrps int16; Ocr_groups [31+1]uint32; Ocr_mpriv _priv_t;
Ocr_ipriv _priv_t; Ocr_epriv _priv_t; Ocr_bpriv _priv_t; Ocr_pag
int32; } type _ucred_ext struct { crx_ruid uint32; Crx_uid uint32;
Crx_suid uint32; Crx_luid uint32; Crx_acctid uint32; Crx_gid uint32;
Crx_rgid uint32; Crx_sgid uint32; Crx_ngrps int32; Crx_groups
[127+1]uint32; Crx_reserved_1 int32; Crx_caps ___cap_t; Crx_mpriv
_priv_t; Crx_ipriv _priv_t; Crx_epriv _priv_t; Crx_bpriv _priv_t;
Crx_npags int32; Crx_pagids [15+1]uint8; Crx_pags [15+1]int32;
Crx_reserved_2 int32; Crx_roles [7+1]uint32; Crx_nroles int16;
Crx_reserved_3 int16; Crx_flags uint32; Crx_effpriv _privg_t;
Crx_maxpriv _privg_t; Crx_inhpriv _privg_t; Crx_limpriv _privg_t;
Crx_usedpriv _privg_t; Crx_pad [31+1]int32; } type _ucred_ext2_t
struct { crx2_labels _sec_labels_t; Crx_pad [147+1]int32; }

^
sysinfo.go:10171:346: error: expected declaration

Could this be a complaint about missing declaration of the _priv_t type,
defined by priv.h on AIX?

[Bug target/78168] [7 Regression] Second ICE in maybe_record_trace_start, at dwarf2cfi.c:2285

[sebastian.hu...@embedded-brains.de]

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

--- Comment #8 from Sebastian Huber  ---
On RTEMS I think -mspe is enabled for -mcpu=8540.

[Bug target/78168] [7 Regression] Second ICE in maybe_record_trace_start, at dwarf2cfi.c:2285

[sebastian.hu...@embedded-brains.de]

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

--- Comment #7 from Sebastian Huber  ---
A git bisect indicates this as the bad commit:

commit 14fdd09f470dea253089d6a5b27d7a2c3ab7d67a
Author: segher 
Date:   Wed Oct 12 15:34:39 2016 +

rs6000: Separate shrink-wrapping

This implements the hooks for separate shrink-wrapping for rs6000.
It handles GPRs and LR.  The GPRs get a component number corresponding
to their register number; LR gets component number 0.


* config/rs6000/rs6000.c (machine_function): Add new fields
gpr_is_wrapped_separately and lr_is_wrapped_separately.
(TARGET_SHRINK_WRAP_GET_SEPARATE_COMPONENTS,
TARGET_SHRINK_WRAP_COMPONENTS_FOR_BB,
TARGET_SHRINK_WRAP_DISQUALIFY_COMPONENTS,
TARGET_SHRINK_WRAP_EMIT_PROLOGUE_COMPONENTS,
TARGET_SHRINK_WRAP_EMIT_EPILOGUE_COMPONENTS,
TARGET_SHRINK_WRAP_SET_HANDLED_COMPONENTS): Define.
(rs6000_get_separate_components): New function.
(rs6000_components_for_bb): New function.
(rs6000_disqualify_components): New function.
(rs6000_emit_prologue_components): New function.
(rs6000_emit_epilogue_components): New function.
(rs6000_set_handled_components): New function.
(rs6000_emit_prologue): Don't emit LR save if lr_is_wrapped_separately.
Don't emit GPR saves if gpr_is_wrapped_separately for that register.
(restore_saved_lr): Don't restore LR if lr_is_wrapped_separately.
(rs6000_emit_epilogue): Don't emit GPR restores if
gpr_is_wrapped_separately for that register.  Don't make a
REG_CFA_RESTORE note for registers we did not restore, either.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@241065
138bc75d-0d04-0410-961f-82ee72b054a4

:04 04 93015f5b1887799cdee7723b46455953bf087911
61a2a5a9e1f078a49af4930e0f62f5269f18ad86 M  gcc

[Bug target/78168] [7 Regression] Second ICE in maybe_record_trace_start, at dwarf2cfi.c:2285

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
(In reply to Segher Boessenkool from comment #5)
> Cannot reproduce on 32-bit Linux, will try a plain powerpc-elf build.

I did that on a x86_64-linux-gnu with --target=powerpc-rtems4.12

[Bug c++/77886] -Wimplicit-fallthrough: breaks duff's device (in function templates)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/78168] [7 Regression] Second ICE in maybe_record_trace_start, at dwarf2cfi.c:2285

[segher at gcc dot gnu.org]

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

--- Comment #5 from Segher Boessenkool  ---
Cannot reproduce on 32-bit Linux, will try a plain powerpc-elf build.

[Bug fortran/78171] New: example with undefined symbol compiles with '-O1 -fcheck=pointer'

[patrick.seewald at gmail dot com]

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

Bug ID: 78171
   Summary: example with undefined symbol compiles with '-O1
-fcheck=pointer'
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick.seewald at gmail dot com
  Target Milestone: ---

This should not compile because 'foo' is undefined:

PROGRAM example
IMPLICIT NONE
REAL, ALLOCATABLE, DIMENSION(:) :: array
CALL foo(array)
END PROGRAM example

However it compiles with 'gfortran -O1 -fcheck=pointer example.f90'. If I run
the executable, I get:

At line 4 of file example.f90
Fortran runtime error: Allocatable actual argument 'array' is not allocated

[Bug middle-end/78047] [7 Regression] Chromium apparently gets miscompiled

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Because

(gdb) p *$54
$55 = {id = 30, is_artificial_var = 0, is_special_var = 0, is_unknown_size_var
= 0, is_full_var = 1, is_heap_var = 0, 
  may_have_pointers = 0, only_restrict_pointers = 0, is_restrict_var = 0,
is_global_var = 1, is_ipa_escape_point = 0, is_fn_info = 0, 
  ruid = 0, next = 0, head = 30, offset = 0, size = 448, fullsize = 448, 
  name = 0x7264dd68
"_ZZN18GrResourceProviderC4EP5GrGpuP15GrResourceCacheP13GrSingleOwnerE27gQuadIndexBufferKey_storage",
 
  decl = , solution =
0x37f54e0, oldsolution = 0x0}

thus it is noted as !may_have_pointers.

Ok, this is because we first generate "sth" at offset zero:

/* If there isn't anything at offset zero, create sth.  */
if (!pair
&& offset + foff != 0)
  {
fieldoff_s e
  = {0, offset + foff, false, false, false, false, NULL_TREE};
pair = fieldstack->safe_push (e);
  }

(note may_have_pointers = false) and then end up simply merging:

/* If adjacent fields do not contain pointers merge them.  */
must_have_pointers_p = field_must_have_pointers (field);
if (pair
&& !has_unknown_size
&& !must_have_pointers_p
&& !pair->must_have_pointers
&& !pair->has_unknown_size
&& pair->offset + (HOST_WIDE_INT)pair->size == offset + foff)
  {
pair->size += tree_to_uhwi (DECL_SIZE (field));

may_have_pointers should be conservative these days (should be removed from
fieldoff I guess).

diff --git a/gcc/tree-ssa-structalias.c b/gcc/tree-ssa-structalias.c
index fb364f1..2880382 100644
--- a/gcc/tree-ssa-structalias.c
+++ b/gcc/tree-ssa-structalias.c
@@ -5566,7 +5568,7 @@ push_fields_onto_fieldstack (tree type, vec
*fieldstack,
&& offset + foff != 0)
  {
fieldoff_s e
- = {0, offset + foff, false, false, false, false, NULL_TREE};
+ = {0, offset + foff, false, false, true, false, NULL_TREE};
pair = fieldstack->safe_push (e);
  }


fixes it:

  MEM[(struct Builder *)].fKey = [(void
*)_storage + 8B];
  # PT = nonlocal escaped null { D.124724 } (nonlocal, escaped)
  _53 = MEM[(struct SkAutoSTMalloc *)_storage + 8B].fPtr;
  if (_53 != [(struct SkAutoSTMalloc *)_storage +
8B].D.47035.fTStorage)
goto ;

[Bug c/78000] -Wimplicit-function-declaration inhibited with macro from system headers

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
I'm testing a patch to disable inhibiting such warnings for macros from system
headers globally.  I've failed to come up with anything better so far.

[Bug target/77308] surprisingly large stack usage for sha512 on arm

[wilco at gcc dot gnu.org]

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

--- Comment #29 from wilco at gcc dot gnu.org ---
(In reply to Bernd Edlinger from comment #28)
> With my latest patch I bootstrapped a configuration with
> --with-arch=armv7-a --with-tune=cortex-a9 --with-fpu=vfpv3-d16
> --with-float=hard
> 
> I noticed a single regression in gcc.target/arm/pr53447-*.c
> 
> That is caused by disabling the adddi3 expansion.
> 
> void t0p(long long * p)
> {
>   *p += 0x10001;
> }
> 
> used to get compiled to this at -O2:
> 
>   ldrdr2, [r0]
>   addsr2, r2, #1
>   adc r3, r3, #1
>   strdr2, [r0]
>   bx  lr
> 
> but without the adddi3 pattern I have at -O2:
> 
>   ldr r3, [r0]
>   ldr r1, [r0, #4]
>   cmn r3, #1
>   add r3, r3, #1
>   movcc   r2, #0
>   movcs   r2, #1
>   add r1, r1, #1
>   str r3, [r0]
>   add r3, r2, r1
>   str r3, [r0, #4]
>   bx  lr

That's because your patch disables adddi3 completely, which is not correct. We
want to use the existing integer sequence, just expanded earlier. Instead of
your change, removing the "&& reload_completed" from the arm_adddi3 instruction
means we expand before register allocation:

ldr r3, [r0]
ldr r2, [r0, #4]
addsr3, r3, #1
str r3, [r0]
adc r2, r2, #16
str r2, [r0, #4]
bx  lr

> Note that also the ldrd instructions are not there.

Yes that's yet another bug...

> I think this is the effect on the ldrd that you already mentioned,
> and it gets worse when the expansion breaks the di registers up
> into two si registers.

Indeed, splitting early means we end up with 2 loads. However in most cases we
should be able to gather the loads and emit LDRD/STRD on Thumb-2 (ARM's
LDRD/STRD is far more limited so not as useful). Combine could help with
merging 2 loads/stores into a single instruction.

[Bug middle-end/78047] [7 Regression] Chromium apparently gets miscompiled

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Biener  ---
(In reply to Markus Trippelsdorf from comment #5)
>   :  
> 
>   MEM[(struct  &)] ={v} {CLOBBER};  
> 
>   _53 = MEM[(struct SkAutoSTMalloc *)_storage +
> 8B].fPtr;   
> 
>   if (_53 != [(struct SkAutoSTMalloc *)_storage +
> 8B].D.47025.fTStorage)  

So X.fPtr !=   This probably means a latent wrong-code
PTA bug.


  :
  MEM[(struct  &)_storage + 8] ={v} {CLOBBER};
  MEM[(struct  &)_storage + 8] ={v} {CLOBBER};
  MEM[(struct  &)_storage + 8] ={v} {CLOBBER};
  MEM[(struct SkAutoSTMalloc *)_storage + 8B].fPtr =
[(void *)_storage + 16B];
  MEM[(unsigned int &)_storage + 16] = 0;
  MEM[(unsigned int &)_storage + 20] = 0;
  MEM[(struct  &)_storage + 48] ={v} {CLOBBER};
  MEM[(struct sk_sp *)_storage + 48B].fPtr = 0B;
  # USE = nonlocal null { D.124671 D.124724 D.124797 D.124805 } (nonlocal,
escaped)
  # CLB = nonlocal null { D.124671 D.124724 D.124797 D.124805 } (nonlocal,
escaped)
  _49 = GrUniqueKey::GenerateDomain ();

  :
  MEM[(struct  &)] ={v} {CLOBBER};
  MEM[(struct Builder *)].fKey = [(void
*)_storage + 8B];
  # PT = null
  _53 = MEM[(struct SkAutoSTMalloc *)_storage + 8B].fPtr;
  # PT = null { D.124724 } (nonlocal, escaped)
  _54 = [(struct SkAutoSTMalloc *)_storage +
8B].D.47035.fTStorage;
  if (_53 != [(struct SkAutoSTMalloc *)_storage +
8B].D.47035.fTStorage)

...

we fail to add a constraint for _53 = ... at all.  We add:

_49 = NONLOCAL
builder =
&_ZZN18GrResourceProviderC4EP5GrGpuP15GrResourceCacheP13GrSingleOwnerE27gQuadIndexBufferKey_storage
_54 =
&_ZZN18GrResourceProviderC4EP5GrGpuP15GrResourceCacheP13GrSingleOwnerE27gQuadIndexBufferKey_storage
ESCAPED = _53
ESCAPED =
&_ZZN18GrResourceProviderC4EP5GrGpuP15GrResourceCacheP13GrSingleOwnerE27gQuadIndexBufferKey_storage

[Bug c++/77886] -Wimplicit-fallthrough: breaks duff's device (in function templates)

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
Author: jakub
Date: Mon Oct 31 13:39:49 2016
New Revision: 241700

URL: https://gcc.gnu.org/viewcvs?rev=241700=gcc=rev
Log:
PR c++/77886
* pt.c (tsubst_expr)  Copy over
FALLTHROUGH_LABEL_P flag to the new LABEL_DECL.
(tsubst_expr) : Likewise.

* g++.dg/warn/Wimplicit-fallthrough-2.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wimplicit-fallthrough-2.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug fortran/77872] [5/6/7 Regression] ICE in gfc_conv_descriptor_token, at fortran/trans-array.c:305

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from vehre at gcc dot gnu.org ---
Can someone explain the code to me? What is it supposed to do? Is this not
modelling an endless recursion?

What is "s" and "f" in the type definition?

I understand that "pass" and "deferred" mean to transport meta-data of an
array, right?

[Bug debug/78112] [7 regression] invalid DWARF generated by the compiler: DIE has multiple AT_inline attributes

[derodat at adacore dot com]

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

--- Comment #10 from Pierre-Marie de Rodat  ---
Created attachment 39932
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39932=edit
pyelftools-based Python3 script to check duplicate attributes in ELF/DWARF info

[Bug debug/78112] [7 regression] invalid DWARF generated by the compiler: DIE has multiple AT_inline attributes

[derodat at adacore dot com]

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

--- Comment #9 from Pierre-Marie de Rodat  ---
Back to business. ;-)

Thank you very much, Jakub! During investigation, I managed to reduce this even
further:

void run (int *int_p, void(*func)(int *)) { func (int_p); }
namespace foo {
   struct Foo {
  int a;
  Foo() { run (, [](int *int_p) { *int_p = 0; }); }
   };
}
int main (void) { foo::Foo f; }

With today’s trunk (gcc/cc1plus -g -dA foo.C) and this reproducer, I see three
DW_TAG_subprogram having two DW_AT_object_pointer each.

Disclaimer: to be perfectly honnest, I have a very partial understanding of how
dwarf2out.c:gen_subprogram_die is supposed to work. It has a good share of
explaining comments, but it is still hard to grasp as it does quite complex
things. That being said…

My analysis so far is that gen_subprogram_die is supposed to be called a very
specific number of times for each function and my change from 2016-10-12 made
it run more times, so it unintentionally added some attributes more than just
once. The following patch seems to restore call count to what we had
previously:

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 78a2979..a85ab3b 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -23909,11 +23909,11 @@ dwarf2out_early_global_decl (tree decl)
  if (!DECL_STRUCT_FUNCTION (decl))
goto early_decl_exit;

- /* For nested functions, emit DIEs for the parents first so that all
-nested DIEs are generated at the proper scope in the first
-shot.  */
+ /* For nested functions, make sure we have DIEs for the parents first
+so that all nested DIEs are generated at the proper scope in the
+first shot.  */
  tree context = decl_function_context (decl);
- if (context != NULL)
+ if (context != NULL && lookup_decl_die (context) == NULL)
{
  current_function_decl = context;
  dwarf2out_decl (context);

I’m currently bootstrapping+regtesting it on x86_64-linux. I tried to come up
with a regression testcase for it, but I can’t find a human-friendly regexp for
scan-assembler-times to check that we don’t have multiple attributes per tag.
So for local testing, I wrote a Python3 script to use the pyelftools library.
I’ll file it right after sending this message if others need to use it.

Something bugs me, though: with Jakub’s reproducer, I get multiple
DW_AT_object_pointer attributes even at r241022 (i.e. right before my
2016-10-12 patch):

$ gcc/cc1plus -g -dA pr78112.ii && gcc -c pr78112.s && ./check.py pr78112.o
In (0x3c4) DW_TAG_subprogram: DW_AT_object_pointer appears 2 times
In (0x46a) DW_TAG_subprogram: DW_AT_object_pointer appears 2 times
In (0x4fe) DW_TAG_subprogram: DW_AT_object_pointer appears 2 times
In (0x55a) DW_TAG_subprogram: DW_AT_object_pointer appears 2 times
In (0x5cf) DW_TAG_subprogram: DW_AT_object_pointer appears 2 times
In (0x668) DW_TAG_subprogram: DW_AT_object_pointer appears 2 times

So I’m surprised Rainer hasn’t spotted this kind of error before.

Thoughts?

[Bug tree-optimization/77860] [7 Regression] ICE in gimple_build_assign_1, at gimple.c:420

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 39931
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39931=edit
gcc7-pr77860.patch

Untested fix.

[Bug target/77308] surprisingly large stack usage for sha512 on arm

[bernd.edlinger at hotmail dot de]

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

--- Comment #28 from Bernd Edlinger  ---
With my latest patch I bootstrapped a configuration with
--with-arch=armv7-a --with-tune=cortex-a9 --with-fpu=vfpv3-d16
--with-float=hard

I noticed a single regression in gcc.target/arm/pr53447-*.c

That is caused by disabling the adddi3 expansion.

void t0p(long long * p)
{
  *p += 0x10001;
}

used to get compiled to this at -O2:

ldrdr2, [r0]
addsr2, r2, #1
adc r3, r3, #1
strdr2, [r0]
bx  lr

but without the adddi3 pattern I have at -O2:

ldr r3, [r0]
ldr r1, [r0, #4]
cmn r3, #1
add r3, r3, #1
movcc   r2, #0
movcs   r2, #1
add r1, r1, #1
str r3, [r0]
add r3, r2, r1
str r3, [r0, #4]
bx  lr

Note that also the ldrd instructions are not there.

Unfortunaltely also the other di3 pattern make the ldrd go away:

void t0p(long long * p)
{
  *p |= 0x10001;
}

was with iordi3 like this:

ldrdr2, [r0]
orr r2, r2, #1
orr r3, r3, #1
strdr2, [r0]
bx  lr

and without iordi3:

ldm r0, {r2, r3}
orr r2, r2, #1
orr r3, r3, #1
stm r0, {r2, r3}
bx  lr

but 

void t0p(long long * p)
{
  p[1] |= 0x10001;
}


gets two loads instead:

ldr r2, [r0, #8]
ldr r3, [r0, #12]
orr r2, r2, #1
orr r3, r3, #1
str r2, [r0, #8]
str r3, [r0, #12]
bx  lr

however:

void t0p(long long * p)
{
  p[1] <<= 11;
}

gets compiled into this:

ldr r3, [r0, #12]
ldr r2, [r0, #8]
lsl r3, r3, #11
lsl r1, r2, #11
orr r3, r3, r2, lsr #21
str r1, [r0, #8]
str r3, [r0, #12]
bx  lr


already before my patch.

I think this is the effect on the ldrd that you already mentioned,
and it gets worse when the expansion breaks the di registers up
into two si registers.

[Bug lto/78129] -Werror=suggest-final-types leads to -ENOSPC.

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Mon Oct 31 12:52:23 2016
New Revision: 241698

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

PR lto/78129
* lto.c (do_whole_program_analysis): Bail out after errors
from WPA analysis.

Modified:
trunk/gcc/lto/ChangeLog
trunk/gcc/lto/lto.c

[Bug tree-optimization/77860] [7 Regression] ICE in gimple_build_assign_1, at gimple.c:420

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Reproduceable also on current trunk with
-O2 -fno-tree-forwprop -fno-tree-vrp
typedef unsigned short V __attribute__((vector_size (16)));

V
foo (V x, V y)
{
  V a = -x;
  V b = -y;
  return a * b;
}

[Bug lto/78129] -Werror=suggest-final-types leads to -ENOSPC.

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
The attached would be still needed in case the ltrans writing is terminated
by, say, ctrl-c (but then there's a race because WPA doesn't write the ltrans
output list before finishing writing all ltrans objects).

[Bug lto/78129] -Werror=suggest-final-types leads to -ENOSPC.

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Ah - I think a simpler pass would be

diff --git a/gcc/lto/lto.c b/gcc/lto/lto.c
index 7256ff9..c1567ca 100644
--- a/gcc/lto/lto.c
+++ b/gcc/lto/lto.c
@@ -3092,6 +3092,10 @@ do_whole_program_analysis (void)

   execute_ipa_pass_list (g->get_passes ()->all_regular_ipa_passes);

+  /* When WPA analysis raises errors, do not bother to output anything.  */
+  if (seen_error ())
+return;
+
   if (symtab->dump_file)
 {
   fprintf (symtab->dump_file, "Optimized ");

[Bug tree-optimization/57206] Auto-vectorization fails when array index is an unsigned int expression

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from amker at gcc dot gnu.org ---
Test case added.  Fixed.

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

[amker at gcc dot gnu.org]

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

Bug 57206 Summary: Auto-vectorization fails when array index is an unsigned int 
expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57206

   What|Removed |Added

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

[Bug tree-optimization/78170] [7 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu

[ktkachov at gcc dot gnu.org]

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

--- Comment #5 from ktkachov at gcc dot gnu.org ---
The problem is in encode_tree_to_bitpos.
It needs to take into account the padding that native_encode_expr may introduce
for sign-extended values for little-endian as well as big-endian.

Testing a patch

[Bug lto/78129] -Werror=suggest-final-types leads to -ENOSPC.

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Created attachment 39930
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39930=edit
patch

Does the attached fix it?  (I lack a testcase to easily reproduce a failing WPA
stage after it has written some ltrans file)

OTOH I wonder where we emit errors during lto_wpa_write_files ...

[Bug lto/78129] -Werror=suggest-final-types leads to -ENOSPC.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

[Bug tree-optimization/78170] [7 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #4 from ktkachov at gcc dot gnu.org ---
(In reply to Richard Biener from comment #3)
> Btw, I see at -Os:
> 
> Starting new chain with statement:
> c.f6 = -1;
> The base object is:
> c
> Volatile access terminates all chains
> Processing basic block <4>:
> 
>   :
>   e = *.LC0;
>   c = e;
>   c.f6 = -1;
>   e ={v} {CLOBBER};
>   a.1_1 = a;
>   b = a.1_1;
> 
> the e ={v} {CLOBBER}; isn't a "volatile" stmt.  Clobbers only should
> terminate
> aliasing chains.

Yes, that's what I'm seeing on aarch64.
I'll look into implementing that once the bugs are squashed out

[Bug target/77834] [7 Regression] ICE: in make_decl_rtl, at varasm.c:1311 with -O -ftree-pre -mstringop-strategy=libcall

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 39929
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39929=edit
gcc7-pr77834.patch

Untested fix.  Will bootstrap/regtest this with additional statistics
gathering, to see if this shouldn't be extended (e.g. allow DECL_RTL to be used
on TREE_STATIC vars or whatever make_decl_rtl allows).

[Bug tree-optimization/78170] [7 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Btw, I see at -Os:

Starting new chain with statement:
c.f6 = -1;
The base object is:
c
Volatile access terminates all chains
Processing basic block <4>:

  :
  e = *.LC0;
  c = e;
  c.f6 = -1;
  e ={v} {CLOBBER};
  a.1_1 = a;
  b = a.1_1;

the e ={v} {CLOBBER}; isn't a "volatile" stmt.  Clobbers only should terminate
aliasing chains.

[Bug target/77834] [7 Regression] ICE: in make_decl_rtl, at varasm.c:1311 with -O -ftree-pre -mstringop-strategy=libcall

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Apparently on the v_lsm.5 variable we trigger cfgexpand.c (set_rtl)'s
  /* If we have something recorded and it's not the same place
 as we want to record now, we have multiple partitions for the
 same base variable, with different places.  We can't just
 randomly chose one, hence we have to say that we don't know.
 This only happens with optimization, and there var-tracking
 will figure out the right thing.  */
  else if (DECL_RTL (var) != x)
SET_DECL_RTL (var, pc_rtx);
hunk, because set_rtl is once called with
(mem/c:BLK (plus:DI (reg/f:DI 82 virtual-stack-vars)
(const_int -64 [0xffc0])) [1 v_lsm.5+0 S64 A512])
on v_lsm.5_24 and then
(mem/c:BLK (plus:DI (reg/f:DI 82 virtual-stack-vars)
(const_int -128 [0xff80])) [1 v_lsm.5+0 S64 A512])
on v_lsm.5_20 and then in pass_expand::execute
  /* If this decl was marked as living in multiple places, reset  
 this now to NULL.  */
  tree var = SSA_NAME_VAR (name);  
  if (var && DECL_RTL_IF_SET (var) == pc_rtx)
SET_DECL_RTL (var, NULL);

[Bug target/78166] [6 Regression] hash.c:1887:1: error: unrecognizable insn

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.3

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |7.0
   Target Milestone|--- |7.0
Summary|ICE on invalid code at -Os  |[7 Regression] ICE on
   |and above on|invalid code at -Os and
   |x86_64-linux-gnu:   |above on x86_64-linux-gnu:
   |Segmentation fault  |Segmentation fault

[Bug tree-optimization/78154] memcpy et al can be assumed to return non-null

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Confirmed.  Improve gimple_stmt_nonzero_warnv_p.

[Bug fortran/78152] [6/7 Regression] coarray and associate

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.3

[Bug tree-optimization/78151] Fail to vectorize *min_element

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-31
 CC||rguenth at gcc dot gnu.org
 Blocks||53947
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Time to play a bit with fold_stmt applying to PHIs using match.pd via
folding a COND_EXPR composed of the dominating controlling condition plus
the PHI arguments ... at least if-conversion could do that.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug other/78161] [7 Regression] contrib/download_prerequisites fails on MacOS, Lubuntu, and Windows

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-31
 CC||rguenth at gcc dot gnu.org
   Target Milestone|--- |7.0
Summary|contrib/download_prerequisi |[7 Regression]
   |tes fails on MacOS, |contrib/download_prerequisi
   |Lubuntu, and Windows|tes fails on MacOS,
   ||Lubuntu, and Windows
 Ever confirmed|0   |1

[Bug other/78161] contrib/download_prerequisites fails on MacOS, Lubuntu, and Windows

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
The issue with the current script is probably relying too much on wget
internals
(the -O option).  It would probably be better to simply cd into the destination
directory and do wget w/o -O.

[Bug tree-optimization/33707] scev not handling unsigned conversion

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from amker at gcc dot gnu.org ---
This has been fixed as added test case.

[Bug tree-optimization/78170] [7 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |ktkachov at gcc dot 
gnu.org

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Confirmed. Oddly I don't see -1 on aarch64.
Will investigate

[Bug c++/78163] ref-qualified function type incorrectly accepted in function parameter type

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||jason at redhat dot com
   Target Milestone|--- |7.0

--- Comment #3 from Martin Liška  ---
You're right, thus I'm confirming that. Started with r225272, where we switch
to std=c++14. -std=c++11 works fine.

[Bug c++/78163] ref-qualified function type incorrectly accepted in function parameter type

[rs2740 at gmail dot com]

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

--- Comment #2 from TC  ---
(In reply to Martin Liška from comment #1)
> For:
> $ gcc --version
> gcc (SUSE Linux) 6.2.1 20160830 [gcc-6-branch revision 239856]
> 
> $ gcc pr78163.c
> pr78163.c:1:16: error: expected ‘;’, ‘,’ or ‘)’ before ‘&’ token
>  void f(void () &);
> ^
> pr78163.c:2:19: error: expected ‘;’, ‘,’ or ‘)’ before ‘&’ token
>  void g(void (*)() &);
>^
> pr78163.c:3:14: error: expected ‘)’ before ‘&’ token
>  void h(void (&)() &);
>   ^
> pr78163.c:4:22: error: expected ‘)’ before ‘&’ token
>  void i(void (* const &)() &);
>   ^
> Same for all releases I have, all of declarations are rejected. What's wrong?

This report is for C++, not C?

[Bug gcov-profile/78086] FAIL: gcc.misc-tests/gcov-1.c, etc

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška  ---
Thanks for testing. Patch has been just sent to ML:
https://gcc.gnu.org/ml/gcc-patches/2016-10/msg02439.html

[Bug fortran/78059] Pointer to variable length array, debug info

[bernhard.heckel at intel dot com]

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

--- Comment #5 from Bernhard Heckel  ---
Hi Dominique,

did my comment help to figure out if the bug report is valid?

[Bug rtl-optimization/78116] [7 regression] Performance drop after r241173 on avx512 target

[ysrumyan at gmail dot com]

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

--- Comment #7 from Yuri Rumyantsev  ---
Compiler was configures with:

Configured with: /configure --enable-languages=c,c++
--enable-clocale=gnu --enable-cloog-backend=isl --enable-shared
--disable-libsanitizer --disable-bootstrap --disable-nls --with-system-zlib
--with-demangler-in-ld --with-arch=corei7 --with-cpu=corei7 --with-fpmath=sse
--prefix=/install
Thread model: posix
gcc version 7.0.0 20161014 (experimental) (GCC)

I assume that arch and cpu are not essential.

[Bug target/78168] [7 Regression] Second ICE in maybe_record_trace_start, at dwarf2cfi.c:2285

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

[Bug target/78168] [7 Regression] Second ICE in maybe_record_trace_start, at dwarf2cfi.c:2285

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #4 from Martin Liška  ---
Created attachment 39928
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39928=edit
Minimized test-case

Confirmed, adding minimized test-case.

[Bug lto/78140] [7 Regression] libxul -flto uses 1GB more memory than gcc-6

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Liška  ---
I'll take a look.

[Bug c++/78163] ref-qualified function type incorrectly accepted in function parameter type

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
For:
$ gcc --version
gcc (SUSE Linux) 6.2.1 20160830 [gcc-6-branch revision 239856]

$ gcc pr78163.c
pr78163.c:1:16: error: expected ‘;’, ‘,’ or ‘)’ before ‘&’ token
 void f(void () &);
^
pr78163.c:2:19: error: expected ‘;’, ‘,’ or ‘)’ before ‘&’ token
 void g(void (*)() &);
   ^
pr78163.c:3:14: error: expected ‘)’ before ‘&’ token
 void h(void (&)() &);
  ^
pr78163.c:4:22: error: expected ‘)’ before ‘&’ token
 void i(void (* const &)() &);
  ^
Same for all releases I have, all of declarations are rejected. What's wrong?

[Bug preprocessor/78169] internal compiler error: in get_substring_ranges_for_loc, at input.c:1379

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Can't reproduce on native x86_64-linux-gnu compiler. Are you using a
cross-compilation (guessing because you have it called crosstool-ng)?

[Bug tree-optimization/78170] [7 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-31
 CC||kyrylo.tkachov at arm dot com,
   ||marxin at gcc dot gnu.org
   Target Milestone|--- |7.0
Summary|wrong code at -O2 and -O3   |[7 Regression] wrong code
   |on x86_64-linux-gnu |at -O2 and -O3 on
   ||x86_64-linux-gnu
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r241649.

[Bug target/78168] [7 Regression] Second ICE in maybe_record_trace_start, at dwarf2cfi.c:2285

[sebastian.hu...@embedded-brains.de]

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

--- Comment #3 from Sebastian Huber  ---
My configure command line:

configure --target=powerpc-rtems4.12 --verbose --with-newlib
--disable-libstdcxx-pch --disable-nls --disable-lto --disable-plugin
--enable-languages=c

Should also work with a bare-metal 32-bit ELF powerpc GCC.

[Bug target/78168] [7 Regression] Second ICE in maybe_record_trace_start, at dwarf2cfi.c:2285

[sebastian.hu...@embedded-brains.de]

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

--- Comment #2 from Sebastian Huber  ---
(In reply to Andrew Pinski from comment #1)
> Most likely a dup of bug 78029.

I am not sure. I get the ICE with the latest GCC which includes the fix for bug
78029.

[Bug target/78168] [7 Regression] Second ICE in maybe_record_trace_start, at dwarf2cfi.c:2285

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

--- Comment #1 from Andrew Pinski  ---
Most likely a dup of bug 78029.