[Bug target/70750] [6/7 Regression] Load and call no longer combined for indirect calls on x86

[hjl at gcc dot gnu.org]

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

--- Comment #5 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Thu Apr 21 22:01:34 2016
New Revision: 235353

URL: https://gcc.gnu.org/viewcvs?rev=235353&root=gcc&view=rev
Log:
X86: Fix a typo in call_insn_operand

r231923 has

 ;; Test for a valid operand for a call instruction.
 ;; Allow constant call address operands in Pmode only.
 (define_special_predicate "call_insn_operand"
   (ior (match_test "constant_call_address_operand
 (op, mode == VOIDmode ? mode : Pmode)")
(match_operand 0 "call_register_no_elim_operand")
-   (and (not (match_test "TARGET_X32"))
-   (match_operand 0 "memory_operand"
+   (ior (and (not (match_test "TARGET_X32"))
+(match_operand 0 "sibcall_memory_operand"))
   ^^^ A typo.
+   (and (match_test "TARGET_X32 && Pmode == DImode")
+(match_operand 0 "GOT_memory_operand")

"sibcall_memory_operand" should be "memory_operand".

gcc/

PR target/70750
* config/i386/predicates.md (call_insn_operand): Replace
sibcall_memory_operand with memory_operand.

gcc/testsuite/

PR target/70750
* gcc.target/i386/pr70750-1.c: New test.
* gcc.target/i386/pr70750-2.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr70750-1.c
trunk/gcc/testsuite/gcc.target/i386/pr70750-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/predicates.md
trunk/gcc/testsuite/ChangeLog

[Bug ipa/68331] [meta-bug] fipa-pta issues

[vries at gcc dot gnu.org]

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

--- Comment #12 from vries at gcc dot gnu.org ---
(In reply to David Abdurachmanov from comment #10)
> I have been reg-testing GCC 6 for the last few weeks and I hit an issue with
> compile code straggly segfaulting.
> 
> Compiler with GCC 5.3.0, ASan and valgrind shows no issues. Compiled with
> GCC 6.0.1, ASan and valgrind shows issues, program segfaults. If I go below
> -O2, the execution at least does not segfault. Developers so far couldn't
> understand whats happening. No issues if compiled with latest Clang or ICC.
> 
> I am trying to understand if this is a potential GCC bug and it's worth
> filling another BZ ticket. I am trying to reg-test as much as I can before
> GCC 6.1.0 is cut. What are your thoughts?

Thanks for your bisect effort and analysis. Please file a bugzilla ticket, and
include the testcase.

[Bug ipa/68331] [meta-bug] fipa-pta issues

[david.abdurachmanov at gmail dot com]

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

--- Comment #11 from David Abdurachmanov  
---
"Good" code, annotated by me. Now notice from my previous message that the fix
for this PR, caused

49 89 1c 24 mov%rbx,(%r12)

to be removed. We lost one instruction which stored the address of allocated
objected via "pointer".

000187b0 
>::__single_object std::make_unique, char const
(&) [16], int const&, bool&>(char const (&) [16], int const&, bool&) [clone
.isra.142]>:
   187b0:   41 56   push   %r14
   187b2:   41 55   push   %r13
   187b4:   49 89 f6mov%rsi,%r14
   187b7:   41 54   push   %r12
   187b9:   55  push   %rbp
   187ba:   49 89 fcmov%rdi,%r12
   187bd:   53  push   %rbx

// Allocate 40 bytes on the heap

   187be:   bf 28 00 00 00  mov$0x28,%edi
   187c3:   49 89 d5mov%rdx,%r13
   187c6:   0f b6 e9movzbl %cl,%ebp
   187c9:   e8 62 e5 ff ff  callq  16d30 

// Store returned pointer in RBX

   187ce:   48 89 c3mov%rax,%rbx
   187d1:   e8 da f8 ff ff  callq  180b0 ()@plt>
   187d6:   41 b8 01 00 00 00   mov$0x1,%r8d
   187dc:   89 e9   mov%ebp,%ecx
   187de:   89 c2   mov%eax,%edx
   187e0:   4c 89 f6mov%r14,%rsi

// Call the ctor, pass pointer (this) from RBX

   187e3:   48 89 dfmov%rbx,%rdi
   187e6:   e8 75 e8 ff ff  callq  17060

   187eb:   48 8b 05 a6 36 03 00mov0x336a6(%rip),%rax#
4be98 <_DYNAMIC+0x430>

// Store RBX to memory pointed by R12

   187f2:   49 89 1c 24 mov%rbx,(%r12)
   187f6:   48 83 c0 10 add$0x10,%rax
   187fa:   48 89 03mov%rax,(%rbx)
   187fd:   41 8b 45 00 mov0x0(%r13),%eax
   18801:   89 43 20mov%eax,0x20(%rbx)

// Put address in R12 into return register

   18804:   4c 89 e0mov%r12,%rax
   18807:   5b  pop%rbx
   18808:   5d  pop%rbp
   18809:   41 5c   pop%r12
   1880b:   41 5d   pop%r13
   1880d:   41 5e   pop%r14
   1880f:   c3  retq
   18810:   48 89 c5mov%rax,%rbp
   18813:   48 89 dfmov%rbx,%rdi
   18816:   be 28 00 00 00  mov$0x28,%esi
   1881b:   e8 50 e4 ff ff  callq  16c70 
   18820:   48 89 efmov%rbp,%rdi
   18823:   e8 48 ef ff ff  callq  17770 <_Unwind_Resume@plt>
   18828:   0f 1f 84 00 00 00 00nopl   0x0(%rax,%rax,1)
   1882f:   00

[Bug ipa/68331] [meta-bug] fipa-pta issues

[david.abdurachmanov at gmail dot com]

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

David Abdurachmanov  changed:

   What|Removed |Added

 CC||david.abdurachmanov at gmail 
dot c
   ||om

--- Comment #10 from David Abdurachmanov  
---
I have been reg-testing GCC 6 for the last few weeks and I hit an issue with
compile code straggly segfaulting.

Compiler with GCC 5.3.0, ASan and valgrind shows no issues. Compiled with GCC
6.0.1, ASan and valgrind shows issues, program segfaults. If I go below -O2,
the execution at least does not segfault. Developers so far couldn't understand
whats happening. No issues if compiled with latest Clang or ICC.

I am trying to understand if this is a potential GCC bug and it's worth filling
another BZ ticket. I am trying to reg-test as much as I can before GCC 6.1.0 is
cut. What are your thoughts?

Bisect brought me to this commit as being the culprit:

7ae97ba6651703d99d9f0e20a4e48eb7743c103c is the first bad commit
commit 7ae97ba6651703d99d9f0e20a4e48eb7743c103c
Author: rguenth 
Date:   Thu Dec 10 09:41:08 2015 +

2015-12-10  Richard Biener  

PR ipa/68331
[..]

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

What fails is:

421 std::unique_ptr node =
std::make_unique>(iLabel, value, isTracked);
422 ParameterDescriptionNode* pnode = addNode(std::move(node), isOptional,
writeToCfi);

addNode will segfault std::unique_ptr content is wrong. If one would do
node.get() you get 0x1 trying to access such memory will cause
segfault.

So, I took 7ae97ba6651703d99d9f0e20a4e48eb7743c103c (first bad commit) and
6c2acfc4892316b46df0fe4a6769fb6766ab1e0b (last good) and compared assembly for 
edmtest::ProducerWithPSetDesc::fillDescriptions(edm::ConfigurationDescriptions&).
I found no significant differences, all are offsets. I know that the second
call to edm::ParameterSetDescription::addNode fails.

[..]
  481f5f1:   e8 9a 7d ff ff  callq  17390
(char const (&) [6], int const&, bool, bool, bool)@plt>
  491f5f6:   48 8d 35 d3 f4 01 00lea0x1f4d3(%rip),%rsi#
3ead0 <_fini+0x2a10>
  501f5fd:   48 89 c7mov%rax,%rdi
  511f600:   e8 db 83 ff ff  callq  179e0

  521f605:   48 8d 85 50 fe ff fflea-0x1b0(%rbp),%rax
  531f60c:   48 8d bd 20 d7 ff fflea-0x28e0(%rbp),%rdi
  541f613:   48 8d 35 c9 cb 01 00lea0x1cbc9(%rip),%rsi#
3c1e3 <_fini+0x123>
  551f61a:   31 c9   xor%ecx,%ecx
  561f61c:   c7 85 50 fe ff ff 01movl   $0x8001,-0x1b0(%rbp)
  571f623:   00 00 80
  581f626:   48 89 c2mov%rax,%rdx
  591f629:   48 89 85 98 d0 ff ffmov%rax,-0x2f68(%rbp)
  601f630:   e8 7b 91 ff ff  callq  187b0
 >::__single_object
std::make_unique, char const (&) [16], int
const&, bool&>(char const (&) [16], int const&, bool&) [clone .isra.142] >
  611f635:   48 8b 85 20 d7 ff ffmov-0x28e0(%rbp),%rax
  621f63c:   b9 01 00 00 00  mov$0x1,%ecx
  631f641:   31 d2   xor%edx,%edx
  641f643:   4c 89 f6mov%r14,%rsi
  651f646:   4c 89 ffmov%r15,%rdi
  661f649:   48 89 85 10 ff ff ffmov%rax,-0xf0(%rbp)
  671f650:   e8 9b 77 ff ff  callq  16df0
 >, bool, bool)@plt>
  681f655:   48 8b bd 10 ff ff ffmov-0xf0(%rbp),%rdi
[..]

Before that it calls the cloned function. Pointer becomes wrong after line 66
[%rax,-0xf0(%rbp)]. Then I looked into cloned function between two commits.

This showed some differences:

  3 @@ -19,7 +19,6 @@
  4 48 89 dfmov%rbx,%rdi
  5 e8 75 e8 ff ff  callq  17060 
  7 -   49 89 1c 24 mov%rbx,(%r12)
  8 48 83 c0 10 add$0x10,%rax
  9 48 89 03mov%rax,(%rbx)
 10 41 8b 45 00 mov0x0(%r13),%eax
 11 @@ -34,9 +33,10 @@
 12 48 89 c5mov%rax,%rbp
 13 48 89 dfmov%rbx,%rdi
 14 be 28 00 00 00  mov$0x28,%esi
 15 -   e8 50 e4 ff ff  callq  16c70 
 16 +   e8 54 e4 ff ff  callq  16c70 
 17 48 89 efmov%rbp,%rdi
 18 -   e8 48 ef ff ff  callq  17770 <_Unwind_Resume@plt>
 19 -   0f 1f 84 00 00 00 00nopl   0x0(%rax,%rax,1)
 20 -   00
 21 +   e8 4c ef ff ff  callq  17770 <_Unwind_Resume@plt>
 22 +   66 90   xchg   %ax,%ax
 23 +   66 2e 0f 1f 84 00 00nopw   %cs
 24 +   00 00 00

# ASAN REPORT #

ASAN:DEADLYSIGNAL

[Bug ada/70759] New: Ada rts fails to build with -mabi=ilp32

[sch...@linux-m68k.org]

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

Bug ID: 70759
   Summary: Ada rts fails to build with -mabi=ilp32
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
  Target Milestone: ---
Target: aarch64-*-*

Created attachment 38324
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38324&action=edit
a-assert.s

Trying to build with --with-multilib-list=lp64,ilp32 on aarch64 fails while
building the ada rts for -mabi=ilp32:

/home/abuild/rpmbuild/BUILD/gcc-6.0.0-r234449/obj-aarch64-suse-linux/./gcc/xgcc
-B/home/abuild/rpmbuild/BUILD/gcc-6.0.0-r234449/obj-aarch64-suse-linux/./gcc/
-B/usr/aarch64-suse-linux/bin/ -B/usr/aarch64-suse-linux/lib/ -isystem
/usr/aarch64-suse-linux/include -isystem /usr/aarch64-suse-linux/sys-include   
-c -g -O2 -mabi=ilp32 -fPIC  -W -Wall -gnatpg -nostdinc -mabi=ilp32 
a-assert.adb -o a-assert.o -save-temps
a-assert.s: Assembler messages:
a-assert.s:114: Error: cannot represent BFD_RELOC_64 relocation in this object
file format

This is the offending definition:

.type   ada__assertions__assertion_error, %object
.size   ada__assertions__assertion_error, 8
ada__assertions__assertion_error:
.8byte  system__assertions__assert_failure
.data

[Bug c++/66067] [6 Regression] tree check ICE: accessed elt 1 of tree_vec with 0 elts in write_template_args, at cp/mangle.c:2574

[jason at gcc dot gnu.org]

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

--- Comment #15 from Jason Merrill  ---
(In reply to Victoria from comment #14)
> issue not seen in GCC 5.x branch, is possible to backport the patch?

I don't understand.  If the issue is not seen, why backport?

[Bug c++/70540] [4.9/5/6 Regression] ICE on invalid code in cxx_incomplete_type_diagnostic, at cp/typeck2.c:569

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

Summary|[4.9/5/6/7 Regression] ICE  |[4.9/5/6 Regression] ICE on
   |on invalid code in  |invalid code in
   |cxx_incomplete_type_diagnos |cxx_incomplete_type_diagnos
   |tic, at cp/typeck2.c:569|tic, at cp/typeck2.c:569

--- Comment #7 from Paolo Carlini  ---
Fixed in trunk so far.

[Bug c++/70540] [4.9/5/6/7 Regression] ICE on invalid code in cxx_incomplete_type_diagnostic, at cp/typeck2.c:569

[paolo at gcc dot gnu.org]

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

--- Comment #6 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Thu Apr 21 19:42:34 2016
New Revision: 235348

URL: https://gcc.gnu.org/viewcvs?rev=235348&root=gcc&view=rev
Log:
/cp
2016-04-21  Paolo Carlini  

PR c++/70540
* semantics.c (process_outer_var_ref): Unconditionally return
error_mark_node when mark_used returns false.

/testsuite
2016-04-21  Paolo Carlini  

PR c++/70540
* g++.dg/cpp0x/auto48.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/auto48.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

[Bug c/70742] Support div as a builtin

[marcos.diaz at tallertechnologies dot com]

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

--- Comment #11 from Marcos Diaz  ---
(In reply to Daniel Gutson from comment #10)
> (In reply to Marc Glisse from comment #8)
> > "The div, ldiv, and lldiv functions return a structure of type div_t,
> > ldiv_t, and lldiv_t, respectively, comprising both the quotient and the
> > remainder. The structures shall contain (in either order) the members quot
> > (the quotient) and rem (the remainder), each of which has the same type as
> > the arguments numer and denom."
> > 
> > So while we know the names and types of the fields, we don't know their
> > order (unless stdlib.h was included).
> 
> 
> IIUC, this is a new situation that has never occurred before regarding
> builtins.
> If so, maybe a new mechanism should be developed, that we add a couple of
> offsetof(div_t) sometime during the building of gcc so the offsets are known
> by the builtins. IOW, some kind of script invoked by the build system that
> generates a header file containing the offsets of the members of the
> structure...
> Maybe something like the attachment
> (https://gcc.gnu.org/bugzilla/attachment.cgi?id=38323)
> Then, we include the generated header file (which contains the offsets) from
> the source file that implements the builtin.
> 
> Would this be acceptable? I'm not sure what about the first time when
> bootstrapping, or when building a cross-compiler.

But that way the offsets will remain hard-coded into the compiler, and it won't
will be able to work with another libc or user definition of div_t

[Bug c/70742] Support div as a builtin

[daniel.gutson at tallertechnologies dot com]

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

--- Comment #10 from Daniel Gutson  ---
(In reply to Marc Glisse from comment #8)
> "The div, ldiv, and lldiv functions return a structure of type div_t,
> ldiv_t, and lldiv_t, respectively, comprising both the quotient and the
> remainder. The structures shall contain (in either order) the members quot
> (the quotient) and rem (the remainder), each of which has the same type as
> the arguments numer and denom."
> 
> So while we know the names and types of the fields, we don't know their
> order (unless stdlib.h was included).


IIUC, this is a new situation that has never occurred before regarding
builtins.
If so, maybe a new mechanism should be developed, that we add a couple of
offsetof(div_t) sometime during the building of gcc so the offsets are known by
the builtins. IOW, some kind of script invoked by the build system that
generates a header file containing the offsets of the members of the
structure...
Maybe something like the attachment
(https://gcc.gnu.org/bugzilla/attachment.cgi?id=38323)
Then, we include the generated header file (which contains the offsets) from
the source file that implements the builtin.

Would this be acceptable? I'm not sure what about the first time when
bootstrapping, or when building a cross-compiler.

[Bug c/70742] Support div as a builtin

[daniel.gutson at tallertechnologies dot com]

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

--- Comment #9 from Daniel Gutson  
---
Created attachment 38323
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38323&action=edit
sample script to be called from the build system

[Bug c++/70758] unique_ptr of aligned T calls invalid free

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-04-21
 Ever confirmed|0   |1

--- Comment #2 from Jonathan Wakely  ---
(In reply to Ingo Müller from comment #0)
> To reproduce:
> 1) Install google sparsehash-2.0.3
> (https://github.com/sparsehash/sparsehash/releases).
> 2) Compile and run with valgrind: g++ -std=c++11 uniqueptr.cpp && valgrind
> ./a.out

Please read https://gcc.gnu.org/bugs/#report (as requested when creating the
bug report).

Although I think HJ is probably right about it being a dup.

[Bug libfortran/70684] [4.9/5/6/7 Regression] incorrect reading of values from file on Windows

[jvdelisle at gcc dot gnu.org]

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

--- Comment #13 from Jerry DeLisle  ---
(In reply to Andy May from comment #12)
> I don't know that it's necessary or desired to support both '\n' and '\r' as
> eol, but instead the native eol just needs to be used consistently
> everywhere, for example something like the following pseudo code:
> 
> #ifdef __MINGW32__
> #define EOL '\r'
> #else
> #define EOL '\n'
> #endif
> ...
> dtp->u.p.at_eol = (c == EOL || c == EOF);
> 

Each compiler may choose to do this a little differently.  In our case we see
/r and look for the /n to eat it. If one is interested in reading a /r as data
one should use access="stream" which allows you to do what ever you want.

I could do something like the above, but it would touch quite a few places in
the code which opens it up for mistakes and regressions (admittedly probably
not any more than we get now and we could improve maintainability). Our
personal time is a factor too.  I have bigger bugs to fry and I don't get paid
to do this.  I do it in my spare time for the greater good of all.  Regardless
I do appreciate all input in this process of "open" software. (I should further
audit the code when I get a chance)

[Bug c++/70744] preincrements possibly double-evaluated in GNU ternaries

[donald.chai at synopsys dot com]

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

--- Comment #5 from Donald Chai  ---
For what it's worth, post-increments behave as I would expect:

$ cat test.c
int main() {
int x = 1;
x++ ?: 0xbeef;
return x;
}
$ gcc-5 -x c test.c; ./a.out; echo $?
2
$ gcc-5 -x c++ test.c; ./a.out; echo $?
2

[Bug c++/70758] unique_ptr of aligned T calls invalid free

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  ---
I think this is a dup of PR 36159.

[Bug libfortran/70684] [4.9/5/6/7 Regression] incorrect reading of values from file on Windows

[ajmay81 at googlemail dot com]

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

--- Comment #12 from Andy May  ---
I don't know that it's necessary or desired to support both '\n' and '\r' as
eol, but instead the native eol just needs to be used consistently everywhere,
for example something like the following pseudo code:

#ifdef __MINGW32__
#define EOL '\r'
#else
#define EOL '\n'
#endif
...
dtp->u.p.at_eol = (c == EOL || c == EOF);

As mentioned in this ifort thread:

https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/268116

you might really want to read the 'wrong' eol as data.

If one wants to move a file generated on one OS to another there are tools
already existing to change the line endings.

[Bug c/70756] Wrong column number shown for "error: invalid use of flexible array member"

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-21
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug c++/70744] preincrements possibly double-evaluated in GNU ternaries

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
A possible fix seems to be
--- a/gcc/tree.c
+++ b/gcc/tree.c
@@ -4255,6 +4255,12 @@ stabilize_reference (tree ref)
 volatiles.  */
   return stabilize_reference_1 (ref);

+case POSTDECREMENT_EXPR:
+case POSTINCREMENT_EXPR:
+case PREDECREMENT_EXPR:
+case PREINCREMENT_EXPR:
+  return stabilize_reference_1 (ref);
+
   /* If arg isn't a kind of lvalue we recognize, make no change.
 Caller should recognize the error for an invalid lvalue.  */
 default:

but not sure if these belong into stabilize_reference ...

[Bug target/70750] [6/7 Regression] Load and call no longer combined for indirect calls on x86

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  ---
Created attachment 38322
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38322&action=edit
A patch

[Bug c++/70758] New: unique_ptr of aligned T calls invalid free

[2013.bugzilla.gcc.gnu.org at ingomueller dot net]

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

Bug ID: 70758
   Summary: unique_ptr of aligned T calls invalid free
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 2013.bugzilla.gcc.gnu.org at ingomueller dot net
  Target Milestone: ---

Created attachment 38321
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38321&action=edit
Example c++ program that produces the invalid free.

In a certain situation, the default delete of a unique_ptr calls an
invalid free.

The situation occurs for a struct that as an __attributed__ ((aligned(x))) with
a google dense_hash_map as a member. I haven't been able to figure out what is
special about the dense_hash_map yet. A short version of the code that produces
the bug (full version is attached):

typedef google::dense_hash_map HmType;

typedef struct C {
HmType hm;
} C __attribute__ ((aligned(64)));

int main(int,char**)
{
std::unique_ptr cx( new C[100] );
}

The free called by delete [] called by the deleter of the unique pointer is
invalid: valgrind says it is "56 bytes inside a block of size 8,064 alloc'd".

To reproduce:
1) Install google sparsehash-2.0.3
(https://github.com/sparsehash/sparsehash/releases).
2) Compile and run with valgrind: g++ -std=c++11 uniqueptr.cpp && valgrind
./a.out

Relevant output:
==7631== Invalid free() / delete / delete[] / realloc()
==7631==at 0x4C2A8E0: operator delete[](void*) (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7631==by 0x401D3D: std::default_delete::operator()(C*) const (in
/tmp/a.out)
==7631==by 0x4018B4: std::unique_ptr
>::~unique_ptr() (in /tmp/a.out)
==7631==by 0x400D10: main (in /tmp/a.out)
==7631==  Address 0x5a07fd8 is 56 bytes inside a block of size 8,064 alloc'd
==7631==at 0x4C298A0: operator new[](unsigned long) (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7631==by 0x400CBB: main (in /tmp/a.out)

Other remark: g++ warns that it ignores attributes on C of the unique_ptr,
but doesn't warn on unique_ptr. Maybe it should ignore the alignment for
the array as well, but doesn't?

[Bug libfortran/70684] [4.9/5/6/7 Regression] incorrect reading of values from file on Windows

[mingw.android at gmail dot com]

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

--- Comment #11 from Ray Donnelly  ---
I wonder if opening the files in text mode on Windows would be
possible? I don't know a lot about fortran at present, but doing that
would cause Windows to dump the \r's for you.

On Thu, Apr 21, 2016 at 5:30 PM, jvdelisle at gcc dot gnu.org
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70684
>
> --- Comment #10 from Jerry DeLisle  ---
> (In reply to Ray Donnelly from comment #9)
>> Should the other two places - next_char_default () and next_char_internal ()
>> -that also do:
>>
>> dtp->u.p.at_eol = (c == '\n' || c == EOF);
>>
>> not check for '\r' too?
>
> Placing it in next_char_default gives us a regression elsewhere.  I am 
> actually
> checking to see if after my patch whether the line above is even needed in
> next_char_default.  There are a lot of subtle interactions that go into this
> code, so i tread lightly.
>
> I will not close this until I have the initial patch back ported and have done
> some more testing and others have had time to do more testing.  If you happen
> to find a use case that fails, of course, let me know, and thanks.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug target/70750] [6/7 Regression] Load and call no longer combined for indirect calls on x86

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
r231923 has

 (define_special_predicate "call_insn_operand"
   (ior (match_test "constant_call_address_operand
 (op, mode == VOIDmode ? mode : Pmode)")
(match_operand 0 "call_register_no_elim_operand")
-   (and (not (match_test "TARGET_X32"))
-   (match_operand 0 "memory_operand"
+   (ior (and (not (match_test "TARGET_X32"))
+(match_operand 0 "sibcall_memory_operand"))
    A typo.
+   (and (match_test "TARGET_X32 && Pmode == DImode")
+(match_operand 0 "GOT_memory_operand")


I am testing

diff --git a/gcc/config/i386/predicates.md b/gcc/config/i386/predicates.md
index 14e80d9..93dda7b 100644
--- a/gcc/config/i386/predicates.md
+++ b/gcc/config/i386/predicates.md
@@ -637,7 +637,7 @@
   (op, mode == VOIDmode ? mode : Pmode)")
(match_operand 0 "call_register_no_elim_operand")
(ior (and (not (match_test "TARGET_X32"))
-  (match_operand 0 "sibcall_memory_operand"))
+  (match_operand 0 "memory_operand"))
   (and (match_test "TARGET_X32 && Pmode == DImode")
   (match_operand 0 "GOT_memory_operand")

[Bug plugins/70757] New: Add plugin callbacks that run early enough to check for declarations using "bad" names

[redi at gcc dot gnu.org]

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

Bug ID: 70757
   Summary: Add plugin callbacks that run early enough to check
for declarations using "bad" names
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: plugins
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

I once tried to write a gcc plugin to check that libstdc++ was not defining any
non-standard names outside the reserved namespace, but quickly realised that
the plugin callbacks all happen too late, so that uninstantiated templates are
never seen by the plugin.

I also wanted it to check for the list of identifiers that are in the reserved
namespace, but need to be avoided in libstdc++ for other reasons, as
documetented at
https://gcc.gnu.org/onlinedocs/libstdc++/manual/source_code_style.html#coding_style.bad_identifiers

I would like a callback in the front-end so that names of decls could be
checked, and ideally the same thing during preprocessing so that macros can
also be checked.

This would help avoid/find bugs like PR 70727 and PR 64135, and would also
allow users to write the opposite plugin, to check that user code doesn't
define anything using reserved names, solving PR 51437.

See also https://gcc.gnu.org/ml/gcc/2016-04/msg00200.html

[Bug c/70756] New: Wrong column number shown for "error: invalid use of flexible array member"

[ch3root at openwall dot com]

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

Bug ID: 70756
   Summary: Wrong column number shown for "error: invalid use of
flexible array member"
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ch3root at openwall dot com
  Target Milestone: ---

When compiling this program:

int main()
{
  struct {
int x;
int y[];
  } s;

  12345 && &s.y + 1;
}

I get the following error message:

$ gcc example.c 
example.c: In function ‘main’:
example.c:8:3: error: invalid use of flexible array member
   12345 && &s.y + 1;
   ^

The column number is wrong.

[Bug c++/70513] [4.9/5/6 Regression] ICE on invalid C++ code on x86_64-linux-gnu: Segmentation fault

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
Summary|[4.9/5/6/7 Regression] ICE  |[4.9/5/6 Regression] ICE on
   |on invalid C++ code on  |invalid C++ code on
   |x86_64-linux-gnu:   |x86_64-linux-gnu:
   |Segmentation fault  |Segmentation fault

--- Comment #7 from Marek Polacek  ---
Fixed for GCC 7.  Not really planning to backport it.

[Bug c++/70513] [4.9/5/6/7 Regression] ICE on invalid C++ code on x86_64-linux-gnu: Segmentation fault

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
Author: mpolacek
Date: Thu Apr 21 16:52:51 2016
New Revision: 235347

URL: https://gcc.gnu.org/viewcvs?rev=235347&root=gcc&view=rev
Log:
PR c++/70513
* parser.c (cp_parser_enum_specifier): Check and possibly error for
extra qualification.

* g++.dg/cpp0x/forw_enum12.C: New test.
* g++.dg/cpp0x/forw_enum13.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/forw_enum12.C
trunk/gcc/testsuite/g++.dg/cpp0x/forw_enum13.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug target/70750] [6/7 Regression] Load and call no longer combined for indirect calls on x86

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-21
 CC||hjl.tools at gmail dot com,
   ||ubizjak at gmail dot com
 Ever confirmed|0   |1

--- Comment #2 from H.J. Lu  ---
It is very likely caused by r231923.

[Bug c++/70744] preincrements possibly double-evaluated in GNU ternaries

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
So build_conditional_expr_1 has

 4626   /* As a G++ extension, the second argument to the conditional can be
 4627  omitted.  (So that `a ? : c' is roughly equivalent to `a ? a :
 4628  c'.)  If the second operand is omitted, make sure it is
 4629  calculated only once.  */
 4630   if (!arg2)
 4631 {
 ...
 4636   /* Make sure that lvalues remain lvalues.  See g++.oliva/ext1.C. 
*/
 4637   if (real_lvalue_p (arg1))
 4638 arg2 = arg1 = stabilize_reference (arg1);
 4639   else
 4640 arg2 = arg1 = save_expr (arg1);
 4641 }

for preincrement_expr is real_lvalue_p true, so we go to stabilize_reference,
that should ensure that we can use the expr more times without causing its
operands to be evaluated more than once, but it doesn't know
{PRE,POST}{INCR,DECR}EMENT so does nothing:
 4258   /* If arg isn't a kind of lvalue we recognize, make no change.
 4259  Caller should recognize the error for an invalid lvalue.  */
 4260 default:
 4261   return ref;

[Bug tree-optimization/69489] missed vectorization for boolean loop, missed if-conversion

[jtaylor.debian at googlemail dot com]

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

--- Comment #14 from Julian Taylor  ---
I am on x86_64. It actually does vectorize with -mavx but not with -msse2.
The other variant of the loop I posted does vectorize with sse2.


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


$ cat test.c

double
yule_bool_distance_char2(const char *u, const char *v, long n)
{
long i;
long ntt = 0l, nff = 0l, nft = 0l, ntf = 0l;

for (i = 0l; i < n; i++) {
ntf += (u[i] && !v[i]);
nft += (!u[i] && v[i]);
}   
return (2.0 * ntf * nft);
}


$ gcc -O2 -ftree-vectorize test.c -c
#same with O3
$ objdump -d test.o

test.o: file format elf64-x86-64


Disassembly of section .text:

 :
   0:   48 85 d2test   %rdx,%rdx
   3:   7e 69   jle6e 
   5:   55  push   %rbp
   6:   53  push   %rbx
   7:   45 31 d2xor%r10d,%r10d
   a:   45 31 dbxor%r11d,%r11d
   d:   31 c0   xor%eax,%eax
   f:   31 ed   xor%ebp,%ebp
  11:   0f 1f 80 00 00 00 00nopl   0x0(%rax)
  18:   44 0f b6 0c 06  movzbl (%rsi,%rax,1),%r9d
  1d:   44 0f b6 04 07  movzbl (%rdi,%rax,1),%r8d
  22:   45 84 c9test   %r9b,%r9b
  25:   0f 94 c3sete   %bl
  28:   31 c9   xor%ecx,%ecx
  2a:   45 84 c0test   %r8b,%r8b
  2d:   0f 95 c1setne  %cl
  30:   48 21 d9and%rbx,%rcx
  33:   49 01 caadd%rcx,%r10
  36:   31 c9   xor%ecx,%ecx
  38:   45 84 c9test   %r9b,%r9b
  3b:   0f 95 c1setne  %cl
  3e:   45 84 c0test   %r8b,%r8b
  41:   48 0f 45 cd cmovne %rbp,%rcx
  45:   48 83 c0 01 add$0x1,%rax
  49:   49 01 cbadd%rcx,%r11
  4c:   48 39 c2cmp%rax,%rdx
  4f:   75 c7   jne18 
  51:   66 0f ef c0 pxor   %xmm0,%xmm0
  55:   66 0f ef c9 pxor   %xmm1,%xmm1
  59:   5b  pop%rbx
  5a:   f2 49 0f 2a c2  cvtsi2sd %r10,%xmm0
  5f:   f2 49 0f 2a cb  cvtsi2sd %r11,%xmm1
  64:   5d  pop%rbp
  65:   f2 0f 58 c0 addsd  %xmm0,%xmm0
  69:   f2 0f 59 c1 mulsd  %xmm1,%xmm0
  6d:   c3  retq   
  6e:   66 0f ef c0 pxor   %xmm0,%xmm0
  72:   c3  retq

[Bug c++/70755] New: [ARM] excessive struct alignment for globals

[bruck.michael at googlemail dot com]

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

Bug ID: 70755
   Summary: [ARM] excessive struct alignment for globals
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bruck.michael at googlemail dot com
  Target Milestone: ---

Discussion at the end

$ arm-none-eabi-g++.exe -std=c++11 -Ofast -c align_foo.cpp -S -fdata-sections

$ cat align_foo.cpp

struct S
{
bool val;
};

S s1;   // 32 bit align
alignas(S) S s2;// 8 bit align

struct alignas(bool) SA
{
bool val;
};

struct alignas(long long) SB
{
bool val;
};

SA sa;  // 32 bit align
SB sb;  // 64 bit align


$ cat align_foo.s
.cpu arm7tdmi
.fpu softvfp
.eabi_attribute 23, 1
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 1
.eabi_attribute 30, 2
.eabi_attribute 34, 0
.eabi_attribute 18, 4
.arm
.syntax divided
.file   "align_foo.cpp"
.global sb
.global sa
.global s2
.global s1
.section.bss.s1,"aw",%nobits
.align  2
.type   s1, %object
.size   s1, 1
s1:
.space  1
.section.bss.s2,"aw",%nobits
.type   s2, %object
.size   s2, 1
s2:
.space  1
.section.bss.sa,"aw",%nobits
.align  2
.type   sa, %object
.size   sa, 1
sa:
.space  1
.section.bss.sb,"aw",%nobits
.align  3
.type   sb, %object
.size   sb, 8
sb:
.space  8
.ident  "GCC: (GNU Tools for ARM Embedded Processors) 5.3.1 20160307
(release) [ARM/embedded-5-branch revision 234589]"

---

The code comments show how the respective variable was aligned in the assembly
output.

a) s1 should be byte aligned.

b) alignas works around the problem but only for s2 but not SA. Even though the
compiler clearly accepts the alignment increase for SB.

c) sb blocks 8 bytes, rather then just being 8 byte aligned


"-fdata-sections" is for clarity, without it we get basically the same,
although for sa the alignment could be unintentional:

...

.bss
.align  3
.type   sb, %object
.size   sb, 8
sb:
.space  8
.type   sa, %object
.size   sa, 1
sa:
.space  1
.type   s2, %object
.size   s2, 1
s2:
.space  1
.space  2
.type   s1, %object
.size   s1, 1
s1:
.space  1

[Bug libfortran/70684] [4.9/5/6/7 Regression] incorrect reading of values from file on Windows

[jvdelisle at gcc dot gnu.org]

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

--- Comment #10 from Jerry DeLisle  ---
(In reply to Ray Donnelly from comment #9)
> Should the other two places - next_char_default () and next_char_internal ()
> -that also do:
> 
> dtp->u.p.at_eol = (c == '\n' || c == EOF);
> 
> not check for '\r' too?

Placing it in next_char_default gives us a regression elsewhere.  I am actually
checking to see if after my patch whether the line above is even needed in
next_char_default.  There are a lot of subtle interactions that go into this
code, so i tread lightly.

I will not close this until I have the initial patch back ported and have done
some more testing and others have had time to do more testing.  If you happen
to find a use case that fails, of course, let me know, and thanks.

[Bug tree-optimization/69489] missed vectorization for boolean loop, missed if-conversion

[amker at gcc dot gnu.org]

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

--- Comment #13 from amker at gcc dot gnu.org ---
(In reply to Julian Taylor from comment #12)
> the testcase in this ticket is not yet vectorized with gcc 20160421 (r235341)

Hi Julian, may I ask which target?  It can be vectorized on x86_64 and AArch64
now.  Thanks.

[Bug tree-optimization/70754] [5/6 Regression] ICE during predictive commoning

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Target||aarch64-unknown-linux-gnu
 Status|UNCONFIRMED |NEW
  Known to work||4.9.4
   Keywords||ice-on-valid-code
   Last reconfirmed||2016-04-21
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|ICE during predictive   |[5/6 Regression] ICE during
   |commoning   |predictive commoning
  Known to fail||5.3.1, 6.0, 7.0

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed with GCC 5 and onwards.
I don't see this ICE on arm-none-linux-gnueabihf or x86_64

[Bug tree-optimization/70754] New: ICE during predictive commoning

[vp at gcc dot gnu.org]

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

Bug ID: 70754
   Summary: ICE during predictive commoning
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vp at gcc dot gnu.org
  Target Milestone: ---

The following fortran testcase (reduced from a large program) at -Ofast causes 
an ICE for aarch64-none-linux-gnu during predictive commoning. This is
reproducible with version 5.3, 6 and trunk.

$ cat y.f90
module m
  implicit none
  private
  save

  integer, parameter, public :: &
ii4  = selected_int_kind(6), &
rr8  = selected_real_kind(13)

  integer (ii4), dimension(40,40,199), public :: xyz
  public :: foo
contains
  subroutine foo(a)
real (rr8), dimension(40,40), intent(out) :: a
real (rr8), dimension(40,40) :: b
integer (ii4), dimension(40,40) :: c
integer  i, j

do i=1,20
  b(i,j) = 123 * a(i,j) + 34 * a(i,j+1) &
 + 34 * a(i,j-1) + a(i+1,j+1) &
 + a(i+1,j-1) + a(i-1,j+1) &
 + a(i-1,j-1)
  c(i,j) = 123
end do

where ((xyz(:,:,2) /= 0) .and. (c /= 0))
  a = b/real(c)
elsewhere
  a = 456
endwhere
 end subroutine foo
end module m


$ gfortran -v -c -Ofast y.f90
Using built-in specs.
COLLECT_GCC=gfortran
Target: aarch64-none-linux-gnu
Configured with: /tmp/native-aarch64-none-linux-gnu/build/src/gcc/configure
--disable-bootstrap
--with-isl=/tmp/native-aarch64-none-linux-gnu/build/build-native-aarch64-none-linux-gnu/host-tools
--with-cloog=/tmp/native-aarch64-none-linux-gnu/build/build-native-aarch64-none-linux-gnu/host-tools
--with-build-sysroot=/tmp/native-aarch64-none-linux-gnu/build/build-native-aarch64-none-linux-gnu/install/glibc
--build=aarch64-none-linux-gnu --host=aarch64-none-linux-gnu
--target=aarch64-none-linux-gnu --prefix=/ --enable-languages=c,c++,fortran
--enable-plugin
--with-gmp=/tmp/native-aarch64-none-linux-gnu/build/build-native-aarch64-none-linux-gnu/host-tools
--with-mpfr=/tmp/native-aarch64-none-linux-gnu/build/build-native-aarch64-none-linux-gnu/host-tools
--with-mpc=/tmp/native-aarch64-none-linux-gnu/build/build-native-aarch64-none-linux-gnu/host-tools
--with-gnu-ld --with-plugin-ld=ld --disable-libsanitizer --disable-werror
Thread model: posix
gcc version 5.3.1 20160415 
COLLECT_GCC_OPTIONS='-v' '-c' '-Ofast' '-mlittle-endian' '-mabi=lp64'
 /usr/bin/../libexec/gcc/aarch64-none-linux-gnu/5.3.1/f951 y.f90 -quiet
-dumpbase y.f90 -mlittle-endian -mabi=lp64 -auxbase y -Ofast -version
-fintrinsic-modules-path
/usr/bin/../lib/gcc/aarch64-none-linux-gnu/5.3.1/finclude -o /tmp/ccIYeMBK.s
GNU Fortran version 5.3.1 20160415 (aarch64-none-linux-gnu)
compiled by GNU C version 4.8.4, GMP version 4.3.2, MPFR version 3.0.0,
MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2008 version 5.3.1 20160415 (aarch64-none-linux-gnu)
compiled by GNU C version 4.8.4, GMP version 4.3.2, MPFR version 3.0.0,
MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
y.f90:13:0:

   subroutine foo(a)
 ^ 
internal compiler error: 291) version 5.oot_vars, at tree-predcom.c:1495
0xa8dae3 initialize_root_vars 
   
/tmp/native-aarch64-none-linux-gnu/build/src/gcc/gcc/tree-predcom.c:1495
0xa8dae3 initialize_root
   
/tmp/native-aarch64-none-linux-gnu/build/src/gcc/gcc/tree-predcom.c:1542
0xa8dae3 execute_pred_commoning_chain
   
/tmp/native-aarch64-none-linux-gnu/build/src/gcc/gcc/tree-predcom.c:1756
0xa8dae3 execute_pred_commoning
   
/tmp/native-aarch64-none-linux-gnu/build/src/gcc/gcc/tree-predcom.c:1822
0xa8f583 tree_predictive_commoning_loop
   
/tmp/native-aarch64-none-linux-gnu/build/src/gcc/gcc/tree-predcom.c:2585
0xa90b63 tree_predictive_commoning()
   
/tmp/native-aarch64-none-linux-gnu/build/src/gcc/gcc/tree-predcom.c:2612
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/69489] missed vectorization for boolean loop, missed if-conversion

[jtaylor.debian at googlemail dot com]

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

--- Comment #12 from Julian Taylor  ---
the testcase in this ticket is not yet vectorized with gcc 20160421 (r235341)

[Bug target/70728] GCC trunk emits invalid assembly for knl target

[kyukhin at gcc dot gnu.org]

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

--- Comment #3 from Kirill Yukhin  ---
Author: kyukhin
Date: Thu Apr 21 15:29:29 2016
New Revision: 235344

URL: https://gcc.gnu.org/viewcvs?rev=235344&root=gcc&view=rev
Log:
AVX-512. PR target/70728. Use separate constraint for AVX-512BW


PR target/70728
gcc/
* gcc/config/i386/sse.md (define_insn
"3"):
Extract AVX-512BW constraint from AVX.
gcc/testsuite/
* gcc.target/i386/pr70728.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr70728.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog

[Bug c++/70744] preincrements possibly double-evaluated in GNU ternaries

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
That must be missing SAVE_EXPR.  I'll have a look.

[Bug c++/70522] Hidden friend functions block qualified name lookup into nested unnamed namespace

[Casey at Carter dot net]

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

Casey Carter  changed:

   What|Removed |Added

 CC||Casey at Carter dot net

--- Comment #2 from Casey Carter  ---
This is a regression of sorts, FWIW, gcc 4.3 compiled it correctly
(http://melpon.org/wandbox/permlink/Efjfvay0U5sZvZP8) back in the day. I assume
that's not quite "regressive" enough for the 6 branch?

[Bug tree-optimization/69489] missed vectorization for boolean loop, missed if-conversion

[sch...@linux-m68k.org]

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

--- Comment #11 from Andreas Schwab  ---
> Isn't that what was reported in PR70725 for its fix?  Does r235341 fix it?

Yes and yes, but r235252 didn't trigger it.

[Bug bootstrap/70704] [6 Regression] AIX bootstrap comparison failure

[dje at gcc dot gnu.org]

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

--- Comment #36 from David Edelsohn  ---
It definitely is Flex.  gcc-6-branch r235040 and r235340 fail when built with
Flex 2.6.0.  gcc-6.0.1-RC-20160415 fails using the supplied gengtype-lex.c
created with Flex 2.5.37.

[Bug tree-optimization/69489] missed vectorization for boolean loop, missed if-conversion

[amker at gcc dot gnu.org]

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

--- Comment #10 from amker at gcc dot gnu.org ---
(In reply to Andreas Schwab from comment #7)
> The second commit triggers this ICE on ia64:
> 
> $ gcc/xgcc -Bgcc/ ../../gcc/gcc/testsuite/gcc.dg/pr70725.c -O3 -S
> ../../gcc/gcc/testsuite/gcc.dg/pr70725.c: In function ‘fn1’:
> ../../gcc/gcc/testsuite/gcc.dg/pr70725.c:13:1: internal compiler error: in
> phi_convertible_by_degenerating_args, at tree-if-conv.c:605
>  fn1 ()
>  ^~~
> 0x41c26b3f phi_convertible_by_degenerating_args
> ../../gcc/tree-if-conv.c:605
> 0x41c2727f if_convertible_phi_p
> ../../gcc/tree-if-conv.c:662
> 0x41c3675f if_convertible_loop_p_1
> ../../gcc/tree-if-conv.c:1408
> 0x41c3700f if_convertible_loop_p
> ../../gcc/tree-if-conv.c:1466
> 0x41c374cf tree_if_conversion
> ../../gcc/tree-if-conv.c:2774
> 0x41c37d9f execute
> ../../gcc/tree-if-conv.c:2875

(In reply to rguent...@suse.de from comment #9)
> On Thu, 21 Apr 2016, sch...@linux-m68k.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69489
> > 
> > --- Comment #7 from Andreas Schwab  ---
> > The second commit triggers this ICE on ia64:
> > 
> > $ gcc/xgcc -Bgcc/ ../../gcc/gcc/testsuite/gcc.dg/pr70725.c -O3 -S
> > ../../gcc/gcc/testsuite/gcc.dg/pr70725.c: In function ‘fn1’:
> > ../../gcc/gcc/testsuite/gcc.dg/pr70725.c:13:1: internal compiler error: in
> > phi_convertible_by_degenerating_args, at tree-if-conv.c:605
> >  fn1 ()
> >  ^~~
> > 0x41c26b3f phi_convertible_by_degenerating_args
> > ../../gcc/tree-if-conv.c:605
> > 0x41c2727f if_convertible_phi_p
> > ../../gcc/tree-if-conv.c:662
> > 0x41c3675f if_convertible_loop_p_1
> > ../../gcc/tree-if-conv.c:1408
> > 0x41c3700f if_convertible_loop_p
> > ../../gcc/tree-if-conv.c:1466
> > 0x41c374cf tree_if_conversion
> > ../../gcc/tree-if-conv.c:2774
> > 0x41c37d9f execute
> > ../../gcc/tree-if-conv.c:2875
> 
> Isn't that what was reported in PR70725 for its fix?  Does r235341 fix it?

I will check this.  Also I have a following patch handling general cases in
which PHIs can be degenerated and have more than one arguments.

[Bug tree-optimization/69489] missed vectorization for boolean loop, missed if-conversion

[sch...@linux-m68k.org]

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

--- Comment #8 from Andreas Schwab  ---
The same ICE also occurs on m68k and aarch64.

[Bug c/70753] missing diagnostic in C11 mode: sizeof, _Alignof of function type

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
But you get the warning with -Wpedantic, right?

[Bug c/70753] missing diagnostic in C11 mode: sizeof, _Alignof of function type

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Why would it have to be error?  If you want errors instead of warnings, use
-pedantic-errors.

[Bug c/70753] missing diagnostic in C11 mode: sizeof, _Alignof of function type

[fw at gcc dot gnu.org]

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

--- Comment #2 from Florian Weimer  ---
(In reply to Marek Polacek from comment #1)
> Why would it have to be error?  If you want errors instead of warnings, use
> -pedantic-errors.

I did not know about -pedantic-errors.  It is extremely surprising that
-std=c11 does not enable all diagnostics required by C11.

[Bug tree-optimization/69489] missed vectorization for boolean loop, missed if-conversion

[rguenther at suse dot de]

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

--- Comment #9 from rguenther at suse dot de  ---
On Thu, 21 Apr 2016, sch...@linux-m68k.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69489
> 
> --- Comment #7 from Andreas Schwab  ---
> The second commit triggers this ICE on ia64:
> 
> $ gcc/xgcc -Bgcc/ ../../gcc/gcc/testsuite/gcc.dg/pr70725.c -O3 -S
> ../../gcc/gcc/testsuite/gcc.dg/pr70725.c: In function ‘fn1’:
> ../../gcc/gcc/testsuite/gcc.dg/pr70725.c:13:1: internal compiler error: in
> phi_convertible_by_degenerating_args, at tree-if-conv.c:605
>  fn1 ()
>  ^~~
> 0x41c26b3f phi_convertible_by_degenerating_args
> ../../gcc/tree-if-conv.c:605
> 0x41c2727f if_convertible_phi_p
> ../../gcc/tree-if-conv.c:662
> 0x41c3675f if_convertible_loop_p_1
> ../../gcc/tree-if-conv.c:1408
> 0x41c3700f if_convertible_loop_p
> ../../gcc/tree-if-conv.c:1466
> 0x41c374cf tree_if_conversion
> ../../gcc/tree-if-conv.c:2774
> 0x41c37d9f execute
> ../../gcc/tree-if-conv.c:2875

Isn't that what was reported in PR70725 for its fix?  Does r235341 fix it?

[Bug tree-optimization/69489] missed vectorization for boolean loop, missed if-conversion

[sch...@linux-m68k.org]

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

--- Comment #7 from Andreas Schwab  ---
The second commit triggers this ICE on ia64:

$ gcc/xgcc -Bgcc/ ../../gcc/gcc/testsuite/gcc.dg/pr70725.c -O3 -S
../../gcc/gcc/testsuite/gcc.dg/pr70725.c: In function ‘fn1’:
../../gcc/gcc/testsuite/gcc.dg/pr70725.c:13:1: internal compiler error: in
phi_convertible_by_degenerating_args, at tree-if-conv.c:605
 fn1 ()
 ^~~
0x41c26b3f phi_convertible_by_degenerating_args
../../gcc/tree-if-conv.c:605
0x41c2727f if_convertible_phi_p
../../gcc/tree-if-conv.c:662
0x41c3675f if_convertible_loop_p_1
../../gcc/tree-if-conv.c:1408
0x41c3700f if_convertible_loop_p
../../gcc/tree-if-conv.c:1466
0x41c374cf tree_if_conversion
../../gcc/tree-if-conv.c:2774
0x41c37d9f execute
../../gcc/tree-if-conv.c:2875

[Bug c/70753] New: missing diagnostic in C11 mode: sizeof, _Alignof of function type

[fw at gcc dot gnu.org]

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

Bug ID: 70753
   Summary: missing diagnostic in C11 mode: sizeof, _Alignof of
function type
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fw at gcc dot gnu.org
  Target Milestone: ---

GCC accepts this code, but sizeof of a function type is invalid in C11 (and
likely earlier).  It is a documented extension for GNU mode, but it is also
accepted with -std=c11.

#include 

int
f (int a, int b)
{
  return a + b;
}

int
main (void)
{
  printf ("%zu\n", sizeof (*f));
  printf ("%zu\n", _Alignof (*f));
  return 0;
}

The pedantic warning should be an error in C11 mode.

[Bug bootstrap/70704] [6 Regression] AIX bootstrap comparison failure

[dje at gcc dot gnu.org]

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

--- Comment #35 from David Edelsohn  ---
Flex 2.6.0 works with --enable-checking=yes, but may not work with
--enable-checking=release.  I believe that Flex may be the culprit.  If the
current bootstrap confirms that, I am going to bootstrap with gengtype-lex.c
compiled with -fsigned-char.

[Bug tree-optimization/70725] Internal compiler error (ICE) on valid code

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
Author: rguenth
Date: Thu Apr 21 14:09:33 2016
New Revision: 235341

URL: https://gcc.gnu.org/viewcvs?rev=235341&root=gcc&view=rev
Log:
2016-04-21  Richard Biener  

PR tree-optimization/70725
* tree-if-conv.c (if_convertible_phi_p): Adjust guard
for phi_convertible_by_degenerating_args.
(predicate_all_scalar_phis): Handle single-argument PHIs.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-if-conv.c

[Bug fortran/70752] Incorrect LEN for ALLOCATABLE CHARACTER

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-21
 Blocks||68241
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.9 up to trunk (7.0). Note LEN(S%C(1)) returns 3, so apparently
the elements of S%C have their length set, but not S%C itself.

>  Why does the pointer assignment fail

The length of S%C is zero and not 3 as expected by the assignment. The fact
that the code executes without bounds check does not mean that the executable
is correct.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241
[Bug 68241] [meta-bug] Deferred-length character

[Bug bootstrap/70704] [6 Regression] AIX bootstrap comparison failure

[dje at gcc dot gnu.org]

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

--- Comment #34 from David Edelsohn  ---
The tarball contains LAST_UPDATED, although different contents.

I previously copied gcc/REVISION from svn checkout to the RC (which is
referenced by Makefile). That showed no difference.

[Bug bootstrap/70704] [6 Regression] AIX bootstrap comparison failure

[dje at gcc dot gnu.org]

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

--- Comment #33 from David Edelsohn  ---
I'm completely confused as well.  The bits seem to be identical.  The only
other obvious difference is ordering of timestamps of the source files that
would cause Make to build files in a different order.

[Bug bootstrap/70704] [6 Regression] AIX bootstrap comparison failure

[jakub at gcc dot gnu.org]

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

--- Comment #32 from Jakub Jelinek  ---
But if gengtype-lex.c is not it, what it is then?  I can't see how the
generated man pages or *.html files or *.gmo or *.info files could affect it,
so is the pathname?  If you check out r235040 into the same directory as you
tested the tarball in, does that work?  Or is it the LAST_UPDATED file missing
in the rc tarball?

[Bug bootstrap/70704] [6 Regression] AIX bootstrap comparison failure

[dje at gcc dot gnu.org]

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

--- Comment #31 from David Edelsohn  ---
I will test, but Flex and gengtype-lex.c does not appear to be the issue.  If
the change works, it will be coincidental.

I have built the RC with gengtype-lex.c removed so that it is regenerated with
the system Flex -- it still fails.

I have build gcc-6-branch r235040 with gengtype-lex.c from the RC -- it works.

[Bug sanitizer/70624] [6/7 Regression] Several hundred asan failures with 6.0 on x86_64-apple-darwin10.8

[chefmax at gcc dot gnu.org]

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

--- Comment #11 from chefmax at gcc dot gnu.org ---
Author: chefmax
Date: Thu Apr 21 12:19:54 2016
New Revision: 235338

URL: https://gcc.gnu.org/viewcvs?rev=235338&root=gcc&view=rev
Log:
Cherry-pick r266868 from upstream.

PR sanitizer/70624  
* asan/asan_mac.cc: Cherry pick upstream r266868.

Modified:
trunk/libsanitizer/ChangeLog
trunk/libsanitizer/asan/asan_mac.cc

[Bug sanitizer/70624] [6/7 Regression] Several hundred asan failures with 6.0 on x86_64-apple-darwin10.8

[chefmax at gcc dot gnu.org]

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

--- Comment #10 from chefmax at gcc dot gnu.org ---
Author: chefmax
Date: Thu Apr 21 12:12:53 2016
New Revision: 235337

URL: https://gcc.gnu.org/viewcvs?rev=235337&root=gcc&view=rev
Log:
Cherry-pick r266868 from upstream.

PR sanitizer/70624
* asan/asan_mac.cc: Cherry pick upstream r266868.

Modified:
branches/gcc-6-branch/libsanitizer/ChangeLog
branches/gcc-6-branch/libsanitizer/asan/asan_mac.cc

[Bug target/70728] GCC trunk emits invalid assembly for knl target

[kyukhin at gcc dot gnu.org]

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

--- Comment #2 from Kirill Yukhin  ---
This is a 5/6 regression

[Bug fortran/70752] New: Incorrect LEN for ALLOCATABLE CHARACTER

[gilbert.scott at easynet dot co.uk]

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

Bug ID: 70752
   Summary: Incorrect LEN for ALLOCATABLE CHARACTER
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gilbert.scott at easynet dot co.uk
  Target Milestone: ---

$ gfortran --version
GNU Fortran (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6)

$ cat test.f95

PROGRAM TEST
IMPLICIT NONE
INTEGER, PARAMETER :: I = 3
TYPE T
   CHARACTER(LEN=:), ALLOCATABLE :: C(:)
END TYPE T
TYPE(T), TARGET :: S
CHARACTER (LEN=I), POINTER :: P(:)

ALLOCATE ( CHARACTER(LEN=I) :: S%C(5) )
PRINT *, 'SIZE(S%C) = ',SIZE(S%C)
PRINT *, 'LEN(S%C) = ',LEN(S%C)
P => S%C

END PROGRAM TEST

$ gfortran -Wall -fbounds-check test.f95 -o test
$ ./test
 SIZE(S%C) =5
 LEN(S%C) =0
At line 14 of file test.f95
Fortran runtime error: Unequal character lengths (3/0) in pointer assignment


? Why does the LEN function return zero?
The SIZE function is correct.
LEN(S%C(1)) gives the correct result, but LEN should work with an array
argument too.

? Why does the pointer assignment fail?
It is OK without -fbounds-check.

[Bug bootstrap/70704] [6 Regression] AIX bootstrap comparison failure

[jakub at gcc dot gnu.org]

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

--- Comment #30 from Jakub Jelinek  ---
Created attachment 38320
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38320&action=edit
2.5.37 -> 2.6

So, can you please verify that the RC1 tarball bootstraps if you apply the
attached patch (which should change the file as if I've created rc1 with flex
2.6 instead of 2.5.37)?
Or do the #line filenames matter instead?
I normally bootstrap with ../configure and therefore the paths are like
../../gcc/something, but in the RC tarballs it is
/d/gcc-6.0.1-RC-20160415/gcc-6.0.1-RC-20160415/gcc/something
(the /d is my dest dir symlink to make those as short as possible, the rest
comes from gcc_release script).

[Bug middle-end/70747] [6/7 Regression] ICE on valid code on x86_64-linux-gnu: verify_gimple failed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug middle-end/70747] [6/7 Regression] ICE on valid code on x86_64-linux-gnu: verify_gimple failed

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Thu Apr 21 11:57:28 2016
New Revision: 235336

URL: https://gcc.gnu.org/viewcvs?rev=235336&root=gcc&view=rev
Log:
2016-04-21  Richard Biener  

PR middle-end/70747
* fold-const.c (fold_comparison): Return properly typed
constant boolean.

* gcc.dg/pr70747.c: New testcase.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.dg/pr70747.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/fold-const.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug middle-end/70747] [6/7 Regression] ICE on valid code on x86_64-linux-gnu: verify_gimple failed

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Thu Apr 21 11:52:50 2016
New Revision: 235335

URL: https://gcc.gnu.org/viewcvs?rev=235335&root=gcc&view=rev
Log:
2016-04-21  Richard Biener  

PR middle-end/70747
* fold-const.c (fold_comparison): Return properly typed
constant boolean.

* gcc.dg/pr70747.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/pr70747.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

[Bug target/70674] [4.9/5/6/7 regression] S/390: Memory access below stack pointer in epilogue

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

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

--- Comment #6 from Andreas Krebbel  ---
Fixed with the committed patch.

[Bug target/70674] [4.9/5/6/7 regression] S/390: Memory access below stack pointer in epilogue

[krebbel at gcc dot gnu.org]

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

--- Comment #5 from Andreas Krebbel  ---
Author: krebbel
Date: Thu Apr 21 11:50:22 2016
New Revision: 235334

URL: https://gcc.gnu.org/viewcvs?rev=235334&root=gcc&view=rev
Log:
PR70674: S/390: Add memory barrier to stack pointer restore
 from fpr.

This patches fixes a problem with stack variable accesses being
scheduled after the stack pointer restore instructions.  In the
testcase this happened with the stack variable 'a' accessed through the
frame pointer.

The existing stack_tie we have in the backend is basically useless
when trying to block stack variable accesses from being scheduled
across an insn.  The alias set of stack variables and the frame alias
set usually differ and hence aren't in conflict with each other.  The
solution appears to be a magic MEM term with a scratch register which
is handled as a full memory barrier when analyzing scheduling
dependencies.

With the patch a (clobber (mem:BLK (scratch))) is being added to the
restore instruction in order to prevent any memory operations to be
scheduled across the insn.  The patch does that only for the one case
where the stack pointer is restored from an FPR.  Theoretically this
might happen also in the case where the stack pointer gets restored
using a load multiple.  However, triggering that problem with
load-multiple appears to be much harder since the load-multiple will
restore the frame pointer as well.  So in order to see the problem a
different call-clobbered register would need to be used as temporary
stack pointer.

Another case which needs to be handled some day is the stack pointer
allocation part.  It needs to be a memory barrier as well.

gcc/ChangeLog:

2016-04-21  Andreas Krebbel  

Backport from mainline
2016-04-20  Andreas Krebbel  

PR target/70674
* config/s390/s390.c (s390_restore_gprs_from_fprs): Pick the new
stack_restore_from_fpr pattern when restoring r15.
(s390_optimize_prologue): Strip away the memory barrier in the
parallel when trying to get rid of restore insns.
* config/s390/s390.md ("stack_restore_from_fpr"): New insn
definition for loading the stack pointer from an FPR.  Compared to
the normal move insn this pattern includes a full memory barrier.

gcc/testsuite/ChangeLog:

2016-04-21  Andreas Krebbel  

Backport from mainline
2016-04-20  Andreas Krebbel  

PR target/70674
* gcc.target/s390/pr70674.c: New test.


Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/s390/pr70674.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/s390/s390.c
branches/gcc-4_9-branch/gcc/config/s390/s390.md
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/70751] [7 Regression] FAIL: gcc.target/arm/eliminate.c scan-assembler-times r0,[\\t ]*sp 3 since r235184

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization, ra
   Target Milestone|--- |7.0
Summary|FAIL:   |[7 Regression] FAIL:
   |gcc.target/arm/eliminate.c  |gcc.target/arm/eliminate.c
   |scan-assembler-times|scan-assembler-times
   |r0,[\\t ]*sp 3 since|r0,[\\t ]*sp 3 since
   |r235184 |r235184

[Bug rtl-optimization/70751] New: FAIL: gcc.target/arm/eliminate.c scan-assembler-times r0,[\\t ]*sp 3 since r235184

[jiwang at gcc dot gnu.org]

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

Bug ID: 70751
   Summary: FAIL: gcc.target/arm/eliminate.c scan-assembler-times
r0,[\\t ]*sp 3 since r235184
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jiwang at gcc dot gnu.org
CC: vmakarov at redhat dot com
  Target Milestone: ---
Target: arm*

r235184 caused the following regression on trunk

  FAIL: gcc: gcc.target/arm/eliminate.c scan-assembler-times r0,[\\t ]*sp 3

configuration: --target=arm-none-eabi --enable-languages=c
compile option: -O2 -march=armv7-a

before:
===
foo:
str lr, [sp, #-4]!
sub sp, sp, #12
add r0, sp, #4
bl  bar
add r0, sp, #4
bl  bar
add r0, sp, #4
bl  bar
add sp, sp, #12
ldr pc, [sp], #4

after:
===
foo:
str lr, [sp, #-4]!
sub sp, sp, #20
add r3, sp, #12
str r3, [sp, #4]
mov r0, r3
bl  bar
add r3, sp, #12
str r3, [sp, #4]
mov r0, r3
bl  bar
add r3, sp, #12
str r3, [sp, #4]
mov r0, r3
bl  bar
add sp, sp, #20
ldr pc, [sp], #4

[Bug tree-optimization/70715] SCEV failed to prove no-overflow-ness information unsigned loop IV

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from amker at gcc dot gnu.org ---
Fixed.

[Bug tree-optimization/70715] SCEV failed to prove no-overflow-ness information unsigned loop IV

[amker at gcc dot gnu.org]

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

--- Comment #1 from amker at gcc dot gnu.org ---
Author: amker
Date: Thu Apr 21 11:28:58 2016
New Revision: 235333

URL: https://gcc.gnu.org/viewcvs?rev=235333&root=gcc&view=rev
Log:
PR tree-optimization/70715
* tree-ssa-loop-niter.c (loop_exits_before_overflow): Check equality
after expanding BASE using expand_simple_operations.

gcc/testsuite/ChangeLog
PR tree-optimization/70715
* gcc.dg/tree-ssa/scev-13.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/scev-13.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-niter.c

[Bug ipa/70646] [4.9/5/6/7 Regression] Corrupt truncated function

[jamborm at gcc dot gnu.org]

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

--- Comment #31 from Martin Jambor  ---
(In reply to rguent...@suse.de from comment #30)
> 
> Any reason it's not unsigned HOST_WIDE_INT size?

The only reason is to use the same type in which
get_ref_base_and_extent returns size.

[Bug ipa/70646] [4.9/5/6/7 Regression] Corrupt truncated function

[rguenther at suse dot de]

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

--- Comment #30 from rguenther at suse dot de  ---
On Wed, 20 Apr 2016, jamborm at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646
> 
> --- Comment #29 from Martin Jambor  ---
> Created attachment 38316
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38316&action=edit
> Fix storing access size to conditions
> 
> Honza asked me to also come up with a version of the patch where we
> store access size to the condition (as a HOST_WIDE_INT) and use that
> for access size comparisons, so that we avoid any potential confusion
> (for example if the loaded value is run through a NOP_EXPR after
> loading but before the described use).
> 
> So this is it.  It survives both regular and LTO bootstrap and testing
> on an x86_64-linux.

Any reason it's not unsigned HOST_WIDE_INT size?

[Bug target/70750] [6/7 Regression] Load and call no longer combined for indirect calls on x86

[david.abdurachmanov at gmail dot com]

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

David Abdurachmanov  changed:

   What|Removed |Added

 CC||david.abdurachmanov at gmail 
dot c
   ||om

--- Comment #1 from David Abdurachmanov  
---
I have noticed this while comparing assembly generated by GCC 5.3.0 and GCC
6.0.1.

Examples (diff -u 5.3.0 6.0.1)

  7 -   ff 50 18callq  *0x18(%rax)
  8 +   48 8b 40 18 mov0x18(%rax),%rax
  9 +   ff d0   callq  *%rax

 41 -   ff 50 08callq  *0x8(%rax)
 42 -   4c 8b 7b f8 mov-0x8(%rbx),%r15
 43 +   48 8b 40 08 mov0x8(%rax),%rax
 44 +   ff d0   callq  *%rax
 45 +   49 8b 5f f8 mov-0x8(%r15),%rbx

 49 -   ff 50 08callq  *0x8(%rax)
 50 +   48 8b 40 08 mov0x8(%rax),%rax
 51 +   ff d0   callq  *%rax

Seems that GCC 6.0.1 is no more combining mov + callq. I have not checked if it
was intentional change or not in GCC.

[Bug target/70750] [6/7 Regression] Load and call no longer combined for indirect calls on x86

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Component|rtl-optimization|target
   Target Milestone|--- |6.0

[Bug rtl-optimization/70750] New: [6/7 Regression] Load and call no longer combined for indirect calls on x86

[amonakov at gcc dot gnu.org]

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

Bug ID: 70750
   Summary: [6/7 Regression] Load and call no longer combined for
indirect calls on x86
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amonakov at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64-*-*, i?86-*-*

int f(int (**p)(void))
{
  return -p[1]();
}

gcc-6 -O2 produces:

f:
subq$8, %rsp
movq8(%rdi), %rax
call*%rax
addq$8, %rsp
negl%eax
ret

gcc-5.1 -O2 could combine movq+call into one memory-indirect call:

f:
subq$8, %rsp
call*8(%rdi)
addq$8, %rsp
negl%eax
ret

[Bug fortran/70748] [6/7 Regression] ICE with debug in gfc_trans_block_construct

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-21
 CC||tkoenig at gcc dot gnu.org
Summary|GCC6 Regression: ICE with   |[6/7 Regression] ICE with
   |debug in|debug in
   |gfc_trans_block_construct   |gfc_trans_block_construct
 Ever confirmed|0   |1
  Known to fail||6.0, 7.0

--- Comment #1 from Dominique d'Humieres  ---
This is caused by revision r233797, see also pr70040.

[Bug c++/60796] Default move constructor not generated by explicit template instantiation

[zerolo at gmail dot com]

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

--- Comment #4 from Daniel Vollmer  ---
The relevant clang issue seems to be
https://llvm.org/bugs/show_bug.cgi?id=22763

In my case, I have the "extern template" declaration in the header for the
corresponding template, thus preventing any implicit instantiations and then
leading to the linker errors with the missing "= default;" methods because the
explicit instantiation doesn't generate them.

[Bug c/70749] error: storage size of ‘a’ isn’t known goes away with -Os

[ktkachov at gcc dot gnu.org]

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

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Trunk errors with or without optimisation.
GCC 5 and earlier don't error with optimisation.

If this behaviour is expected (and the bug is in the kernel sources) feel free
to close the report. I just thought it curious that the error depends on
optimisation level.

[Bug c/70749] error: storage size of ‘a’ isn’t known goes away with -Os

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Summary|[4.9/5 Regression] error:   |error: storage size of ‘a’
   |storage size of ‘a’ isn’t   |isn’t known goes away with
   |known goes away with -Os|-Os
  Known to fail||4.3.5

--- Comment #1 from Richard Biener  ---
What version works for you?  Even 4.3 doesn't error at -O.  I suspect older
compiler eliminate a before diagnosing it.

[Bug c/70742] Support div as a builtin

[glisse at gcc dot gnu.org]

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

--- Comment #8 from Marc Glisse  ---
"The div, ldiv, and lldiv functions return a structure of type div_t, ldiv_t,
and lldiv_t, respectively, comprising both the quotient and the remainder. The
structures shall contain (in either order) the members quot (the quotient) and
rem (the remainder), each of which has the same type as the arguments numer and
denom."

So while we know the names and types of the fields, we don't know their order
(unless stdlib.h was included).

[Bug c/70749] New: [4.9/5 Regression] error: storage size of ‘a’ isn’t known goes away with -Os

[ktkachov at gcc dot gnu.org]

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

Bug ID: 70749
   Summary: [4.9/5 Regression] error: storage size of ‘a’ isn’t
known goes away with -Os
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---

I'm hitting an error when trying to build an allyesconfig arm64 linux kernel
(4.5.2) (with an aarch64-none-linux-gnu toolchain).

drivers/staging/wilc1000/wilc_spi.c:123:34: error: storage size of
‘wilc1000_spi_ops’ isn’t known
 static const struct wilc1000_ops wilc1000_spi_ops;
  ^~~~

I don't get this error when compiling with the GCC 5 branch.
creduce reduces this to just:

static struct wilc1000_ops a;

The weird behaviour is on the GCC 5 branch in that I get the error:
bug.i:1:28: error: storage size of ‘a’ isn’t known
 static struct wilc1000_ops a;
^
when compiling with -std=gnu89 bug.i -S
but it is compiled without an error (into an empty file) if I add -Os:
-std=gnu89 bug.i -S -Os

This behaviour occurs on GCC 5 and 4.9 and 4.8.
GCC 6 and trunk give the error regardless of optimization level.

[Bug tree-optimization/70740] [7 Regression] ICE when compiling the Linux kernel (net/wireless/util.o)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |7.0

--- Comment #6 from Richard Biener  ---
Mine.

[Bug c/70742] Support div as a builtin

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
The compiler would need to provide div_t as a builtin-type.  Or the standard
specifies it enough so that layout issues are no worry.

[Bug c++/70744] preincrements possibly double-evaluated in GNU ternaries

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-21
 Ever confirmed|0   |1
  Known to fail||4.3.5, 7.0

--- Comment #1 from Richard Biener  ---
Confirmed.

;; Function int main() (null)
;; enabled by -tree-original


{
  int x = 1;

  <>;
  <>>
} >;
  return  = x;
}

[Bug c++/60796] Default move constructor not generated by explicit template instantiation

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-21
 Ever confirmed|0   |1
  Known to fail||5.3.0, 6.0, 7.0

--- Comment #3 from Jonathan Wakely  ---
Clang and G++ behave the same, they don't emit the defaulted members in either
translation unit. EDG emits them in main.o where they are needed (but not in
A.o)

template 
struct shared_ptr {
  shared_ptr(T*) { }
  shared_ptr(const shared_ptr&) { }
  shared_ptr(shared_ptr&&) { }
  ~shared_ptr() { }
};

template 
struct A
{
  A (T* a) : a(a) {}

  A() = default;
  A(A&&) = default;
  A& operator =(const A&) = default;

  shared_ptr a;
};

extern template struct A;

int main()
{
  A a = new int(19);
  A b = static_cast&&>(a);
}


g++ -c main.C
nm -C main.o
 U _Unwind_Resume
 W shared_ptr::~shared_ptr()
 W shared_ptr::~shared_ptr()
 n shared_ptr::~shared_ptr()
 U A::A(A&&)
 U A::A(int*)
 W A::~A()
 W A::~A()
 n A::~A()
 U operator new(unsigned long)
 U __gxx_personality_v0
 T main

clang++ -std=c++11 -c main.C
nm -C main.o
 r GCC_except_table0
 U _Unwind_Resume
 W shared_ptr::~shared_ptr()
 U A::A(A&&)
 U A::A(int*)
 W A::~A()
 U operator new(unsigned long)
 U __gxx_personality_v0
 T main

edg --c++11 main.C
nm -C main.o
015c W shared_ptr::~shared_ptr()
01a0 W shared_ptr::~shared_ptr()
02a8 T A::A(A&&)
01e4 T A::A(int*)
0344 T A::A(A&&)
0280 T A::A(int*)
036c W A::~A()
0474 W A::~A()
 U operator delete(void*)
 U operator new(unsigned long)
0004 C __EDGCPFE__4_9
0050 d __T12929048.1926
0040 d __T12932616.1915
0060 d __T12934328.1936
 d __T12936536.1896
 U __curr_eh_stack_entry
 U __eh_curr_region
 T main

[Bug middle-end/70747] [6/7 Regression] ICE on valid code on x86_64-linux-gnu: verify_gimple failed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-04-21
  Component|c   |middle-end
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |6.0
Summary|ICE on valid code on|[6/7 Regression] ICE on
   |x86_64-linux-gnu:   |valid code on
   |verify_gimple failed|x86_64-linux-gnu:
   ||verify_gimple failed
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

The GENERIC looks like

;; Function fn1 (null)
;; enabled by -tree-original


{
  a = (int *) __builtin_malloc (8);
  b = 0, 0;
}

which is already odd.  fold produces this via

  if (TREE_CODE_CLASS (code) == tcc_binary
  || TREE_CODE_CLASS (code) == tcc_comparison)
{
...
  if (TREE_CODE (arg1) == COMPOUND_EXPR
  && reorder_operands_p (arg0, TREE_OPERAND (arg1, 0)))
{
  tem = fold_build2_loc (loc, code, type, op0,
 fold_convert_loc (loc, TREE_TYPE (op1),
   TREE_OPERAND (arg1, 1)));
  return build2_loc (loc, COMPOUND_EXPR, type, TREE_OPERAND (arg1, 0),
 tem);
}

and the issue is that type is int while the comparison folding producing tem
returns a bool via fold_comparison:

8684  switch (code)
8685{
8686case EQ_EXPR:
8687case LE_EXPR:
8688case LT_EXPR:
8689  return boolean_false_node;

[Bug tree-optimization/70725] Internal compiler error (ICE) on valid code

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
Testing that.

[Bug tree-optimization/70729] Loop marked with omp simd pragma is not vectorized

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
(In reply to Richard Biener from comment #9)
> Oh, and I believe to make nests with only outer safelen > 0 work correctly we
> need to move the check elsewhere:
> 
> Index: gcc/tree-ssa-loop-im.c
> ===
> --- gcc/tree-ssa-loop-im.c  (revision 235237)
> +++ gcc/tree-ssa-loop-im.c  (working copy)
> @@ -2120,6 +2120,12 @@ ref_indep_loop_p_1 (struct loop *loop, i
>bitmap_iterator bi;
>im_mem_ref *aref;
>  
> +  /* If the Ith and the I + nth iterations can be evaluated
> + concurrently a reference with an invariant address is
> + not dependent on any other memory reference.  */
> +  if (loop->safelen > 0)
> +return true;
> +
>if (stored_p)
>  refs_to_check = &memory_accesses.refs_in_loop[loop->num];
>else

It doesn't work:

Running target unix
FAIL: c-c++-common/cilk-plus/CK/nested_cilk_for.c  -O1 execution test
FAIL: c-c++-common/cilk-plus/CK/nested_cilk_for.c  -O3 execution test
FAIL: c-c++-common/cilk-plus/CK/nested_cilk_for.c  -g -O2 execution test
FAIL: g++.dg/cilk-plus/CK/for1.cc  -O1 -fcilkplus execution test
FAIL: g++.dg/cilk-plus/CK/for1.cc  -g -O2 -fcilkplus execution test

Running target unix
FAIL: c-c++-common/cilk-plus/CK/nested_cilk_for.c  -O1  execution test
FAIL: c-c++-common/cilk-plus/CK/nested_cilk_for.c  -O2 -ftree-vectorize 
executi
on test
FAIL: c-c++-common/cilk-plus/CK/nested_cilk_for.c  -O2 -std=c99  execution test
FAIL: c-c++-common/cilk-plus/CK/nested_cilk_for.c  -O3 -flto -g  execution test
FAIL: c-c++-common/cilk-plus/CK/nested_cilk_for.c  -O3 -g  execution test
...
FAIL: gcc.dg/vect/pr59984.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/pr59984.c execution test
FAIL: gcc.dg/vect/vect-simd-clone-5.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/vect-simd-clone-5.c execution test
FAIL: gcc.dg/vect/vect-simd-clone-8.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/vect-simd-clone-8.c execution test

Running target unix
FAIL: libgomp.c/ordered-5.c execution test
FAIL: libgomp.c++/pr66702-2.C execution test
FAIL: libgomp.fortran/examples-4/declare_target-5.f90   -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions 
execution test
FAIL: libgomp.fortran/examples-4/simd-2.f90   -O1  execution test
FAIL: libgomp.fortran/examples-4/simd-2.f90   -O2  execution test
FAIL: libgomp.fortran/examples-4/simd-2.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: libgomp.fortran/examples-4/simd-2.f90   -O3 -g  execution test
FAIL: libgomp.fortran/examples-4/simd-7.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: libgomp.fortran/examples-4/simd-7.f90   -O3 -g  execution test

[Bug tree-optimization/70725] Internal compiler error (ICE) on valid code

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
I think that's a separate issue.  if-conversion is confused about

.MEM_198 = PHI <.MEM_191(43)>

which it should simply ignore.

Index: tree-if-conv.c
===
--- tree-if-conv.c  (revision 235305)
+++ tree-if-conv.c  (working copy)
@@ -659,7 +659,7 @@ if_convertible_phi_p (struct loop *loop,

   if (bb != loop->header)
 {
-  if (gimple_phi_num_args (phi) != 2
+  if (gimple_phi_num_args (phi) > 2
  && !aggressive_if_conv
  && !phi_convertible_by_degenerating_args (phi))
{

should fix the ICE but it leads to another latent issue:

/space/rguenther/src/svn/trunk/gcc/testsuite/gcc.dg/pr70725.c: In function
'fn1':
/space/rguenther/src/svn/trunk/gcc/testsuite/gcc.dg/pr70725.c:13:1: error:
statement uses released SSA name:
# .MEM_202 = VDEF <.MEM_198>
# lhs access alignment 32+0
c[_73] = _ifc__387;
The use of .MEM_198 should have been replaced
/space/rguenther/src/svn/trunk/gcc/testsuite/gcc.dg/pr70725.c:13:1: internal
compiler error: cannot update SSA form


Fixed by

Index: tree-if-conv.c
===
--- tree-if-conv.c  (revision 235305)
+++ tree-if-conv.c  (working copy)
@@ -1911,20 +1911,31 @@ predicate_all_scalar_phis (struct loop *
   if (bb == loop->header)
continue;

-  if (EDGE_COUNT (bb->preds) == 1)
-   continue;
-
   phi_gsi = gsi_start_phis (bb);
   if (gsi_end_p (phi_gsi))
continue;

-  gsi = gsi_after_labels (bb);
-  while (!gsi_end_p (phi_gsi))
+  if (EDGE_COUNT (bb->preds) == 1)
{
- phi = phi_gsi.phi ();
- predicate_scalar_phi (phi, &gsi);
- release_phi_node (phi);
- gsi_next (&phi_gsi);
+ /* Propagate degenerate PHIs.  */
+ for (phi_gsi = gsi_start_phis (bb); !gsi_end_p (phi_gsi);
+  gsi_next (&phi_gsi))
+   {
+ gphi *phi = phi_gsi.phi ();
+ replace_uses_by (gimple_phi_result (phi),
+  gimple_phi_arg_def (phi, 0));
+   }
+   }
+  else
+   {
+ gsi = gsi_after_labels (bb);
+ while (!gsi_end_p (phi_gsi))
+   {
+ phi = phi_gsi.phi ();
+ predicate_scalar_phi (phi, &gsi);
+ release_phi_node (phi);
+ gsi_next (&phi_gsi);
+   }
}

   set_phi_nodes (bb, NULL);

[Bug sanitizer/70746] UBSAN runtime fail: undefined symbol: __ubsan_handle_nonnull_arg

[ch3root at openwall dot com]

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

Alexander Cherepanov  changed:

   What|Removed |Added

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

--- Comment #1 from Alexander Cherepanov  ---
I figured it out. New gcc was installed in parallel with the system one and due
to wrong LD_LIBRARY_PATH settings, an old system libubsan.so was used. With the
right libubsan.so everything works fine. Sorry for the noise!

[Bug c++/70018] [4.9/5/6/7 Regression] Possible issue around IPO and C++ comdats discovered as pure/const

[hubicka at gcc dot gnu.org]

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

--- Comment #16 from Jan Hubicka  ---
Author: hubicka
Date: Thu Apr 21 09:05:07 2016
New Revision: 235318

URL: https://gcc.gnu.org/viewcvs?rev=235318&root=gcc&view=rev
Log:

PR ipa/70018
* cgraph.c (cgraph_set_nothrow_flag_1): Rename to ...
(set_nothrow_flag_1): ... this; handle interposition correctly;
recurse on aliases and thunks.
(cgraph_node::set_nothrow_flag): New.
* ipa-pure-const.c (ignore_edge_for_nothrow): Ignore calls to
functions compiled with non-call exceptions that binds to current
def.
(propagate_nothrow): Be safe WRT interposition.
* cgraph.h (set_nothrow_flag): Update prototype.

* g++.dg/ipa/nothrow-1.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/ipa/nothrow-1.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraph.c
trunk/gcc/cgraph.h
trunk/gcc/ipa-pure-const.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/70748] New: GCC6 Regression: ICE with debug in gfc_trans_block_construct

[antony at cosmologist dot info]

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

Bug ID: 70748
   Summary: GCC6 Regression: ICE with debug in
gfc_trans_block_construct
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antony at cosmologist dot info
  Target Milestone: ---

Run "make Debug" on code at https://github.com/cmbant/forutils/


gfortran -cpp -ffree-line-length-none -fmax-errors=4 -MMD -g -O0 -o
IniObjects.o -c ../IniObjects.f90
../IniObjects.f90:348:0:

 S = S(i+2:)

internal compiler error: in gfc_trans_block_construct, at
fortran/trans-stmt.c:1788
0x6e30e1 gfc_trans_block_construct(gfc_code*)
../../gcc/fortran/trans-stmt.c:1788
0x67f637 trans_code
../../gcc/fortran/trans.c:1785
0x6dac43 gfc_trans_if_1
../../gcc/fortran/trans-stmt.c:1299
0x6dac54 gfc_trans_if_1
../../gcc/fortran/trans-stmt.c:1303
0x6e188a gfc_trans_if(gfc_code*)
../../gcc/fortran/trans-stmt.c:1330
0x67f6a7 trans_code
../../gcc/fortran/trans.c:1777
0x6dac43 gfc_trans_if_1
../../gcc/fortran/trans-stmt.c:1299
0x6e188a gfc_trans_if(gfc_code*)
../../gcc/fortran/trans-stmt.c:1330
0x67f6a7 trans_code
../../gcc/fortran/trans.c:1777
0x6e3e2d gfc_trans_do_while(gfc_code*)
../../gcc/fortran/trans-stmt.c:2294
0x67f657 trans_code
../../gcc/fortran/trans.c:1797
0x6dac43 gfc_trans_if_1
../../gcc/fortran/trans-stmt.c:1299
0x6e188a gfc_trans_if(gfc_code*)
../../gcc/fortran/trans-stmt.c:1330
0x67f6a7 trans_code
../../gcc/fortran/trans.c:1777
0x6a302c gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6154
0x682b21 gfc_generate_module_code(gfc_namespace*)
../../gcc/fortran/trans.c:2058
0x63b54d translate_all_program_units
../../gcc/fortran/parse.c:5600
0x63b54d gfc_parse_file()
../../gcc/fortran/parse.c:5819
0x67c985 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:201
Please submit a full bug report,
with preprocessed source if appropriate.


Appeared sometime in gcc in the last couple of months, also in v7 master.

[Bug libstdc++/60936] [4.9/5/6/7 Regression] Binary code bloat with std::string

[d.v.a at ngs dot ru]

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

--- Comment #17 from __vic  ---
Created attachment 38319
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38319&action=edit
Dirty patch for GCC 5/6

This dirty patch created for GCC5 solves the problem for GCC6 as well.
(out_of_range will not contain pretty message)