[Bug fortran/57538] New: SAVE attribute needed for derived type with default initialization?

[valeryweber at hotmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57538

Bug ID: 57538
   Summary: SAVE attribute needed for derived type with default
initialization?
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: valeryweber at hotmail dot com

Dear,
I would like to ask you if the following code is f2008ts valid.
So does the declaration of the table(...) need the SAVE?
Thanks
Valery

MODULE periodic_table
  IMPLICIT NONE
  TYPE, PUBLIC :: atom_type
 INTEGER   :: number = 0
  END TYPE atom_type
  INTEGER, PARAMETER, PRIVATE :: n_elements = 118
  TYPE( atom_type ), PUBLIC :: table( 0:n_elements )
END MODULE periodic_table

[Bug fortran/57538] SAVE attribute needed for derived type with default initialization?

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57538

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #1 from Tobias Burnus  ---
(In reply to Valery Weber from comment #0)
> I would like to ask you if the following code is f2008ts valid.

Please use the mailing list or - for general Fortran questions - also the
comp.lang.fortran newsgroup instead of the bugtracker.

> So does the declaration of the table(...) need the SAVE?

Since Fortran 2008, module variables are have automatically the SAVE attribute.
Effectively, the same happened before Fortran 2008. Thus, you do not need the
SAVE attribute.

"A variable, common block, or procedure pointer declared in the scoping unit of
a main program, module, or submodule implicitly has the SAVE attribute, which
may be conformed by explicit specification." (F2008, 5.3.16 SAVE attribute).

Note: The default initialization never causes that a variable gets the SAVE
attribute.

[Bug c++/53812] lower_stmt (4.6), verify_gimple_stmt (4.7.0, 4.7.1)

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53812

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #5 from Paolo Carlini  ---
Fixed for 4.8.0.

[Bug rtl-optimization/57447] [4.9 Regression] ICE on 435.gromacs from spec2006 after r199298

[dcb314 at hotmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57447

--- Comment #1 from David Binderman  ---
I see this problem also. 

Additional test case available on request.

[Bug regression/53964] regression: sparc64 FreeBSD: /usr/ports/lang/gcc46/work/build/./prev-gcc/include/stddef.h:150:26: error: two or more data types n declaration specifiers

[mexas at bristol dot ac.uk]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53964

--- Comment #8 from Anton Shterenlikht  ---
With this patch to binutils:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gas/config/tc-sparc.h.diff?cvsroot=src&r1=1.31&r2=1.32

I can build gcc-4.6.4,1 successfully.
I can now build lapack with gcc-4.6

Thanks to Michael Moll 
for the hint

[Bug c/57539] New: ice in ipa_edge_duplication_hook

[dcb314 at hotmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57539

Bug ID: 57539
   Summary: ice in ipa_edge_duplication_hook
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com

Created attachment 30265
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30265&action=edit
C source code

The attached source code causes the following crash
on gcc-4.9 trunk dated 20130605 on an AMD x86_64 box
when compiled with -O3.

constraint.c:1011:1: internal compiler error: in ipa_edge_duplication_hook, at
ipa-prop.c:2836
0x7cba11 ipa_edge_duplication_hook
../../src/trunk/gcc/ipa-prop.c:2836
0x624f2b cgraph_call_edge_duplication_hooks(cgraph_edge*, cgraph_edge*)
../../src/trunk/gcc/cgraph.c:438
0x62f831 cgraph_clone_edge(cgraph_edge*, cgraph_node*, gimple_statement_d*,
unsigned int, long, int, bool)
../../src/trunk/gcc/cgraphclones.c:156
0x62fcbc cgraph_clone_node(cgraph_node*, tree_node*, long, int, bool,
vec, bool)
../../src/trunk/gcc/cgraphclones.c:229
0xd73655 clone_inlined_nodes(cgraph_edge*, bool, bool, int*)
../../src/trunk/gcc/ipa-inline-transform.c:171
0xd736a8 clone_inlined_nodes(cgraph_edge*, bool, bool, int*)
../../src/trunk/gcc/ipa-inline-transform.c:186
0xd73974 inline_call(cgraph_edge*, bool, vec*,
int*, bool)
../../src/trunk/gcc/ipa-inline-transform.c:248
0xd72169 inline_small_functions
../../src/trunk/gcc/ipa-inline.c:1615
0xd72169 ipa_inline
../../src/trunk/gcc/ipa-inline.c:1796
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/30604] Unable to coalesce ssa_names and which are marked as MUST COALESCE

[dcb314 at hotmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30604

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #15 from David Binderman  ---
I've got a testcase from gcc trunk dated 20130605 that
can generate the same "Unable to coalesce" message.

Testcase available on request.

[Bug rtl-optimization/57540] New: stack pointer related loop invariants after reload

[amker.cheng at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57540

Bug ID: 57540
   Summary: stack pointer related loop invariants after reload
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amker.cheng at gmail dot com

For below program,

void foo ( unsigned char *len,
 int alphaSize,
 int maxLen )
{
   int i, j, k;
   unsigned char tooLong;

   int parent [ 258 * 2 ];


  parent[0] = -2;

  tooLong = 0;
  for (i = 1; i <= alphaSize; i++)
  {
 j = 0;
 k = i;
 while (parent[k] >= 0)
 {
 k = parent[k];
 j++;
 }
 len[i-1] = j;
 if (j > maxLen)
 tooLong = 1;
  }
}

Compile with command line,
arm-linux-gnueabihf-gcc -S -O2 -marm -mcpu=cortex-a15 -o foo.S -xc foo.E

The generated code is like,
.cpu cortex-a15
.eabi_attribute 27, 3
.eabi_attribute 28, 1
.fpu vfpv3-d16
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 2
.eabi_attribute 30, 2
.eabi_attribute 34, 1
.eabi_attribute 18, 4
.file"foo.E"
.text
.align2
.globalfoo
.typefoo, %function
foo:
@ args = 0, pretend = 0, frame = 2064
@ frame_needed = 0, uses_anonymous_args = 0
strlr, [sp, #-4]!
subsp, sp, #2064
mvnr3, #1
subsp, sp, #4
cmpr1, #0
strr3, [sp]
ble.L1
movip, sp
addr1, r0, r1
.L6:
ldrr3, [ip, #4]!
movr2, #0
cmpr3, #0
blt.L3
.L5:
addlr, sp, #2064loop invariant
addr2, r2, #1
addr3, lr, r3, asl #2
ldrr3, [r3, #-2064]
cmpr3, #0
bge.L5
uxtbr2, r2
.L3:
strbr2, [r0], #1
cmpr0, r1
bne.L6
.L1:
addsp, sp, #2064
addsp, sp, #4
@ sp needed
ldrpc, [sp], #4
.sizefoo, .-foo
.ident"GCC: (GNU) 4.9.0 20130524 (experimental)"
.section.note.GNU-stack,"",%progbits


Apparently, first instruction in basic block .L5 is invariant, but kept in loop
because it is generated by reload.

I think this is a common issue.

[Bug tree-optimization/30604] Unable to coalesce ssa_names and which are marked as MUST COALESCE

[rguenther at suse dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30604

--- Comment #16 from rguenther at suse dot de  ---
On Thu, 6 Jun 2013, dcb314 at hotmail dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30604
> 
> David Binderman  changed:
> 
>What|Removed |Added
> 
>  CC||dcb314 at hotmail dot com
> 
> --- Comment #15 from David Binderman  ---
> I've got a testcase from gcc trunk dated 20130605 that
> can generate the same "Unable to coalesce" message.
> 
> Testcase available on request.

Can you open a new bugreport please?  It's very likely a different
reason than this one.

[Bug middle-end/57541] New: [Cilkplus]: internal compiler error: in gimplify_expr, at gimplify.c:7809

[anna.m.tikhonova at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57541

Bug ID: 57541
   Summary: [Cilkplus]: internal compiler error: in gimplify_expr,
at gimplify.c:7809
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anna.m.tikhonova at gmail dot com

Created attachment 30266
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30266&action=edit
Reproducer

Hi,
Attached test case fails with ICE:

$ gcc -fcilkplus 1.c
1.c: In function 'main':
1.c:4:18: error: 'N' undeclared (first use in this function)
   char c = (char)N;
  ^
1.c:4:18: note: each undeclared identifier is reported only once for each
function it appears in
1.c:7:3: internal compiler error: in gimplify_expr, at gimplify.c:7809
   A[l:s:c];
   ^
0x78dacf gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
/home/anna/trunk/gcc/gimplify.c:7809
0x78f5f6 gimplify_stmt(tree_node**, gimple_statement_d**)
/home/anna/trunk/gcc/gimplify.c:5692
0x78b8bb gimplify_statement_list
/home/anna/trunk/gcc/gimplify.c:1521
0x78b8bb gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
/home/anna/trunk/gcc/gimplify.c:7549
0x78f5f6 gimplify_stmt(tree_node**, gimple_statement_d**)
/home/anna/trunk/gcc/gimplify.c:5692
0x790c81 gimplify_body(tree_node*, bool)
/home/anna/trunk/gcc/gimplify.c:8193
0x791136 gimplify_function_tree(tree_node*)
/home/anna/trunk/gcc/gimplify.c:8325
0x6282ef analyze_function
/home/anna/trunk/gcc/cgraphunit.c:629
0x62b2e4 analyze_functions
/home/anna/trunk/gcc/cgraphunit.c:913
0x62c795 finalize_compilation_unit()
/home/anna/trunk/gcc/cgraphunit.c:2097
0x509ee3 c_write_global_declarations()
/home/anna/trunk/gcc/c/c-decl.c:10118
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug middle-end/57541] [Cilkplus]: internal compiler error: in gimplify_expr, at gimplify.c:7809

[anna.m.tikhonova at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57541

--- Comment #1 from Anna  ---
Same test, another ICE.

$ gcc -fcilkplus 1.c -DN=10
1.c: In function 'main':
1.c:4:8: internal compiler error: in gimplify_var_or_parm_decl, at
gimplify.c:2042
   char c = (char)N;
^
0x78a33b gimplify_var_or_parm_decl
/home/anna/trunk/gcc/gimplify.c:2042
0x78c00b gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
/home/anna/trunk/gcc/gimplify.c:7565
0x797643 gimplify_modify_expr
/home/anna/trunk/gcc/gimplify.c:4851
0x78bfd3 gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
/home/anna/trunk/gcc/gimplify.c:7160
0x78f5f6 gimplify_stmt(tree_node**, gimple_statement_d**)
/home/anna/trunk/gcc/gimplify.c:5692
0x78d5cd gimplify_and_add
/home/anna/trunk/gcc/gimplify.c:327
0x78d5cd gimplify_decl_expr
/home/anna/trunk/gcc/gimplify.c:1468
0x78d5cd gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
/home/anna/trunk/gcc/gimplify.c:7327
0x78f5f6 gimplify_stmt(tree_node**, gimple_statement_d**)
/home/anna/trunk/gcc/gimplify.c:5692
0x78b8bb gimplify_statement_list
/home/anna/trunk/gcc/gimplify.c:1521
0x78b8bb gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
/home/anna/trunk/gcc/gimplify.c:7549
0x78f5f6 gimplify_stmt(tree_node**, gimple_statement_d**)
/home/anna/trunk/gcc/gimplify.c:5692
0x790c81 gimplify_body(tree_node*, bool)
/home/anna/trunk/gcc/gimplify.c:8193
0x791136 gimplify_function_tree(tree_node*)
/home/anna/trunk/gcc/gimplify.c:8325
0x6282ef analyze_function
/home/anna/trunk/gcc/cgraphunit.c:629
0x62b2e4 analyze_functions
/home/anna/trunk/gcc/cgraphunit.c:913
0x62c795 finalize_compilation_unit()
/home/anna/trunk/gcc/cgraphunit.c:2097
0x509ee3 c_write_global_declarations()
/home/anna/trunk/gcc/c/c-decl.c:10118
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug middle-end/57541] [Cilkplus]: internal compiler error: in gimplify_expr, at gimplify.c:7809

[anna.m.tikhonova at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57541

--- Comment #2 from Anna  ---
Comment out line "long l = (long)N;" and here's another ICE.

$ gcc -fcilkplus 1.c
1.c: In function 'main':
1.c:4:18: error: 'N' undeclared (first use in this function)
   char c = (char)N;
  ^
1.c:4:18: note: each undeclared identifier is reported only once for each
function it appears in
1.c:7:5: error: 'l' undeclared (first use in this function)
   A[l:s:c];
 ^
1.c:7:6: error: expected array notation expression before ':' token
   A[l:s:c];
  ^
1.c:7:6: internal compiler error: Segmentation fault
0x8fee9f crash_signal
/home/anna/trunk/gcc/toplev.c:333
0x54b5aa contains_struct_check
/home/anna/trunk/gcc/tree.h:3803
0x54b5aa build_array_notation_ref(unsigned int, tree_node*, tree_node*,
tree_node*, tree_node*, tree_node*)
/home/anna/trunk/gcc/c/c-array-notation.c:2809
0x53c5ce c_parser_array_notation
/home/anna/trunk/gcc/c/c-parser.c:11165
0x53dad6 c_parser_postfix_expression_after_primary
/home/anna/trunk/gcc/c/c-parser.c:6978
0x534e70 c_parser_postfix_expression
/home/anna/trunk/gcc/c/c-parser.c:6850
0x53681a c_parser_unary_expression
/home/anna/trunk/gcc/c/c-parser.c:6042
0x53ac86 c_parser_cast_expression
/home/anna/trunk/gcc/c/c-parser.c:5880
0x53aeae c_parser_binary_expression
/home/anna/trunk/gcc/c/c-parser.c:5691
0x53b7c7 c_parser_conditional_expression
/home/anna/trunk/gcc/c/c-parser.c:5486
0x53bdd0 c_parser_expr_no_commas
/home/anna/trunk/gcc/c/c-parser.c:5405
0x53c2dd c_parser_expression
/home/anna/trunk/gcc/c/c-parser.c:7139
0x53cd44 c_parser_expression_conv
/home/anna/trunk/gcc/c/c-parser.c:7170
0x545b46 c_parser_statement_after_labels
/home/anna/trunk/gcc/c/c-parser.c:4599
0x543067 c_parser_compound_statement_nostart
/home/anna/trunk/gcc/c/c-parser.c:4261
0x54387b c_parser_compound_statement
/home/anna/trunk/gcc/c/c-parser.c:4094
0x5447aa c_parser_declaration_or_fndef
/home/anna/trunk/gcc/c/c-parser.c:1758
0x54958b c_parser_external_declaration
/home/anna/trunk/gcc/c/c-parser.c:1363
0x549ff6 c_parser_translation_unit
/home/anna/trunk/gcc/c/c-parser.c:1251
0x549ff6 c_parse_file()
/home/anna/trunk/gcc/c/c-parser.c:11000
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Compiler used is:
Target: x86_64-unknown-linux-gnu
Configured with: /home/anna/trunk/configure --with-arch=corei7
--with-cpu=corei7 --enable-clocale=gnu --with-system-zlib --enable-shared
--with-demangler-in-ld --enable-cloog-backend=isl --with-fpmath=sse
--enable-languages=c,c++,fortran,java,lto
Thread model: posix
gcc version 4.9.0 20130605 (experimental) (GCC)

[Bug tree-optimization/57539] [4.9 Regression] ice in ipa_edge_duplication_hook

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57539

Richard Biener  changed:

   What|Removed |Added

 CC||mjambor at suse dot cz
  Component|c   |tree-optimization
   Target Milestone|--- |4.9.0
Summary|ice in  |[4.9 Regression] ice in
   |ipa_edge_duplication_hook   |ipa_edge_duplication_hook

[Bug tree-optimization/57537] [4.8/4.9 Regression] gcc.dg/vect/slp-widen-mult-half.c generating wrong code on PowerPC64

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57537

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |4.8.2
Summary|[4.8/4.9]   |[4.8/4.9 Regression]
   |gcc.dg/vect/slp-widen-mult- |gcc.dg/vect/slp-widen-mult-
   |half.c generating wrong |half.c generating wrong
   |code on PowerPC64   |code on PowerPC64

[Bug tree-optimization/57539] [4.9 Regression] ice in ipa_edge_duplication_hook

[jamborm at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57539

Martin Jambor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-06-06
 CC|mjambor at suse dot cz |jamborm at gcc dot 
gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jamborm at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Jambor  ---
Confirmed, mine.

[Bug fortran/57542] New: [OOP, Fortran] ICE on FINALization with specific options

[sfilippone at uniroma2 dot it]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57542

Bug ID: 57542
   Summary: [OOP, Fortran] ICE on FINALization with specific
options
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sfilippone at uniroma2 dot it

Created attachment 30267
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30267&action=edit
Test case

The attached code triggers an ICE with debug options  -O0 -ggdb -fcheck=all  

  log ---
[sfilippo@jacobi BugDeallocateFinal]$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/gnu49/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/usr/local/gnu49
--enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp
--with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc
--with-cloog=/home/travel/GNUBUILD/cloog : (reconfigured) ../gcc/configure
--prefix=/usr/local/gnu49 --enable-languages=c,c++,fortran
--with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr
--with-mpc=/home/travel/GNUBUILD/mpc --with-cloog=/home/travel/GNUBUILD/cloog :
(reconfigured) ../gcc/configure --prefix=/usr/local/gnu49
--enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp
--with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc
--with-cloog=/home/travel/GNUBUILD/cloog : (reconfigured) ../gcc/configure
--prefix=/usr/local/gnu49 --enable-languages=c,c++,fortran
--with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr
--with-mpc=/home/travel/GNUBUILD/mpc --with-cloog=/home/travel/GNUBUILD/cloog
Thread model: posix
gcc version 4.9.0 20130605 (experimental) (GCC) 

[sfilippo@jacobi BugDeallocateFinal]$ gfortran -c -O3  testFinal.f90 

[sfilippo@jacobi BugDeallocateFinal]$ gfortran -c -O0 -ggdb -fcheck=all 
testFinal.f90 
testFinal.f90: In function 'testfinal':
testFinal.f90:24:0: internal compiler error: in gfc_build_final_call, at
fortran/trans.c:898
   deallocate(var%v(1)%item%item)
 ^
0x5b97d1 gfc_build_final_call
../../gcc/gcc/fortran/trans.c:898
0x5b97d1 gfc_add_finalizer_call(stmtblock_t*, gfc_expr*)
../../gcc/gcc/fortran/trans.c:1014
0x5b9aee gfc_deallocate_scalar_with_status(tree_node*, tree_node*, bool,
gfc_expr*, gfc_typespec)
../../gcc/gcc/fortran/trans.c:1298
0x61c174 gfc_trans_deallocate(gfc_code*)
../../gcc/gcc/fortran/trans-stmt.c:5429
0x5b8a47 trans_code
../../gcc/gcc/fortran/trans.c:1683
0x5e0cce gfc_generate_function_code(gfc_namespace*)
../../gcc/gcc/fortran/trans-decl.c:5460
0x5788f8 translate_all_program_units
../../gcc/gcc/fortran/parse.c:4509
0x5788f8 gfc_parse_file()
../../gcc/gcc/fortran/parse.c:4706
0x5b47f5 gfc_be_parse_file
../../gcc/gcc/fortran/f95-lang.c:189
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
[sfilippo@jacobi BugDeallocateFinal]$

[Bug c++/57543] New: decltype needs eplicity 'this' pointer in member function declaration of template class with trailing return type

[mitchnull+gcc at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57543

Bug ID: 57543
   Summary: decltype needs eplicity 'this' pointer in member
function declaration of template class with trailing
return type
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mitchnull+gcc at gmail dot com

Created attachment 30268
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30268&action=edit
decltype-implicit-this.cpp

When using trailing return-type for member functions of a template class, the
'this' pointer must be explicitly mentioned. This should not be necessary (The
implicit 'this' works with a non-template class).

Example:

emplate 
struct DecltypeConstThis {

T f() const { return T{}; }

auto g() -> decltype(this->f()) { return this->f(); }
auto h() const  ->  decltype(f()) { return f(); } // this should work the
same as g() above (with implicit 'this')

};

struct Working {
int f() const { return 0; }
auto h() const -> decltype(f()) { return 0; }
};


int main() {

Working w;
w.h();

DecltypeConstThis d;
d.g();
d.h();

return 0;
}

compiler output:

[mitch@deneb src]$ g++ -std=c++11 -o decltype-implicit-this
decltype-implicit-this.cpp 
decltype-implicit-this.cpp: In instantiation of ‘struct
DecltypeConstThis’:
decltype-implicit-this.cpp:22:28:   required from here
decltype-implicit-this.cpp:7:36: error: cannot call member function ‘T
DecltypeConstThis::f() const [with T = int]’ without object
 auto h() const  ->  decltype(f()) { return f(); } // this should work the
same as g() above (with implicit 'this')
^
decltype-implicit-this.cpp: In function ‘int main()’:
decltype-implicit-this.cpp:24:7: error: ‘struct DecltypeConstThis’ has no
member named ‘h’
 d.h();
   ^

ps: possibly related to bug #54359

[Bug fortran/54370] [4.7 Regression] error: non-trivial conversion in unary operation

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54370

Tobias Burnus  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code, patch
 CC||burnus at gcc dot gnu.org
   Target Milestone|--- |4.7.4
Summary|error: non-trivial  |[4.7 Regression] error:
   |conversion in unary |non-trivial conversion in
   |operation   |unary operation

--- Comment #4 from Tobias Burnus  ---
The bug was solved in August 2012 on the GCC 4.8 trunk; however, as it is a
regression, it should have been backported to the GCC 4.7 branch.

[Bug c/57544] New: /../libcommon/stdio.h:121:12: error: expected declaration specifiers or ... before numeric constant

[michael.prujan at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57544

Bug ID: 57544
   Summary: /../libcommon/stdio.h:121:12: error: expected
declaration specifiers or ... before numeric constant
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: michael.prujan at gmail dot com

During compilation c code via gcc 4.7.2 under Ubuntu i get following error:
/../libcommon/stdio.h:121:12: error: expected declaration specifiers or ...
before numeric constant

Thanks,
Michael.

[Bug other/56442] Could not identify that register is clobbered already

[gjl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56442

Georg-Johann Lay  changed:

   What|Removed |Added

 CC||eric.weddington at atmel dot 
com
   Target Milestone|--- |4.7.4

[Bug c/57544] /../libcommon/stdio.h:121:12: error: expected declaration specifiers or ... before numeric constant

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

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57544

Andreas Schwab  changed:

   What|Removed |Added

   Severity|blocker |normal

[Bug fortran/57542] [4.9 Regression][OOP] ICE on FINALization with specific options

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57542

Tobias Burnus  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 CC||burnus at gcc dot gnu.org
   Target Milestone|--- |4.9.0
Summary|[OOP, Fortran] ICE on   |[4.9 Regression][OOP] ICE
   |FINALization with specific  |on FINALization with
   |options |specific options

[Bug c/57544] /../libcommon/stdio.h:121:12: error: expected declaration specifiers or ... before numeric constant

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57544

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2013-06-06
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
You didn't read http://gcc.gnu.org/bugs/

[Bug fortran/57542] [4.9 Regression][OOP] ICE on FINALization with specific options

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57542

--- Comment #1 from Tobias Burnus  ---
Author: burnus
Date: Thu Jun  6 14:36:41 2013
New Revision: 199736

URL: http://gcc.gnu.org/viewcvs?rev=199736&root=gcc&view=rev
Log:
2013-06-06  Tobias Burnus  

PR fortran/57542
* trans.c (gfc_build_final_call): Add se.pre to the block
and modify the assert.

2013-06-06  Tobias Burnus  

PR fortran/57542
* gfortran.dg/finalize_16.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/finalize_16.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/57542] [4.9 Regression][OOP] ICE on FINALization with specific options

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57542

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #2 from Tobias Burnus  ---
FIXED.

Thanks for the report!

[Bug rtl-optimization/57459] [4.8/4.9 Regression] LRA inheritance bug

[mikpe at it dot uu.se]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57459

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpe at it dot uu.se

--- Comment #5 from Mikael Pettersson  ---
r192718 was OK, started with r192719, the LRA merge and activation on x86.

[Bug fortran/57530] [OOP] Wrongly rejects type_pointer => class_target (which have identical declared type)

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57530

--- Comment #4 from Tobias Burnus  ---
(In reply to Tobias Burnus from comment #3)
The resolve patch has been approved (but not yet committed):
  http://gcc.gnu.org/ml/fortran/2013-06/msg00049.html

The trans*.c patch has still to be fixed and submitted. (Cf. comment 3)

[Bug rtl-optimization/57468] [4.9 Regression] 26% performance drop on important benchmark after r199298.

[vmakarov at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57468

Vladimir Makarov  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #2 from Vladimir Makarov  ---
Thanks for reporting this.  I guess the secondary reload is generated when one
pseudo is spilled.  I'll be working on this.

[Bug rtl-optimization/55342] [4.8/4.9 Regression] [LRA,x86] Non-optimal code for simple loop with LRA

[vmakarov at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55342

Vladimir Makarov  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #7 from Vladimir Makarov  ---
(In reply to Yuri Rumyantsev from comment #2)
> The patching compiler produces better binaries but we still have -6%
> performance degradation on corei7. The main cause of it it that LRA compiler
> generates spill of 'pure' byte 'g' whereas old compiler generates spill for
> 'm' that is negation of 'g':
> 
> gcc wwithout LRA (assembly part the head of loop)
> 
> .L7:
>   movzbl  1(%edi), %edx
>   leal3(%edi), %ebp
>   movzbl  (%edi), %ebx
>   movl%ebp, %edi
>   notl%edx   // perform negation on register
>   movb%dl, 3(%esp)
> 
> gcc with LRA
> 
> .L7:
>   movzbl  (%edi), %ebx
>   leal3(%edi), %ebp
>   movzbl  1(%edi), %ecx
>   movl%ebp, %edi
>   movzbl  -1(%ebp), %edx
>   notl%ebx
>   notl%ecx
>   movb%dl, (%esp)
>   cmpb%cl, %bl
>   notb(%esp) // perform nagation in memory
> 
> i.e. wwe have redundant load and store form/to stack.
> 
> I assume that this should be fixed also.

Fixing problem with notl needs implementing a new functionality in LRA: making
reloads which stays if the reload pseudo got a hard registers and was inherited
(in this case it is profitable).  Otherwise the current code should be
generated (the reloads and reload pseudos should be removed, the old code
should be restored).  I've started work on this but it will not be fixed
quickly as implementing the new functionality is not trivial task.

[Bug rtl-optimization/57447] [4.9 Regression] ICE on 435.gromacs from spec2006 after r199298

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57447

--- Comment #2 from H.J. Lu  ---
(In reply to David Binderman from comment #1)
> I see this problem also. 
> 
> Additional test case available on request.

Please upload a testcase here.  Thanks.

[Bug c++/57545] New: Generation of debug symbols leads to internal compiler error

[g...@severin-strobl.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57545

Bug ID: 57545
   Summary: Generation of debug symbols leads to internal compiler
error
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: g...@severin-strobl.de

Created attachment 30269
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30269&action=edit
test case leading to internal compiler error

Enabling the generation of debug symbols leads to an internal compiler error
(segmentation fault). A preprocessed minimal example is attached. The problem
is reproducible in g++ versions 4.7.2, 4.7.3, 4.8.0 and 4.8.1. Version 4.7.1 is
the last version where I did not encounter any problems.

// code
template
struct array {
T data[N];
};

template
struct derived {
typedef long unsigned int size_type;
static const size_type n = 42;

array a;
};

// compile
$ g++ -g -Wall -Wextra -save-temps test-case.cpp
test-case.cpp:12:2: internal compiler error: Segmentation fault
 };
  ^
0x89f8ff crash_signal
../../gcc-4.8.1/gcc/toplev.c:332
0x897567 bit_from_pos(tree_node*, tree_node*)
../../gcc-4.8.1/gcc/stor-layout.c:799
0x6ad653 field_byte_offset
../../gcc-4.8.1/gcc/dwarf2out.c:14351
0x6b72e9 add_data_member_location_attribute
../../gcc-4.8.1/gcc/dwarf2out.c:14577
0x6c3c89 gen_field_die
../../gcc-4.8.1/gcc/dwarf2out.c:18697
0x6bfa4f gen_decl_die
../../gcc-4.8.1/gcc/dwarf2out.c:20072
0x6c0d37 gen_member_die
../../gcc-4.8.1/gcc/dwarf2out.c:19031
0x6c0d37 gen_struct_or_union_type_die
../../gcc-4.8.1/gcc/dwarf2out.c:19117
0x6c0d37 gen_tagged_type_die
../../gcc-4.8.1/gcc/dwarf2out.c:19307
0x6c1a2e gen_type_die_with_usage
../../gcc-4.8.1/gcc/dwarf2out.c:19454
0x6c2142 gen_type_die
../../gcc-4.8.1/gcc/dwarf2out.c:19493
0x6c2142 modified_type_die
../../gcc-4.8.1/gcc/dwarf2out.c:10163
0x6c2f70 force_type_die
../../gcc-4.8.1/gcc/dwarf2out.c:19789
0x6c37f9 get_context_die
../../gcc-4.8.1/gcc/dwarf2out.c:19704
0x6c37f9 scope_die_for
../../gcc-4.8.1/gcc/dwarf2out.c:16419
0x6c15d9 gen_type_die_with_usage
../../gcc-4.8.1/gcc/dwarf2out.c:19349
0x6c2ebe gen_type_die
../../gcc-4.8.1/gcc/dwarf2out.c:19493
0x6c2ebe modified_type_die
../../gcc-4.8.1/gcc/dwarf2out.c:10095
0x6c3a2b add_type_attribute
../../gcc-4.8.1/gcc/dwarf2out.c:16497
0x6bad18 generic_parameter_die
../../gcc-4.8.1/gcc/dwarf2out.c:10356

$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/apps/gcc/gcc-4.8.1/libexec/gcc/x86_64-pc-linux-gnu/4.8.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-4.8.1/configure --prefix=/apps/gcc/gcc-4.8.1
--build=x86_64-pc-linux-gnu --enable-bootstrap --enable-checking=release
--enable-__cxa_atexit --enable-languages=c,c++,fortran --enable-libgomp
--enable-libmudflap --enable-lto --enable-multilib --enable-nls --enable-shared
--enable-threads=posix --with-system-zlib --enable-cloog-backend=isl
--with-cloog=/home/hpc/severin/apps/cloog/cloog-0.18.0
--with-cloog-include=/home/hpc/severin/apps/cloog/cloog-0.18.0/include/
--with-ppl=/home/hpc/severin/apps/ppl/ppl-1.0
Thread model: posix
gcc version 4.8.1 (GCC)

[Bug rtl-optimization/57447] [4.9 Regression] ICE on 435.gromacs from spec2006 after r199298

[dcb314 at hotmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57447

--- Comment #3 from David Binderman  ---
Created attachment 30270
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30270&action=edit
C++ source code

The attached source code causes the following crash
on gcc-4.9 trunk dated 20130605 on an AMD x86_64 box
when compiled with -O2.

paging.cpp: In function 'void PAGING_Enable(bool)':
paging.cpp:867:1: internal compiler error: in curr_insn_transform, at
lra-constraints.c:3007
 }
 ^
0x9c287d curr_insn_transform
../../src/trunk/gcc/lra-constraints.c:3006
0x9c34fc lra_constraints(bool)
../../src/trunk/gcc/lra-constraints.c:3785
0x9b5b94 lra(_IO_FILE*)
../../src/trunk/gcc/lra.c:2278
0x97b418 do_reload
../../src/trunk/gcc/ira.c:4641
0x97b418 rest_of_handle_reload
../../src/trunk/gcc/ira.c:4753
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/54370] [4.7 Regression] error: non-trivial conversion in unary operation

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54370

--- Comment #5 from Tobias Burnus  ---
Author: burnus
Date: Thu Jun  6 16:45:04 2013
New Revision: 199746

URL: http://gcc.gnu.org/viewcvs?rev=199746&root=gcc&view=rev
Log:
2013-06-06  Tobias Burnus  

Backport from mainline
2012-08-27  Tobias Burnus  

PR fortran/54370
* trans-stmt.c (gfc_trans_do_while): Don't change the logical
kind for negation of the condition.

2013-06-06  Tobias Burnus  

Backport from mainline
2012-08-27  Tobias Burnus  

PR fortran/54370
* gfortran.dg/do_5.f90: New.


Added:
branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/do_5.f90
Modified:
branches/gcc-4_7-branch/gcc/fortran/ChangeLog
branches/gcc-4_7-branch/gcc/fortran/trans-stmt.c
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog

[Bug fortran/54370] [4.7/4.8 Regression] error: non-trivial conversion in unary operation

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54370

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||4.6.3
 Resolution|--- |FIXED
Summary|[4.7 Regression] error: |[4.7/4.8 Regression] error:
   |non-trivial conversion in   |non-trivial conversion in
   |unary operation |unary operation

--- Comment #6 from Tobias Burnus  ---
FIXED on the GCC 4.8 trunk (and hence also working on GCC 4.9).
And belated FIXED on the 4.7 branch.

Thanks for the report!

[Bug c++/57546] New: templated gnu multiversion function pointer returns wrong value

[mib.bugzilla at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57546

Bug ID: 57546
   Summary: templated gnu multiversion function pointer returns
wrong value
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mib.bugzilla at gmail dot com

/rdrive/ref/gcc/bin/g++48  fum.cpp -std=c++0x
-bash-4.1$ ./a.out
FAILED i:0 j:0x80499c6
-bash-4.1$ cat fum.cpp
template 
class Foo
{
public:
  /* Default version of foo.  */
  __attribute__ ((target("default")))
  T foo () { return 0; }

  /* corei7 version of foo.  */
  __attribute__ ((target("arch=corei7")))
  T foo () { return 0; }

  T (Foo::*p)() = &Foo::foo;   // pointer to member
};
#include 
int main ()
{
  Foo f;
  int i = f.foo();
  int j = (f.*(f.p))();   // pointer to member call
  if (i==j && j==0) {
printf("PASSED\n");
return 0;
  } else {
printf("FAILED i:%d j:0x%x\n", i, j);
return -1;
  }
}
-bash-4.1$  /rdrive/ref/gcc/bin/g++48 -v
Using built-in specs.
COLLECT_GCC=/rdrive/ref/gcc/4.8.1/rhel60/x86/bin/g++
COLLECT_LTO_WRAPPER=/site/spt/rdrive/ref/gcc/4.8.1/rhel60/x86/bin/../libexec/gcc/i686-pc-linux-gnu/4.8.1/lto-wrapper
Target: i686-pc-linux-gnu
Configured with:
/rusers/sys_cron/grab_gcc/downloads_rel/4.8.1/gcc-4.8.1/configure
--prefix=/rdrive/ref/gcc/4.8.1/rhel60/x86 --enable-languages=c,c++,objc,fortran
--disable-multilib --target=i686-pc-linux-gnu --disable-bootstrap
--enable-decimal-float
--with-gmp=/rusers/sys_cron/grab_gcc/downloads_rel/lib/x86
--with-mpfr=/rusers/sys_cron/grab_gcc/downloads_rel/lib/x86
--with-mpc=/rusers/sys_cron/grab_gcc/downloads_rel/lib/x86
Thread model: posix
gcc version 4.8.1 (GCC)

[Bug c++/57545] [4.7/4.8/4.9 Regression] Generation of debug symbols leads to internal compiler error

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57545

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-06-06
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |4.7.4
Summary|Generation of debug symbols |[4.7/4.8/4.9 Regression]
   |leads to internal compiler  |Generation of debug symbols
   |error   |leads to internal compiler
   ||error
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r187106 (which has been backported to 4.7 branch with r188812 aka
PR52637).

[Bug web/57547] New: Missing vector intrinsics in PowerPC Altivec documentation

[wainersm at linux dot vnet.ibm.com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57547

Bug ID: 57547
   Summary: Missing vector intrinsics in PowerPC Altivec
documentation
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wainersm at linux dot vnet.ibm.com

It is missing following vector intrinsics in the PowerPC Altivec documentation:
vec_extract
vec_insert
vec_promote
vec_recipdiv

The PowerPC Altivec online documentation
http://gcc.gnu.org/onlinedocs/gcc-4.8.1/gcc/PowerPC-AltiVec_002fVSX-Built_002din-Functions.html#PowerPC-AltiVec_002fVSX-Built_002din-Functions

[Bug target/57547] Missing vector intrinsics in PowerPC Altivec documentation

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57547

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||documentation
  Component|web |target

--- Comment #1 from Andrew Pinski  ---
I think the vec_extract/vec_insert/vec_promote are my fault as I added them for
Cell.

[Bug c++/57548] New: calling gnu multiversioned function at file scope causes ICE

[mib.bugzilla at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57548

Bug ID: 57548
   Summary: calling gnu multiversioned function at file scope
causes ICE
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mib.bugzilla at gmail dot com

/rdrive/ref/gcc/bin/g++48 -c mv1.cpp
mv1.cpp:28:13: internal compiler error: Segmentation fault
 int j = fum();
 ^
0x84eaa07 crash_signal
   
/rusers/sys_cron/grab_gcc/downloads_rel/4.8.1/gcc-4.8.1/gcc/toplev.c:332
0x868bd44 ix86_can_inline_p
   
/rusers/sys_cron/grab_gcc/downloads_rel/4.8.1/gcc-4.8.1/gcc/config/i386/i386.c:4498
0x8102760 build_over_call
   
/rusers/sys_cron/grab_gcc/downloads_rel/4.8.1/gcc-4.8.1/gcc/cp/call.c:7044
0x8106154 build_new_function_call(tree_node*, vec**, bool, int)
   
/rusers/sys_cron/grab_gcc/downloads_rel/4.8.1/gcc-4.8.1/gcc/cp/call.c:3918
0x81bbdef finish_call_expr(tree_node*, vec**,
bool, bool, int)
   
/rusers/sys_cron/grab_gcc/downloads_rel/4.8.1/gcc-4.8.1/gcc/cp/semantics.c:2220
0x8176dd7 cp_parser_postfix_expression
   
/rusers/sys_cron/grab_gcc/downloads_rel/4.8.1/gcc-4.8.1/gcc/cp/parser.c:5855
0x8178a82 cp_parser_unary_expression
   
/rusers/sys_cron/grab_gcc/downloads_rel/4.8.1/gcc-4.8.1/gcc/cp/parser.c:6729
0x8179532 cp_parser_binary_expression
   
/rusers/sys_cron/grab_gcc/downloads_rel/4.8.1/gcc-4.8.1/gcc/cp/parser.c:7421
0x8179ab0 cp_parser_assignment_expression
   
/rusers/sys_cron/grab_gcc/downloads_rel/4.8.1/gcc-4.8.1/gcc/cp/parser.c:7657
0x8179f29 cp_parser_assignment_expression
   
/rusers/sys_cron/grab_gcc/downloads_rel/4.8.1/gcc-4.8.1/gcc/cp/parser.c:7707
0x8179f29 cp_parser_constant_expression
   
/rusers/sys_cron/grab_gcc/downloads_rel/4.8.1/gcc-4.8.1/gcc/cp/parser.c:7917
0x818303a cp_parser_init_declarator
   
/rusers/sys_cron/grab_gcc/downloads_rel/4.8.1/gcc-4.8.1/gcc/cp/parser.c:16095
0x8184d49 cp_parser_simple_declaration
   
/rusers/sys_cron/grab_gcc/downloads_rel/4.8.1/gcc-4.8.1/gcc/cp/parser.c:10670
0x81726d6 cp_parser_block_declaration
   
/rusers/sys_cron/grab_gcc/downloads_rel/4.8.1/gcc-4.8.1/gcc/cp/parser.c:10551
0x818c2b4 cp_parser_declaration
   
/rusers/sys_cron/grab_gcc/downloads_rel/4.8.1/gcc-4.8.1/gcc/cp/parser.c:10448
0x818c676 cp_parser_declaration_seq_opt
   
/rusers/sys_cron/grab_gcc/downloads_rel/4.8.1/gcc-4.8.1/gcc/cp/parser.c:10334
0x818cac4 cp_parser_translation_unit
   
/rusers/sys_cron/grab_gcc/downloads_rel/4.8.1/gcc-4.8.1/gcc/cp/parser.c:3813
0x818cac4 c_parse_file()
   
/rusers/sys_cron/grab_gcc/downloads_rel/4.8.1/gcc-4.8.1/gcc/cp/parser.c:28338
0x8227d5a c_common_parse_file()
   
/rusers/sys_cron/grab_gcc/downloads_rel/4.8.1/gcc-4.8.1/gcc/c-family/c-opts.c:1046
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions. 

Test case:

int fum (); // Extra declaration that is merged with the second one.
int fum () __attribute__ ((target("default")));

#if 0
// gcc doesn't recognize cmov
int fum () __attribute__((target( "cmov")));
#endif
int fum () __attribute__((target( "mmx")));
int fum () __attribute__((target( "popcnt")));
int fum () __attribute__((target( "sse")));
int fum () __attribute__((target( "sse2")));
int fum () __attribute__((target( "sse3")));
int fum () __attribute__((target( "ssse3")));
int fum () __attribute__((target( "sse4.1")));
int fum () __attribute__((target( "sse4.2")));
int fum () __attribute__((target( "avx")));
int fum () __attribute__((target( "avx2")));

int fum () __attribute__((target("arch=core2")));
int fum () __attribute__((target("arch=corei7")));
int fum () __attribute__((target("arch=atom")));

int (*p)() = &fum;


int j = fum();

[Bug target/57547] Missing vector intrinsics in PowerPC Altivec documentation

[meissner at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57547

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-06-06
   Assignee|unassigned at gcc dot gnu.org  |meissner at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug fortran/57549] New: Bogus error with array constructor with derived-type typespec

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57549

Bug ID: 57549
   Summary: Bogus error with array constructor with derived-type
typespec
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org

Vladimir Fuka reports at http://gcc.gnu.org/ml/fortran/2013-06/msg00055.html
that the following code doesn't work:

 a = [t::t()]
   1
Error: Function 't' requires an argument list at (1)


 type t
 end type
 type(t),allocatable :: a(:)
 a = [t::t()]
end

[Bug c++/57543] decltype needs explicit 'this' pointer in member function declaration of template class with trailing return type

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57543

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-06-06
 Blocks||54366
 Ever confirmed|0   |1

[Bug c++/43652] wrong column number for duplicate qualifier

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43652

Paolo Carlini  changed:

   What|Removed |Added

 CC|gcc-bugs at gcc dot gnu.org|

--- Comment #1 from Paolo Carlini  ---
This is fixed in 4.8.0. I'm adding the testcase and closing the bug.

[Bug c++/43652] wrong column number for duplicate qualifier

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43652

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||4.8.0, 4.9.0
 Resolution|--- |FIXED

--- Comment #2 from Paolo Carlini  ---
Done.

[Bug c++/55149] capturing VLA in lambda

[david.abdurachmanov at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55149

David Abdurachmanov  changed:

   What|Removed |Added

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

--- Comment #9 from David Abdurachmanov  
---
I am looking into 55520, which is marked a being duplicate of this ticket.

The example 1 below from 55520, still ICE on 4.9.0 (r199649). Yet it's marked
as RESOLVED FIXED. Jason, w/ 4.8.{0,1} VLA capture by reference in lambda works
fine, or at least compiles. Yet it now fails w/ 4.9.0. Details in example 2.

1. Is 55520 and this bug really RESOLVED FIXED? Example 1 produces ICE under
4.9.0.
2. Does capturing VLA by reference works **only** in 4.9.0? Example 2 compiles
under 4.8.{0,1}.
3. Looking at example 2, I would say capturing VLA by reference doesn't work in
4.9.0, or am I missing something here? Should I file a bug report?

### EXAMPLE 1 ###

int main(int argc, char** argv)
{
int x[1][argc];

[&x](int i)
{
x[0][i]  = 0;
}(5);

return 0;
}

### GCC OUTPUT ###

test2.cxx: In lambda function:
test2.cxx:7:15: internal compiler error: in expand_expr_real_1, at expr.c:9361
 x[0][i]  = 0;
   ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


### EXAMPLE 2 ###

134   uint32_t index[nt];
135   float e[nt];
136   for (std::size_t k=0; k!=nt; ++k) {
137 e[k]=towers[k].eta();
138 index[k]=k;
139 std::push_heap(index,index+k+1,[&e](uint32_t i, uint32_t j){ return
e[i]

[Bug rtl-optimization/57447] [4.9 Regression] ICE on 435.gromacs from spec2006 after r199298

[vmakarov at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57447

Vladimir Makarov  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #4 from Vladimir Makarov  ---
It was fixed by patch for PR57468.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57468

[Bug c++/44811] non controllable bogus warning: right/left shift count is negative

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44811

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC|gcc-bugs at gcc dot gnu.org|
 Resolution|--- |DUPLICATE

--- Comment #5 from Paolo Carlini  ---
This is a Dup of PR11856. Comment #3 is different, I think it's a known kind of
issue anyway.

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

[Bug c++/11856] unsigned warning in template

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11856

Paolo Carlini  changed:

   What|Removed |Added

 CC||gpiez at web dot de

--- Comment #36 from Paolo Carlini  ---
*** Bug 44811 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/57459] [4.8/4.9 Regression] LRA inheritance bug

[wmi at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57459

--- Comment #6 from wmi at google dot com ---
continue the analysis in the first post, for the smallcase 1.c, the IR after
calling inherit_in_ebb in lra_inheritance for bb12 is:

(insn 289 47 48 12 (set (reg:SI 116 [79])
(reg:SI 121 [79])) 1.c:16 85 {*movsi_internal}
 (nil))
(insn 48 289 290 12 (set (reg:SI 116 [79])
(if_then_else:SI (eq (reg:CCNO 17 flags)
(const_int 0 [0]))
(reg:SI 122 [83])
(reg:SI 116 [79]))) 1.c:16 923 {*movsicc_noc}
 (expr_list:REG_DEAD (reg:SI 122 [83])
(nil)))
(insn 290 48 294 12 (set (reg:SI 120 [79])
(reg:SI 116 [79])) 1.c:16 85 {*movsi_internal}
 (nil))
(insn 294 290 49 12 (set (reg:SI 79)
(reg:SI 120 [79])) 1.c:16 85 {*movsi_internal}
 (nil))
..
(insn 292 50 51 12 (set (reg:QI 118)
(subreg:QI (reg:SI 120 [79]) 0)) 1.c:16 87 {*movqi_internal}
 (nil))
(insn 51 292 52 12 (parallel [
(set (reg:CC 17 flags)
(unspec:CC [
(subreg:QI (reg:SI 79) 0)
(reg:QI 118)
] UNSPEC_ADD_CARRY))
(set (subreg:QI (reg:SI 79) 0)
(plus:QI (subreg:QI (reg:SI 79) 0)It is still correct 
(reg:QI 118)))
]) 1.c:16 259 {addqi3_cc}
 (expr_list:REG_UNUSED (reg:SI 79)
(nil)))

The IR is still correct after this step. 

However, after update_ebb_live_info (called after inherit_in_ebb), insn 294 is
removed. Then reg 79 cannot get updated value and it doesn't equal to reg 118
anymore. IR is wrong after this step. 
insn 294 is removed in update_ebb_live_info because the reg type of reg 79 is
OP_INOUT but update_ebb_live_info only marks OP_IN type reg as live_regs.

So the fix is:
Index: gcc/lra-constraints.c
===
--- gcc/lra-constraints.c(revision 199752)
+++ gcc/lra-constraints.c(working copy)
@@ -4545,7 +4545,7 @@ update_ebb_live_info (rtx head, rtx tail
   bitmap_clear_bit (&live_regs, reg->regno);
   /* Mark each used value as live.  */
   for (reg = curr_id->regs; reg != NULL; reg = reg->next)
-if (reg->type == OP_IN
+if ((reg->type == OP_IN || reg->type == OP_INOUT)
 && bitmap_bit_p (&check_only_regs, reg->regno))
   bitmap_set_bit (&live_regs, reg->regno);
   /* It is quite important to remove dead move insns because it

Bootstrapped and tested on x86_64-linux.

[Bug c++/55109] internal compiler error: Segmentation fault while reporting error in template function instantiation

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55109

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||4.8.0, 4.9.0
 Resolution|--- |FIXED
   Target Milestone|--- |4.8.0

--- Comment #6 from Paolo Carlini  ---
Fixed in 4.8.0.

[Bug c++/57183] [C++11] auto and -Wunused-variable

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57183

Paolo Carlini  changed:

   What|Removed |Added

 CC||ricilake at gmail dot com

--- Comment #4 from Paolo Carlini  ---
*** Bug 55128 has been marked as a duplicate of this bug. ***

[Bug c++/55128] auto changes storage from .data to .rodata

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55128

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #1 from Paolo Carlini  ---
Fixed in 4.8.1.

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

[Bug c++/57550] New: [4.8/4.9] Regression: bogus "error ... is private"

[ppluzhnikov at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57550

Bug ID: 57550
   Summary: [4.8/4.9] Regression: bogus "error ... is private"
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ppluzhnikov at google dot com

Google ref: b/9321660

Current trunk (r199768) fails to compile this test when ACCESS is private:


g++ -c proto1.xx.cc  -Wall -DACCESS=public && echo OK
OK

g++ -c proto1.xx.cc  -Wall -DACCESS=private

proto1.xx.cc: In instantiation of ‘static void Handler::SetPrimitiveHandlers()
[with T = double]’:
proto1.xx.cc:15:53:   required from here
proto1.xx.cc:9:36: error: no matching function for call to
‘MakeHandler()’
MakeHandler(Wrapper >);
   ^
proto1.xx.cc:9:36: note: candidate is:
proto1.xx.cc:2:25: note: template void MakeHandler(bool (*)(T))
 template  void MakeHandler (bool (T));
^
proto1.xx.cc:2:25: note:   template argument deduction/substitution failed:
proto1.xx.cc:12:37: error: ‘static bool Handler::Append(T) [with T = double]’
is private
  template  static bool Append (T);
^
proto1.xx.cc:9:36: error: within this context
MakeHandler(Wrapper >);
   ^


/// --- cut ---
template  bool Wrapper(double);
template  void MakeHandler(bool (T));

class Handler
{
public:
  template  static void SetPrimitiveHandlers()
  {
MakeHandler(Wrapper >);
  }
ACCESS :
  template  static bool Append(T);
};

template void Handler::SetPrimitiveHandlers();
/// --- cut ---

[Bug c++/57550] [4.8/4.9 Regression] : bogus "error ... is private"

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57550

Andrew Pinski  changed:

   What|Removed |Added

Summary|[4.8/4.9] Regression: bogus |[4.8/4.9 Regression] :
   |"error ... is private"  |bogus "error ... is
   ||private"

--- Comment #1 from Andrew Pinski  ---
I think the problem is that you cannot take an address of a private static
function as that would get around access controls.

[Bug c++/57550] [4.8/4.9 Regression] bogus "error ... is private"

[ppluzhnikov at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57550

--- Comment #2 from Paul Pluzhnikov  ---
(In reply to Andrew Pinski from comment #1)
> I think the problem is that you cannot take an address of a private static
> function as that would get around access controls.

Surely you can in a class member function.

[Bug regression/57551] New: [4.9 Regression]: g++.dg/ext/visibility/anon6.C scan-assembler 1BIiE1cE

[hp at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57551

Bug ID: 57551
   Summary: [4.9 Regression]: g++.dg/ext/visibility/anon6.C
scan-assembler 1BIiE1cE
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hp at gcc dot gnu.org
CC: hubicka at ucw dot cz

With revision 199692 this test passed.
>From revision 199702 and on, this test has failed as follows:

Running /tmp/hpautotest-gcc0/gcc/gcc/testsuite/g++.dg/dg.exp ...
...
FAIL: g++.dg/ext/visibility/anon6.C -std=c++98  scan-assembler 1BIiE1cE
FAIL: g++.dg/ext/visibility/anon6.C -std=c++11  scan-assembler 1BIiE1cE

With the message in the logfile being:

Executing on host:
/tmp/hpautotest-gcc0/cris-elf/gccobj/gcc/testsuite/g++/../../xg++
-B/tmp/hpautotest-gcc0/cris-elf/gccobj/gcc/testsuite/g++/../../
/tmp/hpautotest-gcc0/gcc/gcc/testsuite/g++.dg/ext/visibility/anon6.C 
-fno-diagnostics-show-caret -fdiagnostics-color=never  -nostdinc++
-I/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/libstdc++-v3/include/cris-elf
-I/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/libstdc++-v3/include
-I/tmp/hpautotest-gcc0/gcc/libstdc++-v3/libsupc++
-I/tmp/hpautotest-gcc0/gcc/libstdc++-v3/include/backward
-I/tmp/hpautotest-gcc0/gcc/libstdc++-v3/testsuite/util -fmessage-length=0
-std=c++98 -pedantic-errors -Wno-long-long -ffat-lto-objects -ffat-lto-objects
-ffat-lto-objects  -S   -isystem
/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/./newlib/targ-include -isystem
/tmp/hpautotest-gcc0/gcc/newlib/libc/include  -o anon6.s(timeout = 300)
PASS: g++.dg/ext/visibility/anon6.C -std=c++98 (test for excess errors)
FAIL: g++.dg/ext/visibility/anon6.C -std=c++98  scan-assembler 1BIiE1cE
PASS: g++.dg/ext/visibility/anon6.C -std=c++98  scan-assembler-not
globl.*1BIiE1cE
PASS: g++.dg/ext/visibility/anon6.C -std=c++98  scan-assembler-not 1CIiE1cE

(similarly for -std=c++11)

The generated assembly file is empty.
Messages on gcc-patches indicate that the failure is universal; at a glance it
seems the suspect commit 199695 made the whole code go away as unused and
unreachable.  Tweak or remove test-case?

Author of suspect patch in revision range CC:ed.

[Bug c++/53658] internal compiler error -- segmentation fault

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53658

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com
   Target Milestone|--- |4.9.0

--- Comment #4 from Paolo Carlini  ---
Mine.

[Bug c++/55520] [C++11] ICE when capturing a variable-length stack array in lambda; in expand_expr_real_1, at expr.c:9122

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55520

Jason Merrill  changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |ice-on-invalid-code
 Status|RESOLVED|ASSIGNED
   Last reconfirmed||2013-06-07
 CC||jason at gcc dot gnu.org
 Resolution|DUPLICATE   |---
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Jason Merrill  ---
Not a duplicate.  This capture is ill-formed, as x has a variable-size type
which is not a C++14 array of runtime bound because a bound other than the
first one is variable.  But we still shouldn't ICE.

[Bug rtl-optimization/57540] stack pointer related loop invariants after reload

[amker.cheng at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57540

--- Comment #1 from bin.cheng  ---
The dump of loop_init is like,
   72: r178:SI=0
  106: L106:
   90: NOTE_INSN_BASIC_BLOCK 6
   91: r178:SI=r178:SI+0x1
   94: r190:SI=r177:SI<<0x2
  REG_DEAD r177:SI
   95: r191:SI=sfp:SI+r190:SI
  REG_DEAD r190:SI
   96: r192:SI=r191:SI-0x810
  REG_DEAD r191:SI
  REG_DEAD r189:SI
   97: r177:SI=[r192:SI]
  REG_DEAD r192:SI
   98: cc:CC=cmp(r177:SI,0)
   99: pc={(cc:CC>=0)?L104:pc}
  REG_DEAD cc:CC
  REG_BR_PROB 0x238c

Instructions 95/96 should be re-factored as below:
   95: r191:SI=sfp:SI-0x810
  REG_DEAD r190:SI
   96: r192:SI=r191:SI+r190:SI
  REG_DEAD r191:SI
  REG_DEAD r189:SI

Thus instruction 95 is loop invariant and be hoisted. For arm target, the loop
can be simplified into:

blt.L3

.L5:
addr2, r2, #1
ldrr3, [sp, r3, asl #2]
cmpr3, #0
bge.L5
uxtbr2, r2