[Bug target/68286] [6 Regression] ICE: in wide_int_to_tree, at tree.c:1468

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |6.0
   Target Milestone|--- |6.0

[Bug target/68285] [6 Regression] Assembler error on x86_64-linux-gnu: invalid instruction suffix for `movabs'

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*
   Target Milestone|--- |6.0
Summary|Assembler error on  |[6 Regression] Assembler
   |x86_64-linux-gnu: invalid   |error on x86_64-linux-gnu:
   |instruction suffix for  |invalid instruction suffix
   |`movabs'|for `movabs'

[Bug sanitizer/68065] Size calculations for VLAs can overflow

[danielmicay at gmail dot com]

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

--- Comment #25 from Daniel Micay  ---
> Just as GCC on Windows...

Sure. I'm pointing out that Windows has had safety here for years, while Linux
doesn't. It should. It really shouldn't be possible to exploit well-defined
code. Running out of resources and aborting isn't ideal but that's at least
sane and doing better doesn't seem possible for C.

> Figures please, otherwise that's just FUD as usual.

... pointing out that something isn't implemented ideally is FUD now? If it had
no significant performance hit (which should be the case for optimized C,
because it shouldn't need to reserve a register), then it would surely be
enabled by default.

We tried enabling it in Arch Linux but it had to be backed out due to
performance concerns. Some compatibility issues came up (due to inline
assembly) and then investigation into it demonstrated that it wasn't really
causing a negligible performance hit, especially on i686. Among other things,
it causes a significant performance hit (over 5% slower in a malloc
micro-benchmark on x86_64, more on i686) for jemalloc which has large enough
stack frames to trigger it and essentially all of the code is inlined. It's
usually pretty small... but a lot more than it should be.

Anyway, I was just trying to be helpful. I'm only really interested in Android
these days so GCC isn't really something I care about... I just happened to
have thoughts about this stuff because I worked on similar issues in the Rust
compiler / standard libraries (Rust is why LLVM is getting proper stack
checking at all, Clang implements -fstack-check as a no-op right now for
'compatibility') and recently Bionic.

[Bug c++/64267] [DR 482] Qualified declarators in redeclarations

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug sanitizer/68065] Size calculations for VLAs can overflow

[ebotcazou at gcc dot gnu.org]

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

--- Comment #26 from Eric Botcazou  ---
> Sure. I'm pointing out that Windows has had safety here for years, while
> Linux doesn't.

Thanks for correcting, the initial formulation was quite misleading and could
be understood as GCC not being on par with MSVC and Clang on Windows; it is.

> ... pointing out that something isn't implemented ideally is FUD now? If it
> had no significant performance hit (which should be the case for optimized
> C, because it shouldn't need to reserve a register), then it would surely be
> enabled by default.

Well, the sentence is "The implementation of -fstack-check in GCC does have
significant overhead" so it seems to be talking about something implemented.
-fstack-check has a measurable overhead but doesn't cause a significant
performance hit in most cases.

> We tried enabling it in Arch Linux but it had to be backed out due to
> performance concerns. Some compatibility issues came up (due to inline
> assembly) and then investigation into it demonstrated that it wasn't really
> causing a negligible performance hit, especially on i686. Among other
> things, it causes a significant performance hit (over 5% slower in a malloc
> micro-benchmark on x86_64, more on i686) for jemalloc which has large enough
> stack frames to trigger it and essentially all of the code is inlined. It's
> usually pretty small... but a lot more than it should be.

Thanks for the figures.  There is a specific issue on x86{-64}/Linux caused by
the reservation of the frame pointer in order to be able to unwind the stack
for propagating exceptions (stack checking was initially implemented for Ada
and the Ada language requires stack overflows to be turned into exceptions that
can be caught) and which also gives rise to PR target/67265; that's not the
case on other platforms.  I'll propose a fix for the PR.

[Bug fortran/67826] gcc/fortran/openmp.c:1808: bad test ?

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #5 from Dominique d'Humieres  ---
No plan to backport to 5.3, closing as FIXED.

[Bug bootstrap/68271] [6 Regression] Boostrap fails on x86_64-apple-darwin14 at r230084

[dominiq at lps dot ens.fr]

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

--- Comment #12 from Dominique d'Humieres  ---
Is the problem that difficult to fix?

[Bug c/68272] Unwanted out-of-line instances for C inline functions that are also GCC builtins.

[sorganov at gmail dot com]

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

Sergey Organov  changed:

   What|Removed |Added

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

--- Comment #2 from Sergey Organov  ---
Yeah, sorry, my mistake.  When I was preparing a simple test-case for a problem
that I observed with gcc 5.2.0 (built for rare target), I missed that gcc 4.x
has -std=c89 by default. I'll need to dig into my original problem further.

[Bug middle-end/68291] New: [6 regression] ICE in emit_move_insn, at expr.c:3540

[ro at gcc dot gnu.org]

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

Bug ID: 68291
   Summary: [6 regression] ICE in emit_move_insn, at expr.c:3540
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
  Host: sparc*-sun-solaris2.*
Target: sparc*-sun-solaris2.*
 Build: sparc*-sun-solaris2.*

On 64-bit Solaris/SPARC, I see a number of testsuite regressions:

FAIL: gcc.c-torture/compile/pr39928-1.c   -O2  (internal compiler error)
FAIL: gcc.c-torture/compile/pr39928-1.c   -O2  (test for excess errors)
FAIL: gcc.c-torture/compile/pr39928-1.c   -O2 -flto  (internal compiler error)
FAIL: gcc.c-torture/compile/pr39928-1.c   -O2 -flto  (test for excess errors)
FAIL: gcc.c-torture/compile/pr39928-1.c   -O2 -flto -flto-partition=none 
(internal compiler error)
FAIL: gcc.c-torture/compile/pr39928-1.c   -O2 -flto -flto-partition=none  (test
for excess errors)
FAIL: gcc.c-torture/compile/pr39928-1.c   -O3 -g  (internal compiler error)
FAIL: gcc.c-torture/compile/pr39928-1.c   -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/compile/pr39928-1.c   -Os  (internal compiler error)
FAIL: gcc.c-torture/compile/pr39928-1.c   -Os  (test for excess errors)

They show the following ICE:

/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.c-torture/compile/pr39928-1.c: In
function 'vq_nbest':
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.c-torture/compile/pr39928-1.c:9:1:
internal compiler error: in emit_move_insn, at expr.c:3540
0x4a8507 emit_move_insn(rtx_def*, rtx_def*)
/vol/gcc/src/hg/trunk/local/gcc/expr.c:3539
0x4aa303 emit_group_load_1
/vol/gcc/src/hg/trunk/local/gcc/expr.c:1591
0x4aa45f emit_group_load(rtx_def*, rtx_def*, tree_node*, int)
/vol/gcc/src/hg/trunk/local/gcc/expr.c:1754
0x513ed3 expand_function_end()
/vol/gcc/src/hg/trunk/local/gcc/function.c:5479
0x39fa0b construct_exit_block
/vol/gcc/src/hg/trunk/local/gcc/cfgexpand.c:5813
0x39fa0b execute
/vol/gcc/src/hg/trunk/local/gcc/cfgexpand.c:6319

Reproduce with

cc1 -fpreprocessed pr39928-1.i -mptr64 -mstack-bias -mno-v8plus -mcpu=v9 -quiet
-m64 -O2 -o pr39928-1.s

  Rainer

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

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #5 from Rainer Orth  ---
Created attachment 36685
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36685=edit
-fdump-tree-optimized dump

[Bug target/68286] [6 Regression] ICE: in wide_int_to_tree, at tree.c:1468

[trippels at gcc dot gnu.org]

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

--- Comment #1 from Markus Trippelsdorf  ---
Started with r230098.

[Bug fortran/68283] ice: gfc_variable_attr(): Bad array reference

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-11-11
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Did you provide the right test? The one (duplicated?) in comment 0 does not
compile

pr68283.f90:6:15:

   TYPE neb_var_type
   2
  REAL(KIND=dp), DIMENSION(:, :),  POINTER  :: xyz, int, wrk

   END TYPE neb_var_type

   IMPLICIT NONE
   1

Error: IMPLICIT NONE statement at (1) cannot follow derived type declaration
statement at (2)
pr68283.f90:14:66:

 dot_product_band(neb_env,forces%wrk(:,i),tangent,Mmatrix,error)*tangent
  1

Error: Symbol 'error' at (1) has no IMPLICIT type
pr68283.f90:10:49:

 INTEGER, INTENT(IN)  :: i
 1

Error: Symbol at (1) is not a DUMMY variable
pr68283.f90:14:60:

 dot_product_band(neb_env,forces%wrk(:,i),tangent,Mmatrix,error)*tangent
1

Error: Symbol 'mmatrix' at (1) has no IMPLICIT type
pr68283.f90:14:28:

 dot_product_band(neb_env,forces%wrk(:,i),tangent,Mmatrix,error)*tangent
1

Error: Symbol 'neb_env' at (1) has no IMPLICIT type
pr68283.f90:14:52:

 dot_product_band(neb_env,forces%wrk(:,i),tangent,Mmatrix,error)*tangent
1

Error: Symbol 'tangent' at (1) has no IMPLICIT type

Fixing the error does not lead to any ICE.

[Bug fortran/68283] [5/6 Regression] ice: gfc_variable_attr(): Bad array reference

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||manu at gcc dot gnu.org
Summary|ice: gfc_variable_attr():   |[5/6 Regression] ice:
   |Bad array reference |gfc_variable_attr(): Bad
   ||array reference

--- Comment #3 from Dominique d'Humieres  ---
Compiling the test with revision r215860 (2014-10-03) gives

pr68283.f90:7.15:

  IMPLICIT NONE
   1
pr68283.f90:4.19:

  TYPE neb_var_type
   2
Error: IMPLICIT NONE statement at (1) cannot follow derived type declaration
statement at (2)
pr68283.f90:11.49:

INTEGER, INTENT(IN)  :: i
 1
Error: Symbol at (1) is not a DUMMY variable

With revision r216098 (2014-10-10) it gives

pr68283.f90:7.15:

  IMPLICIT NONE
   1
pr68283.f90:4.19:

  TYPE neb_var_type
INTEGER, INTENT(IN)  :: i
 1
Error: Symbol at (1) is not a DUMMY variable
pr68283.f90:15.60:

dot_product_band(neb_env,forces%wrk(:,i),tangent,Mmatrix,error)*tangent
1
Error: Symbol 'mmatrix' at (1) has no IMPLICIT type
pr68283.f90:15.28:

dot_product_band(neb_env,forces%wrk(:,i),tangent,Mmatrix,error)*tangent
1
Error: Symbol 'neb_env' at (1) has no IMPLICIT type
pr68283.f90:15.52:

dot_product_band(neb_env,forces%wrk(:,i),tangent,Mmatrix,error)*tangent
1
Error: Symbol 'tangent' at (1) has no IMPLICIT type
pr68283.f90:17.20:

END MODULE neb_utils
1
Internal Error at (1):
gfc_variable_attr(): Bad array reference

Usual suspect r215974 (pr44054).

[Bug libfortran/66756] libgfortran: ThreadSanitizer: lock-order-inversion

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
> but why do set the status on waiting ? Is there any question implied ?

Yes. In a perfect world, someone else would have to confirm it. In GCC land,
you can change the status to NEW if you still see the problem.

[Bug libstdc++/64651] std::rethrow_exception not found by ADL

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Fixed for gcc 6.

[Bug bootstrap/68271] [6 Regression] Boostrap fails on x86_64-apple-darwin14 at r230084

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
Quick temporary fix is easy, just make pragma_kind in cp/parser.h 8 bit, and
change id < 64 to id < 256 in c-family and update the comment.  This I believe
shouldn't make the C++ token any larger.
And then incrementally we can improve this by dropping pragma_kind.

[Bug middle-end/68292] [6 regression] ICE in copy_blkmode_to_reg, at expr.c:2277

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug middle-end/68292] New: [6 regression] ICE in copy_blkmode_to_reg, at expr.c:2277

[ro at gcc dot gnu.org]

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

Bug ID: 68292
   Summary: [6 regression] ICE in copy_blkmode_to_reg, at
expr.c:2277
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
  Host: sparc*-sun-solaris2.*
Target: sparc*-sun-solaris2.*
 Build: sparc*-sun-solaris2.*

Two testcases recently regressed on 64-bit Solaris/SPARC:

FAIL: gcc.dg/pr63594-1.c (internal compiler error)
FAIL: gcc.dg/pr63594-1.c (test for excess errors)
FAIL: gcc.dg/pr63594-2.c (internal compiler error)
FAIL: gcc.dg/pr63594-2.c (test for excess errors)
WARNING: gcc.dg/pr63594-2.c compilation failed to produce executable

/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/pr63594-1.c: In function
'test1char32':
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/pr63594-1.c:23:10: internal
compiler error: in copy_blkmode_to_reg, at expr.c:2277
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/pr63594-1.c:37:1: note: in
expansion of macro 'T'
0x4ae4b7 copy_blkmode_to_reg(machine_mode, tree_node*)
/vol/gcc/src/hg/trunk/local/gcc/expr.c:2277
0x396e3b expand_return
/vol/gcc/src/hg/trunk/local/gcc/cfgexpand.c:3447
0x396e3b expand_gimple_stmt_1
/vol/gcc/src/hg/trunk/local/gcc/cfgexpand.c:3546
0x396e3b expand_gimple_stmt
/vol/gcc/src/hg/trunk/local/gcc/cfgexpand.c:3673
0x398733 expand_gimple_basic_block
/vol/gcc/src/hg/trunk/local/gcc/cfgexpand.c:5677
0x39f7f7 execute
/vol/gcc/src/hg/trunk/local/gcc/cfgexpand.c:6289

Reproduce with

cc1 -fpreprocessed pr63594-1.i -mptr64 -mstack-bias -mno-v8plus -mcpu=v9 -quiet
-m64 -O2 -o pr63594-1.s

  Rainer

[Bug fortran/68283] ice: gfc_variable_attr(): Bad array reference

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch

--- Comment #2 from Joost VandeVondele  
---
(In reply to Dominique d'Humieres from comment #1)
> Did you provide the right test? The one (duplicated?) in comment 0 does not
> compile

yes, it is an ice-on-invalid-code, to avoid confusion with the pasting mess in
comment #0, here it is again:

> cat bug.f90
MODULE neb_utils
  INTEGER, PARAMETER :: dp=8
  TYPE neb_var_type
 REAL(KIND=dp), DIMENSION(:, :),  POINTER  :: xyz, int, wrk
  END TYPE neb_var_type
  IMPLICIT NONE
CONTAINS
  RECURSIVE SUBROUTINE get_neb_force(&
  )
INTEGER, INTENT(IN)  :: i
TYPE(neb_var_type), POINTER  :: forces
REAL(KIND=dp), ALLOCATABLE, DIMENSION(:) :: dtmp1, wrk
   dtmp1   = forces%wrk(:,i)- &
dot_product_band(neb_env,forces%wrk(:,i),tangent,Mmatrix,error)*tangent
  END SUBROUTINE get_neb_force
END MODULE neb_utils

[Bug target/68285] [6 Regression] Assembler error on x86_64-linux-gnu: invalid instruction suffix for `movabs'

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #1 from Uroš Bizjak  ---
Fixed by [1].

[1] https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01259.html

[Bug fortran/68268] configure: error: GNU Fortran is not working;

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
Executing "./configure ..." means you are bootstrapping in the sources
directory which is not supported according the manual. You must create a build
directory, cd to it, and execute "sources_dir/./configure ..." from it, then
"make".

[Bug tree-optimization/68234] tree-vrp pass need to be improved when handling ASSERT_EXPR

[jiwang at gcc dot gnu.org]

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

Jiong Wang  changed:

   What|Removed |Added

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

--- Comment #6 from Jiong Wang  ---
fixed by r230150.

[Bug fortran/68289] Missing diagnostic pragmas

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez  ---
(In reply to Dominique d'Humieres from comment #1)
> IMO implementing the diagnostic pragmas in gfortran will just be a waste of
> time. Thus if someone want to close this PR as WONTFIX, I won't object!

Why? Doesn't Fortran have pragmas?

[Bug tree-optimization/68234] tree-vrp pass need to be improved when handling ASSERT_EXPR

[jiwang at gcc dot gnu.org]

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

--- Comment #5 from Jiong Wang  ---
Author: jiwang
Date: Wed Nov 11 10:51:31 2015
New Revision: 230150

URL: https://gcc.gnu.org/viewcvs?rev=230150=gcc=rev
Log:
[Patch] PR tree-optimization/68234 Improve range info for loop Phi node

2015-11-11  Richard Biener  
Jiong Wang  
gcc/
  PR tree-optimization/68234
  * tree-vrp.c (vrp_visit_phi_node): Extend SCEV check to those loop PHI
  node which estimiated to be VR_VARYING initially.

gcc/testsuite/
  * gcc.dg/tree-ssa/pr68234.c: New testcase. 


Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr68234.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vrp.c

[Bug fortran/68289] Missing diagnostic pragmas

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC|manu at gcc dot gnu.org|

--- Comment #4 from Manuel López-Ibáñez  ---
(In reply to Dominique d'Humieres from comment #3)
> > > IMO implementing the diagnostic pragmas in gfortran will just be a waste 
> > > of
> > > time. Thus if someone want to close this PR as WONTFIX, I won't object!
> >
> > Why? Doesn't Fortran have pragmas?
> 
> Yes indeed, but I don't see the use (interest) of diagnostic pragmas in
> gfortran.
> I am pretty sure that this PR will rot forever.

Oh, well, that is up to Fortran devs and users. (I'm pretty sure many people
said that about C/C++ diagnostic pragmas until they started to be widely use.)

[Bug rtl-optimization/68282] Optimization fails to remove unnecessary sign extension instruction

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||x86_64-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-11
  Component|other   |rtl-optimization
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
The reason this is not needed is that c >> 2 + 1 cannot be > 255.  Note that I
see

func:
.LFB0:
.cfi_startproc
shrb$2, %dil
leaq1(%rdi), %rax
andl$127, %eax
movltable(,%rax,4), %eax
ret

but similar the andl is not needed here.  Not sure where that comes from as
we expand from

func (unsigned char c)
{
  unsigned char _2;
  int _3;
  int _4;
  int _6;

  :
  _2 = c_1(D) >> 2;
  _3 = (int) _2;
  _4 = _3 + 1;
  _6 = table[_4];
  return _6;

(insn 8 7 9 (parallel [
(set (reg:QI 95)
(lshiftrt:QI (reg/v:QI 91 [ c ])
(const_int 2 [0x2])))
(clobber (reg:CC 17 flags))
]) t.c:5 -1
 (nil))

(insn 9 8 10 (set (reg:SI 96)
(zero_extend:SI (reg:QI 95))) t.c:5 -1
 (nil))

(insn 10 9 11 (parallel [
(set (reg:SI 97)
(plus:SI (reg:SI 96)
(const_int 1 [0x1])))
(clobber (reg:CC 17 flags))
]) t.c:5 -1
 (nil))

(insn 11 10 12 (set (reg:DI 98)
(sign_extend:DI (reg:SI 97))) t.c:5 -1
 (nil))

(insn 12 11 13 (set (reg:SI 99)
(mem:SI (plus:DI (mult:DI (reg:DI 98)
(const_int 4 [0x4]))
(reg/f:DI 94)) [1 table S4 A32])) t.c:5 -1
 (nil))

I wonder how we conclude that exchanging the zero-extend with the plus is ok.

[Bug tree-optimization/66388] [6 Regression] Test gcc.target/i386/pr49781-1.c failed because of recent scev overflow patches.

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from amker at gcc dot gnu.org ---
Should be fixed.

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

[ro at gcc dot gnu.org]

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

--- Comment #6 from Rainer Orth  ---
The new gcc.dg/tree-ssa/vector-5.c testcase FAILs on 64-bit Solaris/SPARC:

FAIL: gcc.dg/tree-ssa/vector-5.c scan-tree-dump-times optimized " * 3;" 1

  Rainer

[Bug fortran/67826] gcc/fortran/openmp.c:1808: bad test ?

[dominiq at gcc dot gnu.org]

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

--- Comment #4 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Wed Nov 11 10:30:25 2015
New Revision: 230148

URL: https://gcc.gnu.org/viewcvs?rev=230148=gcc=rev
Log:
2015-11-11  Dominique d'Humieres 

PR fortran/67826
* openmp.c (gfc_omp_udr_find): Fix typo.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/openmp.c

[Bug fortran/53934] Better CPP macro diagnostics

[dominiq at lps dot ens.fr]

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

Bug 44054 Summary: Handle -Werror, -Werror=, -fdiagnostics-show-option, !GCC$ 
diagnostic (pragmas) and color
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44054

   What|Removed |Added

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

[Bug fortran/68289] New: Missing diagnostic pragmas

[dominiq at lps dot ens.fr]

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

Bug ID: 68289
   Summary: Missing diagnostic pragmas
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
  Target Milestone: ---

From pr44054 comment 27:

> From my POV, this is FIXED.
>
> The only thing missing is the diagnostic pragmas:
> https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html#Diagnostic-Pragmas
>
> I'm not sure how pragmas work in the Fortran FE, but it should be a matter
> of following more or less what the C/C++ FE do to interface with 
> diagnostic.c. 
>
> I'm not going to work on that. I leave to the Fortran maintainers whether
> to track that on a different PR and close this one or leave this one open.

[Bug fortran/68283] [5/6 Regression] ice: gfc_variable_attr(): Bad array reference

[manu at gcc dot gnu.org]

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

--- Comment #4 from Manuel López-Ibáñez  ---
(In reply to Dominique d'Humieres from comment #3)
> 
> With revision r216098 (2014-10-10) it gives

This seems a problem with the buffering of errors that Fortran does. I might
have missed some cases. Or I may have mistakenly changed a gfc_error with
gfc_error_now or viceversa. The first step would be to compare those gfc_error*
calls for one working vs. one non-working revision and see if they match. The
second step would be to compare why the working revision does not generate (or
prints) the errors but the non-working one does. Something must be clearing the
buffering flag (or not setting it) when it should not.

> Internal Error at (1):
> gfc_variable_attr(): Bad array reference

Does the ICE happens while printing an error? If not, something must be
checking for buffered errors and changing behavior depending on that. The new
code might be clearing the buffered errors flag (or not buffering them at all)
too early.

[Bug c++/68284] -Wlong-long causes dialect options to be ignored

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Right, this is the expected behavior.

[Bug c++/68290] g++.dg/concepts/auto1.C FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug c++/68290] New: g++.dg/concepts/auto1.C FAILs

[ro at gcc dot gnu.org]

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

Bug ID: 68290
   Summary: g++.dg/concepts/auto1.C FAILs
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: jason at gcc dot gnu.org
  Target Milestone: ---
  Host: sparc*-sun-solaris2.*
Target: sparc*-sun-solaris2.*
 Build: sparc*-sun-solaris2.*

The new g++.dg/concepts/auto1.C testcase ICEs on 64-bit Solaris/SPARC:

/vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/concepts/auto1.C:15:13: error:
unable to deduce 'A' from 'a2'
/vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/concepts/auto1.C:15:13: note: 
 deduced conflicting types for parameter 'C' ('double' and 'float')
/vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/concepts/auto1.C:16:6:
internal compiler error: canonical types differ for identical types C and C
0x3cd62b comptypes(tree_node*, tree_node*, int)
/vol/gcc/src/hg/trunk/local/gcc/cp/typeck.c:1431
0x2b32d3 template_args_equal
/vol/gcc/src/hg/trunk/local/gcc/cp/pt.c:7842
0x2b3a93 comp_template_args_with_info
/vol/gcc/src/hg/trunk/local/gcc/cp/pt.c:7889
0x2c35d7 comp_template_args(tree_node*, tree_node*)
/vol/gcc/src/hg/trunk/local/gcc/cp/pt.c:7907
0x2c35d7 spec_hasher::equal(spec_entry*, spec_entry*)
/vol/gcc/src/hg/trunk/local/gcc/cp/pt.c:1648
0x2f687b lookup_template_class_1
/vol/gcc/src/hg/trunk/local/gcc/cp/pt.c:8288
0x2f687b lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
/vol/gcc/src/hg/trunk/local/gcc/cp/pt.c:8602
0x4218fb finish_template_type(tree_node*, tree_node*, int)
/vol/gcc/src/hg/trunk/local/gcc/cp/semantics.c:3063
0x3a9e6f cp_parser_template_id
/vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:14501
0x3aa1d3 cp_parser_class_name
/vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:20700
0x397a47 cp_parser_qualifying_entity
/vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:5999
0x397a47 cp_parser_nested_name_specifier_opt
/vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:5685
0x3880e7 cp_parser_template_introduction
/vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:25001
0x3880e7 cp_parser_template_declaration_after_export
/vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:25152
0x388bf3 cp_parser_declaration
/vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:11760
0x3be6c7 cp_parser_declaration_seq_opt
/vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:11644
0x3bea27 cp_parser_translation_unit
/vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:4169
0x3bea27 c_parse_file()
/vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:36342
0x536c37 c_common_parse_file()
/vol/gcc/src/hg/trunk/local/gcc/c-family/c-opts.c:1064

Compile with

cc1plus -fpreprocessed auto1.ii -mptr64 -mstack-bias -mno-v8plus -mcpu=v9
-quiet -m64 -std=c++1z -version -o auto1.s

  Rainer

[Bug target/68293] New: [6 Regression] ICE: in prepare_cmp_insn, at optabs.c:3813 with vector compare with -O0 @ aarch64

[zsojka at seznam dot cz]

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

Bug ID: 68293
   Summary: [6 Regression] ICE: in prepare_cmp_insn, at
optabs.c:3813 with vector compare with -O0 @ aarch64
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---

Created attachment 36684
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36684=edit
reduced testcase

This seems to be a recent regression.

r230014 is fine (only 6 ICEs in prepare_cmp_insn in the whole testsuite run),
r230115 and r230151 are failing (hundreds of ICEs)

Compiler output:
$ cc1 -quiet testcase.c
testcase.c: In function 'foo':
testcase.c:6:13: internal compiler error: in prepare_cmp_insn, at optabs.c:3813
   return *u == *v;
 ^

0xa00156 prepare_cmp_insn
/repo/gcc-trunk/gcc/optabs.c:3813
0xa00251 emit_cmp_and_jump_insns(rtx_def*, rtx_def*, rtx_code, rtx_def*,
machine_mode, int, rtx_def*, int)
/repo/gcc-trunk/gcc/optabs.c:3960
0x737d82 do_compare_rtx_and_jump(rtx_def*, rtx_def*, rtx_code, int,
machine_mode, rtx_def*, rtx_code_label*, rtx_code_label*, int)
/repo/gcc-trunk/gcc/dojump.c:1140
0x738d58 do_compare_and_jump
/repo/gcc-trunk/gcc/dojump.c:1219
0x73b089 do_jump_1(tree_code, tree_node*, tree_node*, rtx_code_label*,
rtx_code_label*, int)
/repo/gcc-trunk/gcc/dojump.c:231
0x7ee12f expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/repo/gcc-trunk/gcc/expr.c:9076
0x6c5d6b expand_gimple_stmt_1
/repo/gcc-trunk/gcc/cfgexpand.c:3613
0x6c5d6b expand_gimple_stmt
/repo/gcc-trunk/gcc/cfgexpand.c:3673
0x6c76e2 expand_gimple_basic_block
/repo/gcc-trunk/gcc/cfgexpand.c:5679
0x6cce6e execute
/repo/gcc-trunk/gcc/cfgexpand.c:6291
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

$ xgcc -v  
Using built-in specs.
COLLECT_GCC=/repo/build-trunk-230151-checking-yes-rtl-df-nographite-aarch64/gcc/xgcc
Target: aarch64-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-checking=yes,rtl,df --without-cloog --without-ppl --without-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=aarch64-unknown-linux-gnu
--with-ld=/usr/bin/aarch64-unknown-linux-gnu-ld
--with-as=/usr/bin/aarch64-unknown-linux-gnu-as --with-sysroot=/chroot/aarch64
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-230151-checking-yes-rtl-df-nographite-aarch64
Thread model: posix
gcc version 6.0.0 2015 (experimental) (GCC) 

Tested revisions:
r230151 - ICE
r230115 - ICE
r230014 - OK
4_5-branch r230093 - OK

[Bug libstdc++/64651] std::rethrow_exception not found by ADL

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Author: redi
Date: Wed Nov 11 10:08:23 2015
New Revision: 230147

URL: https://gcc.gnu.org/viewcvs?rev=230147=gcc=rev
Log:
PR libstdc++/64651
* libsupc++/exception_ptr.h (rethrow_exception): Add using-declaration
to __exception_ptr namespace.
* testsuite/18_support/exception_ptr/rethrow_exception.cc: Test ADL.
Remove unnecessary test variables.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/libsupc++/exception_ptr.h
trunk/libstdc++-v3/testsuite/18_support/exception_ptr/rethrow_exception.cc

[Bug fortran/68289] Missing diagnostic pragmas

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-11-11
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
IMO implementing the diagnostic pragmas in gfortran will just be a waste of
time. Thus if someone want to close this PR as WONTFIX, I won't object!

[Bug middle-end/68291] [6 regression] ICE in emit_move_insn, at expr.c:3540

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||ienkovich at gcc dot gnu.org,
   ||trippels at gcc dot gnu.org

--- Comment #1 from Markus Trippelsdorf  ---
Probably more r230098 outfall. Adding CC.

[Bug target/68275] bb-slp-38 FAILs on armeb

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-11
  Component|tree-optimization   |target
Version|unknown |6.0
 Ever confirmed|0   |1

--- Comment #4 from Richard Biener  ---

/home/christophe.lyon/src/GCC/sources/gcc-fsf/trunk-for-crontab/gcc/testsuite/gcc.dg/vect/bb-slp-38.c:23:3:
note: Load permutation 0 0 3 3 
+/home/christophe.lyon/src/GCC/sources/gcc-fsf/trunk-for-crontab/gcc/testsuite/gcc.dg/vect/bb-slp-38.c:23:3:
note: unsupported vect permute { 0 0 3 3 }

so it's a similar reason.  BE vectorization being cripled but still being
effective target vect_perm.

Looks like BE supports vectorizing the permutation { 0 0 } so we get the
first half of the BB vectorized with v2si vectors.  vec_perm_cost just
dispatches to arm_expand_vec_perm_const which dispatches to helpers where
most of them have sth like

  /* TODO: Handle GCC's numbering of elements for big-endian.  */
  if (BYTES_BIG_ENDIAN)
return false;

Confirmed.  Backend bug IMHO (or testsuite one in that vect_perm is too generic
to capture the half-way state armeb is in.

What's so difficult to fix your target?  It looks like there is really no
interest in it given those TODOs.

[Bug rtl-optimization/68287] [6 Regression] conditional jump or move depends on uninitialized value in lra-lives.c:1048

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Started from r230027 which is my commit, sorry for the noise, I'm going to fix
it.

Martin

[Bug fortran/58189] Color diagnostics for gfortran

[dominiq at lps dot ens.fr]

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

Bug 44054 Summary: Handle -Werror, -Werror=, -fdiagnostics-show-option, !GCC$ 
diagnostic (pragmas) and color
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44054

   What|Removed |Added

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

[Bug fortran/44054] Handle -Werror, -Werror=, -fdiagnostics-show-option, !GCC$ diagnostic (pragmas) and color

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #28 from Dominique d'Humieres  ---
From comment 27:

> From my POV, this is FIXED.

>
> The only thing missing is the diagnostic pragmas:
> https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html#Diagnostic-Pragmas

>
> I'm not sure how pragmas work in the Fortran FE, but it should be a matter
> of following more or less what the C/C++ FE do to interface with 
> diagnostic.c. 

>
> I'm not going to work on that. I leave to the Fortran maintainers whether
> to track that on a different PR and close this one or leave this one open.

I have filed pr68289, closing as FIXED.

[Bug fortran/68289] Missing diagnostic pragmas

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
> > IMO implementing the diagnostic pragmas in gfortran will just be a waste of
> > time. Thus if someone want to close this PR as WONTFIX, I won't object!
>
> Why? Doesn't Fortran have pragmas?

Yes indeed, but I don't see the use (interest) of diagnostic pragmas in
gfortran.
I am pretty sure that this PR will rot forever.

[Bug c/68272] Unwanted out-of-line instances for C inline functions that are also GCC builtins.

[sorganov at gmail dot com]

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

Sergey Organov  changed:

   What|Removed |Added

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

--- Comment #3 from Sergey Organov  ---
Sorry again, but digging into the problem further, it still seems like a bug in
GCC (both 4.x and 5.x).

First, for gcc 4.x, using neither -std=gnu99 nor -std=gnu11 (nor c11, nor c99)
makes the problem go away.

Second, declaring the inline function "extern inline" allows the example to
compile/link correctly with -std=gnu89 (but not in recent x99 or x11 modes)
that is expected and sane behavior.

Now, from the GCC manual, it follows that to port "inlines" from 89 to 99 and
above, one needs to (mostly) turn "extern inline" to "inline", that does work
in all other cases but GCC builtin functions.

I realize all this is on the raw edge with standard C functions, but current
GCC behavior with builtins in x99 and x11 modes seems to be just a left-over
from x89 days. Even from pure consistency POV it looks like a good idea to fix
it, provided there is no good reason to violate standard C "inline" semantics
for GCC builtin functions.

[Bug middle-end/68291] [6 regression] ICE in emit_move_insn, at expr.c:3540

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug rtl-optimization/68282] Optimization fails to remove unnecessary sign extension instruction

[sgunderson at bigfoot dot com]

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

sgunderson at bigfoot dot com changed:

   What|Removed |Added

 CC||sgunderson at bigfoot dot com

--- Comment #2 from sgunderson at bigfoot dot com ---
Shouldn't it be possible to fold the incl into the mov, too?

shrl$2, %edi
movltable+4(,%rdi,4), %eax
retq

[Bug rtl-optimization/68269] [5/6 regression] FAIL: gcc.dg/pr68129_1.c (internal compiler error)

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-11
 CC||segher at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Segher Boessenkool  ---
Confirmed.

[Bug target/68277] [5] [SH]: error: insn does not satisfy its constraints when compiling erlang

[kkojima at gcc dot gnu.org]

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

--- Comment #1 from Kazumoto Kojima  ---
Created attachment 36686
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36686=edit
reduced test case for -O1

It fails on trunk too.  It seems that the problematic add insn

(insn 765 764 300 46 (set (reg:SI 10 r10)
(plus:SI (reg:SI 1 r1)
(const_int 4 [0x4]))) add3i.c:7 66 {*addsi3}
 (nil))

is generated with the old reload to load a memory address of
the complex atomic_compare_and_swapsi_soft_gusa insn and
postreload complains about that insn.

[Bug target/67305] [6 Regression] gcc.c-torture/compile/20121027-1.c ICE on arm-none-eabi

[jiwang at gcc dot gnu.org]

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

--- Comment #9 from Jiong Wang  ---
Author: jiwang
Date: Wed Nov 11 12:30:46 2015
New Revision: 230158

URL: https://gcc.gnu.org/viewcvs?rev=230158=gcc=rev
Log:
[ARM] PR67305, tighten neon_vector_mem_operand on eliminable registers

2015-11-11  Jiong Wang  
Jim Wilson  

PR target/67305
* config/arm/arm.md (neon_vector_mem_operand): Return FALSE if strict
be true and eliminable registers mentioned.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c

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

[ro at gcc dot gnu.org]

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

--- Comment #8 from Rainer Orth  ---
Created attachment 36687
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36687=edit
-fdump-tree-dom2-details dump

[Bug bootstrap/68271] [6 Regression] Boostrap fails on x86_64-apple-darwin14 at r230084

[dominiq at lps dot ens.fr]

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

--- Comment #14 from Dominique d'Humieres  ---
> Quick temporary fix is easy, just make pragma_kind in cp/parser.h 8 bit,
> and change id < 64 to id < 256 in c-family and update the comment.
> This I believe shouldn't make the C++ token any larger.
> And then incrementally we can improve this by dropping pragma_kind.

I have successfully bootstrapped r230151 with the following patch

--- ../_clean/gcc/cp/parser.h   2015-11-10 01:54:44.0 +0100
+++ gcc/cp/parser.h 2015-11-11 12:10:28.0 +0100
@@ -48,7 +48,7 @@ struct GTY (()) cp_token {
   /* Token flags.  */
   unsigned char flags;
   /* Identifier for the pragma.  */
-  ENUM_BITFIELD (pragma_kind) pragma_kind : 6;
+  ENUM_BITFIELD (pragma_kind) pragma_kind : 8;
   /* True if this token is from a context where it is implicitly extern "C" */
   BOOL_BITFIELD implicit_extern_c : 1;
   /* True if an error has already been reported for this token, such as a
--- ../_clean/gcc/c-family/c-pragma.c   2015-11-10 01:54:43.0 +0100
+++ gcc/c-family/c-pragma.c 2015-11-11 12:10:25.0 +0100
@@ -1372,7 +1372,7 @@ c_register_pragma_1 (const char *space, 

   /* The C++ front end allocates 6 bits in cp_token; the C front end
 allocates 7 bits in c_token.  At present this is sufficient.  */
-  gcc_assert (id < 64);
+  gcc_assert (id < 256);
 }

   cpp_register_deferred_pragma (parse_in, space, name, id,

I let people understanding the problem update the comment. IMO the comment
should include a pointer to "ENUM_BITFIELD (pragma_kind) pragma_kind : n;" when
updating the assert to 2**n. It would also be interesting to know how many
pragmas can be added before reaching the limit.

[Bug c++/68138] "operator== is ambiguous" when comparing a tuple containing values with one containing refs

[ville.voutilainen at gmail dot com]

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

--- Comment #1 from Ville Voutilainen  ---
The test works if operator== is not a member. There's something fairly fishy
going on here.

[Bug target/56592] [SH] Add vector ABI

[olegendo at gcc dot gnu.org]

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

--- Comment #4 from Oleg Endo  ---
(In reply to Oleg Endo from comment #0)
> 
> Function argument/return value aggregates are decomposed so that the
> individual members can be passed in different register classes, based on the
> data type.  E.g. 
> 
> ...
> 
> struct FuncArg
> {
>   float a;  // -> fr4
>   float b;  // -> fr5
>   float c;  // -> fr6
>   float d;  // -> fr7
> };
> 

Maybe such simple cases can be handled by implementing
TARGET_ARRAY_MODE_SUPPORTED_P

[Bug sanitizer/68299] New: [5/6 Regression] runtime error: member call on null pointer of type 'const struct __lambda0'

[redi at gcc dot gnu.org]

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

Bug ID: 68299
   Summary: [5/6 Regression] runtime error: member call on null
pointer of type 'const struct __lambda0'
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

int main()
{
  void(*p)() = +[] { };
  p();
}

$ g++ -fsanitize=undefined ub.cc  
$ ./a.out
ub.cc:3:22: runtime error: member call on null pointer of type 'const struct
__lambda0'

[Bug c++/68300] New: Bogus -Wnon-virtual-dtor warning with protected base class constructor

[trippels at gcc dot gnu.org]

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

Bug ID: 68300
   Summary: Bogus -Wnon-virtual-dtor warning with protected base
class constructor
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

markus@x4 ~ % cat non_virt.ii
class A {
protected:
  ~A();

public:
  friend struct C;
  virtual void foo();
};

class B final : public A {
  void foo() override;
};

markus@x4 ~ % clang++ -Wnon-virtual-dtor -c -std=c++14 non_virt.ii
markus@x4 ~ % g++ -Wnon-virtual-dtor -c -std=c++14 non_virt.ii
non_virt.ii:1:7: warning: ‘class A’ has virtual functions and accessible
non-virtual destructor [-Wnon-virtual-dtor]
 class A {
   ^
non_virt.ii:10:7: warning: base class ‘class A’ has accessible non-virtual
destructor [-Wnon-virtual-dtor]
 class B final : public A {
   ^

The warning goes away if I comment out the friend declaration.

[Bug sanitizer/68299] [5/6 Regression] runtime error: member call on null pointer of type 'const struct __lambda0'

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Ah yes, so it is.

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

[Bug ada/66205] gnatbind generates invalid code when finalization is enabled in restricted runtime

[simon at pushface dot org]

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

simon at pushface dot org changed:

   What|Removed |Added

  Attachment #35567|0   |1
is obsolete||

--- Comment #7 from simon at pushface dot org ---
Created attachment 36690
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36690=edit
Patch to gcc/ada/bindgen.adb

[Bug other/60158] powerpc: usage of the .data.rel.ro.local section

[joakim.tjernlund at transmode dot se]

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

--- Comment #5 from joakim.tjernlund at transmode dot se  ---
I am sure I saw .data.rel.ro.local section with a .4byte statement in it
using -S

Now I cannot repeat it. The only thing that has changed that I know is
glibc 2.19 is no glibc 2.20 and binutils from 2.24 to 2.25.1

Maybe binutils version makes a difference?
Don't have that handy anymore

[Bug fortran/68283] [5/6 Regression] ice: gfc_variable_attr(): Bad array reference

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #7 from Steve Kargl  ---
On Wed, Nov 11, 2015 at 06:01:19PM +, dominiq at lps dot ens.fr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68283
> 
> --- Comment #6 from Dominique d'Humieres  ---
> For some reason, the ICE requires to use at least -O.
> 

Yep.  Mostlikely, a different path through the compiler stomping on different
chunks of memory.

[Bug rtl-optimization/68298] New: wrong code at -O3 on x86_64-linux-gnu (in 64-bit mode)

[su at cs dot ucdavis.edu]

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

Bug ID: 68298
   Summary: wrong code at -O3 on x86_64-linux-gnu (in 64-bit mode)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The current gcc trunk (as well as 5.1.x and 5.2.x) miscompiles the following
code on x86_64-linux-gnu at -O3 in the 64-bit mode (but not in the 32-bit
mode). 

This is a regression from 4.9.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 20151110 (experimental) [trunk revision 230107] (GCC) 
$ 
$ gcc-trunk -m64 -O2 small.c; ./a.out
0
$ gcc-trunk -m32 -O3 small.c; ./a.out
0
$ gcc-4.9 -m64 -O3 small.c; ./a.out
0
$ 
$ gcc-trunk -m64 -O3 small.c
$ ./a.out
Segmentation fault (core dumped)
$ gcc-5.2 -m64 -O3 small.c
$ ./a.out
Segmentation fault (core dumped)
$ gcc-5.1 -m64 -O3 small.c
$ ./a.out
Segmentation fault (core dumped)
$ 


-


int printf (const char *, ...); 

int a[1], b, c, d;
char e = 2;

char
fn1 ()
{
  if (e > 1)
return e;
}

void
fn2 ()
{
  b = fn1 ();
  for (; c;)
;
  if (!e)
b = a[400];
  printf ("0\n");
}

void
fn3 ()
{
  for (; d;)
;
  for (; d < 1; d++)
fn2 ();
}

int
main ()
{
  fn3 ();
  return 0;
}

[Bug libstdc++/60421] std::this_thread::sleep_for doesn't sleep for all arguments

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
(In reply to Jaak Ristioja from comment #6)
> Additionally, the nanosleep code is also missing proper EINTR handling,
> which again could break the sleep.

This part is done.

[Bug target/68286] [6 Regression] ICE: in wide_int_to_tree, at tree.c:1468

[renlin at gcc dot gnu.org]

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

Renlin Li  changed:

   What|Removed |Added

 Target|powerpc64le-unknown-linux-g |powerpc64le-unknown-linux-g
   |nu  |nu,
   ||arm-none-linux-gnueabihf
 CC||renlin at gcc dot gnu.org

--- Comment #3 from Renlin Li  ---
same issue happens on arm-none-linuxgnu-eabihf toolchain.

[Bug debug/67192] [6 Regression] Backward-goto in loop can get wrong line number

[arnez at linux dot vnet.ibm.com]

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

Andreas Arnez  changed:

   What|Removed |Added

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

--- Comment #25 from Andreas Arnez  ---
To me the problem looks fixed now.  In particular checkpoint.exp from the GDB
test suite shows no more FAILs on s390x.

There's another patch pending that deals with C++:
  https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01192.html
But that addresses a different issue and shouldn't affect this PR's status.

[Bug sanitizer/68299] [5/6 Regression] runtime error: member call on null pointer of type 'const struct __lambda0'

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Looks like a dup of PR67941.

[Bug sanitizer/67941] calls on function pointer from a captureless lambda cause ubsan warning

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||redi at gcc dot gnu.org

--- Comment #3 from Jonathan Wakely  ---
*** Bug 68299 has been marked as a duplicate of this bug. ***

[Bug c/68062] [4.9/5/6 Regression] ICE when comparing vectors

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
If we should pay attention to the sign, then maybe

--- gcc/c-family/c-common.c
+++ gcc/c-family/c-common.c
@@ -11903,9 +11903,9 @@ vector_types_compatible_elements_p (tree t1, tree t2)
  && (c2 == INTEGER_TYPE || c2 == REAL_TYPE
  || c2 == FIXED_POINT_TYPE));

-  t1 = c_common_signed_type (t1);
-  t2 = c_common_signed_type (t2);
-  /* Equality works here because c_common_signed_type uses
+  t1 = c_common_signed_or_unsigned_type (TYPE_UNSIGNED (t1), t1);
+  t2 = c_common_signed_or_unsigned_type (TYPE_UNSIGNED (t2), t2);
+  /* Equality works here because c_common_signed_or_unsigned_type uses
  TYPE_MAIN_VARIANT.  */
   if (t1 == t2)
 return true;

(it has a small fallout)

[Bug fortran/68283] [5/6 Regression] ice: gfc_variable_attr(): Bad array reference

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  ---
For some reason, the ICE requires to use at least -O.

[Bug libstdc++/60421] std::this_thread::sleep_for doesn't sleep for all arguments

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
Author: redi
Date: Wed Nov 11 17:08:51 2015
New Revision: 230183

URL: https://gcc.gnu.org/viewcvs?rev=230183=gcc=rev
Log:
Loop in std::this_thread sleep functions

PR libstdc++/60421
* include/std/thread (this_thread::sleep_for): Retry on EINTR.
(this_thread::sleep_until): Retry if time not reached.
* src/c++11/thread.cc (__sleep_for): Retry on EINTR.
* testsuite/30_threads/this_thread/60421.cc: Test interruption and
non-steady clocks.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/thread
trunk/libstdc++-v3/src/c++11/thread.cc
trunk/libstdc++-v3/testsuite/30_threads/this_thread/60421.cc

[Bug fortran/68283] [5/6 Regression] ice: gfc_variable_attr(): Bad array reference

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #5 from kargl at gcc dot gnu.org ---
(In reply to Manuel López-Ibáñez from comment #4)
>
> Does the ICE happens while printing an error? If not, something must be
> checking for buffered errors and changing behavior depending on that. The
> new code might be clearing the buffered errors flag (or not buffering them
> at all) too early.

No.  It happens after error messages have been issued.
The ICE goes away with

laptop-kargl:kargl[219] svn diff primary.c 
Index: primary.c
===
--- primary.c   (revision 229970)
+++ primary.c   (working copy)
@@ -2268,8 +2268,6 @@ gfc_variable_attr (gfc_expr *expr, gfc_t
&& errors > 0)
  break;
  }
-   if (n == ref->u.ar.as->rank)
- gfc_internal_error ("gfc_variable_attr(): Bad array reference");
  }

break;

There are a number of questionable gfc_internal_error()'s within gfortran.
I suspect some come from the idea "Correctly written Fortran code cannot
possibly reach this point, so there must be some internal error to get
here."  The original code should have simply returned because clearly
"Poorly written invalid code can reach this point, and an internal 
error is not appropriate.  So, let gfortran exit gracefully".

[Bug target/67265] [x86] 'asm' operand has impossible constraints with -fstack-check

[ebotcazou at gcc dot gnu.org]

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

--- Comment #9 from Eric Botcazou  ---
Author: ebotcazou
Date: Wed Nov 11 14:56:17 2015
New Revision: 230176

URL: https://gcc.gnu.org/viewcvs?rev=230176=gcc=rev
Log:
PR target/67265
* ira.c (ira_setup_eliminable_regset): Do not necessarily create the
frame pointer for stack checking if non-call exceptions aren't used.
* config/i386/i386.c (ix86_finalize_stack_realign_flags): Likewise.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr67265.c
  - copied unchanged from r230168,
trunk/gcc/testsuite/gcc.target/i386/pr67265.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/i386/i386.c
branches/gcc-5-branch/gcc/ira.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/68294] gcc cannot deduce (a | b) != 0 from (a != 0 && b != 0)

[fuz at fuz dot su]

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

--- Comment #2 from Robert Clausecker  ---
Created attachment 36689
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36689=edit
Testcase for bug #68294

[Bug rtl-optimization/68282] Optimization fails to remove unnecessary sign extension instruction

[stanshebs at earthlink dot net]

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

--- Comment #3 from Stan Shebs  ---
Sorry, left out a detail - the cltq output is compilation as C++.  Compiled as
a C file, the code does have the andl as noted.  (I'm sure there are good
reasons why the *exact* *same* source text ends up with two completely
different asm sequences, ahem.)

[Bug libstdc++/68297] Faster std::make_exception

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Yes, this is certainly possible, someone just needs to do the work.

[Bug c++/68266] pointers to arrays of excessive size not diagnosed

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Wed Nov 11 14:47:03 2015
New Revision: 230174

URL: https://gcc.gnu.org/viewcvs?rev=230174=gcc=rev
Log:
PR c/68107
PR c++/68266
* c-common.c (valid_array_size_p): New function.
* c-common.h (valid_array_size_p): Declare.

* c-decl.c (grokdeclarator): Call valid_array_size_p.  Remove code
checking the size of an array.

* decl.c (grokdeclarator): Call valid_array_size_p.  Remove code
checking the size of an array.

* c-c++-common/pr68107.c: New test.
* g++.dg/init/new38.C (large_array_char): Adjust dg-error.
(large_array_char_template): Likewise.
* g++.dg/init/new44.C: Adjust dg-error.

Added:
trunk/gcc/testsuite/c-c++-common/pr68107.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/c-family/c-common.h
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/init/new38.C
trunk/gcc/testsuite/g++.dg/init/new44.C

[Bug c/68107] Non-VLA type whose size is half or more of the address space constructed via a pointer

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Wed Nov 11 14:47:03 2015
New Revision: 230174

URL: https://gcc.gnu.org/viewcvs?rev=230174=gcc=rev
Log:
PR c/68107
PR c++/68266
* c-common.c (valid_array_size_p): New function.
* c-common.h (valid_array_size_p): Declare.

* c-decl.c (grokdeclarator): Call valid_array_size_p.  Remove code
checking the size of an array.

* decl.c (grokdeclarator): Call valid_array_size_p.  Remove code
checking the size of an array.

* c-c++-common/pr68107.c: New test.
* g++.dg/init/new38.C (large_array_char): Adjust dg-error.
(large_array_char_template): Likewise.
* g++.dg/init/new44.C: Adjust dg-error.

Added:
trunk/gcc/testsuite/c-c++-common/pr68107.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/c-family/c-common.h
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/init/new38.C
trunk/gcc/testsuite/g++.dg/init/new44.C

[Bug middle-end/68296] New: [6 regression] ICE in prepare_cmp_insn, at optabs.c:3813

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

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

Bug ID: 68296
   Summary: [6 regression] ICE in prepare_cmp_insn, at
optabs.c:3813
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
CC: ienkovich at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64-*-*, ia64-*-*

Started with r230098.

For example on aarch64:

FAIL: gcc.c-torture/compile/pr53410-2.c   -O0  (internal compiler error)
FAIL: gcc.c-torture/compile/pr53410-2.c   -O0  (test for excess errors)
Excess errors:
/opt/gcc/gcc-2015/gcc/testsuite/gcc.c-torture/compile/pr53410-2.c:27:18:
internal compiler error: in prepare_cmp_insn, at optabs.c:3813
0xa10aeb prepare_cmp_insn
../../gcc/optabs.c:3813
0xa10b7f emit_cmp_and_jump_insns(rtx_def*, rtx_def*, rtx_code, rtx_def*,
machine_mode, int, rtx_def*, int)
../../gcc/optabs.c:3960
0x780d17 do_compare_rtx_and_jump(rtx_def*, rtx_def*, rtx_code, int,
machine_mode, rtx_def*, rtx_code_label*, rtx_code_label*, int)
../../gcc/dojump.c:1140
0x781cc7 do_compare_and_jump
../../gcc/dojump.c:1219
0x820f33 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../gcc/expr.c:9076
0x70fd87 expand_gimple_stmt_1
../../gcc/cfgexpand.c:3612
0x70fd87 expand_gimple_stmt
../../gcc/cfgexpand.c:3673
0x7139bb expand_gimple_basic_block
../../gcc/cfgexpand.c:5679
0x719077 execute
../../gcc/cfgexpand.c:6291

[Bug c/68039] Incorrect unused-result warning

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Since op1 and op2 in that COND_EXPR are the same, we fold the conditional
expression to a COMPOUND_EXPR:
  return x ();, 0;
so the result of x () looks unused.

Same for C++.

[Bug target/67305] [6 Regression] gcc.c-torture/compile/20121027-1.c ICE on arm-none-eabi

[jiwang at gcc dot gnu.org]

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

Jiong Wang  changed:

   What|Removed |Added

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

--- Comment #10 from Jiong Wang  ---
fixed, r230158.

[Bug sanitizer/68065] Size calculations for VLAs can overflow

[ch3root at openwall dot com]

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

--- Comment #29 from Alexander Cherepanov  ---
On 2015-11-11 14:57, ebotcazou at gcc dot gnu.org wrote:
>> Are you saying that -fstack-check is ready for use? Why it's not
>> documented (except for Ada and in gccint)?
>
> !???  See 3.18 Options for Code Generation Conventions in the manual.

Ouch. Searching in Google for 'fstack-check gcc', gnat and gccint are 
the first hits but Code-Gen-Options is not on the first page. (For other 
options it usually works quite well.) And looking for it in the manual 
near -fstack-protector, i.e. in "3.10 Options That Control 
Optimization", doesn't find anything. I should have tried Option Index 
at least. It's documented even for gcc 2.95.3.

>> According to comments[1][2] by Florian Wiemer (cc'd) in 2013 it's not
>> production-ready and "used to be rather buggy". Is this changed?
>>
>> [1] https://gcc.gnu.org/ml/gcc-patches/2013-09/msg01176.html
>> [2] http://www.openwall.com/lists/oss-security/2013/01/23/4
>
> Yes, at least on mainstream architectures (x86, x86-64, Alpha, MIPS, SPARC,
> PowerPC, IA-64).  ARM and AArch64 need the PR middle-end/65958 changes.

Cool! One more question, if you don't mind: which version of gcc do I 
need for this -- is 4.9.2 ok or 5 is required? Links to additional info 
would be appreciated.

[Bug c++/68138] "operator== is ambiguous" when comparing a tuple containing values with one containing refs

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-11
 CC||ville.voutilainen at gmail dot 
com
 Ever confirmed|0   |1
  Known to fail||4.8.2, 4.9.2, 5.2.0, 6.0

[Bug tree-optimization/67612] Unable to vectorize DOT_PROD_EXPR (PMADDWD?)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug target/67265] [x86] 'asm' operand has impossible constraints with -fstack-check

[ebotcazou at gcc dot gnu.org]

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

--- Comment #8 from Eric Botcazou  ---
Author: ebotcazou
Date: Wed Nov 11 14:24:39 2015
New Revision: 230170

URL: https://gcc.gnu.org/viewcvs?rev=230170=gcc=rev
Log:
PR target/67265
* config/i386/i386.c (ix86_finalize_stack_realign_flags): Likewise.

Modified:
trunk/gcc/config/i386/i386.c

[Bug target/68293] [6 Regression] ICE: in prepare_cmp_insn, at optabs.c:3813 with vector compare with -O0 @ aarch64

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

 CC||jgreenhalgh at gcc dot gnu.org

--- Comment #1 from James Greenhalgh  ---
Looks related to pr68134 ?

[Bug c/68272] Unwanted out-of-line instances for C inline functions that are also GCC builtins.

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
You could work around this with -fno-builtin-abs.

[Bug c/68272] Unwanted out-of-line instances for C inline functions that are also GCC builtins.

[sorganov at gmail dot com]

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

--- Comment #5 from Sergey Organov  ---
Thanks, but my particular problem is that I do want nice GCC builtin when it is
available, and I want generic inline implementation, rather than function call,
when GCC builtin is not available.

[Bug c/68062] [4.9/5/6 Regression] ICE when comparing vectors

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #5 from Marek Polacek  ---
The FEs stopped rejecting the testcase with r202364.

[Bug libstdc++/68297] New: Faster std::make_exception

[nyh at math dot technion.ac.il]

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

Bug ID: 68297
   Summary: Faster std::make_exception
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nyh at math dot technion.ac.il
  Target Milestone: ---

std::make_exception(object) currently does this:

make_exception_ptr(_Ex __ex) _GLIBCXX_USE_NOEXCEPT
{
  try
{
  throw __ex;
}
  catch(...)
{
  return current_exception();
}
}

I think this could have been made much faster... Throwing an exception is very
slow, and not really needed here, as gcc (libsupc++) knows exactly how to
create an exception_ptr from the given object, without going through the
motions of looking for the exception frame (we know exactly where it will be).
By taking the right code from __cxa_throw, std::current_exception(), etc., this
can be done without any stack unwinding, and therefore much more quickly.

Such an improvement will benefit especially code that passes around
exception_ptrs instead of actually throwing exception (the Seastar library, for
example, does this).

[Bug c/68107] Non-VLA type whose size is half or more of the address space constructed via a pointer

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Should be fixed.

[Bug c++/68266] pointers to arrays of excessive size not diagnosed

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Should be fixed.

[Bug target/68293] [6 Regression] ICE: in prepare_cmp_insn, at optabs.c:3813 with vector compare with -O0 @ aarch64

[zsojka at seznam dot cz]

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

--- Comment #2 from Zdenek Sojka  ---
(In reply to James Greenhalgh from comment #1)
> Looks related to pr68134 ?

Maybe; the compiler crashes at roughly the same place.
PR68134 is "r230014 or older", so either the buggy path is now triggered much
more often, or the bugs are unrelated.

[Bug tree-optimization/68294] gcc cannot deduce (a | b) != 0 from (a != 0 && b != 0)

[fuz at fuz dot su]

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

--- Comment #3 from Robert Clausecker  ---
Sorry, I forgot to attach the test case. Here it is.

[Bug target/67265] [x86] 'asm' operand has impossible constraints with -fstack-check

[ebotcazou at gcc dot gnu.org]

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

--- Comment #10 from Eric Botcazou  ---
Author: ebotcazou
Date: Wed Nov 11 16:04:34 2015
New Revision: 230179

URL: https://gcc.gnu.org/viewcvs?rev=230179=gcc=rev
Log:
PR target/67265
* ira.c (ira_setup_eliminable_regset): Do not necessarily create the
frame pointer for stack checking if non-call exceptions aren't used.
* config/i386/i386.c (ix86_finalize_stack_realign_flags): Likewise.

Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/i386/pr67265.c
  - copied unchanged from r230177,
trunk/gcc/testsuite/gcc.target/i386/pr67265.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/i386/i386.c
branches/gcc-4_9-branch/gcc/ira.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug target/67265] [x86] 'asm' operand has impossible constraints with -fstack-check

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.4

--- Comment #11 from Eric Botcazou  ---
Fixed on all active branches.

[Bug target/67265] [x86] 'asm' operand has impossible constraints with -fstack-check

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #12 from Eric Botcazou  ---
Fixed on all active branches.

[Bug rtl-optimization/68287] New: [6 Regression] conditional jump or move depends on uninitialized value in lra-lives.c:1048

[marxin at gcc dot gnu.org]

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

Bug ID: 68287
   Summary: [6 Regression] conditional jump or move depends on
uninitialized value in lra-lives.c:1048
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Using --enable-valgrind-annotations there's a possible issues in lra-lives.c
that is seen by valgrind as conditional jump or move depends on uninitialized
value. I know that RA contains couple of valgrind annotations that suppress
detection of similar errors. Maybe this should be also included?

revision: r230114

./configure --enable-languages=c,c++ --prefix=/home/marxin/Programming/bin/gcc2
--disable-multilib --disable-libsanitizer --enable-checking=release
--enable-valgrind-annotations --disable-bootstrap : (reconfigured) ../configure
--enable-languages=c,c++ --prefix=/home/marxin/Programming/bin/gcc2
--disable-multilib --disable-libsanitizer --enable-checking=release
--enable-valgrind-annotations --disable-bootstrap : (reconfigured) ../configure
--enable-languages=c,c++ --prefix=/home/marxin/Programming/bin/gcc2
--disable-multilib --disable-libsanitizer --enable-checking=release
--enable-valgrind-annotations --disable-bootstrap

valgrind --leak-check=yes --trace-children=yes --error-exitcode=111 -q 
/home/marxin/Programming/gcc2/objdir/gcc/xgcc
-B/home/marxin/Programming/gcc2/objdir/gcc/ -fno-diagnostics-show-caret
-fdiagnostics-color=never -O0 -w -c -o 2609-1.o
/home/marxin/Programming/gcc2/gcc/testsuite/gcc.c-torture/compile/2609-1.c
-O0

==28462== Conditional jump or move depends on uninitialised value(s)
==28462==at 0xB75890: remove_some_program_points_and_update_live_ranges()
(lra-lives.c:1048)
==28462==by 0xB75C96: compress_live_ranges() (lra-lives.c:1161)
==28462==by 0xB763A0: lra_create_live_ranges_1(bool, bool)
(lra-lives.c:1310)
==28462==by 0xB763D7: lra_create_live_ranges(bool, bool) (lra-lives.c:1322)
==28462==by 0xB55420: lra(_IO_FILE*) (lra.c:2301)
==28462==by 0xB041B3: do_reload() (ira.c:5380)
==28462==by 0xB04528: (anonymous
namespace)::pass_reload::execute(function*) (ira.c:5551)
==28462==by 0xC163D4: execute_one_pass(opt_pass*) (passes.c:2323)
==28462==by 0xC166D7: execute_pass_list_1(opt_pass*) (passes.c:2396)
==28462==by 0xC16708: execute_pass_list_1(opt_pass*) (passes.c:2397)
==28462==by 0xC16760: execute_pass_list(function*, opt_pass*)
(passes.c:2407)
==28462==by 0x8E7E7D: cgraph_node::expand() (cgraphunit.c:1965)
==28462== 

Thanks,
Martin

[Bug c++/68288] New: botched floating-point UDL

[lucdanton at free dot fr]

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

Bug ID: 68288
   Summary: botched floating-point UDL
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lucdanton at free dot fr
  Target Milestone: ---

I'm seeing this behaviour with GCC 6, GCC 5.2.0 and GCC 4.9.2.

$ g++-trunk --version
g++-trunk (GCC) 6.0.0 20151103 (experimental)
Copyright (C) 2015 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 main.cpp
long double operator""_a(long double) { return {}; }
long double operator""_e(long double) { return {}; }

int main()
{
// all fine
void(0e1_a+0);
void(0e1_e*0);
void(0e1_e +0);
// error: unable to find numeric literal operator 'operator""e+0'
void(0e1_e+0);
}
$ g++-trunk -std=c++11 main.cpp
main.cpp: In function 'int main()':
main.cpp:10:10: error: unable to find numeric literal operator 'operator""_e+0'
 void(0e1_e+0);
  ^
main.cpp:10:10: note: use -std=gnu++11 or -fext-numeric-literals to enable more
built-in suffixes

[Bug rtl-optimization/68287] [6 Regression] conditional jump or move depends on uninitialized value in lra-lives.c:1048

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug sanitizer/68065] Size calculations for VLAs can overflow

[ch3root at openwall dot com]

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

--- Comment #27 from Alexander Cherepanov  ---
On 2015-11-11 11:16, ebotcazou at gcc dot gnu.org wrote:
 > On 2015-11-11 03:36, danielmicay at gmail dot com wrote:
>> The implementation of -fstack-check in GCC does have significant overhead,
>> but it doesn't have to be that way. It shouldn't go out of the way to
>> provide a proper stack trace with -O2/-O3 (or whatever other reasons it has
>> for the slow implementation).
>
> Figures please, otherwise that's just FUD as usual.

Are you saying that -fstack-check is ready for use? Why it's not 
documented (except for Ada and in gccint)?

According to comments[1][2] by Florian Wiemer (cc'd) in 2013 it's not 
production-ready and "used to be rather buggy". Is this changed?

[1] https://gcc.gnu.org/ml/gcc-patches/2013-09/msg01176.html
[2] http://www.openwall.com/lists/oss-security/2013/01/23/4

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

[rguenther at suse dot de]

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

--- Comment #9 from rguenther at suse dot de  ---
On Wed, 11 Nov 2015, ro at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58497
> 
> --- Comment #8 from Rainer Orth  ---
> Created attachment 36687
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36687=edit
> -fdump-tree-dom2-details dump

Ok, it's not supposed to look like this after lowering.  Does SPARC
not have an integer multiply instruction (SImode)?  Then the
FAIL is expected (though folding halfway does the transform anyway...).