[Bug c/68431] Regression in GCC-6.0.0's optimizer

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
This got changed in r225108.

[Bug c++/68430] std::is_constructible::value == true for unconstructable type T

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
The standard isn't clear about what should happen here, there will be an issue
opened about it.

[Bug c++/68427] GCC (G++) flunks legal ANSI-C code

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Severity|major   |normal

[Bug fortran/64522] [4.9 Regression] Free-form source code: -Wline-truncation is no longer enabled by default

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING
  Known to work||5.2.0, 6.0
Summary|[4.9/5/6 Regression]|[4.9 Regression] Free-form
   |Free-form source code:  |source code:
   |-Wline-truncation is no |-Wline-truncation is no
   |longer enabled by default   |longer enabled by default
  Known to fail||4.9.3

--- Comment #6 from Dominique d'Humieres  ---
Fixed on 5.2 and trunk (6.0). IMO backporting r219424 to 4.9.4 does not worth
the work. Unless someone objects (and do the work), I'll close this PR as
FIXED.

[Bug target/67770] [4.9/5/6 Regression] i386: -fshrink-wrap can interact badly with trampolines

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Thu Nov 19 08:30:19 2015
New Revision: 230593

URL: https://gcc.gnu.org/viewcvs?rev=230593=gcc=rev
Log:
PR target/67770
* config/i386/i386.md (simple_return): Disable if
ix86_static_chain_on_stack is true.

* gcc.target/i386/pr67770.c: New test.

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

[Bug rtl-optimization/67609] [5 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

Richard Henderson  changed:

   What|Removed |Added

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

--- Comment #38 from Richard Henderson  ---
Fixed for 5.3.

[Bug target/67770] [4.9/5/6 Regression] i386: -fshrink-wrap can interact badly with trampolines

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Thu Nov 19 08:47:24 2015
New Revision: 230595

URL: https://gcc.gnu.org/viewcvs?rev=230595=gcc=rev
Log:
PR target/67770
* config/i386/i386.md (simple_return): Disable if
ix86_static_chain_on_stack is true.

* gcc.target/i386/pr67770.c: New test.

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

[Bug fortran/68433] Wrong code with INTERFACE, INTRINSIC, and optional arguments

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Present from 4.8 up to trunk (6.0).

[Bug fortran/68433] New: Wrong code with INTERFACE, INTRINSIC, and optional arguments

[dominiq at lps dot ens.fr]

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

Bug ID: 68433
   Summary: Wrong code with INTERFACE, INTRINSIC, and optional
arguments
   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: ---

While investigating pr46846, I found that the following code

program ainttest
   implicit none
   intrinsic aint
   intrinsic index
   intrinsic len
   intrinsic nint
   real r
   character c, string2
   character(7) string1
   integer i

   r = 3.14
   c = 'A'
   string2 = 'n'
   string1 = 'string1'
   i = 13
   call rsub('aint',aint,r)
   call rsubi('nint',nint,r)
   call char2isub('index',index,string1,string2)
   call charstarisub('len',len,string1)
end program ainttest

subroutine rsub(label,fun,x)
   implicit none
   character(*) label
   interface
  function fun(x,k)
 implicit none
 integer, intent(in), optional :: k
 real, intent(in) :: x
 real fun
  end function fun
   end interface
   real x

   write(*,*) label//'(',x,') = ',fun(x,k=8)
   print *, "expected:", aint(x,kind=8)
end subroutine rsub

subroutine rsubi(label,fun,x)
   implicit none
   character(*) label
   interface
  function fun(x,k)
 implicit none
 integer, intent(in), optional :: k
 real, intent(in) :: x
 integer fun
  end function fun
   end interface
   real x

   write(*,*) label//'(',x,') = ',"'",fun(x,k=2),"'"
   print *, "expected:","'",nint(x,kind=2),"'"
end subroutine rsubi

subroutine char2isub(label,fun,x,y)
   implicit none
   character(*) label,x,y
   interface
  function fun(x,y,l,k)
 implicit none
 logical, intent(in), optional :: l
 integer, intent(in), optional :: k
 character(*), intent(in) :: x,y
 integer fun
  end function fun
   end interface

   write(*,*) label//'(',x,',',y,') = ',fun(x,y)
   print *, "expected:", index(x,y)
end subroutine char2isub

subroutine charstarisub(label,fun,x)
   implicit none
   character(*) label,x
   write(*,*) label//'(',x,') = ',fun(x)
   print *, "expected:", len(x)
end subroutine charstarisub

while silencing the spurious warnings, generates a wrong code, the output
being:

 aint(   3.1410 ) =3.
 expected:   3. 
 nint(   3.1410 ) = '   3 '
 expected:'  3 '
 index(string1,n) =1
 expected:   5
 len(string1) =0
 expected:   7

Note that I am not 100% sure that the above code is valid.

[Bug preprocessor/60736] [4.9/5/6 Regression] Crash in preprocessor including stdc-predef.h when it does not exist on glibc-based systems

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  ---
Author: jakub
Date: Thu Nov 19 08:28:43 2015
New Revision: 230592

URL: https://gcc.gnu.org/viewcvs?rev=230592=gcc=rev
Log:
PR preprocessor/60736
* include/cpplib.h (cpp_errno_filename): New prototype.
* errors.c (cpp_errno): Don't handle msgid "" specially, use
_(msgid) instead of msgid as argument to cpp_error.
(cpp_errno_filename): New function.
* files.c (read_file_guts): Use cpp_errno_filename instead of
cpp_errno.
(open_file_failed): Likewise.  Use file->name if file->path is NULL
in diagnostics.

Modified:
branches/gcc-5-branch/libcpp/ChangeLog
branches/gcc-5-branch/libcpp/errors.c
branches/gcc-5-branch/libcpp/files.c
branches/gcc-5-branch/libcpp/include/cpplib.h

[Bug fortran/66707] Endless compilation on wrong usage of common

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #2 from Dominique d'Humieres  ---
> Confirmed with 4.9.3 and 5.2. This seems to have been fixed on trunk between
> revision r226476 (2015-08-02, endless compilation) and r227016 (2015-08-19,
> tests compiled in a fraction of second).

Can someone confirms that the tests compile on recent trunk (post r227016)? A
finer range would be nice too!

[Bug middle-end/68117] [6 Regression] error: invalid PHI argument <<< Unknown tree: >>>

[rguenth at gcc dot gnu.org]

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

--- Comment #39 from Richard Biener  ---
Author: rguenth
Date: Thu Nov 19 08:47:16 2015
New Revision: 230594

URL: https://gcc.gnu.org/viewcvs?rev=230594=gcc=rev
Log:
2015-11-19  Richard Biener  

PR middle-end/68117
* tree-ssa.c (delete_tree_ssa): Revert removal of call to
redirect_edge_var_map_destroy.

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

[Bug middle-end/68117] [6 Regression] error: invalid PHI argument <<< Unknown tree: >>>

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/68432] [6 Regression] internal compiler error: in expand_insn, at optabs.c:6947

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org
   Target Milestone|--- |6.0

[Bug middle-end/68393] internal compiler error: in convert_move, at expr.c:286

[rsandifo at gcc dot gnu.org]

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

--- Comment #5 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Thu Nov 19 08:17:21 2015
New Revision: 230590

URL: https://gcc.gnu.org/viewcvs?rev=230590=gcc=rev
Log:
PR 68393: Handle SUBREG_PROMOTED_VAR_P in expand_direct_optab_fn

Do the usual dance when assigning to SUBREG_PROMOTED_VAR_P destinations:
first convert to the outer mode, then extend to the inner mode.

Tested that it fixes the powerpc64le-linux-gnu breakage.  Also tested
on x86_64-linux-gnu and powerpc64-linux-gnu.

gcc/
PR bootstrap/68393
* internal-fn.c (expand_direct_optab_fn): Handle SUBREG_PROMOTED_VAR_P
destinations.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/internal-fn.c

[Bug preprocessor/60736] [4.9/5/6 Regression] Crash in preprocessor including stdc-predef.h when it does not exist on glibc-based systems

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  ---
Author: jakub
Date: Thu Nov 19 08:27:12 2015
New Revision: 230591

URL: https://gcc.gnu.org/viewcvs?rev=230591=gcc=rev
Log:
PR preprocessor/60736
* include/cpplib.h (cpp_errno_filename): New prototype.
* errors.c (cpp_errno): Don't handle msgid "" specially, use
_(msgid) instead of msgid as argument to cpp_error.
(cpp_errno_filename): New function.
* files.c (read_file_guts): Use cpp_errno_filename instead of
cpp_errno.
(open_file_failed): Likewise.  Use file->name if file->path is NULL
in diagnostics.

Modified:
trunk/libcpp/ChangeLog
trunk/libcpp/errors.c
trunk/libcpp/files.c
trunk/libcpp/include/cpplib.h

[Bug c++/68383] Demangler stack overflow

[fiesh at zefix dot tv]

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

--- Comment #8 from fiesh at zefix dot tv ---
Would it be helpful it I tried to create a test case for 5.2.0?  Or anything
else I can provide?

[Bug tree-optimization/68198] [6 Regression]Excessive code size, compile time and memory usage bloat due to FSM threading in 453.povray

[ktkachov at gcc dot gnu.org]

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

--- Comment #11 from ktkachov at gcc dot gnu.org ---
(In reply to Jeffrey A. Law from comment #10)
> Should be fixed on the trunk now.  I went from some absurd time down to less
> than a second for the critical code in 453.povray.

Yep, I can confirm that as well.
Thanks!

[Bug other/66827] [6 Regression] left shifts of negative value warnings due to C++14 switch

[bonzini at gnu dot org]

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

--- Comment #6 from Paolo Bonzini  ---
If you really want to fix it, (-(1 << 19)) is the best.

The real fix would be to lobby the C/C++ committees so that left shift of a
negative value is unspecified behavior rather than undefined.

[Bug rtl-optimization/68376] [4.9/5/6 Regression] wrong code at -O1 and above on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Thu Nov 19 08:53:52 2015
New Revision: 230597

URL: https://gcc.gnu.org/viewcvs?rev=230597=gcc=rev
Log:
PR rtl-optimization/68376
* ifcvt.c (noce_try_abs): Disable one_cmpl optimization if
encountering x <= 0 ? ~x : x or x > 0 ? ~x : x.

* gcc.c-torture/execute/pr68376-1.c: New test.
* gcc.c-torture/execute/pr68376-2.c: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.c-torture/execute/pr68376-1.c
branches/gcc-5-branch/gcc/testsuite/gcc.c-torture/execute/pr68376-2.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/ifcvt.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug middle-end/68279] ICE: in create_pw_aff_from_tree, at graphite-sese-to-poly.c:836

[jana at saout dot de]

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

Jana Saout  changed:

   What|Removed |Added

 CC||jana at saout dot de

--- Comment #3 from Jana Saout  ---
Created attachment 36769
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36769=edit
Reduced testcase from liborc

Hi,

I am probably hitting the same bug when trying to compile liborc.

Here's a reduced testcase that still triggers the ICE for me:

gcc -O2 -ftree-loop-linear -c create_pw_aff_from_tree-ice.c -o
create_pw_aff_from_tree-ice.o

create_pw_aff_from_tree-ice.c: In function 'orc_compiler_sse_init':
create_pw_aff_from_tree-ice.c:11:6: internal compiler error: in
create_pw_aff_from_tree, at graphite-ssse-to-poly.c:713
 void orc_compiler_sse_init (OrcCompiler *compiler)
  ^

Please submit a full bug report,
with preprocessed source if appropriate

[Bug c++/68427] GCC (G++) flunks legal ANSI-C code

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-11-19
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
The file is very weirdly archived, can you post just the preprocessed source
file?

[Bug rtl-optimization/68376] [4.9/5/6 Regression] wrong code at -O1 and above on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Thu Nov 19 08:49:59 2015
New Revision: 230596

URL: https://gcc.gnu.org/viewcvs?rev=230596=gcc=rev
Log:
PR rtl-optimization/68376
* ifcvt.c (noce_try_abs): Disable one_cmpl optimization if
encountering x <= 0 ? ~x : x or x > 0 ? ~x : x.

* gcc.c-torture/execute/pr68376-1.c: New test.
* gcc.c-torture/execute/pr68376-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr68376-1.c
trunk/gcc/testsuite/gcc.c-torture/execute/pr68376-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ifcvt.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/68383] Demangler stack overflow

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #9 from Markus Trippelsdorf  ---
(In reply to fiesh from comment #8)
> Would it be helpful it I tried to create a test case for 5.2.0?  Or anything
> else I can provide?

The reduced testcase works with all gcc versions.

[Bug tree-optimization/68341] [6 Regression] FAIL: gcc.dg/graphite/interchange-{1,11,13}.c (internal compiler error)

[vries at gcc dot gnu.org]

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

--- Comment #3 from vries at gcc dot gnu.org ---
FTR, related comment at
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01792.html

[Bug fortran/68237] ICE on invalid with submodules

[pault at gcc dot gnu.org]

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

--- Comment #10 from Paul Thomas  ---
(In reply to Paul Thomas from comment #9)
> I'll take a look at Steve's proposed patch tonight. In the meantime, I have
> taken the PR.
> 
> Cheers
> 
> Paul

Steve's patch is good... obvious, even :-)

Here is a dejagnuified version of the testcase:

! { dg-do compile }
!
! Test the fix for PR68237 in which 'foo' caused a seg fault rather than an
error.
!
! Contributed by Martin Reinecke  
!
module m1
  interface
module subroutine bar
end subroutine
  end interface
end module m1

submodule (m1) m2
contains
  module procedure foo ! { dg-error "must be in a generic module interface" }
  end procedure ! { dg-error "Expecting END SUBMODULE statement" }
end submodule

I'll try to find the time to commit this afternoon; otherwise it will be next
week.

Paul

[Bug middle-end/66214] [6 Regression] ICE verify_type failed with -O0 -g via gen_type_die_with_usage's dwarf2out.c:20250

[adam at os dot inf.tu-dresden.de]

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

Adam Lackorzynski  changed:

   What|Removed |Added

 CC||adam at os dot 
inf.tu-dresden.de

--- Comment #25 from Adam Lackorzynski  ---
I've also came across this ICE, with this reduced testcase:

template< typename C > class Dl
{
  class __ii { };
  typedef __ii It;
  It ii(typename C::I *e) { return It(e); }
};

template class X1 { typename E::L foo; };

struct M
{
  struct CO { typedef M I; };
  enum Type { };
  typedef Dl L;
  Type t;
  struct R { X1 f; };
};

With: gcc version 6.0.0 20151119 (experimental) (GCC) 

t.i: In instantiation of ‘class Dl’:
t.i:8:47:   required from ‘class X1’
t.i:16:20:   required from here
t.i:1:30: error: TYPE_CANONICAL is not compatible
 template< typename C > class Dl
  ^~

 
asm_written unsigned SI
size 
unit size 
align 32 symtab -862572224 alias set -1 canonical type
0x7f1ccca8c348 precision 32 min  max  context 
chain >
decl_3 VOID file t.i line 15 col 8
align 1 offset_align 1 context 
chain 
used nonlocal decl_4 VOID file t.i line 11 col 1
align 1 context  result 
chain >> context

full-name "struct M"
n_parents=0 use_template=0 interface-unknown
pointer_to_this  chain >
 
full-name "struct M"
n_parents=0 use_template=0 interface-unknown
chain >
used nonlocal decl_4 VOID file t.i line 11 col 1
align 1 context 
result  context

full-name "struct M"
n_parents=0 use_template=0 interface-unknown
pointer_to_this  chain >

chain 
public decl_2 VOID file t.i line 12 col 10
align 8 context  chain >> context 
full-name "M::CO::I"
n_parents=0 use_template=0 interface-unknown
pointer_to_this  chain >
t.i:1:30: internal compiler error: verify_type failed
0xf75d1c verify_type(tree_node const*)
../../gcc/gcc/tree.c:13818
0x991de4 gen_type_die_with_usage
../../gcc/gcc/dwarf2out.c:20739
0x992428 gen_type_die_with_usage
../../gcc/gcc/dwarf2out.c:20836
0x9932e6 gen_type_die
../../gcc/gcc/dwarf2out.c:20932
0x99efb7 gen_formal_types_die
../../gcc/gcc/dwarf2out.c:18283
0x9978b5 gen_subprogram_die
../../gcc/gcc/dwarf2out.c:19141
0x9996ac gen_decl_die
../../gcc/gcc/dwarf2out.c:21496
0x994563 gen_member_die
../../gcc/gcc/dwarf2out.c:20432
0x994563 gen_struct_or_union_type_die
../../gcc/gcc/dwarf2out.c:20516
0x994563 gen_tagged_type_die
../../gcc/gcc/dwarf2out.c:20717
0x99278d gen_type_die_with_usage
../../gcc/gcc/dwarf2out.c:20877
0x9932e6 gen_type_die
../../gcc/gcc/dwarf2out.c:20932
0x999c71 gen_decl_die
../../gcc/gcc/dwarf2out.c:21519
0x99a6bc dwarf2out_decl
../../gcc/gcc/dwarf2out.c:21974
0x99a9fb dwarf2out_type_decl
../../gcc/gcc/dwarf2out.c:21684
0xc0175f rest_of_type_compilation(tree_node*, int)
../../gcc/gcc/passes.c:335
0x6b0956 finish_struct_1(tree_node*)
../../gcc/gcc/cp/class.c:6776
0x67ff9b instantiate_class_template_1
../../gcc/gcc/cp/pt.c:10198
0x67ff9b instantiate_class_template(tree_node*)
../../gcc/gcc/cp/pt.c:10238
0x723f4b complete_type(tree_node*)
../../gcc/gcc/cp/typeck.c:131
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.

[Bug c/68447] New: ICE with -Wall on valid code on x86_64-linux-gnu in fold_binary_loc, at fold-const.c:9085

[su at cs dot ucdavis.edu]

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

Bug ID: 68447
   Summary: ICE with -Wall on valid code on x86_64-linux-gnu in
fold_binary_loc, at fold-const.c:9085
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  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 with
-Wall enabled 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 20151118 (experimental) [trunk revision 230547] (GCC) 
$ 
$ gcc-trunk -c small.c
$ gcc-5.2 -Wall -c small.c
small.c: In function ‘fn1’:
small.c:6:10: warning: left-hand operand of comma expression has no effect
[-Wunused-value]
   a != (0, 0); 
  ^
small.c:6:3: warning: statement with no effect [-Wunused-value]
   a != (0, 0); 
   ^
$ 
$ gcc-trunk -Wall -c small.c
small.c: In function ‘fn1’:
small.c:6:10: warning: left-hand operand of comma expression has no effect
[-Wunused-value]
   a != (0, 0);
  ^

small.c:6:3: internal compiler error: in fold_binary_loc, at fold-const.c:9085
   a != (0, 0);
   ^

0x83befd fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc-trunk/gcc/fold-const.c:9082
0x858f94 fold(tree_node*)
../../gcc-trunk/gcc/fold-const.c:11974
0x649880 warn_tautological_cmp(unsigned int, tree_code, tree_node*, tree_node*)
../../gcc-trunk/gcc/c-family/c-common.c:1927
0x601e5f parser_build_binary_op(unsigned int, tree_code, c_expr, c_expr)
../../gcc-trunk/gcc/c/c-typeck.c:3515
0x613678 c_parser_binary_expression
../../gcc-trunk/gcc/c/c-parser.c:6544
0x613b35 c_parser_conditional_expression
../../gcc-trunk/gcc/c/c-parser.c:6187
0x6141d0 c_parser_expr_no_commas
../../gcc-trunk/gcc/c/c-parser.c:6104
0x6148f2 c_parser_expression
../../gcc-trunk/gcc/c/c-parser.c:8250
0x615339 c_parser_expression_conv
../../gcc-trunk/gcc/c/c-parser.c:8283
0x62e4d1 c_parser_statement_after_labels
../../gcc-trunk/gcc/c/c-parser.c:5177
0x630594 c_parser_compound_statement_nostart
../../gcc-trunk/gcc/c/c-parser.c:4762
0x63098e c_parser_compound_statement
../../gcc-trunk/gcc/c/c-parser.c:4599
0x62c54b c_parser_declaration_or_fndef
../../gcc-trunk/gcc/c/c-parser.c:2017
0x637e6d c_parser_external_declaration
../../gcc-trunk/gcc/c/c-parser.c:1461
0x638869 c_parser_translation_unit
../../gcc-trunk/gcc/c/c-parser.c:1348
0x638869 c_parse_file()
../../gcc-trunk/gcc/c/c-parser.c:17658
0x6988d2 c_common_parse_file()
../../gcc-trunk/gcc/c-family/c-opts.c:1064
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;

void
fn1 ()
{
  a != (0, 0); 
}

[Bug c/61534] Wlogical-op should not warn when either operand comes from macro expansion

[manu at gcc dot gnu.org]

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

--- Comment #8 from Manuel López-Ibáñez  ---
The last patch did not fix the original testcase nor
gcc/testsuite/gcc.dg/pr40172-3.c

[Bug c/61534] Wlogical-op should not warn when either operand comes from macro expansion

[mpolacek at gcc dot gnu.org]

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

--- Comment #9 from Marek Polacek  ---
So that's why this PR is still open.

[Bug other/67868] ICE in handling VTV sections for targets with section anchors.

[wschmidt at gcc dot gnu.org]

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

--- Comment #11 from Bill Schmidt  ---
However, I should note that although libvtv builds and installs for Power, it
fails the testsuite completely, so we are going to leave this disabled for now.
 I'll open a bug report on the test failures.

[Bug tree-optimization/61502] == comparison on "one-past" pointer gives wrong result

[ch3root at openwall dot com]

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

--- Comment #18 from Alexander Cherepanov  ---
A bit simplified variant:

#include 

int main()
{
   int x, y = 1;
   int *volatile v;
   int *p;

   v = 
   p = v;
   if (p ==  + 1) {
 *p = 2;
 printf("y = %d\n", y);
   }
}

077t.alias dump shows such "Points-to sets" (among others):

v = { y }
p_5 = { y } same as v

and then the code:

   :
   *p_5 = 2;
   y.0_7 = y;
   printf ("y = %d\n", y.0_7);

Seems right.

081t.vrp1 dump shows such "Value ranges after VRP":

p_11: [[(void *) + 4B], [(void *) + 4B]]  EQUIVALENCES: { 
p_5 } (1 elements)

and the code:

   :
   MEM[(int *) + 4B] = 2;
   y.0_7 = y;
   printf ("y = %d\n", y.0_7);

Seems wrong.

gcc 5.2.0

On 2015-11-16 01:30, ch3root at openwall dot com wrote:
> I guess it depends on the transitivity of the == operator. After this bug is
> fixed it will be possible to constuct a third pointer r from two pointer p and
> q such that r == p and r == q but p != q. For p and q take  + 1 and  as
> above, obtain r by stripping provenance info from p or q (e.g. by printf/scanf
> with %p).

This bug turned out to be not that tricky after all. The program:

#include 

int main()
{
   int x, y;
   void *p =  + 1, *q = , *r;

   /* Strip p of provenance info */
   /* To simplify testing: */
   char s[100]; sprintf(s, "%p", p); sscanf(s, "%p", );
   /* Instead, imagine this:
   printf("%p or %p? ", p, q); scanf("%p", );
   */

   char *eq[] = {"!=", "=="};
   printf("r %s p, r %s q, p %s q\n", eq[r == p], eq[r == q], eq[p == q]);
}

prints "r == p, r == q, p != q" and the first two equalities are 
essentially mandated by C11 (unless you patch it by making one of them UB).

[Bug tree-optimization/68445] New: ICE: internal compiler error: in operator[], at vec.h

[pthaugen at gcc dot gnu.org]

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

Bug ID: 68445
   Summary: ICE: internal compiler error: in operator[], at vec.h
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pthaugen at gcc dot gnu.org
CC: bergner at gcc dot gnu.org, dje at gcc dot gnu.org
  Target Milestone: ---
  Host: powerpc64-unknown-linux-gnu
Target: powerpc64-unknown-linux-gnu
 Build: powerpc64-unknown-linux-gnu

See the following using current trunk (r230619).

[pthaugen@igoo delta]$ cat junk.c
void IMB_double_fast_x (float *destf, int *dest, int y, float *p1f)
{
  int i;
  for (i = y; i > 0; i--)
{
  *dest++ = 0;
  destf[0] = destf[4] = p1f[0];
  destf[1] = destf[5] = p1f[1];
  destf[2] = destf[6] = p1f[2];
  destf[3] = destf[7] = p1f[3];
  destf += 8;
  p1f += 4;
}
}


[pthaugen@igoo delta]$ ~/install/gcc/trunk/bin/gcc -c -O3 -mcpu=power8 junk.c
junk.c: In function ‘IMB_double_fast_x’:
junk.c:1:6: internal compiler error: in operator[], at vec.h:714
 void IMB_double_fast_x (float *destf, int *dest, int y, float *p1f)
  ^

0x10aedf43 vec::operator[](unsigned int)
/home/pthaugen/src/gcc/trunk/gcc/gcc/vec.h:714
0x10aedf43 vec::operator[](unsigned int)
/home/pthaugen/src/gcc/trunk/gcc/gcc/vec.h:1180
0x10aedf43 vect_create_mask_and_perm
/home/pthaugen/src/gcc/trunk/gcc/gcc/tree-vect-slp.c:3195
0x10aedf43 vect_transform_slp_perm_load(_slp_tree*, vec, gimple_stmt_iterator*, int, _slp_instance*, bool)
/home/pthaugen/src/gcc/trunk/gcc/gcc/tree-vect-slp.c:3458
0x10abf86b vectorizable_load
/home/pthaugen/src/gcc/trunk/gcc/gcc/tree-vect-stmts.c:7196
0x10aca8cf vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*,
_slp_tree*, _slp_instance*)
/home/pthaugen/src/gcc/trunk/gcc/gcc/tree-vect-stmts.c:8046
0x10af2737 vect_schedule_slp_instance
/home/pthaugen/src/gcc/trunk/gcc/gcc/tree-vect-slp.c:3608
0x10af27b7 vect_schedule_slp_instance
/home/pthaugen/src/gcc/trunk/gcc/gcc/tree-vect-slp.c:3489
0x10af3057 vect_schedule_slp(vec_info*)
/home/pthaugen/src/gcc/trunk/gcc/gcc/tree-vect-slp.c:3673
0x10ad4a03 vect_transform_loop(_loop_vec_info*)
/home/pthaugen/src/gcc/trunk/gcc/gcc/tree-vect-loop.c:6747
0x10afcdbb vectorize_loops()
/home/pthaugen/src/gcc/trunk/gcc/gcc/tree-vectorizer.c:548
0x109d2103 execute
/home/pthaugen/src/gcc/trunk/gcc/gcc/tree-ssa-loop.c:276

[Bug c++/68427] GCC (G++) flunks legal ANSI-C code

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to wam from comment #3)
> comment 1: How do I go about doing that (posting preprocessed source file) ?

It's explained at the link you should have read before creating a bug:
https://gcc.gnu.org/bugs/

> The tarball I uploaded just has 2 text files showing the output of my effort
> to compile the code, & the code in its own tarball.

Yes I know, I used the same commands as you showed in your file, and it
compiled successfully.

> comment 2: The code was ANSI-C for about 15 years (from ~1995 on), then
> converted to C++ by simply renaming it to gauss.cpp & overloading the names
> of the various gauss functions. It is otherwise legal ANSI C code.

But that's irrelevant. It's *not* ANSI C code if you've used overloaded
functions, and you're compiling it as C++ anyway so it's besides the point. C
and C++ are different languages, just because something used to be valid C
doesn't mean failing to compile as C++ indicates a compiler bug.

> As to the
> makefile, I used GCC 4.8.5, pkg-installed, i.e. compiled up by the FreeBSD
> folks & retreived by me from their repo. I compiled the GCC5.2.1 up myself,
> adding Graphite support (recently accomodated by the GCC maintainer(s)). I
> did nothing to the makefile myself. I originally posted this to the
> FreeBSD-toolchain list & was advised to repost it here. When you compile it,
> are you using FreeBSD 9.3R to do so, or another implementation ?

I only tried on GNU/Linux. The errors shown in your file are not
platform-specific, they suggest a header file was missing or something like
that.

[Bug ada/68443] [ada] FAIL: c39006b

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Confirmed between revisions r230509 (PASS) and r230581 (FAIL).

[Bug other/68444] New: [libvtv] All libvtv tests fail for powerpc*-*-linux* (undefined references)

[wschmidt at gcc dot gnu.org]

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

Bug ID: 68444
   Summary: [libvtv] All libvtv tests fail for powerpc*-*-linux*
(undefined references)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wschmidt at gcc dot gnu.org
CC: dje.gcc at gmail dot com
  Target Milestone: ---
  Host: powerpc*-*-linux*
Target: powerpc*-*-linux*
 Build: powerpc*-*-linux*

I attempted enabling libvtv for power*-*-linux* today by setting
VTV_SUPPORTED=yes in libvtv/configure.tgt.  The build and installation of
libvtv all succeeded.  However, all of the tests in the test suite fail.

Looking at the libvtv.log file, the failures all involve linkage errors like
these:

bb_tests.cc:(.text+0x174): undefined reference to
`__VLTVerifyVtablePointer(void
**, void const*)'

bb_tests.cc:(.text+0x29c): undefined reference to `__VLTRegisterSet(void**,
void
 const*, unsigned long, unsigned long, void**)'

nested_vcall_test.cc:(.text+0x3f8): undefined reference to
`__VLTRegisterPair(vo
id**, void const*, unsigned long, void const*)'

register_set_pair.cc:(.text+0x380): undefined reference to
`__VLTChangePermission'

[Bug jit/68446] jit testsuite failures seen inside dwarf2out.c:gen_producer_string

[dmalcolm at gcc dot gnu.org]

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

--- Comment #1 from David Malcolm  ---
(In reply to David Malcolm from comment #0)
[...]
> I ran a git bisect, it indicated that the failure of test-volatile.c was
> introduced by:
> 
> commit 25faed340686df8d7bb2242dc8d04285976922b6
> Author: marxin 
> Date:   Thu Nov 12 15:50:05 2015 +
> 
> Fix big memory leak in ix86_valid_target_attribute_p
> 
> * config/i386/i386.c (ix86_valid_target_attribute_p):
> Finalize options at the of the function.
> * gcc.c (driver_get_configure_time_options): Call newly
> introduced init_opts_obstack.
> * lto-wrapper.c (main): Likewise.
> * opts.c (init_opts_obstack): New function.
> (init_options_struct): Call newly
> introduced init_opts_obstack.
> * opts.h (init_options_struct): Declare.

i.e. r230264 (hopefully bugzilla will URL-ify this)

[Bug fortran/68442] ICE on kind specification, depending on ordering of functions

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

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

--- Comment #1 from Gerhard Steinmetz  
---
Detected with reversed order :


$ cat z2.f90
module m
   interface gkind
  procedure g
   end interface
contains
   integer function g()
  g = 1
   end
   subroutine f(x)
  character(kind=gkind()) :: x
   end
end


$ gfortran-5 -g -O0 -Wall -fcheck=all z2.f90
z2.f90:10:21:

   character(kind=gkind()) :: x
 1
Error: Function 'gkind' in initialization expression at (1) must be an
intrinsic function

[Bug ada/68443] New: [ada] FAIL: c39006b

[vries at gcc dot gnu.org]

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

Bug ID: 68443
   Summary: [ada] FAIL: c39006b
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

With r230596:
...
RUN c39006b

,.,. C39006B ACATS 2.5 15-11-19 04:41:57
 C39006B CHECK THAT PROGRAM_ERROR IS RAISED IF AN ATTEMPT IS MADE TO
CALL A SUBPROGRAM WHOSE BODY HAS NOT YET BEEN
ELABORATED.
   * C39006B PROGRAM_ERROR NOT RAISED - 2.
 C39006B FAILED .
FAIL:   c39006b
...

[Bug c++/68396] function auto-deduced return types get incorrectly classified as parameter packs

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Thu Nov 19 18:25:38 2015
New Revision: 230620

URL: https://gcc.gnu.org/viewcvs?rev=230620=gcc=rev
Log:
PR c++/68396

2015-11-19  Ryan Burn  

* pt.c (find_parameter_packs_r) [DECLTYPE_TYPE]: When traversing
the DECLTYPE_TYPE_EXPR, set type_pack_expansion_p to false.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/pr68396.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug fortran/66762] ICE when compiling gfortran.dg/submodule_[16].f90 with -flto

[dominiq at lps dot ens.fr]

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

--- Comment #11 from Dominique d'Humieres  ---
> The attached patch fixes the problem but is, as yet, not regtested.

Confirmed and regtested without regression. Thanks.

[Bug jit/68446] New: jit testsuite failures seen inside dwarf2out.c:gen_producer_string

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 68446
   Summary: jit testsuite failures seen inside
dwarf2out.c:gen_producer_string
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

At r230562 (aka 21a6b87b86defda10ac903a9cd49e34b1f8ce6fb) jit.sum has:
  # of expected passes1711
  # of unexpected failures60
  # of unresolved testcases   2
as compared to e.g. trunk from July (r226339;
1ae7fdc96dfbbd74f29a0d563fa7641c1563d615) which has jit.sum:
  # of expected passes6372
  # of unexpected failures1
(where: FAIL: jit.dg/test-threads.c, initial compilation, due to:
/home/david/coding-3/gcc-git-jit-clean/src/gcc/testsuite/jit.dg/harness.h:25:14:
error: static declaration of 'dejagnu_pass' follows non-static declaration
/home/david/coding-3/gcc-git-jit-clean/src/gcc/testsuite/jit.dg/test-threads.c:23:6:
note: previous declaration of 'dejagnu_pass' was here
(I think I've fixed this other failure).

i.e. lots of major failures.

They seem to mostly be an ICE in:
0x7f9d586ee332 gen_producer_string
../../src/gcc/dwarf2out.c:20139
0x7f9d586ee332 dwarf2out_finish
../../src/gcc/dwarf2out.c:25250

due to this assertion failing:
20139 gcc_checking_assert (save_decoded_options[j].canonical_option[0][0]
20140  == '-');

A minimal reproducer is e.g. test-volatile.c

As far as I can tell, save_decoded_options[3] and [4] canonical_option
fieldhave become the empty string (or corrupt?); the loop is accessing 0..9,
and dies with j == 3:
(gdb) p save_decoded_options[0]
$6 = {opt_index = 1432, warn_message = 0x0, 
  arg = 0x606120
"/home/david/coding-3/gcc-git-clean/build-with-jit/gcc/test-volatile.c.exe", 
  orig_option_with_args_text = 0x606120
"/home/david/coding-3/gcc-git-clean/build-with-jit/gcc/test-volatile.c.exe", 
  canonical_option = {0x606120
"/home/david/coding-3/gcc-git-clean/build-with-jit/gcc/test-volatile.c.exe",
0x0, 0x0, 0x0}, 
  canonical_option_num_elements = 1, value = 1, errors = 0}
(gdb) p save_decoded_options[1]
$7 = {opt_index = 1433, warn_message = 0x0, arg = 0x606b50
"/tmp/libgccjit-8Mwbrw/fake.c", 
  orig_option_with_args_text = 0x606b50 "/tmp/libgccjit-8Mwbrw/fake.c",
canonical_option = {
0x606b50 "/tmp/libgccjit-8Mwbrw/fake.c", 0x0, 0x0, 0x0},
canonical_option_num_elements = 1, value = 1, errors = 0}
(gdb) p save_decoded_options[2]
$8 = {opt_index = 486, warn_message = 0x0, arg = 0x0,
orig_option_with_args_text = 0x608340 "", canonical_option = {
0x775b9759 "-fPIC", 0x0, 0x0, 0x0}, canonical_option_num_elements = 1,
value = 1, errors = 0}
(gdb) p save_decoded_options[3]
$9 = {opt_index = 139, warn_message = 0x0, arg = 0x606e42 "3",
orig_option_with_args_text = 0x608360 "\377\377\001", 
  canonical_option = {0x608350 "", 0x0, 0x0, 0x0},
canonical_option_num_elements = 1, value = 1, errors = 0}
(gdb) p save_decoded_options[4]
$10 = {opt_index = 1126, warn_message = 0x0, arg = 0x606e62 "",
orig_option_with_args_text = 0x608380 "\200", canonical_option = {
0x608370 "", 0x0, 0x0, 0x0}, canonical_option_num_elements = 1, value = 1,
errors = 0}

I ran a git bisect, it indicated that the failure of test-volatile.c was
introduced by:

commit 25faed340686df8d7bb2242dc8d04285976922b6
Author: marxin 
Date:   Thu Nov 12 15:50:05 2015 +

Fix big memory leak in ix86_valid_target_attribute_p

* config/i386/i386.c (ix86_valid_target_attribute_p):
Finalize options at the of the function.
* gcc.c (driver_get_configure_time_options): Call newly
introduced init_opts_obstack.
* lto-wrapper.c (main): Likewise.
* opts.c (init_opts_obstack): New function.
(init_options_struct): Call newly
introduced init_opts_obstack.
* opts.h (init_options_struct): Declare.


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

[Bug c/61534] Wlogical-op should not warn when either operand comes from macro expansion

[manu at gcc dot gnu.org]

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

--- Comment #10 from Manuel López-Ibáñez  ---
(In reply to Marek Polacek from comment #9)
> So that's why this PR is still open.

Sure, sorry, I should have been clearer. It was mostly a note to myself so I do
not need to re-check next time I look at this PR.

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

[joseph at codesourcery dot com]

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

--- Comment #34 from joseph at codesourcery dot com  ---
On Thu, 19 Nov 2015, ch3root at openwall dot com wrote:

> What does the following mean then?
> 
> C11, 4p5:
> "A strictly conforming program[...] It [...] shall not exceed any 
> minimum implementation limit."

It's well-known that, if you read the standard literally, strictly 
conforming programs may not exist; too much is unspecified or 
implementation-defined (including, in general, limits on supported 
programs; cf 1#2 "This International Standard does not specify ... the 
size or complexity of a program and its data that will exceed the capacity 
of any specific data-processing system or the capacity of a particular 
processor").

In general, you can only reason about C programs conditional on the 
program not exceeding any implementation limit.

[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 #33 from Alexander Cherepanov  ---
On 2015-11-12 06:25, msebor at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
>
> --- Comment #31 from Martin Sebor  ---
> (In reply to Alexander Cherepanov from comment #23)
>
>> 2. The practical problem is size calculation in general, it's not
>> limited to sizeof operation. You don't need to use sizeof to create
>> oversized automatic VLA (an example in the description).
>
> Agreed.  Creating an automatic VLA object that exhausts the stack is bad.  In
> all likelihood it will crash the program.  I'm not sure to what extent it 
> might
> be exploitable.

 From http://www.openwall.com/lists/oss-security/2014/11/03/2 :
"It can be exploitable in multithreaded programs though if there is
an unused stack allocation of at least one page further down in the
stack."

Sorry, don't have more info off-hand.

> Allowing a sizeof expression to overflow given a VLA type is
> benign in an of itself, but can lead to more subtle bugs depending on how the
> result is used (e.g., to allocate an array on the heap whose elements are then
> written to).  Some of those bugs have known exploits.

Sure.

>> 3. IMHO overflow in sizeof operation is UB due to C11, 6.5p5, and
>> wrapping according to C11, 6.2.5p9, is not applicable (see the comment #7).
>
> No, that's not a correct interpretation.  It's exactly the other way around.
> Sizeof is computed in an unsigned type.

IMHO, how sizeof is computed is an implementation detail. C11 doesn't 
describe it at all. E.g., for arrays it doesn't mention multiplication 
and just says that "the result is the total number of bytes in the 
array". From another side: an operand of sizeof is usually not unsigned. 
Even when the operand is unsigned, sizeof doesn't compute anything with 
it, sizeof work with its type.

>> 4. From the POV of the standard I don't see much difference between VLA
>> and ordinary arrays in this question. AFAICT the standard doesn't place
>> limits on constructed types of any kind and hence oversized types are
>> permitted by the standard. See comment #3 (or pr68107) for a practical
>> example of sizeof overflow with an array of a known constant size which
>> works with the current gcc.
>
> It is the intent of the standard to allow implementations to impose such a
> limit.  It may not be specified with sufficient clarity in the text, but the
> intent is reflected in the C99 Rationale.

Yeah, it seems to be a known problem without know solution:-) But IMHO:

* if C11, 4p6, (about acceptig any strictly conforming
program) is really mean what I think it means it should be fixed;

* the scope of the problem should be somehow acknowledged and preferably 
limited in the standard. Something like saying that an implementation 
can impose any other restrictions but those restrictions must be 
documented. It's a sad situation when arbitrary limits could be imposed 
but there is no way for a user to find out which. The ideal illustration 
here is pr67999. It's a limit which can lead to security problems, which 
is not documented and which is not detected at compile- or run-time.

[Bug c++/68450] New: regex matching different from ECMAScript?

[lcoquelle at gmail dot com]

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

Bug ID: 68450
   Summary: regex matching different from ECMAScript?
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lcoquelle at gmail dot com
  Target Milestone: ---

Created attachment 36777
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36777=edit
Code sample

Using a complex regex to remove comment in JSON file (...), the behaviour seems
to differ from ECMAScript.
FYI: boost::regex 1.59 seems to have the correct behaviour.

Regex: ((['"])(?:(?!\2|\\).|\\.)*\2)|\/\/[^\n]*|\/\*(?:[^*]|\*(?!\/))*\*\/
(can be try here: https://regex101.com/r/vI2iW5/2#javascript)

Input string: "Entry": "Value", // Skip "me"
Expected output: "Entry": "Value", 
Real output: "Entry": "Value", // Skip "me"



Attached a code sample.
Compiling output as below:


> /usr/local/gcc49/bin/g++ -v -save-temps -Wall -std=gnu++14 re.cc 
Using built-in specs.
COLLECT_GCC=/usr/local/gcc49/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/gcc49/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /usr/local/src/gcc-4.9.2/configure --disable-multilib
--enable-cloog-backend=isl --enable-gold=default --enable-languages=c,c++
--enable-lto --enable-libssp --enable-plugins --enable-plugin
--with-build-config=bootstrap-lto --enable-stage1-checking=release
--prefix=/usr/local/gcc49
Thread model: posix
gcc version 4.9.2 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-std=gnu++1y' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/local/gcc49/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/cc1plus -E -quiet
-v -D_GNU_SOURCE re.cc -mtune=generic -march=x86-64 -std=gnu++1y -Wall
-fpch-preprocess -o re.ii
ignoring nonexistent directory
"/usr/local/gcc49/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/usr/local/gcc49/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../include/c++/4.9.2

/usr/local/gcc49/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../include/c++/4.9.2/x86_64-unknown-linux-gnu

/usr/local/gcc49/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../include/c++/4.9.2/backward
 /usr/local/gcc49/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/include
 /usr/local/include
 /usr/local/gcc49/include
 /usr/local/gcc49/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-std=gnu++1y' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/local/gcc49/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/cc1plus
-fpreprocessed re.ii -quiet -dumpbase re.cc -mtune=generic -march=x86-64
-auxbase re -Wall -std=gnu++1y -version -o re.s
GNU C++ (GCC) version 4.9.2 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.9.2, GMP version 6.0.0, MPFR version 3.1.2,
MPC version 1.0.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (GCC) version 4.9.2 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.9.2, GMP version 6.0.0, MPFR version 3.1.2,
MPC version 1.0.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 4c9e457b752b2d9171dda4de0a18535a
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-std=gnu++1y' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'

/usr/local/gcc49/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../x86_64-unknown-linux-gnu/bin/as
-v --64 -o re.o re.s
GNU assembler version 2.24 (x86_64-unknown-linux-gnu) using BFD version (GNU
Binutils) 2.24
COMPILER_PATH=/usr/local/gcc49/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/:/usr/local/gcc49/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/:/usr/local/gcc49/libexec/gcc/x86_64-unknown-linux-gnu/:/usr/local/gcc49/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/:/usr/local/gcc49/lib/gcc/x86_64-unknown-linux-gnu/:/usr/local/gcc49/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../x86_64-unknown-linux-gnu/bin/
LIBRARY_PATH=/usr/local/gcc49/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/:/usr/local/gcc49/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/local/gcc49/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../x86_64-unknown-linux-gnu/lib/:/usr/local/gcc49/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-std=gnu++1y' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/local/gcc49/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/collect2 -plugin
/usr/local/gcc49/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/liblto_plugin.so
-plugin-opt=/usr/local/gcc49/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper
-plugin-opt=-fresolution=re.res -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc

[Bug c/68447] ICE with -Wall on valid code on x86_64-linux-gnu in fold_binary_loc, at fold-const.c:9085

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Dup.  Patch: https://gcc.gnu.org/ml/gcc-patches/2015-11/msg02408.html

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

[Bug c/68412] [6 Regression] ICE with -Wall -Wextra in fold_binary_loc()

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||su at cs dot ucdavis.edu

--- Comment #3 from Marek Polacek  ---
*** Bug 68447 has been marked as a duplicate of this bug. ***

[Bug libstdc++/68448] Python Pretty Printers get disabled on libstdc++ reload by GDB

[jan.kratochvil at redhat dot com]

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

--- Comment #1 from Jan Kratochvil  ---
https://bugzilla.redhat.com/show_bug.cgi?id=1279406

[Bug c++/68348] [6 regression] ICE: segfault in cxx_eval_constant_expression at cp/constexpr.c:3172

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #4 from Martin Sebor  ---
Bug 68449 is likely a duplicate of this one, though with a test case not
involving C++ 11 constexpr.

[Bug libstdc++/68448] Python Pretty Printers get disabled on libstdc++ reload by GDB

[jan.kratochvil at redhat dot com]

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

--- Comment #2 from Jan Kratochvil  ---
[patch] Python Pretty Printers get disabled on libstdc++ reload by GDB (PR
libstdc++/68448)
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg02418.html

[Bug fortran/68442] New: ICE on kind specification, depending on ordering of functions

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

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

Bug ID: 68442
   Summary: ICE on kind specification, depending on ordering of
functions
   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: ---

Using this order (f before g) :


$ cat z1.f90
module m
   interface gkind
  procedure g
   end interface
contains
   subroutine f(x)
  character(kind=gkind()) :: x
   end
   integer function g()
  g = 1
   end
end


$ gfortran-5 -g -O0 -Wall -fcheck=all z1.f90
f951: internal compiler error: in gfc_arglist_matches_symbol, at
fortran/interface.c:3468

[Bug ada/68443] [ada] FAIL: c39006b

[charlet at gcc dot gnu.org]

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

Arnaud Charlet  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||charlet at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|--- |6.0

--- Comment #2 from Arnaud Charlet  ---
was fixed on revision 230617

[Bug c/61534] Wlogical-op should not warn when either operand comes from macro expansion

[mpolacek at gcc dot gnu.org]

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

--- Comment #11 from Marek Polacek  ---
Np.  It's certainly something I'd love to see fixed :/.  Hopefully the next
stage1.

[Bug libstdc++/68448] New: Python Pretty Printers get disabled on libstdc++ reload by GDB

[jan.kratochvil at redhat dot com]

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

Bug ID: 68448
   Summary: Python Pretty Printers get disabled on libstdc++
reload by GDB
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.kratochvil at redhat dot com
  Target Milestone: ---

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

echo -e '#include \nint main(){std::vector l;\nreturn 0;}'|g++ -g
-Wall -x c++ -;gdb -q ./a.out -batch -ex 'b 3' -ex r -ex 'p l' -ex r -ex 'p l'

Actual:
[...]
$1 = std::vector of length 0, capacity 0
[...]
$2 = {> = {_M_impl =
{ = {<__gnu_cxx::new_allocator> = {},
}, _M_start = 0x0, _M_finish = 0x0, _M_end_of_storage = 0x0}},
}

Expected:
[...]
$1 = std::vector of length 0, capacity 0
[...]
$2 = std::vector of length 0, capacity 0

[Bug c++/68449] New: ICE in cxx_eval_constant_expression on atomic_load in C++

[msebor at gcc dot gnu.org]

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

Bug ID: 68449
   Summary: ICE in cxx_eval_constant_expression on atomic_load in
C++
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Compiling the following program with the latest trunk triggers a number of
errors due to the _Atomic qualifier that's not recognized in C++ followed by an
ICE:

$ cat z.cpp && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -S
-Wall -o/dev/null  -xc++ z.cpp
#include 

int foo (int *p)
{
return atomic_load (p) < 0;
}

After reducing that to a small test case I ended up with the following valid
code.

Searching for cxx_eval_constant_expression suggests this might be a duplicate
of bug 68348.

$ cat z.ii && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -S
-Wall -o/dev/null -xc++ z.ii
int foo (int a)
{
return __extension__ ({
__typeof__ (a) b;
b; }) < 0;
}
z.ii: In function ‘int foo(int)’:
z.ii:5:17: internal compiler error: Segmentation fault
 b; }) < 0;
 ^

0xffa298 crash_signal
/home/msebor/scm/fsf/gcc-svn/gcc/toplev.c:334
0x9f417f cxx_eval_constant_expression
/home/msebor/scm/fsf/gcc-svn/gcc/cp/constexpr.c:3198
0x9f377d cxx_eval_statement_list
/home/msebor/scm/fsf/gcc-svn/gcc/cp/constexpr.c:3029
0x9f59ce cxx_eval_constant_expression
/home/msebor/scm/fsf/gcc-svn/gcc/cp/constexpr.c:3614
0x9f5a4d cxx_eval_constant_expression
/home/msebor/scm/fsf/gcc-svn/gcc/cp/constexpr.c:3620
0x9f628a cxx_eval_outermost_constant_expr
/home/msebor/scm/fsf/gcc-svn/gcc/cp/constexpr.c:3774
0x9f6c9c maybe_constant_value_1
/home/msebor/scm/fsf/gcc-svn/gcc/cp/constexpr.c:3960
0x9f6d99 maybe_constant_value(tree_node*, tree_node*)
/home/msebor/scm/fsf/gcc-svn/gcc/cp/constexpr.c:3981
0x8f5e3c cp_build_binary_op(unsigned int, tree_code, tree_node*, tree_node*,
int)
/home/msebor/scm/fsf/gcc-svn/gcc/cp/typeck.c:5045
0x73e1d4 build_new_op_1
/home/msebor/scm/fsf/gcc-svn/gcc/cp/call.c:5758
0x73e2c8 build_new_op(unsigned int, tree_code, int, tree_node*, tree_node*,
tree_node*, tree_node**, int)
/home/msebor/scm/fsf/gcc-svn/gcc/cp/call.c:5803
0x8f1d8f build_x_binary_op(unsigned int, tree_code, tree_node*, tree_code,
tree_node*, tree_code, tree_node**, int)
/home/msebor/scm/fsf/gcc-svn/gcc/cp/typeck.c:3828
0x892faa cp_parser_binary_expression
/home/msebor/scm/fsf/gcc-svn/gcc/cp/parser.c:8591
0x8932a1 cp_parser_assignment_expression
/home/msebor/scm/fsf/gcc-svn/gcc/cp/parser.c:8712
0x893511 cp_parser_expression
/home/msebor/scm/fsf/gcc-svn/gcc/cp/parser.c:8871
0x8981bc cp_parser_jump_statement
/home/msebor/scm/fsf/gcc-svn/gcc/cp/parser.c:11408
0x895904 cp_parser_statement
/home/msebor/scm/fsf/gcc-svn/gcc/cp/parser.c:10035
0x896408 cp_parser_statement_seq_opt
/home/msebor/scm/fsf/gcc-svn/gcc/cp/parser.c:10426
0x896303 cp_parser_compound_statement
/home/msebor/scm/fsf/gcc-svn/gcc/cp/parser.c:10380
0x8a70f3 cp_parser_function_body
/home/msebor/scm/fsf/gcc-svn/gcc/cp/parser.c:20192
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
tmp$

[Bug c++/68427] GCC (G++) flunks legal ANSI-C code

[wam at hiwaay dot net]

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

--- Comment #5 from wam at hiwaay dot net ---
Created attachment 36776
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36776=edit
response to comment 4 

Here is the stuff in reply to comment 4 

[Bug tree-optimization/68335] [6 Regression][GRAPHITE] ICE: tree check: expected ssa_name, have real_cst in add_phi_arg_for_new_expr, at sese.c:1373

[spop at gcc dot gnu.org]

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

--- Comment #4 from Sebastian Pop  ---
testcase added in r230630

[Bug fortran/68439] ICE in alloc_scalar_allocatable_for_subcomponent_assignment, at fortran/trans-expr.c:6711

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Confirmed for 5.2 and trunk (6.0). Version 4.9 gives the error

pr68439.f90:7.7:

   x = t(a=1)
   1
Error: No initializer for component 'c' given in the structure constructor at
(1)!

and version 4.8

pr68439.f90:4.36:

  character(:), allocatable :: c
1
Error: Deferred-length character component 'c' at (1) is not yet supported

[Bug fortran/68440] ICE on declaring class variable with wrong attribute

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #3 from Dominique d'Humieres  ---
Compiling the first two tests with 4.8 up to trunk gives an ICE. Compiling the
third and fourth tests with 4.8 up to 5.2 gives and ICE, but with trunk (6.0)
the third test compiles without error and the fourth test gives the following
error

pr68440_3.f90:4:16:

class(t) :: x = t()
1

Error: CLASS variable 'x' at (1) must be dummy, allocatable or pointer

The last two tests give the reported errors with 4.8 up to trunk, except the
last one when compiled with 4.8:

   x = t()
   1
Error: Variable must not be polymorphic in intrinsic assignment at (1) - check
that there is a matching specific subroutine for '=' operator

[Bug tree-optimization/68428] [6 Regression] [graphite] ICE in outermost_loop_in_sese w/ -O2 -floop-strip-mine or -O2 -floop-nest-optimize

[spop at gcc dot gnu.org]

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

Sebastian Pop  changed:

   What|Removed |Added

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

--- Comment #1 from Sebastian Pop  ---
Fixed in r230632

[Bug c/68412] [6 Regression] ICE with -Wall -Wextra in fold_binary_loc()

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
Fixed.

[Bug c/68412] [6 Regression] ICE with -Wall -Wextra in fold_binary_loc()

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Author: mpolacek
Date: Thu Nov 19 22:04:00 2015
New Revision: 230627

URL: https://gcc.gnu.org/viewcvs?rev=230627=gcc=rev
Log:
PR c/68412
* c-typeck.c (parser_build_binary_op): Properly handle
C_MAYBE_CONST_EXPR before calling warn_tautological_cmp.

* gcc.dg/pr68412-2.c: New test.
* gcc.dg/pr68412.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr68412-2.c
trunk/gcc/testsuite/gcc.dg/pr68412.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/68422] compile-time cost of sizeof... is quadratic

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Thu Nov 19 22:29:08 2015
New Revision: 230629

URL: https://gcc.gnu.org/viewcvs?rev=230629=gcc=rev
Log:
PR c++/68422

* cp-tree.h (PACK_EXPANSION_SIZEOF_P): New.
* parser.c (cp_parser_sizeof_pack): Set it.
* pt.c  (tsubst_copy) [SIZEOF_EXPR]: Likewise.
(tsubst_pack_expansion): Improve T... shortcut for expression packs.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/parser.c
trunk/gcc/cp/pt.c

[Bug fortran/68442] ICE on kind specification, depending on ordering of functions

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #2 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk.

[Bug tree-optimization/68335] [6 Regression][GRAPHITE] ICE: tree check: expected ssa_name, have real_cst in add_phi_arg_for_new_expr, at sese.c:1373

[spop at gcc dot gnu.org]

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

Sebastian Pop  changed:

   What|Removed |Added

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

--- Comment #3 from Sebastian Pop  ---
This is fixed in trunk as of today.  I will add the testcase.

[Bug fortran/68441] ICE on using transfer with character parameter

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (6.0).

[Bug tree-optimization/68341] [6 Regression] FAIL: gcc.dg/graphite/interchange-{1,11,13}.c (internal compiler error)

[spop at gcc dot gnu.org]

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

Sebastian Pop  changed:

   What|Removed |Added

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

--- Comment #4 from Sebastian Pop  ---
Fixed in r230631

[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 #32 from Alexander Cherepanov  ---
Sorry for the late reply. Decided to read DR 260 and got distracted. It 
so fundamentally undermines the base of classical C that it took me some 
time to grasp the scale:-)

On 2015-11-12 01:51, joseph at codesourcery dot com wrote:
>> 4. From the POV of the standard I don't see much difference between VLA
>> and ordinary arrays in this question. AFAICT the standard doesn't place
>> limits on constructed types of any kind and hence oversized types are
>> permitted by the standard. See comment #3 (or pr68107) for a practical
>
> "permitted by" only in the sense of "the standard does not require
> implementations to reject them".  It is not intended that the listed
> implementation limits are the only limits that there may be, at compile
> time or run time.

What does the following mean then?

C11, 4p5:
"A strictly conforming program[...] It [...] shall not exceed any 
minimum implementation limit."

C11, 4p6:
"A conforming hosted implementation shall accept any strictly conforming 
program."

>> 3. The same for sizes of objects. There is an environmental limit for
>> "bytes in an object" but it's marked as "(in a hosted environment
>> only)". So there is no such limit in the standard for a freestanding
>> implementation, right? But I doubt that you are supposed to be able to
>
> No, what's "in a hosted environment only" is the requirement that the
> implementation translate and execute some program with a 65535-byte object
> (and an instance of the other given limits, simultaneously); freestanding
> implementations may have an object size limit smaller than 65535 bytes.
> That is, effectively, C99 and above do not support hosted environments
> with a 16-bit address space; systems with a 16-bit address space are only
> supported for freestanding implementations.

I see, thanks for the info.

[Bug rtl-optimization/68432] [6 Regression] internal compiler error: in expand_insn, at optabs.c:6947

[rsandifo at gcc dot gnu.org]

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

--- Comment #1 from rsandifo at gcc dot gnu.org  
---
Just to check: is this x86_64-linux-gnu?

[Bug target/68408] broken support for attribute init_priority

[ebotcazou at gcc dot gnu.org]

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

--- Comment #3 from Eric Botcazou  ---
Author: ebotcazou
Date: Thu Nov 19 11:49:32 2015
New Revision: 230598

URL: https://gcc.gnu.org/viewcvs?rev=230598=gcc=rev
Log:
PR target/68408
* config/sparc/sp-elf.h (CTORS_SECTION_ASM_OP): Undefine.
(DTORS_SECTION_ASM_OP): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sparc/sp-elf.h

[Bug target/68408] broken support for attribute init_priority

[ebotcazou at gcc dot gnu.org]

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

--- Comment #5 from Eric Botcazou  ---
Author: ebotcazou
Date: Thu Nov 19 11:51:20 2015
New Revision: 230600

URL: https://gcc.gnu.org/viewcvs?rev=230600=gcc=rev
Log:
PR target/68408
* config/sparc/sp-elf.h (CTORS_SECTION_ASM_OP): Undefine.
(DTORS_SECTION_ASM_OP): Likewise.

Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/sparc/sp-elf.h

[Bug tree-optimization/68413] [6 Regression] internal compiler error: in vect_transform_stmt

[alahay01 at gcc dot gnu.org]

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

alahay01 at gcc dot gnu.org changed:

   What|Removed |Added

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

[Bug tree-optimization/68413] [6 Regression] internal compiler error: in vect_transform_stmt

[alahay01 at gcc dot gnu.org]

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

--- Comment #5 from alahay01 at gcc dot gnu.org ---
Yes, your right, I meant to say vectorizable_reduction - it's a reduction of a
condition.

[Bug tree-optimization/68431] [6 Regression] Regression in GCC-6.0.0's optimizer

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

  Component|c   |tree-optimization
   Target Milestone|--- |6.0
Summary|Regression in GCC-6.0.0's   |[6 Regression] Regression
   |optimizer   |in GCC-6.0.0's optimizer

[Bug tree-optimization/68431] [6 Regression] Regression in GCC-6.0.0's optimizer

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-11-19
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Marek Polacek  ---
So should be trivial to fix, if I understood this right.

[Bug rtl-optimization/68432] [6 Regression] internal compiler error: in expand_insn, at optabs.c:6947

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-11-19
   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
Confirmed.  I can reproduce this with the anint_1.f90 test
when compiled with -fprofile-generate and then -fprofile-use.
The problem is the optimize_insn_for_size_p tests.

[Bug c++/68427] GCC (G++) flunks legal ANSI-C code

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Jonathan Wakely  ---
Why are you talking about ANSI-C when this is clearly C++ code?

The file gauss.cpp compiles fine for me, you must have a problem with your
makefile.

[Bug target/68408] broken support for attribute init_priority

[ebotcazou at gcc dot gnu.org]

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

--- Comment #4 from Eric Botcazou  ---
Author: ebotcazou
Date: Thu Nov 19 11:50:35 2015
New Revision: 230599

URL: https://gcc.gnu.org/viewcvs?rev=230599=gcc=rev
Log:
PR target/68408
* config/sparc/sp-elf.h (CTORS_SECTION_ASM_OP): Undefine.
(DTORS_SECTION_ASM_OP): Likewise.

Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/sparc/sp-elf.h

[Bug tree-optimization/68413] [6 Regression] internal compiler error: in vect_transform_stmt

[ienkovich at gcc dot gnu.org]

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

--- Comment #4 from Ilya Enkovich  ---
BTW I had an impression it was vectorizable_reduction which failed to
transform, not vectorizable_condition.

[Bug rtl-optimization/68432] [6 Regression] internal compiler error: in expand_insn, at optabs.c:6947

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch

--- Comment #2 from Joost VandeVondele  
---
(In reply to rsand...@gcc.gnu.org from comment #1)
> Just to check: is this x86_64-linux-gnu?

yes it is.x86_64-pc-linux-gnu

[Bug target/68408] broken support for attribute init_priority

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |4.9.4

--- Comment #6 from Eric Botcazou  ---
Fixed everywhere.

[Bug fortran/66762] ICE when compiling gfortran.dg/submodule_[16].f90 with -flto

[pault at gcc dot gnu.org]

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

--- Comment #10 from Paul Thomas  ---
Created attachment 36770
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36770=edit
Fix for the PR

The attached patch fixes the problem but is, as yet, not regtested.

Cheers

Paul

[Bug middle-end/68393] internal compiler error: in convert_move, at expr.c:286

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #6 from rsandifo at gcc dot gnu.org  
---
Patch applied.

[Bug lto/61313] configure incorrectly strips $target_alias from PLUGIN_LD_SUFFIX

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
Version|unknown |4.9.3
   Assignee|unassigned at gcc dot gnu.org  |ebotcazou at gcc dot 
gnu.org

--- Comment #3 from Eric Botcazou  ---
Let's just revert part of the change then, no big deal.

[Bug tree-optimization/68413] [6 Regression] internal compiler error: in vect_transform_stmt

[alan.hayward at arm dot com]

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

Alan Hayward  changed:

   What|Removed |Added

 CC||alan.hayward at arm dot com

--- Comment #2 from Alan Hayward  ---
The the first call to vectorizable_condition (the check stage) succeeded, but
the second call (the build stage) failed, causing an assert.

Reproduced with head r230297

When updated to latest head, r230596 , issue is no longer present.

Looking at changes in the vectorisor, there have been some vector bool changes,
r230309. The vector bool work previously clashed with my work, so I suspect
those changes have fixed it.

[Bug tree-optimization/68413] [6 Regression] internal compiler error: in vect_transform_stmt

[ienkovich at gcc dot gnu.org]

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

--- Comment #3 from Ilya Enkovich  ---
r230309 refers to a vectorization of a comparison of boolean values.  It
shouldn't affect condition vectorizaion.  Thus most probably check and build
stages of vectorizable_condition are still inconsistent.

[Bug fortran/68243] QOI: no warning about unused entities in submodules

[pault at gcc dot gnu.org]

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

--- Comment #5 from Paul Thomas  ---
(In reply to Dominique d'Humieres from comment #1)
> Confirmed.

Isn't this testcase a demonstration that unused3 and unused4 can be used
outside of m2?

module m1
  implicit none
  private
  interface
module subroutine s1
end subroutine
  end interface
  public s1
  integer unused1
contains
  subroutine unused2
  end subroutine
end module

submodule (m1) m2
  implicit none
  integer :: unused3 = 9
contains
  subroutine unused4
unused3 = 99
  end subroutine
end submodule

submodule (m1:m2) m3
  implicit none
contains
  module procedure s1
print *, unused3
call unused4
print *, unused3
  end procedure
end submodule

  use m1
  call s1
end

Cheers

Paul

[Bug rtl-optimization/68435] New: [6 Regression] Missed if-conversion optimization

[afomin.mailbox at gmail dot com]

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

Bug ID: 68435
   Summary: [6 Regression] Missed if-conversion optimization
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: afomin.mailbox at gmail dot com
CC: izamyatin at gmail dot com, kyrylo.tkachov at arm dot com,
ysrumyan at gmail dot com
  Target Milestone: ---
 Build: x86_64-linux-gnu

Created attachment 36772
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36772=edit
A reproducer

Given the following code compiled with -fif-conversion, we miss if-conversion
opportunity since r228194.

int
foo(char *p1, char *p2, int n)
{
  int s = 0;
  int v;
  int i;

  for (i = 0; i < n; i++) {
v = p1[i] - p2[i];
if (v >= 0)
  s += v;
else
  s -= v;
p1 = p2++;
  }

  return s;
}

[Bug target/57845] ICE with -freg-struct-return on SPARC

[sorganov at gmail dot com]

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

--- Comment #16 from Sergey Organov  ---
I confirm it is fixed on sparc-elf-gcc (GCC) 5.2.1 20151119.

Thanks one more time!

[Bug rtl-optimization/68435] [6 Regression] Missed if-conversion optimization

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #1 from ktkachov at gcc dot gnu.org ---
I'll have a look, thanks.
Is this on x86_64?
Could you please post the if-converted code before that revision?

[Bug tree-optimization/68431] [6 Regression] Regression in GCC-6.0.0's optimizer

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
Fixed.

[Bug tree-optimization/68431] [6 Regression] Regression in GCC-6.0.0's optimizer

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Author: mpolacek
Date: Thu Nov 19 15:12:35 2015
New Revision: 230608

URL: https://gcc.gnu.org/viewcvs?rev=230608=gcc=rev
Log:
PR tree-optimization/68431
* tree-vrp.c (extract_range_from_binary_expr_1): Fix condition.

* gcc.dg/tree-ssa/pr68431.c: New test.

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

[Bug target/68408] broken support for attribute init_priority

[ebotcazou at gcc dot gnu.org]

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

--- Comment #8 from Eric Botcazou  ---
> Eric, thank you very much for the quick fix! 

You're welcome.

> I confirm it is fixed on sparc-elf-g++ (GCC) 5.2.1 20151119.

Thanks, independent verification is always helpful.

[Bug c/68431] Regression in GCC-6.0.0's optimizer

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
In extract_range_from_binary_expr_1 we have
  /* When vr0.max < 0, vr1.min != 0 and value
 ranges for dividend and divisor are available.  */
  if (vr1.type == VR_RANGE
  && !symbolic_range_p ()
  && !symbolic_range_p ()
  && !compare_values (vr1.min, zero))
max = int_const_binop (code, vr0.max, vr1.min);
  else
max = zero; 

but that looks weird: the comment says "vr1.min != 0" but "&& !compare_values
(vr1.min, zero)" ensures that vr1.min is zero.

[Bug libstdc++/68448] Python Pretty Printers get disabled on libstdc++ reload by GDB

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
Thanks for figuring out the problem, this has been annoying me recently but I
didn't know what caused it.

Please CC the patch to the libstdc++ list (I'm not subscribed to gcc-patches).

N.B. this reverts https://gcc.gnu.org/r215726 so we should look back at why
that change was made.

[Bug tree-optimization/66573] Unexpected change in static, branch-prediction cost from O1 to O2 in if-then-else.

[jvg1981 at aim dot com]

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

jvg1981 at aim dot com changed:

   What|Removed |Added

 CC||jvg1981 at aim dot com

--- Comment #5 from jvg1981 at aim dot com ---
I recently came across this surprising behavior.  Has anyone taken a serious
look at it?  Is it likely to be corrected/changed?

[Bug plugins/68452] New: C front end doesn't call PLUGIN_FINISH_DECL on CONST_DECLs

[tromey at gcc dot gnu.org]

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

Bug ID: 68452
   Summary: C front end doesn't call PLUGIN_FINISH_DECL on
CONST_DECLs
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: plugins
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tromey at gcc dot gnu.org
  Target Milestone: ---

While working on a plugin I noticed that PLUGIN_FINISH_DECL doesn't
seem to be called for a CONST_DECL.

I think this could be fixed by adding the appropriate plugin call
near the end of c-decl.c:build_enumerator.

[Bug c++/68451] New: internal compiler error: Segmentation fault when using decltype with friend inside a class template

[tim.pavlic at minelab dot com.au]

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

Bug ID: 68451
   Summary: internal compiler error: Segmentation fault when using
decltype with friend inside a class template
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tim.pavlic at minelab dot com.au
  Target Milestone: ---

Source to reproduce:



struct A {};

struct B
{
A a;
friend decltype(a); // This works, B is not a class template
};

template 
struct C
{
A a;
// This friend declaration gives an ICE.
// Seemingly because C is a class template
friend decltype(a); 
};

int main()
{
B b;
C c;   // This causes the ICE
}



I have the above source in a single file, ice.cpp, and compile with: g++
-std=c++14 ice.cpp

Looks like using decltype in conjunction with friend has problems when you are
in a class template.

It also crashes on GCC 5 (not sure of minor number).
-std=c++11 has the same issue.

[Bug rtl-optimization/68435] [6 Regression] Missed if-conversion optimization

[ysrumyan at gmail dot com]

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

--- Comment #4 from Yuri Rumyantsev  ---
Created attachment 36774
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36774=edit
tar file

tar file contains good and bad ce1-rtl dumps showing the problem