[Bug c++/67870] ICE: in type_throw_all_p, at cp/except.c:1306

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #2 from Paolo Carlini  ---
Confirmed fixed in 5.x and 6.x.

[Bug fortran/58754] [4.9/5 Regression] ICE on allocating character array with source

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #15 from Paul Thomas  ---
Dear Juergen,

Thanks for the report. I am sorry that it has taken a long time to get round to
fixing it.

Best regards

Paul

[Bug c++/67989] [REGRESSION] g++ ICE on armel valid code

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||rguenther at suse dot de

--- Comment #3 from Paolo Carlini  ---
For the record: given the actual error, can't be one of my two C++ front-end
patches. I'm also pretty sure isn't a C++ front-end issue at all.

Richard, sorry for bothering, can you have a look?

[Bug target/68015] ICE in s390_emit_compare

[krebbel at gcc dot gnu.org]

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

--- Comment #3 from Andreas Krebbel  ---
Author: krebbel
Date: Thu Oct 22 08:24:01 2015
New Revision: 229163

URL: https://gcc.gnu.org/viewcvs?rev=229163=gcc=rev
Log:
S/390: PR68015 Fix ICE in s390_emit_compare

gcc/ChangeLog:

2015-10-22  Andreas Krebbel  

PR target/68015
* config/s390/s390.md (movcc): Emit compare only if we don't
already have a comparison result.

gcc/testsuite/ChangeLog:

2015-10-22  Andreas Krebbel  

PR target/68015
* gcc.target/s390/pr68015.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/s390/pr68015.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/s390/s390.md
trunk/gcc/testsuite/ChangeLog

[Bug sanitizer/68042] [6 Regression] c-c++-common/asan/(memcmp-1.c|sanity-check-pure-c-1.c) failures on x86_64-apple-darwin14 after r229111

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug c++/60976] Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2

[rene.koec...@wincor-nixdorf.com]

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

--- Comment #28 from Rene Koecher  ---
(In reply to Giuseppe Ottaviano from comment #26)

Giuseppe, is there an easy way you could provide me with your changes to
alloc_traits.h?

I'd really like to give it a shot against our codebase and see if there's any
speedup. I tried to follow along by taking the alloc_traits.h from 225242
adding the suggested diff to compensate for the missing bits in type_traits.

While this results in a working drop-in replacement I can not detect any
noticable changes in compile time.

[Bug middle-end/68046] -ftrapv doesn't catch leaq-based overflows on x86-64

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Note that -fsanitize-undefined doesn't properly handle

  volatile int x = __INT_MAX__ + 1;

which is in PR61893, it handles the case in this PR fine and with
trap-on-error more efficiently than -ftrapv:

main:
.LFB0:
.cfi_startproc
movqi(%rip), %rax
movq%rax, %rdx
addq$1, %rdx
jo  .L6
cmpq%rdx, %rax
setg%al
movzbl  %al, %eax
ret
.L6:
ud2
.cfi_endproc

of course you simply get a SIGILL (on x86_64), an option to use
abort () would be more "compatible" with how -ftrapv behaves
(abort is also used on targets that do not have a trapping instruction
defined).

[Bug c++/67989] [REGRESSION] g++ ICE on armel valid code

[sylvestre at debian dot org]

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

Sylvestre Ledru  changed:

   What|Removed |Added

 CC||sylvestre at debian dot org

--- Comment #2 from Sylvestre Ledru  ---
The actual error is:

// /usr/include/c++/5/bits/atomic_base.h: In member function 'bool
lldb::SBAddress::OffsetAddress(lldb::addr_t)':
// /usr/include/c++/5/bits/atomic_base.h:396:35: internal compiler error: in
emit_move_insn, at expr.c:3601
//   return __atomic_load_n(&_M_i, __m);
//^

[Bug middle-end/61893] Constant folding inhibits trapping with -ftrapv

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||eggert at gnu dot org

--- Comment #3 from Richard Biener  ---
*** Bug 68046 has been marked as a duplicate of this bug. ***

[Bug middle-end/68046] -ftrapv doesn't catch leaq-based overflows on x86-64

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
If we have a variant that doesn't require libubsan (which is not available
on all targets) then yes, that would indeed be nice.  Of course it's restricted
to the C family languages while -ftrapv was "working" for all languages before
(though IIRC Ada has its own implementation).

Note this bug may be a duplicate (and I must admit I didn't end up committing
a few fixes I had for some of the -ftrapv bugs...).  The testcase works in
my dev tree:

main:
.LFB0:
.cfi_startproc
pushq   %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
movqi(%rip), %rbx
movl$1, %esi
movq%rbx, %rdi
call__addvdi3
cmpq%rax, %rbx
setg%al
movzbl  %al, %eax
popq%rbx
.cfi_def_cfa_offset 8
ret

> ./a.out
Aborted

Sorry about that... :/  (see PR61893)

I'm going to re-test and commit the optab changes (which I believe triggers
the above issue).

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

[Bug target/68015] ICE in s390_emit_compare

[krebbel at gcc dot gnu.org]

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

--- Comment #4 from Andreas Krebbel  ---
Author: krebbel
Date: Thu Oct 22 08:28:57 2015
New Revision: 229165

URL: https://gcc.gnu.org/viewcvs?rev=229165=gcc=rev
Log:
S/390: PR68015 Fix ICE in s390_emit_compare

gcc/ChangeLog:

2015-10-22  Andreas Krebbel  

Backport from mainline
2015-10-22  Andreas Krebbel  

PR target/68015
* config/s390/s390.md (movcc): Emit compare only if we don't
already have a comparison result.

gcc/testsuite/ChangeLog:

2015-10-22  Andreas Krebbel  

Backport from mainline
2015-10-22  Andreas Krebbel  

PR target/68015
* gcc.target/s390/pr68015.c: New test.


Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/s390/pr68015.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/s390/s390.md
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug target/68018] [6 Regression] ICE: in ix86_compute_frame_layout, at config/i386/i386.c:11308 with -mstackrealign

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|6.0 |5.3

--- Comment #7 from Uroš Bizjak  ---
Fixed.

[Bug target/67989] [5/6 Regression] g++ ICE on armel valid code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||arm*
   Priority|P3  |P1
  Known to work||5.2.0
  Component|c++ |target
 CC||kyrylo.tkachov at arm dot com
Summary|[REGRESSION] g++ ICE on |[5/6 Regression] g++ ICE on
   |armel valid code|armel valid code
   Target Milestone|--- |5.3
  Known to fail||5.2.1

--- Comment #4 from Richard Biener  ---
Looks like a target issue to me, possibly caused by

2015-10-01  Kyrylo Tkachov  

Backport from mainline
2015-06-09  Shiva Chen  

* sync.md (atomic_load): Add conditional code for lda/ldr
(atomic_store): Likewise.

testcase needs reduction, working on trunk needs to be verified and the
regression bisected (in case it's not obvious).

[Bug target/68018] [6 Regression] ICE: in ix86_compute_frame_layout, at config/i386/i386.c:11308 with -mstackrealign

[uros at gcc dot gnu.org]

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

--- Comment #6 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Oct 22 06:52:00 2015
New Revision: 229162

URL: https://gcc.gnu.org/viewcvs?rev=229162=gcc=rev
Log:
Backport from mainline
2015-10-21  Uros Bizjak  

PR target/68018
* config/i386/i386.c (ix86_compute_frame_layout): Realign the stack
for 64-bit MS_ABI targets also when default incoming stack boundary
is overriden.

testsuite/ChangeLog:

Backport from mainline
2015-10-21  Uros Bizjak  

PR target/68018
* gcc.target/i386/pr68018.c: New test.
Backport from mainline
2015-10-21  Uros Bizjak  

PR target/68018
* config/i386/i386.c (ix86_compute_frame_layout): Realign the stack
for 64-bit MS_ABI targets also when default incoming stack boundary
is overriden.

testsuite/ChangeLog:

Backport from mainline
2015-10-21  Uros Bizjak  

PR target/68018
* gcc.target/i386/pr68018.c: New test.


Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr68018.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/i386/i386.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug c++/68051] copy constructor does not copy default initialized union member

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #2 from Markus Trippelsdorf  ---
It is already fixed.

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

[Bug c++/66583] incorrect implicitly-defined move constructor for class with anonymous union and NSDMI

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||akju at mailinator dot com

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

[Bug fortran/68054] New: ICE on using protected attribute in program without program statement

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 68054
   Summary: ICE on using protected attribute in program without
program statement
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Without an explicit program statement :

$ cat z1.f90
!program p
   real, protected :: x
end


$ gfortran -g -O0 -Wall -fcheck=all z1.f90
f951: internal compiler error: Segmentation fault

---

Detected with program statement :

$ cat z1p.f90
program p
   real, protected :: x
end


$ gfortran -g -O0 -Wall -fcheck=all z1p.f90
z1p.f90:2:21:

real, protected :: x
 1
Error: PROTECTED at (1) only allowed in specification part of a module

[Bug fortran/68055] ICE on using unsupported kinds in program without program statement

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #1 from Gerhard Steinmetz  
---
Simplified. Still different behaviour :

$ cat z3.f90
!program p
   integer*3 c
   print *, c
end

$ gfortran -g -O0 -Wall -fcheck=all z3.f90
z3.f90:2:0:

integer*3 c
 1
internal compiler error: Segmentation fault

[Bug fortran/58754] [4.9/5 Regression] ICE on allocating character array with source

[pault at gcc dot gnu.org]

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

--- Comment #14 from Paul Thomas  ---
Author: pault
Date: Thu Oct 22 18:08:31 2015
New Revision: 229180

URL: https://gcc.gnu.org/viewcvs?rev=229180=gcc=rev
Log:
2015-10-22  Paul Thomas  

PR fortran/58754
* gfortran.dg/pr58754.f90: New test

Added:
branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/pr58754.f90
Modified:
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug fortran/67805] ICE on array constructor with wrong character specification

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from kargl at gcc dot gnu.org ---
I have patch cooking.  It works for everything except the use of NULL()

!   s =  [character(null()) :: 'x', 'y']  ! This should cause an error.
!   print *, '6: ', [character(null()) :: 'x', 'y'] ! This should cause an
error.

and an array

   integer, parameter :: m(3) = [1, 2, 3]
   character(len=1) s(2)
   s = [character(m(1)) :: 'x', 'y']  ! OK.
   s = [character(m) :: 'x', 'y'] ! This should cause an error.
   s = [character(m(2:3)) :: 'x', 'y']! This should cause an error.

[Bug rtl-optimization/67609] [5/6 Regression] Generates wrong code for SSE2 _mm_load_pd

[law at redhat dot com]

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

--- Comment #21 from Jeffrey A. Law  ---
On 10/22/2015 07:40 AM, rguenth at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67609
>
> --- Comment #20 from Richard Biener  ---
> (In reply to Jeffrey A. Law from comment #19)
>> Preserving the upper part when setting the low part would be expressed via
>> STRICT_LOW_PART.  At least that's what I'd expect to see.
>
> According to documentation this is only needed for smaller-than-word subregs:
Yea, you're probably right.  Sigh.

So going back to the original problem, for a subreg of a multi-word reg, 
why can't we simplify that down to a suitably sized reg?

Jeff

[Bug middle-end/67989] [4.9/5/6 Regression] g++ ICE on armel valid code

[ktkachov at gcc dot gnu.org]

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

--- Comment #10 from ktkachov at gcc dot gnu.org ---
Proposed patch at:
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg02299.html

[Bug fortran/58754] [4.9/5 Regression] ICE on allocating character array with source

[pault at gcc dot gnu.org]

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

--- Comment #13 from Paul Thomas  ---
Author: pault
Date: Thu Oct 22 18:05:21 2015
New Revision: 229179

URL: https://gcc.gnu.org/viewcvs?rev=229179=gcc=rev
Log:
2015-10-22  Paul Thomas  

PR fortran/58754
* trans-stmt.c (gfc_trans_allocate): Do not use the scalar
character assignment if the allocate expression is an array
descriptor.

2015-10-22  Paul Thomas  

PR fortran/58754
* gfortran.dg/pr58754.f90: New test

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr58754.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/trans-stmt.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug c++/68056] New: can use keyword as " _Atomic" as an identifier

[zhijian at ca dot ibm.com]

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

Bug ID: 68056
   Summary: can use keyword as " _Atomic" as  an identifier
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhijian at ca dot ibm.com
  Target Milestone: ---

in the following source code 

int _Atomic;

int main()
{

return 1;
}

it compile pass with gcc .

But according to 

 ISO/IEC 9899:2011, 6.4.1, Keywords, _Atomic

 When a keyword is used as an identifier, a diagnostic must
be issued. 6.4.1;2a

[Bug fortran/68055] New: ICE on using unsupported kinds in program without program statement

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 68055
   Summary: ICE on using unsupported kinds in program without
program statement
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Without an explicit program statement :

$ cat z1.f90
!program p
   real*9 :: c
   write (c, '(i3)') 1
end


$ gfortran -g -O0 -Wall -fcheck=all z1.f90
f951: internal compiler error: gfc_validate_kind(): Got bad kind

---

Detected with program statement :

$ cat z2.f90
program p
   real*9 :: c
   write (c, '(i3)') 1
end


$ gfortran -g -O0 -Wall -fcheck=all z2.f90
z2.f90:2:9:

real*9 :: c
 1
Error: Old-style type declaration REAL*9 not supported at (1)
z2.f90:3:10:

write (c, '(i3)') 1
  1
Error: UNIT specification at (1) must be an INTEGER expression or a CHARACTER
variable

[Bug c++/60976] Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2

[ott at fb dot com]

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

--- Comment #29 from Giuseppe Ottaviano  ---
(In reply to Rene Koecher from comment #28)
> (In reply to Giuseppe Ottaviano from comment #26)
> 
> Giuseppe, is there an easy way you could provide me with your changes to
> alloc_traits.h?
> 
> I'd really like to give it a shot against our codebase and see if there's
> any speedup. I tried to follow along by taking the alloc_traits.h from
> 225242 adding the suggested diff to compensate for the missing bits in
> type_traits.
> 
> While this results in a working drop-in replacement I can not detect any
> noticable changes in compile time.

Interesting, in a previous comment you say that you see a large jump in
"parsing" time, while in my case (and also in the attached reports) the largest
increases are in template instantiation. Maybe you have a different problem?

Anyway, of course I can share my changes (please ignore the weird formatting):
https://gist.github.com/ot/b094d58bf049cee3db99

If replacing alloc_traits.h does not work, try also allocator.h, it includes
the partial specialization that shortcuts SFINAE.

[Bug debug/68010] internal compiler error: in tree_to_shwi, at tree.h:3661

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #7 from Markus Trippelsdorf  ---
Thank you. CCing Jason.

[Bug rtl-optimization/67609] [5/6 Regression] Generates wrong code for SSE2 _mm_load_pd

[rguenth at gcc dot gnu.org]

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

--- Comment #18 from Richard Biener  ---
(In reply to Jeffrey A. Law from comment #16)
> reload has traditionally removed subregs of hardregs and passes after reload
> have depended on that behaviour.  Doing something similar in lra is
> obviously necessary.  In fact, subregs of multi-word hard regs isn't ever
> supposed to appear in the except during allocation & reloading.

But how do you preserve semantics of preserving the upper part then?
Do recognized insns never change after reload and thus the target needs
to make sure to have insns "separated" enough that the property is preserved
solely by means of the selected insn (we don't record the chosen alternatives
in the insns, do we?)?

> I'm not sure why final has another call to cleanup_subreg_operands.  While
> git blame blames me, I was just refactoring existing code code back in '98.
> 
> Does that shed any light on what the right behaviour for LRA ought to be?

[Bug c/67488] Incorrect error message on call of nested functions

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-22
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug c++/67354] [5/6 regression] internal compiler error: in add_to_same_comdat_group, at symtab.c:421

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #5 from Markus Trippelsdorf  ---
Hmm that commit is strange. It states that
 -fabi-version=8 is the default for GCC 5.1
 -fabi-version=9 is the default for GCC 5.2
which is clearly not the case.

Jason?

[Bug c++/67354] [5/6 regression] internal compiler error: in add_to_same_comdat_group, at symtab.c:421

[trippels at gcc dot gnu.org]

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

--- Comment #6 from Markus Trippelsdorf  ---
No, the statement is correct:

markus@x4 tmp % echo | g++ -fabi-version=9 -dM -E - | grep -i abi
#define __GXX_ABI_VERSION 1009
markus@x4 tmp % echo | g++ -fabi-version=0 -dM -E - | grep -i abi
#define __GXX_ABI_VERSION 1009

But why does the testcase stop ICEing only with an explicit -fabi-version=9?

[Bug middle-end/68046] -ftrapv doesn't catch leaq-based overflows on x86-64

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Thu Oct 22 11:44:11 2015
New Revision: 229170

URL: https://gcc.gnu.org/viewcvs?rev=229170=gcc=rev
Log:
2015-10-22  Richard Biener  

PR middle-end/68046
PR middle-end/61893
* optabs.c (emit_libcall_block_1): Allow a NULL_RTX equiv.
(expand_binop): For -ftrapv optabs do not record an REG_EQUAL note.
(expand_unop): Likewise.

* gcc.dg/torture/ftrapv-2.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/ftrapv-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/optabs.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/61893] Constant folding inhibits trapping with -ftrapv

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Thu Oct 22 11:44:11 2015
New Revision: 229170

URL: https://gcc.gnu.org/viewcvs?rev=229170=gcc=rev
Log:
2015-10-22  Richard Biener  

PR middle-end/68046
PR middle-end/61893
* optabs.c (emit_libcall_block_1): Allow a NULL_RTX equiv.
(expand_binop): For -ftrapv optabs do not record an REG_EQUAL note.
(expand_unop): Likewise.

* gcc.dg/torture/ftrapv-2.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/ftrapv-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/optabs.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/61893] Constant folding inhibits trapping with -ftrapv

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Note only the non-constant-folding part is fixed (the REG_EQUAL notes which
enable combine to remove the trapping).

[Bug target/67989] [5/6 Regression] g++ ICE on armel valid code

[ktkachov at gcc dot gnu.org]

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

--- Comment #6 from ktkachov at gcc dot gnu.org ---
Created attachment 36561
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36561=edit
Reduced testcase

Attaching reduced testcase, here's the full ICE backtrace.

Can be reproduced with -O2 -std=c++11 -march=armv4t -marm


besttry.cpp: In member function ‘void
lldb::SBAddress::SetAddress(lldb::SBSection, lldb::addr_t)’:
besttry.cpp:27:23: internal compiler error: in emit_move_insn, at expr.c:3553
 __atomic_load (&_M_i, , __m);
   ^
0x8135af emit_move_insn(rtx_def*, rtx_def*)
$SRC/gcc/expr.c:3552
0x9763c1 expand_atomic_compare_and_swap(rtx_def**, rtx_def**, rtx_def*,
rtx_def*, rtx_def*, bool, memmodel, memmodel)
$SRC/gcc/optabs.c:5907
0x976a22 expand_atomic_load(rtx_def*, rtx_def*, memmodel)
$SRC/gcc/optabs.c:6019
0x71e9cf expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
$SRC/gcc/builtins.c:6738
0x810a85 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
$SRC/gcc/expr.c:10474
0x73bded expand_expr
$SRC/gcc/expr.h:255
0x73bded expand_call_stmt
$SRC/gcc/cfgexpand.c:2647
0x73bded expand_gimple_stmt_1
$SRC/gcc/cfgexpand.c:3534
0x73bded expand_gimple_stmt
$SRC/gcc/cfgexpand.c:3697
0x73cd89 expand_gimple_tailcall
$SRC/gcc/cfgexpand.c:3744
0x73cd89 expand_gimple_basic_block
$SRC/gcc/cfgexpand.c:5677
0x741dde execute
$SRC/gcc/cfgexpand.c:6286
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/67989] [4.9/5/6 Regression] g++ ICE on armel valid code

[ktkachov at gcc dot gnu.org]

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

--- Comment #8 from ktkachov at gcc dot gnu.org ---
Also, fails only for the arm-linux targets. arm-none-eabi compiles fine.
Also, needs an -march option of armv6z or lower. armv6kz, armv7-a and higher
don't ICE

[Bug c++/67354] [5/6 regression] internal compiler error: in add_to_same_comdat_group, at symtab.c:421

[trippels at gcc dot gnu.org]

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

--- Comment #4 from Markus Trippelsdorf  ---
It was fixed on trunk by r228017.
And indeed -fabi-version=5 ICEs, 6 or higher is fine.

[Bug c/56956] ftrapv traps on valid abs-like code

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Yeah, unfortunately that doesn't look correct :(

I've always wanted to have an ABS_EXPR variant that returns an unsigned value
(so with no undefined behavior).  Maybe just overload ABS_EXPR in this way.
You'd need to assure expansion doesn't use absv optabs, that is, trapping
behavior / undefinedness would depend on the ABS_EXPR result type.  The
argument type would still be signed.

[Bug target/67989] [4.9/5/6 Regression] g++ ICE on armel valid code

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
Summary|[5/6 Regression] g++ ICE on |[4.9/5/6 Regression] g++
   |armel valid code|ICE on armel valid code
  Known to fail||4.9.4

--- Comment #7 from ktkachov at gcc dot gnu.org ---
Btw, I see the ICE on 4.9 as well

[Bug c/56956] ftrapv traps on valid abs-like code

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-22
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

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

#define INT_MIN (-__INT_MAX__ - 1L)

unsigned int
foo (unsigned int x)
{
  return x <= __INT_MAX__ ? x : -x;
}

int
main ()
{
  return foo (INT_MIN);
}

We transform foo to
return (unsigned int) ABS_EXPR <(signed int) x>;

[Bug c++/56856] the location of Wformat warnings points *after* the format string

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||gcc at blino dot org

--- Comment #2 from Manuel López-Ibáñez  ---
*** Bug 68052 has been marked as a duplicate of this bug. ***

[Bug c++/68052] No printf format warnings in C++ code for macro in system headers

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||manu at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Manuel López-Ibáñez  ---
The differences that you observe are because C and C++ give the warnings at
different locations. I think the location used by C++ is wrong.

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

[Bug target/68059] New: [arm] libgcc uses __write to report error

[nsz at gcc dot gnu.org]

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

Bug ID: 68059
   Summary: [arm] libgcc uses __write to report error
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nsz at gcc dot gnu.org
  Target Milestone: ---

this bug was reported on the musl libc list:
http://www.openwall.com/lists/musl/2015/10/22/3

libgcc/config/arm/linux-atomic-64bit.c references __write
in __check_for_sync8_kernelhelper.

__write is not a public abi symbol in libc, libgcc should not
reference it.

the standard way is to use assert, but in this case the error
message seems superfluous: the crash is in a ctor, easily
reproducible.

[Bug rtl-optimization/67609] [5/6 Regression] Generates wrong code for SSE2 _mm_load_pd

[rth at gcc dot gnu.org]

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

--- Comment #22 from Richard Henderson  ---
(In reply to Jeffrey A. Law from comment #21)
> So going back to the original problem, for a subreg of a multi-word reg, 
> why can't we simplify that down to a suitably sized reg?

Because we're dealing with registers of different sizes.

Assigning to a subreg as the low-part of a multi-word pseudo only
makes sense when talking about general registers, which is the only
place that "word_mode" applies.

When talking about vector registers, which are universally larger
than word-mode, we cannot simply assign to a subreg.

There is a vec_set named pattern that can perform an insertion into
a vector element, like what's being demonstrated in the test source
here.  Ideally that's how we'd have expanded this originally.

We already have ix86_cannot_change_mode_class to avoid the cases
that we knew we couldn't support, e.g. QI and HImode loads/stores.
But perhaps we should prevent all size-changing mode changes for
the vector registers.

[Bug ipa/68057] New: [6 Regression] 450.soplex in SPEC CPU 2006 failed to build

[hjl.tools at gmail dot com]

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

Bug ID: 68057
   Summary: [6 Regression] 450.soplex in SPEC CPU 2006 failed to
build
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

For x32, r229159 gave

g++ -mx32  -O2 -ffast-math -fwhole-program -flto=jobserver -fuse-linker-plugin 
changesoplex.o didxset.o dsvector.o dvector.o enter.o example.o
factor.o forest.o idxset.o leave.o lpcolset.o lprow.o lprowset.o message.o
mpsinput.o nameset.o slufactor.o solve.o soplex.o spxaggregatesm.o spxbasis.o
spxbounds.o spxchangebasis.o spxdefaultpr.o spxdefaultrt.o spxdefines.o
spxdesc.o spxdevexpr.o spxequilisc.o spxfastrt.o spxgeneralsm.o spxharrisrt.o
spxhybridpr.o spxid.o spxio.o spxlp.o spxlpfread.o spxmpsread.o spxmpswrite.o
spxparmultpr.o spxquality.o spxredundantsm.o spxrem1sm.o spxscaler.o spxshift.o
spxsolve.o spxsolver.o spxstarter.o spxsteeppr.o spxsumst.o spxvecs.o
spxvectorst.o spxweightpr.o spxweightst.o ssvector.o svector.o svset.o timer.o
unitvector.o update.o updatevector.o vector.o vsolve.o -o
soplex
lto1: internal compiler error: in record_target_from_binfo, at
ipa-devirt.c:2599
0x806e06 record_target_from_binfo
../../src-trunk/gcc/ipa-devirt.c:2599
0x806910 record_target_from_binfo
../../src-trunk/gcc/ipa-devirt.c:2640
0x807344 possible_polymorphic_call_targets_1
../../src-trunk/gcc/ipa-devirt.c:2687
0x80e6c9 possible_polymorphic_call_targets(tree_node*, long,
ipa_polymorphic_call_context, bool*, void**, bool)
../../src-trunk/gcc/ipa-devirt.c:3216
0x80ffbc try_speculative_devirtualization(tree_node*, long,
ipa_polymorphic_call_context)
../../src-trunk/gcc/ipa-devirt.c:3576
0x10a887f ipa_get_indirect_edge_target_1
../../src-trunk/gcc/ipa-cp.c:2142
0x8220d2 estimate_edge_devirt_benefit
../../src-trunk/gcc/ipa-inline-analysis.c:3048
0x8224db estimate_edge_size_and_time
../../src-trunk/gcc/ipa-inline-analysis.c:3088
0x8224db estimate_calls_size_and_time
../../src-trunk/gcc/ipa-inline-analysis.c:3164
0x822826 estimate_node_size_and_time
../../src-trunk/gcc/ipa-inline-analysis.c:3259
0x824d8d do_estimate_edge_time(cgraph_edge*)
../../src-trunk/gcc/ipa-inline-analysis.c:3745
0x825317 do_estimate_edge_size(cgraph_edge*)
../../src-trunk/gcc/ipa-inline-analysis.c:3796
0x825587 estimate_edge_size
../../src-trunk/gcc/ipa-inline.h:293
0x825587 estimate_edge_growth
../../src-trunk/gcc/ipa-inline.h:306
0x825587 estimate_size_after_inlining(cgraph_node*, cgraph_edge*)
../../src-trunk/gcc/ipa-inline-analysis.c:3889
0x10b8c64 caller_growth_limits
../../src-trunk/gcc/ipa-inline.c:193
0x10b8c64 can_inline_edge_p
../../src-trunk/gcc/ipa-inline.c:398
0x10bdaad update_callee_keys
../../src-trunk/gcc/ipa-inline.c:1404
0x10c00eb inline_small_functions
../../src-trunk/gcc/ipa-inline.c:2041
0x10c00eb ipa_inline
../../src-trunk/gcc/ipa-inline.c:2425
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: g++ returned 1 exit status
compilation terminated.
/usr/local/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
specmake[3]: *** [soplex] Error 1

r229021 is OK.

[Bug c++/68052] No printf format warnings in C++ code for macro in system headers

[gcc at blino dot org]

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

Olivier Blin  changed:

   What|Removed |Added

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

--- Comment #2 from Olivier Blin  ---
No, the difference that I observe is that, in this specific case involving a
macro in system header, there is a warning in C, and none in C++.
This has been discussed with Martin Sebor on the gcc-help mailing list.

[Bug c++/68052] No printf format warnings in C++ code for macro in system headers

[gcc at blino dot org]

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

--- Comment #3 from Olivier Blin  ---
Quoting Martin Sebor's answer from the gcc-help mailing list:
https://gcc.gnu.org/ml/gcc-help/2015-10/msg00128.html

> I'm inclined to say it's a bug. I recommend opening it in Bugzilla.
> The only way I was able to work around it is by changing MY_PRINTF
> from a function-like macro to an object macro like so:
> 
>   #define MY_PRINTF printf
> 
> The problem isn't specific to -Wformat but can be reproduced with
> other warnings as well. For example, replacing the contents of
> the header in the test case with this:
> 
>   #pragma GCC system_header
> 
>   static inline void __attribute__ ((deprecated)) foobar (void) { }
> 
>   #define foo foobar
>   #define bar() foobar()
> 
> and the body of main with
> 
>   foo ();
>   bar ();
> 
> emits a warning for each of foo() and bar() in C but just one,
> for foo(), in C++.
> 
> While stepping through the code that checks to see whether or not
> a diagnostic should be issued (diagnostic_issue_diagnostic) I see
> that the difference in the bar() case is in the return value of
> the linemap_macro_expansion_map_p() function which is documented
> to
> 
>   Return TRUE if MAP encodes locations coming from a macro
>   replacement-list at macro expansion point.
> 
> and implemented by testing the location MAP's REASON member for
> equality to the LC_ENTER_MACRO constant. In C, the REASON member
> is set to LC_LEAVE while in C++ to LC_ENTER_MACRO. In C, the
> call to bar is then treated as an ordinary token whose location
> (i.e., bar's invocation) determines whether or not to issue the
> diagnostic. In C++ the reference to bar is recognized as a macro
> expansion and the function proceeds to find the token it expands
> to and use that to determine whether or not to diagnose it. And
> since the token bar() expands to is defined in a system header,
> C++ doesn't issue the warning.
> 
> In the case of foo(), the REASON is LC_LEAVE in both front-ends
> and so they both diagnose it.
> 
> Martin

[Bug c++/68056] GCC do not compile failed with using keyword " _Atomic" as an identifier

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

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

--- Comment #1 from Joseph S. Myers  ---
_Atomic was added in 4.9.

[Bug driver/68029] Strange behavior of -fdiagnostics-color option

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez  ---
What does -### show for the call to cc1 ? My commit r228094 to opts-common.c
should have fixed this.

[Bug libstdc++/68058] New: _GLIBCXX_BEGIN_NAMESPACE_VERSION breaks regex

[dmorilha at gmail dot com]

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

Bug ID: 68058
   Summary: _GLIBCXX_BEGIN_NAMESPACE_VERSION breaks regex
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmorilha at gmail dot com
  Target Milestone: ---

when compiling libstdc++ with --enable-symvers=gnu-versioned-namespace
std::regex complaining about private data members trying to be accessed outside
the class:

22:55:46 /home/y/include/c++/4.9.2/bits/regex.h:796:30: error:
‘std::__7::basic_regex::_AutomatonPtr
std::__7::basic_regex::_M_automaton’ is protected
22:55:46_AutomatonPtr  _M_automaton;

I believe the bug is related with the __detail namespace[1] and friend
classes[2] as it lacks the NAMESPACE_VERSION expansion. This happens in other
lines and I believe it extends to hashmap as well. Turning data members public
"fixes" the compilation problem.

[1]:
https://github.com/gcc-mirror/gcc/blob/e0f174323b4297f46d9109201666da42aaa55fc8/libstdc%2B%2B-v3/include/bits/regex.h#L46

[2]:
https://github.com/gcc-mirror/gcc/blob/e0f174323b4297f46d9109201666da42aaa55fc8/libstdc%2B%2B-v3/include/bits/regex.h#L772

[Bug tree-optimization/68060] New: ICE on valid code at -O3 on x86_64-linux-gnu in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1413

[su at cs dot ucdavis.edu]

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

Bug ID: 68060
   Summary: ICE on valid code at -O3 on x86_64-linux-gnu in
vect_get_vec_def_for_operand, at
tree-vect-stmts.c:1413
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following code causes an ICE when compiled with the current gcc trunk at
-O3 on x86_64-linux-gnu in both 32-bit and 64-bit modes.

It is a regression from 5.2.x.


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20151021 (experimental) [trunk revision 229137] (GCC) 
$ 
$ gcc-trunk -O2 small.c; ./a.out
$ gcc-5.2 -O3 small.c; ./a.out
$ 
$ gcc-trunk -O3 small.c
small.c: In function ‘main’:
small.c:4:1: internal compiler error: in vect_get_vec_def_for_operand, at
tree-vect-stmts.c:1413
 main ()
 ^
0xd07273 vect_get_vec_def_for_operand(tree_node*, gimple*)
../../gcc-trunk/gcc/tree-vect-stmts.c:1413
0xd077e1 vect_get_vec_defs(tree_node*, tree_node*, gimple*, vec*, vec*, _slp_tree*, int)
../../gcc-trunk/gcc/tree-vect-stmts.c:1568
0xd102c0 vectorizable_operation
../../gcc-trunk/gcc/tree-vect-stmts.c:4894
0xd1d956 vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*, _slp_tree*,
_slp_instance*)
../../gcc-trunk/gcc/tree-vect-stmts.c:7690
0xd23b73 vect_transform_loop(_loop_vec_info*)
../../gcc-trunk/gcc/tree-vect-loop.c:6134
0xd3e6c7 vectorize_loops()
../../gcc-trunk/gcc/tree-vectorizer.c:512
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ 


--


int a, b, c;

int
main ()
{
  for (; c; c++)
for (a = 0; a < 4; a++)
  {
c &= 5;
for (b = 0; b < 2; b++)
  c |= 1;
  }
  return 0; 
}

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

[gong_su at hotmail dot com]

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

--- Comment #4 from gong_su at hotmail dot com ---
Hi Dominik, here is the output after making the changes you asked. It looks the
same as adding "-x" to the "go" command. I will email all the .go files under
.../rpc/api.

root@linux05:~/Downloads/go-ethereum# make geth
build/env.sh go install -x -v -ldflags '-X main.gitCommit
4813a39100dc8dc884b0a68ceae51c2c420f92af' ./cmd/geth
WORK=/tmp/go-build873382851
github.com/ethereum/go-ethereum/rpc/api
mkdir -p $WORK/github.com/ethereum/go-ethereum/rpc/api/_obj/
mkdir -p $WORK/github.com/ethereum/go-ethereum/rpc/
cd
/root/Downloads/go-ethereum/build/_workspace/src/github.com/ethereum/go-ethereum/rpc/api
/usr/bin/gccgo-5 -I $WORK -I
/root/Downloads/go-ethereum/build/_workspace/src/github.com/ethereum/go-ethereum/Godeps/_workspace/pkg/gccgo_linux_s390x
-I /root/Downloads/go-ethereum/build/_workspace/pkg/gccgo_linux_s390x -c -g
-fgo-pkgpath=github.com/ethereum/go-ethereum/rpc/api
-fgo-relative-import-path=_/root/Downloads/go-ethereum/build/_workspace/src/github.com/ethereum/go-ethereum/rpc/api
-o $WORK/github.com/ethereum/go-ethereum/rpc/api/_obj/_go_.o ./admin.go
./admin_args.go ./admin_js.go ./api.go ./args.go ./db.go ./db_args.go
./db_js.go ./debug.go ./debug_args.go ./debug_js.go ./eth.go ./eth_args.go
./eth_js.go ./mergedapi.go ./miner.go ./miner_args.go ./miner_js.go ./net.go
./net_js.go ./parsing.go ./personal.go ./personal_args.go ./personal_js.go
./shh.go ./shh_args.go ./shh_js.go ./txpool.go ./txpool_js.go ./utils.go
./web3.go ./web3_args.go
# github.com/ethereum/go-ethereum/rpc/api
go1: internal compiler error: in write_specific_type_functions, at
go/gofrontend/types.cc:1812
0x802473df Type::write_specific_type_functions(Gogo*, Named_type*,
std::__cxx11::basic_string
const&, Function_type*, std::__cxx11::basic_string const&, Function_type*)
../../src/gcc/go/gofrontend/types.cc:1812
0x80245b33 Type::specific_type_functions(Gogo*, Named_type*, Function_type*,
Function_type*, Named_object**, Named_object**)
../../src/gcc/go/gofrontend/types.cc:1791
0x8024639d Type::type_functions(Gogo*, Named_type*, Function_type*,
Function_type*, Named_object**, Named_object**)
../../src/gcc/go/gofrontend/types.cc:1668
0x8024eff7 Type::type_descriptor_constructor(Gogo*, int, Named_type*, Methods
const*, bool)
../../src/gcc/go/gofrontend/types.cc:2011
0x80250b1d Array_type::array_type_descriptor(Gogo*, Named_type*)
../../src/gcc/go/gofrontend/types.cc:6318
0x80248a33 Type::make_type_descriptor_var(Gogo*)
../../src/gcc/go/gofrontend/types.cc:1218
0x80248e05 Type::type_descriptor_pointer(Gogo*, Location)
../../src/gcc/go/gofrontend/types.cc:1156
0x801c8e6f Type_descriptor_expression::do_get_backend(Translate_context*)
../../src/gcc/go/gofrontend/expressions.cc:13400
0x801a8efd Interface_value_expression::do_get_backend(Translate_context*)
../../src/gcc/go/gofrontend/expressions.cc:14023
0x8021ef49 Temporary_statement::do_get_backend(Translate_context*)
../../src/gcc/go/gofrontend/statements.cc:470
0x801e8d27 Block::get_backend(Translate_context*)
../../src/gcc/go/gofrontend/gogo.cc:5811
0x8021ea51 Block_statement::do_get_backend(Translate_context*)
../../src/gcc/go/gofrontend/statements.cc:1802
0x801e8d27 Block::get_backend(Translate_context*)
../../src/gcc/go/gofrontend/gogo.cc:5811
0x8021ea51 Block_statement::do_get_backend(Translate_context*)
../../src/gcc/go/gofrontend/statements.cc:1802
0x801e8d27 Block::get_backend(Translate_context*)
../../src/gcc/go/gofrontend/gogo.cc:5811
0x801ea647 Function::build(Gogo*, Named_object*)
../../src/gcc/go/gofrontend/gogo.cc:5417
0x801ebd7d Named_object::get_backend(Gogo*, std::vector >&, std::vector >&,
std::vector >&)
../../src/gcc/go/gofrontend/gogo.cc:7136
0x801f514d Gogo::write_globals()
../../src/gcc/go/gofrontend/gogo.cc:1345
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
Makefile:9: recipe for target 'geth' failed
make: *** [geth] Error 2

[Bug target/62109] __gthr_i486_lock_cmp_xchg missing clobber

[gccbugzilla at limegreensocks dot com]

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

--- Comment #10 from David  ---
(In reply to Kai Tietz from comment #5)
> This patch is clear stage 1 material. 

We're in stage 1.  Is it time?

The patch adds the memory clobber, but I think the conclusion here was to
remove __gthr_i486_lock_cmp_xchg since it only applies to (the no longer
supported) win95.

[Bug rtl-optimization/67609] [5/6 Regression] Generates wrong code for SSE2 _mm_load_pd

[rth at gcc dot gnu.org]

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

--- Comment #23 from Richard Henderson  ---
Created attachment 36563
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36563=edit
possible patch

Certainly this fixes the executable test case from #c13.

[Bug target/68059] [arm] libgcc uses __write to report error

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Musl support is not upstream yet. So this is not a bug. The patches to support
musl should change this file so this part is conditional on !musl.

[Bug driver/68043] many undocumented options, missing punctuation

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Thu Oct 22 23:48:17 2015
New Revision: 229205

URL: https://gcc.gnu.org/viewcvs?rev=229205=gcc=rev
Log:
gcc/ChangeLog:

2015-10-22  Martin Sebor  

PR driver/68043
* config/i386/i386.opt: Add missing periods to the ends of sentences.
* config/msp430/msp430.opt: Same.

gcc/testsuite/ChangeLog:

2015-10-22  Martin Sebor  

PR driver/68043
* gcc.misc-tests/help.exp: Verify that option descriptions
end in periods.
* lib/options.exp (check_for_options): Use the regexp --line option.
Print unexpected match on failure.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.opt
trunk/gcc/config/msp430/msp430.opt
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.misc-tests/help.exp
trunk/gcc/testsuite/lib/options.exp

[Bug c/66322] Linus Torvalds: -Wswitch-bool produces dubious warnings, fails to notice really bad things

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #9 from Marek Polacek  ---
Fixed for GCC 6.

[Bug c++/67249] [concepts] ICE parsing f(pair<auto, concept>)

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-22
 Blocks||67491
 Ever confirmed|0   |1


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
[Bug 67491] [meta-bug] concepts issues

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

[vogt at linux dot vnet.ibm.com]

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

--- Comment #3 from Dominik Vogt  ---
To narrow down where the problem happens please try this:

1. Edit the first line of the file build/env.sh and append "-a":

#!/bin/sh -a

2. Locate the gccgo executable (whould be in the path GOBIN that is set in the
Makefile) and rename it:

$ mv gccgo gccgo.bin

3. Place this small script with the name "gccgo" into the directory with
gccgo.bin and make it executable:

#!/bin/sh 
exec "$GOBIN"/gccgo.bin -v $@ 

$ chmod 755 gccgo

Finally the GOBIN directory should look like this:

$ ls -l gccgo*
-rwxr-xr-x 1 ...  40 ... gccgo
-rwxr-xr-x 2 ... 13M ... gccgo.bin

4. Built ethereum als usual.  Gccgo now prints all commands it executes, and
hopefully the failing command last.

Please attach this output to the bug report.  Also, please make a tar archive
of only the source files listed in the failing "go1" command line, compress it
with "bzip2 -9" or 7zip and send it to me via email.

[Bug bootstrap/68041] [6 Regression] Bootstrap broken on x86_64-apple-darwin14 at revision r229119

[chefmax at gcc dot gnu.org]

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

--- Comment #12 from Maxim Ostapenko  ---
Should be fixed on trunk. Dominique, let me know if the issue still occurs.

[Bug c++/68049] New: template instantiation involving may_alias defines symbol twice

[kretz at kde dot org]

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

Bug ID: 68049
   Summary: template instantiation involving may_alias defines
symbol twice
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kretz at kde dot org
  Target Milestone: ---

The following testcase fails to compile at -O0, but works at -O1 and higher
(-std=c++11 is the only required compiler flag):

template  struct Bar
{
using type = T;
};
template  struct Foo
{
typedef typename Bar::type alias_type [[gnu::may_alias]];

alias_type operator()() { return {}; }
};

template  void print(T) {}

int main()
{
print(Foo()());
print(0);
return 0;
}

The template instantiation of print(T) is done twice:
/tmp/ccDEkoML.s: Assembler messages:
/tmp/ccDEkoML.s:69: Error: symbol `_Z5printIiEvT_' is already defined

With a recent GCC 6 snapshot I get:
failure.cpp:19:1: error: Two symbols with same comdat_group are not linked by
the same_comdat_group list.
 }
 ^
_Z5printIiEvT_/3 (void print(T) [with T = int]) @0x7faa000d75c0
  Type: function definition analyzed
  Visibility: public weak comdat comdat_group:_Z5printIiEvT_ one_only
  previous sharing asm name: 2
  References: 
  Referring: 
  First run: 0
  Function flags: body
  Called by: main/0 (1.00 per call) 
  Calls: 
_Z5printIiEvT_/2 (void print(T) [with T = Bar::type]) @0x7faa000d7450
  Type: function definition analyzed
  Visibility: public weak comdat comdat_group:_Z5printIiEvT_ one_only
  next sharing asm name: 3
  References: 
  Referring: 
  First run: 0
  Function flags: body
  Called by: main/0 (1.00 per call) 
  Calls: 
failure.cpp:19:1: internal compiler error: symtab_node::verify failed
0x90a6e9 symtab_node::verify_symtab_nodes()
../.././gcc/symtab.c:1126
0x91d3d5 symbol_table::compile()
../.././gcc/cgraphunit.c:2377
0x920162 symbol_table::compile()
../.././gcc/cgraphunit.c:2536
0x920162 symbol_table::finalize_compilation_unit()
../.././gcc/cgraphunit.c:2562

[Bug c/65106] C99 intialization of struct with const member through a non-const pointer

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #4 from Marek Polacek  ---
Looks like this doesn't point to a bug in GCC.

[Bug tree-optimization/68050] New: SLP vectorization should negate constants to match up + vs -

[rguenth at gcc dot gnu.org]

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

Bug ID: 68050
   Summary: SLP vectorization should negate constants to match up
+ vs -
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
Blocks: 53947
  Target Milestone: ---

double x[1024], y[1024], z[1024];
void foo (double w)
{
  int i;
  for (i = 0; i < 1023; i+=2)
{
  z[i] = x[i] + 3.;
  z[i+1] = x[i+1] + -3.;
}
}


Referenced Bugs:

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

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

[rguenth at gcc dot gnu.org]

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

Bug 56902 Summary: Fails to SLP with mismatched +/- and negatable constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56902

   What|Removed |Added

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

[Bug tree-optimization/68050] SLP vectorization should negate constants to match up + vs -

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-10-22
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

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

[Bug c++/67354] [5/6 regression] internal compiler error: in add_to_same_comdat_group, at symtab.c:421

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini  ---
Works for me in trunk.

[Bug c/68039] Incorrect unused-result warning

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-22
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug bootstrap/68041] [6 Regression] Bootstrap broken on x86_64-apple-darwin14 at revision r229119

[chefmax at gcc dot gnu.org]

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

--- Comment #11 from Maxim Ostapenko  ---
Author: chefmax
Date: Thu Oct 22 09:47:17 2015
New Revision: 229168

URL: https://gcc.gnu.org/viewcvs?rev=229168=gcc=rev
Log:
Fix bootstrap on x86_64-apple-darwin14 after r229119.

libsanitizer/

PR bootstrap/68041
* configure.ac (link_sanitizer_common): Link against librt only if it
contains shm_open, required by sanitizers.
(CXX_ABI_NEEDED): Remove variable.
* configure: Regenerate.
* ubsan/Makefile.am (libubsan_la_LIBADD): Do not add -lc++abi anymore.
* ubsan/Makefile.in: Regenerate.


Modified:
trunk/libsanitizer/ChangeLog
trunk/libsanitizer/configure
trunk/libsanitizer/configure.ac
trunk/libsanitizer/ubsan/Makefile.am
trunk/libsanitizer/ubsan/Makefile.in

[Bug target/67989] [5/6 Regression] g++ ICE on armel valid code

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-22
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||6.0

--- Comment #5 from ktkachov at gcc dot gnu.org ---
The preprocessed source in the log was interspersed with a number of
warnings/debug messages from other components of the parallel build, so it was
not compilable due to the syntax errors.

Once I removed them I reproduced the ICE on GCC 5 and trunk.
Now reducing

[Bug c/47837] FAIL: gcc.dg/uninit-pred-7_a.c bogus warning (test for bogus messages, line 26)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #19 from Marek Polacek  ---
Looks fixed then.

[Bug tree-optimization/56902] Fails to SLP with mismatched +/- and negatable constants

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||6.0
 Resolution|--- |FIXED

--- Comment #4 from Richard Biener  ---
This is now fixed.  Note + 3. vs. - 3. should be handled more optimally
(PR68050)

[Bug tree-optimization/37021] Fortran Complex reduction / multiplication not vectorized

[rguenth at gcc dot gnu.org]

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

Bug 56902 Summary: Fails to SLP with mismatched +/- and negatable constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56902

   What|Removed |Added

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

[Bug c++/67248] Variable template cannot be used as dependent name

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-22
 Ever confirmed|0   |1

[Bug c/58309] spurious "parameter set but not used" warning in cilk plus array code

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Another testcase:

int *
fn (int *A, int n, int m)
{
  A[n:m] *= 2;
  return A;
}

I think this is about missing mark_exp_read in c_parser_array_notation.

[Bug bootstrap/68041] [6 Regression] Bootstrap broken on x86_64-apple-darwin14 at revision r229119

[chefmax at gcc dot gnu.org]

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

--- Comment #10 from Maxim Ostapenko  ---
(In reply to Dominique d'Humieres from comment #9)
> > Created attachment 36556 [details]
> > The patch I've posted to gcc-patches ML for review.
> 
> I have not tested the part "removes -lc++abi flag for UBSan on Darwin"
> (later tonight).
> Comment from Iain Sandoe on IRC:
> 
>   we don't use libc++ anyway on GCC, so academic
>   i.e. "it seems the right thing to do"


The patch was approved by Mike in ML
(https://gcc.gnu.org/ml/gcc-patches/2015-10/msg02127.html).

[Bug middle-end/65962] Missed vectorization of strided stores

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
While strided stores are now implemented the case is still not handled because
single-element interleaving takes precedence (and single-element interleaving
isn't supported for stores as that always produces gaps).

I have a patch that produces

.L2:
movdqu  16(%rax), %xmm1
addq$32, %rax
movdqu  -32(%rax), %xmm0
shufps  $136, %xmm1, %xmm0
paddd   %xmm2, %xmm0
pshufd  $85, %xmm0, %xmm1
movd%xmm0, -32(%rax)
movd%xmm1, -24(%rax)
movdqa  %xmm0, %xmm1
punpckhdq   %xmm0, %xmm1
pshufd  $255, %xmm0, %xmm0
movd%xmm1, -16(%rax)
movd%xmm0, -8(%rax)
cmpq%rdx, %rax
jne .L2

when you disable the cost model.  Otherwise it's deemed not profitable.  Using
scatters for AVX could in theory make it profitable (not sure).

t.c:5:3: note: Cost model analysis:
  Vector inside of loop cost: 13
  Vector prologue cost: 1
  Vector epilogue cost: 12
  Scalar iteration cost: 3
  Scalar outside cost: 0
  Vector outside cost: 13
  prologue iterations: 0
  epilogue iterations: 4
t.c:5:3: note: cost model: the vector iteration cost = 13 divided by the scalar
iteration cost = 3 is greater or equal to the vectorization factor = 4.
t.c:5:3: note: not vectorized: vectorization not profitable.
t.c:5:3: note: not vectorized: vector version will never be profitable.

t.c:5:3: note: ==> examining statement: *_8 = _10;
t.c:5:3: note: vect_is_simple_use: operand _10
t.c:5:3: note: def_stmt: _10 = _9 + 7;
t.c:5:3: note: type of def: internal
t.c:5:3: note: vect_model_store_cost: inside_cost = 8, prologue_cost = 0 .

so the strided store has cost 8, that's 4 extracts plus 4 scalar stores.
With AVX we generate

vmovd   %xmm0, -32(%rax)
vpextrd $1, %xmm0, -24(%rax)
vpextrd $2, %xmm0, -16(%rax)
vpextrd $3, %xmm0, -8(%rax)

so it can combine extract and store, with SSE2 we get

pshufd  $85, %xmm0, %xmm1
movd%xmm0, -32(%rax)
movd%xmm1, -24(%rax)
movdqa  %xmm0, %xmm1
punpckhdq   %xmm0, %xmm1
pshufd  $255, %xmm0, %xmm0
movd%xmm1, -16(%rax)
movd%xmm0, -8(%rax)

which is even worse than expected ;)

As usual the cost model isn't target aware enough here (and it errs on the
conservative side here)

[Bug target/60618] ICE when building openssh on hppa w/-ftrapv in gcse.c

[vapier at gentoo dot org]

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

Mike Frysinger  changed:

   What|Removed |Added

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

--- Comment #2 from Mike Frysinger  ---
seems to pass with latest versions of 4.7/4.8

[Bug c++/67838] Rejects-valid-code: templated lambda variable.

[paolo at gcc dot gnu.org]

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

--- Comment #4 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Thu Oct 22 14:55:14 2015
New Revision: 229175

URL: https://gcc.gnu.org/viewcvs?rev=229175=gcc=rev
Log:
2015-10-22  Paolo Carlini  

PR c++/67838
* g++.dg/cpp1y/var-templ46.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/var-templ46.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug driver/68038] "Internal compiler error: Killed: program cc1" should read "Virtual memory exhausted"

[d.u.thibault at bigfoot dot com]

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

Daniel U. Thibault  changed:

   What|Removed |Added

 CC||d.u.thibault at bigfoot dot com

--- Comment #2 from Daniel U. Thibault  ---
Confirmed.

[Bug c++/67829] Bogus "ambiguous template instantiation" error with partial specializations involving a template template parameter

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-22
 Ever confirmed|0   |1

[Bug driver/68029] Strange behavior of -fdiagnostics-color option

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-22
 CC||mpolacek at gcc dot gnu.org
  Component|c   |driver
 Ever confirmed|0   |1

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

[Bug c++/67838] Rejects-valid-code: templated lambda variable.

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini  ---
I'm going to add a testcase to trunk and close the bug, then.

[Bug tree-optimization/19049] not vectorizing a fortran loop

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
Author: rguenth
Date: Thu Oct 22 13:33:17 2015
New Revision: 229172

URL: https://gcc.gnu.org/viewcvs?rev=229172=gcc=rev
Log:
2015-10-22  Richard Biener  

PR tree-optimization/19049
PR tree-optimization/65962
* tree-vect-data-refs.c (vect_analyze_group_access_1): Fall back
to strided accesses if single-element interleaving doesn't work.

* gcc.dg/vect/vect-strided-store-pr65962.c: New testcase.
* gcc.dg/vect/vect-63.c: Adjust.
* gcc.dg/vect/vect-70.c: Likewise.
* gcc.dg/vect/vect-strided-u8-i2-gap.c: Likewise.
* gcc.dg/vect/vect-strided-a-u8-i2-gap.c: Likewise.
* gfortran.dg/vect/pr19049.f90: Likewise.
* gfortran.dg/vect/vect-8.f90: Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/vect-63.c
trunk/gcc/testsuite/gcc.dg/vect/vect-70.c
trunk/gcc/testsuite/gcc.dg/vect/vect-strided-a-u8-i2-gap.c
trunk/gcc/testsuite/gcc.dg/vect/vect-strided-u8-i2-gap.c
trunk/gcc/testsuite/gfortran.dg/vect/pr19049.f90
trunk/gcc/testsuite/gfortran.dg/vect/vect-8.f90
trunk/gcc/tree-vect-data-refs.c

[Bug tree-optimization/19049] not vectorizing a fortran loop

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||6.0
 Resolution|--- |FIXED

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

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

[rguenth at gcc dot gnu.org]

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

Bug 65962 Summary: Missed vectorization of strided stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65962

   What|Removed |Added

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

[Bug middle-end/65962] Missed vectorization of strided stores

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Thu Oct 22 13:33:17 2015
New Revision: 229172

URL: https://gcc.gnu.org/viewcvs?rev=229172=gcc=rev
Log:
2015-10-22  Richard Biener  

PR tree-optimization/19049
PR tree-optimization/65962
* tree-vect-data-refs.c (vect_analyze_group_access_1): Fall back
to strided accesses if single-element interleaving doesn't work.

* gcc.dg/vect/vect-strided-store-pr65962.c: New testcase.
* gcc.dg/vect/vect-63.c: Adjust.
* gcc.dg/vect/vect-70.c: Likewise.
* gcc.dg/vect/vect-strided-u8-i2-gap.c: Likewise.
* gcc.dg/vect/vect-strided-a-u8-i2-gap.c: Likewise.
* gfortran.dg/vect/pr19049.f90: Likewise.
* gfortran.dg/vect/vect-8.f90: Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/vect-63.c
trunk/gcc/testsuite/gcc.dg/vect/vect-70.c
trunk/gcc/testsuite/gcc.dg/vect/vect-strided-a-u8-i2-gap.c
trunk/gcc/testsuite/gcc.dg/vect/vect-strided-u8-i2-gap.c
trunk/gcc/testsuite/gfortran.dg/vect/pr19049.f90
trunk/gcc/testsuite/gfortran.dg/vect/vect-8.f90
trunk/gcc/tree-vect-data-refs.c

[Bug sanitizer/68042] [6 Regression] c-c++-common/asan/(memcmp-1.c|sanity-check-pure-c-1.c) failures on x86_64-apple-darwin14 after r229111

[chefmax at gcc dot gnu.org]

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

--- Comment #3 from Maxim Ostapenko  ---
Created attachment 36562
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36562=edit
Draft patch.

Here an expected patch for memcmp-1.c and sanity-check-pure-c-1.c output
patterns. Does it fix the problem?

[Bug sanitizer/68016] ASan doesn't catch overflow in globals when COPY relocation is involved.

[chefmax at gcc dot gnu.org]

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

Maxim Ostapenko  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #3 from Maxim Ostapenko  ---
Won't fix, this is intentional design decision.

[Bug rtl-optimization/67609] [5/6 Regression] Generates wrong code for SSE2 _mm_load_pd

[vmakarov at gcc dot gnu.org]

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

--- Comment #25 from Vladimir Makarov  ---
(In reply to Vladimir Makarov from comment #24)
> (In reply to Richard Henderson from comment #23)
> > Created attachment 36563 [details]
> > possible patch
> > 
> > Certainly this fixes the executable test case from #c13.
> 

> The patch will force any pseudo which is accessed as a subregister of DImode
> to be spilled.

Probably, I exaggerated with "any", but still the patch will result in more
loads/stores.  So it would be nice to benchmark it.  I'll try to do this on
Friday.

[Bug c/68062] New: ICE when comparing vectors

[hubicka at gcc dot gnu.org]

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

Bug ID: 68062
   Summary: ICE when comparing vectors
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

Hi,
the following testcase:

typedef char __attribute__ ((vector_size (4))) v4qi;
typedef unsigned char __attribute__ ((vector_size (4))) uv4qi;

v4qi v;
void ret(char a)
{
  v4qi c={a,a,a,a};
  uv4qi d={a,a,a,a};
  v = (c!=d);
}

Gives:
b.c:8:6: error: mismatching comparison operand types
 void ret(char a)
  ^
v4qi
uv4qi
D.2265 = c != d;
b.c:8:6: internal compiler error: verify_gimple failed
0xcef09d verify_gimple_in_seq(gimple*)
../../gcc/tree-cfg.c:4767
0xaae4e8 gimplify_body(tree_node*, bool)
../../gcc/gimplify.c:9319
0xaaecb5 gimplify_function_tree(tree_node*)
../../gcc/gimplify.c:9408
0x923fa7 cgraph_node::analyze()
../../gcc/cgraphunit.c:636
0x9274e3 analyze_functions
../../gcc/cgraphunit.c:1091
0x927d90 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2540
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

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

[chrisb2244 at gmail dot com]

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

Bug ID: 68061
   Summary: Can't use [[deprecated]] with requires clause
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chrisb2244 at gmail dot com
  Target Milestone: ---

Either of 

template requires RequiresConcept
const T x(const parameter... p) const { ... }

or 

template
[[deprecated]] const T x(const parameter... p) const { ... }

will compile (using 'g++-trunk -std=c++1z ...')

Using the 'requires' clause along with an attempt to deprecate the function
using [[deprecated]] produces

"two consecutive '[' shall only introduce an attribute before '[' token"

[Bug libstdc++/68058] _GLIBCXX_BEGIN_NAMESPACE_VERSION breaks regex

[dmorilha at gmail dot com]

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

--- Comment #1 from Daniel Morilha  ---
Created attachment 36564
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36564=edit
regex patch

[Bug rtl-optimization/67609] [5/6 Regression] Generates wrong code for SSE2 _mm_load_pd

[vmakarov at gcc dot gnu.org]

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

--- Comment #24 from Vladimir Makarov  ---
(In reply to Richard Henderson from comment #23)
> Created attachment 36563 [details]
> possible patch
> 
> Certainly this fixes the executable test case from #c13.

This patch could be a solution to generate a correct code.  Unfortunately, it
generates ineffective code:

movdqa  reg(%rip), %xmm1
movaps  %xmm1, -24(%rsp)
movsd   %xmm0, -24(%rsp)
movapd  -24(%rsp), %xmm2
movaps  %xmm2, reg(%rip)

instead of better code which would be expected for this case

movdqa  reg(%rip), %xmm1
movlpd  %xmm0, %xmm1
movaps  %xmm1, reg(%rip)

The patch will force any pseudo which is accessed as a subregister of DImode to
be spilled.  Although I don't know how it will affect performance of SPEC
benchmarks.

[Bug middle-end/67989] [4.9/5/6 Regression] g++ ICE on armel valid code

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Component|target  |middle-end
   Assignee|unassigned at gcc dot gnu.org  |ktkachov at gcc dot 
gnu.org

--- Comment #9 from ktkachov at gcc dot gnu.org ---
I think this is a middle-end bug. I have a patch in testing

[Bug rtl-optimization/67609] [5/6 Regression] Generates wrong code for SSE2 _mm_load_pd

[rguenth at gcc dot gnu.org]

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

--- Comment #20 from Richard Biener  ---
(In reply to Jeffrey A. Law from comment #19)
> Preserving the upper part when setting the low part would be expressed via
> STRICT_LOW_PART.  At least that's what I'd expect to see.

According to documentation this is only needed for smaller-than-word subregs:

"When used as an lvalue, @code{subreg} is a word-based accessor.
Storing to a @code{subreg} modifies all the words of @var{reg} that
overlap the @code{subreg}, but it leaves the other words of @var{reg}
alone.

for the case in question, while strict-low-part:

"When storing to a normal @code{subreg} that is smaller than a word,
the other bits of the referenced word are usually left in an undefined
state.  This laxity makes it easier to generate efficient code for
such instructions.  To represent an instruction that preserves all the
bits outside of those in the @code{subreg}, use @code{strict_low_part}
or @code{zero_extract} around the @code{subreg}.

[Bug rtl-optimization/67609] [5/6 Regression] Generates wrong code for SSE2 _mm_load_pd

[law at redhat dot com]

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

--- Comment #19 from Jeffrey A. Law  ---
Preserving the upper part when setting the low part would be expressed via
STRICT_LOW_PART.  At least that's what I'd expect to see.

[Bug middle-end/65962] Missed vectorization of strided stores

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||6.0
 Resolution|--- |FIXED

--- Comment #4 from Richard Biener  ---
Fixed for GCC 6.

[Bug tree-optimization/58497] SLP vectorizes identical operations

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Thu Oct 22 13:36:46 2015
New Revision: 229173

URL: https://gcc.gnu.org/viewcvs?rev=229173=gcc=rev
Log:
2015-10-22  Richard Biener  

PR tree-optimization/58497
* tree-vect-generic.c (ssa_uniform_vector_p): New helper.
(expand_vector_operations_1): Use it.  Lower operations on
all uniform vectors to scalar operations if the HW supports it.

* gcc.dg/tree-ssa/vector-5.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/vector-5.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-generic.c

--- Comment #4 from Richard Biener  ---
Now we fix this up in veclower, still the bug should be addressed in SLP
directly
(also because it affects cost decisions).

[Bug tree-optimization/58497] SLP vectorizes identical operations

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Thu Oct 22 13:36:46 2015
New Revision: 229173

URL: https://gcc.gnu.org/viewcvs?rev=229173=gcc=rev
Log:
2015-10-22  Richard Biener  

PR tree-optimization/58497
* tree-vect-generic.c (ssa_uniform_vector_p): New helper.
(expand_vector_operations_1): Use it.  Lower operations on
all uniform vectors to scalar operations if the HW supports it.

* gcc.dg/tree-ssa/vector-5.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/vector-5.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-generic.c

--- Comment #4 from Richard Biener  ---
Now we fix this up in veclower, still the bug should be addressed in SLP
directly
(also because it affects cost decisions).

[Bug c++/68051] New: copy constructor does not copy default initialized union member

[akju at mailinator dot com]

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

Bug ID: 68051
   Summary: copy constructor does not copy default initialized
union member
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: akju at mailinator dot com
  Target Milestone: ---

The assertion at the end of the following code fails erroneously:

#include 
#include 

struct test
{
union {int v = 0;};
std::string dummy;
};

int main ()
{
test x;
x.v = 1;
test y = x;
assert (y.v == 1);
}

According to the assembly listing, it seems that the copy construction of y
uses the default member initializer of v instead of x.v. This behaviour does
not occur if the dummy member is removed causing the struct to be trivially
copyable.