[Bug c++/34949] Dead code in empty destructors.

[jakub at gcc dot gnu.org]

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



--- Comment #21 from Jakub Jelinek  2013-04-03 
06:31:50 UTC ---

Author: jason

Date: Tue Apr  2 21:09:38 2013

New Revision: 197375



URL: http://gcc.gnu.org/viewcvs?rev=197375&root=gcc&view=rev

Log:

PR c++/34949

* decl.c (begin_destructor_body): Clobber the object in a cleanup.



Added:

trunk/gcc/testsuite/g++.dg/opt/vt2.C

Modified:

trunk/gcc/cp/ChangeLog

trunk/gcc/cp/decl.c

[Bug c++/34949] Dead code in empty destructors.

[jakub at gcc dot gnu.org]

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



--- Comment #20 from Jakub Jelinek  2013-04-03 
06:31:13 UTC ---

Author: jakub

Date: Tue Apr  2 18:27:45 2013

New Revision: 197370



URL: http://gcc.gnu.org/viewcvs?rev=197370&root=gcc&view=rev

Log:

PR c++/34949

* tree-ssa-alias.c (stmt_kills_ref_p_1): If base != ref->base

and both of them are MEM_REFs, just compare first argument for

equality and attempt to deal even with differing offsets.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/tree-ssa-alias.c

[Bug c++/34949] Dead code in empty destructors.

[jakub at gcc dot gnu.org]

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



--- Comment #19 from Jakub Jelinek  2013-04-03 
06:31:02 UTC ---

Author: jakub

Date: Tue Apr  2 18:25:36 2013

New Revision: 197369



URL: http://gcc.gnu.org/viewcvs?rev=197369&root=gcc&view=rev

Log:

PR c++/34949

* tree-cfg.c (verify_gimple_assign_single): Allow lhs

of gimple_clobber_p to be MEM_REF.

* gimplify.c (gimplify_modify_expr): Gimplify *to_p of

an assignment from TREE_CLOBBER_P.  Allow it to be MEM_REF

after gimplification.

* asan.c (get_mem_ref_of_assignment): Don't instrument

gimple_clobber_p stmts.

* tree-ssa-dse.c (dse_optimize_stmt): Allow DSE of

gimple_clobber_p stmt if they have MEM_REF lhs and

are dead because of another gimple_clobber_p stmt.

* tree-ssa-live.c (clear_unused_block_pointer): Treat

gimple_clobber_p stmts like debug stmts.

(remove_unused_locals): Remove clobbers with MEM_REF lhs

that refer to unused VAR_DECLs or uninitialized values.

* tree-sra.c (sra_ipa_reset_debug_stmts): Also remove

gimple_clobber_p stmts if they refer to removed parameters.

(get_repl_default_def_ssa_name, sra_ipa_modify_expr): Fix up

formatting.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/asan.c

trunk/gcc/gimplify.c

trunk/gcc/tree-cfg.c

trunk/gcc/tree-sra.c

trunk/gcc/tree-ssa-dse.c

trunk/gcc/tree-ssa-live.c

[Bug rtl-optimization/56745] [4.8/4.9 Regression] ICE in merge_if_block

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED



--- Comment #4 from Jakub Jelinek  2013-04-03 
06:30:26 UTC ---

Should be fixed now for 4.8.1+.

[Bug rtl-optimization/56745] [4.8/4.9 Regression] ICE in merge_if_block

[jakub at gcc dot gnu.org]

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



--- Comment #3 from Jakub Jelinek  2013-04-03 
06:30:06 UTC ---

Author: jakub

Date: Tue Apr  2 18:31:37 2013

New Revision: 197372



URL: http://gcc.gnu.org/viewcvs?rev=197372&root=gcc&view=rev

Log:

PR rtl-optimization/56745

* ifcvt.c (cond_exec_find_if_block): Don't try to optimize

if then_bb has no successors and else_bb is EXIT_BLOCK_PTR.



* gcc.c-torture/compile/pr56745.c: New test.



Added:

branches/gcc-4_8-branch/gcc/testsuite/gcc.c-torture/compile/pr56745.c

Modified:

branches/gcc-4_8-branch/gcc/ChangeLog

branches/gcc-4_8-branch/gcc/ifcvt.c

branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/56745] [4.8/4.9 Regression] ICE in merge_if_block

[jakub at gcc dot gnu.org]

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



--- Comment #2 from Jakub Jelinek  2013-04-03 
06:29:48 UTC ---

Author: jakub

Date: Tue Apr  2 18:29:18 2013

New Revision: 197371



URL: http://gcc.gnu.org/viewcvs?rev=197371&root=gcc&view=rev

Log:

PR rtl-optimization/56745

* ifcvt.c (cond_exec_find_if_block): Don't try to optimize

if then_bb has no successors and else_bb is EXIT_BLOCK_PTR.



* gcc.c-torture/compile/pr56745.c: New test.



Added:

trunk/gcc/testsuite/gcc.c-torture/compile/pr56745.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/ifcvt.c

trunk/gcc/testsuite/ChangeLog

[Bug c++/56815] void pointer arithmetic

[d.v.a at ngs dot ru]

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



--- Comment #5 from __vic  2013-04-03 06:24:43 UTC ---

(In reply to comment #4)

> From gcc manpage, the option '-std=' specifies base standard and

> accept some GNU extensions that do not contradict it.

> 

> If you would like to issue warnings/errors demanded by strict

> ISO C and ISO C++, the -pedantic/-pedantic-errors are required.



Ok, thanks. It works.

But still. What is the difference between +=1 and ++ ? It's the same operation.

[Bug middle-end/45472] [4.6/4.7 Regression] [Middle-end volatile semantics] ICE: in move_op_ascend, at sel-sched.c:6124 with -fselective-scheduling2

[abel at gcc dot gnu.org]

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



--- Comment #29 from Andrey Belevantsev  2013-04-03 
05:59:53 UTC ---

Ported to 4.7 and 4.6, though no bugzilla commit made.  Do I close the bug or

do we want to fix the front-end to produce the proper volatile bits?

[Bug middle-end/56077] [4.6/4.7 Regression] volatile ignored when function inlined

[abel at gcc dot gnu.org]

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



Andrey Belevantsev  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #12 from Andrey Belevantsev  2013-04-03 
05:58:05 UTC ---

Ported to 4.7/4.6, fixed, closed.

[Bug c++/56815] void pointer arithmetic

[jasonwucj at gmail dot com]

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



Chung-Ju Wu  changed:



   What|Removed |Added



 CC||jasonwucj at gmail dot com



--- Comment #4 from Chung-Ju Wu  2013-04-03 
05:57:17 UTC ---

(In reply to comment #3)

> (In reply to comment #2)

> > void* arithmetic is a GCC extension.

> But why my examples are treated differently?



>From gcc manpage, the option '-std=' specifies base standard and

accept some GNU extensions that do not contradict it.



If you would like to issue warnings/errors demanded by strict

ISO C and ISO C++, the -pedantic/-pedantic-errors are required.

[Bug libstdc++/56822] std::promise seems broken on 10.8 lion

[pinskia at gcc dot gnu.org]

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



Andrew Pinski  changed:



   What|Removed |Added



 Target||*darwin*

  Component|c++ |libstdc++



--- Comment #1 from Andrew Pinski  2013-04-03 
04:51:56 UTC ---

I think it best if you can run gdb on the executable to see why it fails.

[Bug c++/56822] New: std::promise seems broken on 10.8 lion

[verdagon at gmail dot com]

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



 Bug #: 56822

   Summary: std::promise seems broken on 10.8 lion

Classification: Unclassified

   Product: gcc

   Version: 4.8.1

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: verda...@gmail.com





See

http://stackoverflow.com/questions/15778085/is-stdpromise-broken-on-my-machine

[Bug c++/56821] Unable to overload with references to 'this'.

[jason at gcc dot gnu.org]

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



Jason Merrill  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #3 from Jason Merrill  2013-04-03 
03:14:11 UTC ---

Fixed.

[Bug c++/56821] Unable to overload with references to 'this'.

[jason at gcc dot gnu.org]

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



Jason Merrill  changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2013-04-03

 CC||jason at gcc dot gnu.org

 AssignedTo|unassigned at gcc dot   |jason at gcc dot gnu.org

   |gnu.org |

   Target Milestone|--- |4.8.1

 Ever Confirmed|0   |1



--- Comment #2 from Jason Merrill  2013-04-03 
00:09:07 UTC ---

Oh dear, I forgot mangling.  Oops!

[Bug lto/56804] lto1: internal compiler error: bytecode stream: found non-null terminated string

[vchou79 at gmail dot com]

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



--- Comment #6 from Vincent  2013-04-02 23:48:41 UTC 
---

bash-4.1$ cat test.res 

3

test.o 4

459 b27d8a298c16d07e PREVAILING_DEF_IRONLY_EXP check_vpx_codec_dec_init_ver

475 b27d8a298c16d07e PREVAILING_DEF_IRONLY_EXP main

463 b27d8a298c16d07e RESOLVED_IR vpx_codec_dec_init_ver

478 b27d8a298c16d07e RESOLVED_IR vpx_codec_control_

./libvpx.a@0x5b54 10

887 aa0ed57284137d70 PREVAILING_DEF_IRONLY_EXP vpx_codec_dec_init_ver

907 aa0ed57284137d70 PREVAILING_DEF_IRONLY_EXP vpx_codec_peek_stream_info

919 aa0ed57284137d70 PREVAILING_DEF_IRONLY_EXP vpx_codec_get_stream_info

927 aa0ed57284137d70 PREVAILING_DEF_IRONLY_EXP vpx_codec_decode

942 aa0ed57284137d70 PREVAILING_DEF_IRONLY_EXP vpx_codec_get_frame

951 aa0ed57284137d70 PREVAILING_DEF_IRONLY_EXP vpx_codec_register_put_frame_cb

962 aa0ed57284137d70 PREVAILING_DEF_IRONLY_EXP vpx_codec_register_put_slice_cb

972 aa0ed57284137d70 PREVAILING_DEF_IRONLY_EXP vpx_codec_get_mem_map

983 aa0ed57284137d70 PREVAILING_DEF_IRONLY_EXP vpx_codec_set_mem_map

994 aa0ed57284137d70 RESOLVED_IR vpx_codec_destroy

./libvpx.a@0x11d60 10

873 3ff73b4c7c71e571 PREVAILING_DEF_IRONLY_EXP vpx_codec_version

877 3ff73b4c7c71e571 PREVAILING_DEF_IRONLY_EXP vpx_codec_version_str

881 3ff73b4c7c71e571 PREVAILING_DEF_IRONLY_EXP vpx_codec_version_extra_str

884 3ff73b4c7c71e571 PREVAILING_DEF_IRONLY_EXP vpx_codec_iface_name

890 3ff73b4c7c71e571 PREVAILING_DEF_IRONLY_EXP vpx_codec_err_to_string

900 3ff73b4c7c71e571 PREVAILING_DEF_IRONLY_EXP vpx_codec_error

907 3ff73b4c7c71e571 PREVAILING_DEF_IRONLY_EXP vpx_codec_error_detail

911 3ff73b4c7c71e571 PREVAILING_DEF_IRONLY_EXP vpx_codec_destroy

917 3ff73b4c7c71e571 PREVAILING_DEF_IRONLY_EXP vpx_codec_get_caps

923 3ff73b4c7c71e571 PREVAILING_DEF_IRONLY_EXP vpx_codec_control_





bash-4.1$ nm test.o

 b .bss

 d .data

 r .gnu.lto_.decls.b27d8a298c16d07e

 r .gnu.lto_.inline.b27d8a298c16d07e

 r .gnu.lto_.opts

 r .gnu.lto_.refs.b27d8a298c16d07e

 r .gnu.lto_.symbol_nodes.b27d8a298c16d07e

 r .gnu.lto_.symtab.b27d8a298c16d07e

 r .gnu.lto_check_vpx_codec_dec_init_ver.b27d8a298c16d07e

 r .gnu.lto_main.b27d8a298c16d07e

 r

.gnu.lto_vpx_codec_control_VP8D_GET_FRAME_CORRUPTED.b27d8a298c16d07e

 r

.gnu.lto_vpx_codec_control_VP8D_GET_LAST_REF_UPDATES.b27d8a298c16d07e

 r

.gnu.lto_vpx_codec_control_VP8D_GET_LAST_REF_USED.b27d8a298c16d07e

 r

.gnu.lto_vpx_codec_control_VP8_COPY_REFERENCE.b27d8a298c16d07e

 r

.gnu.lto_vpx_codec_control_VP8_SET_DBG_COLOR_B_MODES.b27d8a298c16d07e

 r

.gnu.lto_vpx_codec_control_VP8_SET_DBG_COLOR_MB_MODES.b27d8a298c16d07e

 r

.gnu.lto_vpx_codec_control_VP8_SET_DBG_COLOR_REF_FRAME.b27d8a298c16d07e

 r

.gnu.lto_vpx_codec_control_VP8_SET_DBG_DISPLAY_MV.b27d8a298c16d07e

 r .gnu.lto_vpx_codec_control_VP8_SET_POSTPROC.b27d8a298c16d07e

 r

.gnu.lto_vpx_codec_control_VP8_SET_REFERENCE.b27d8a298c16d07e

 p .pdata

 r .rdata$zzz

 t .text

 r .xdata

0001 C __gnu_lto_v1

 U __main

01c8 T check_vpx_codec_dec_init_ver

01d5 T main

 U vpx_codec_control_

016c t vpx_codec_control_VP8D_GET_FRAME_CORRUPTED

013e t vpx_codec_control_VP8D_GET_LAST_REF_UPDATES

019a t vpx_codec_control_VP8D_GET_LAST_REF_USED

002e t vpx_codec_control_VP8_COPY_REFERENCE

00e4 t vpx_codec_control_VP8_SET_DBG_COLOR_B_MODES

00b7 t vpx_codec_control_VP8_SET_DBG_COLOR_MB_MODES

008a t vpx_codec_control_VP8_SET_DBG_COLOR_REF_FRAME

0111 t vpx_codec_control_VP8_SET_DBG_DISPLAY_MV

005c t vpx_codec_control_VP8_SET_POSTPROC

 t vpx_codec_control_VP8_SET_REFERENCE

 U vpx_codec_dec_init_ver

[Bug tree-optimization/56799] Runfail after r197060+r197082.

[law at redhat dot com]

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



--- Comment #2 from Jeffrey A. Law  2013-04-02 22:18:39 
UTC ---

The test to verify we were doing a widening conversion was lost when I made the

tweaks Richi suggested.  I'll have a fix in the tree tomorrow.

[Bug c++/56821] Unable to overload with references to 'this'.

[3dw4rd at verizon dot net]

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



Ed Smith-Rowland <3dw4rd at verizon dot net> changed:



   What|Removed |Added



 CC||jason at redhat dot com



--- Comment #1 from Ed Smith-Rowland <3dw4rd at verizon dot net> 2013-04-02 
21:57:22 UTC ---

Adding Jason.

[Bug c++/56821] New: Unable to overload with references to 'this'.

[3dw4rd at verizon dot net]

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

 Bug #: 56821
   Summary: Unable to overload with references to 'this'.
Classification: Unclassified
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: 3dw...@verizon.net


Created attachment 29783
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29783
This is a reference for 'this' toy.

Here is a busybox I wrote to play with the new feature in gcc-4.8.1 and trunk:

class Foo
{
public:
  Foo(int i) : _M_i(i) { }
  int bar() & { return _M_i /= 2; }
  int bar() const & { return _M_i; }
  int bar() && { return 2 * _M_i; }

private:
  int _M_i = 42;
};

int
main()
{
  Foo ph(333);
  ph.bar();

  const Foo ff(123);
  ff.bar();

  Foo(333).bar();
}


It looks to me reading the standard 8.3.5 that the three bar() methods should
be overloadable. I get a linker error though:


[ed@localhost ref_this]$ ../bin/bin/g++ -std=c++11 -o ref_this ref_this.cpp
/tmp/ccwPhzqr.s: Assembler messages:
/tmp/ccwPhzqr.s:73: Error: symbol `_ZN3Foo3barEv' is already defined


If I comment out 'int bar() const &' I am unable to resolve 'ff.bar()':


[ed@localhost ref_this]$ ../bin/bin/g++ -std=c++11 -o ref_this ref_this.cpp
ref_this.cpp: In function ‘int main()’:
ref_this.cpp:26:10: error: no matching function for call to ‘Foo::bar() const’
   ff.bar();
  ^
ref_this.cpp:26:10: note: candidates are:
ref_this.cpp:11:7: note: int Foo::bar() &
   int bar() & { return _M_i /= 2; }
   ^
ref_this.cpp:11:7: note:   no known conversion for implicit ‘this’ parameter
from ‘const Foo’ to ‘Foo&’
ref_this.cpp:13:7: note: int Foo::bar() &&
   int bar() && { return 2 * _M_i; }
   ^
ref_this.cpp:13:7: note:   no known conversion for implicit ‘this’ parameter
from ‘const Foo’ to ‘Foo&&’


I think this is gcc bug.

[Bug debug/56805] DW_TAG_typedef missing when -fdebug-types-section is used (and -fno-eliminate-unused-debug-types)

[jan.sm...@alcatel-lucent.com]

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



--- Comment #5 from Jan Smets  2013-04-02 
21:28:37 UTC ---

-gstrict-dwarf does not disable type sections in GCC 4.6, the result is

unchanged. With 4.8 the behaviour is what you described. 



Is it really that much trouble to add a DW_TAG_typedef to the .debug_type

entry, regardless of -fno-eliminate-unused-types ?  Without it the debug entry

is incomplete, imho. I would really appreciate it. Thanks.

[Bug c++/50243] vtable for pure abstract class (interface) shouldn't be emitted

[jason at gcc dot gnu.org]

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



--- Comment #4 from Jason Merrill  2013-04-02 
21:19:18 UTC ---

Created attachment 29782

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29782

possible patch



The patches we checked in today for 34949 almost fix this bug as well, but not

quite; the vtable pointer assignment remains in the exception handler, because

optimize_clobbers in tree-eh.c is removing the clobber before it can be used to

optimize away the assignment.



This patch fixes that by skipping MEM_REF clobbers, but I suspect this isn't

really the right way to fix the issue.  Jakub?

[Bug c++/56820] New: elaborated-type-specifier friend incorrectly looked up beyond innermost enclosing namespace

[wd11 at leicester dot ac.uk]

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



 Bug #: 56820

   Summary: elaborated-type-specifier friend incorrectly looked up

beyond innermost enclosing namespace

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: minor

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: w...@leicester.ac.uk





Created attachment 29781

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29781

errorneous C++ source which compiles



gcc (4.7 & 4.8) using -std=c++11 incorrectly looks up unqualified template

friends (not template-id) outside of the innermost enclosing namespace.

According to 7.3.1.2, 



"If the name in a friend declaration is neither qualified nor a template-id and

the declaration is a function or an elaborated-type-specifier, the lookup to

determine whether the entity has been previously declared shall not consider

any scopes outside the innermost enclosing namespace."



For example, in this simple code



namespace outer {

  template class A;

  namespace details {

template class B

{

  template friend class A;

};

  }

}



template class outer::details::B must not befriend (but does to with gcc)

template class outer::A, because the latter is not member of the innermost

inclosing namespace. In order to befriend outer::A, the friend declaration

would need to be qualified, i.e. template friend class outer::A;



---



I attach a simple test program which triggers the error: it compiles although

it shouldn't. output from g++ -v:



Using built-in specs.

COLLECT_GCC=/opt/local/bin/g++-mp-4.8

COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin12/4.8.0/lto-wrapper

Target: x86_64-apple-darwin12

Configured with: ../gcc-4.8-20130321/configure --prefix=/opt/local

--build=x86_64-apple-darwin12

--enable-languages=c,c++,objc,obj-c++,fortran,java

--libdir=/opt/local/lib/gcc48 --includedir=/opt/local/include/gcc48

--infodir=/opt/local/share/info --mandir=/opt/local/share/man

--datarootdir=/opt/local/share/gcc-4.8 --with-local-prefix=/opt/local

--with-system-zlib --disable-nls --program-suffix=-mp-4.8

--with-gxx-include-dir=/opt/local/include/gcc48/c++/ --with-gmp=/opt/local

--with-mpfr=/opt/local --with-mpc=/opt/local --with-ppl=/opt/local

--with-cloog=/opt/local --enable-cloog-backend=isl

--disable-cloog-version-check --enable-stage1-checking --disable-multilib

--enable-lto --enable-libstdcxx-time --with-as=/opt/local/bin/as

--with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar

--with-bugurl=https://trac.macports.org/newticket --with-pkgversion='MacPorts

gcc48 4.8-20130321_0'

Thread model: posix

gcc version 4.8.0 20130321 (prerelease) (MacPorts gcc48 4.8-20130321_0) 



compilation command line (on max OS 10.8):

g++ -std=c++11 -Wextra -Wall -pedantic simple_test.cc



output: working executable writing

  a.foo(4) = 120

to stderr.

[Bug c++/34949] Dead code in empty destructors.

[jason at gcc dot gnu.org]

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



Jason Merrill  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 CC||jason at gcc dot gnu.org

 Resolution||FIXED

   Target Milestone|--- |4.9.0



--- Comment #18 from Jason Merrill  2013-04-02 
21:10:55 UTC ---

Fixed for 4.9.

[Bug c++/56819] New: [4.7/4.8/4.9 Regression] ICE: SIGSEGV in int_cst_value (tree.h:4013) with -fcompare-debug

[zsojka at seznam dot cz]

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



 Bug #: 56819

   Summary: [4.7/4.8/4.9 Regression] ICE: SIGSEGV in int_cst_value

(tree.h:4013) with -fcompare-debug

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: zso...@seznam.cz





Created attachment 29780

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29780

reduced testcase



This ICE happens quite often when running the testsuite with -fcompare-debug



Compiler output:

$ gcc -fcompare-debug testcase.C -wrapper

valgrind,-q,--num-callers=40,--track-origins=yes

==26928== Invalid read of size 2

==26928==at 0xDC0984: int_cst_value(tree_node const*) (tree.h:4013)

==26928==by 0x67D124: get_non_default_template_args_count(tree_node*, int)

(error.c:181)

==26928==by 0x685548: dump_template_argument_list(tree_node*, int)

(error.c:190)

==26928==by 0x67F24F: dump_decl(tree_node*, int) (error.c:1135)

==26928==by 0x68590A: dump_template_parms(tree_node*, int, int)

(error.c:1647)

==26928==by 0x685C0A: dump_typename(tree_node*, int) (error.c:569)

==26928==by 0x68590A: dump_template_parms(tree_node*, int, int)

(error.c:1647)

==26928==by 0x67E2F5: dump_type_prefix(tree_node*, int) (error.c:783)

==26928==by 0x68841B: dump_function_decl(tree_node*, int) (error.c:1406)

==26928==by 0x689D60: decl_as_string(tree_node*, int) (error.c:2613)

==26928==by 0x730E22: cxx_printable_name_internal(tree_node*, int, bool)

(tree.c:1879)

==26928==by 0xC5BE38: dump_function_header(_IO_FILE*, tree_node*, int)

(tree-pretty-print.c:3138)

==26928==by 0x943DFF: rest_of_clean_state() (final.c:4456)

==26928==by 0xAE2457: execute_one_pass(opt_pass*) (passes.c:2330)

==26928==by 0xAE2864: execute_pass_list(opt_pass*) (passes.c:2378)

==26928==by 0x8650B1: expand_function(cgraph_node*) (cgraphunit.c:1640)

==26928==by 0x86724D: compile() (cgraphunit.c:1833)

==26928==by 0x867509: finalize_compilation_unit() (cgraphunit.c:2119)

==26928==by 0x67C59E: cp_write_global_declarations() (decl2.c:4312)

==26928==by 0xBC9A1C: compile_file() (toplev.c:557)

==26928==by 0xBCB837: toplev_main(int, char**) (toplev.c:1864)

==26928==by 0x5A3C60C: (below main) (in /lib64/libc-2.15.so)

==26928==  Address 0x0 is not stack'd, malloc'd or (recently) free'd

==26928== 

==26928== 

==26928== Process terminating with default action of signal 11 (SIGSEGV)

==26928==  Access not within mapped region at address 0x0

==26928==at 0xDC0984: int_cst_value(tree_node const*) (tree.h:4013)

==26928==by 0x67D124: get_non_default_template_args_count(tree_node*, int)

(error.c:181)

==26928==by 0x685548: dump_template_argument_list(tree_node*, int)

(error.c:190)

==26928==by 0x67F24F: dump_decl(tree_node*, int) (error.c:1135)

==26928==by 0x68590A: dump_template_parms(tree_node*, int, int)

(error.c:1647)

==26928==by 0x685C0A: dump_typename(tree_node*, int) (error.c:569)

==26928==by 0x68590A: dump_template_parms(tree_node*, int, int)

(error.c:1647)

==26928==by 0x67E2F5: dump_type_prefix(tree_node*, int) (error.c:783)

==26928==by 0x68841B: dump_function_decl(tree_node*, int) (error.c:1406)

==26928==by 0x689DB9: decl_as_string_translate(tree_node*, int)

(error.c:2621)

==26928==by 0x730E22: cxx_printable_name_internal(tree_node*, int, bool)

(tree.c:1879)

==26928==by 0x6892AA: cp_diagnostic_starter(diagnostic_context*,

diagnostic_info*) (error.c:2959)

==26928==by 0x13505D2: diagnostic_report_diagnostic(diagnostic_context*,

diagnostic_info*) (diagnostic.c:759)

==26928==by 0x135141F: internal_error(char const*, ...) (diagnostic.c:1097)

==26928==by 0xBC99AF: crash_signal(int) (toplev.c:332)

==26928==by 0x5A4FC4F: ??? (in /lib64/libc-2.15.so)

==26928==by 0xDC0983: int_cst_value(tree_node const*) (tree.c:10247)

==26928==by 0x6336C07: ???

==26928==by 0x67D124: get_non_default_template_args_count(tree_node*, int)

(error.c:181)

==26928==by 0x685548: dump_template_argument_list(tree_node*, int)

(error.c:190)

==26928==by 0x67F24F: dump_decl(tree_node*, int) (error.c:1135)

==26928==by 0x68590A: dump_template_parms(tree_node*, int, int)

(error.c:1647)

==26928==by 0x685C0A: dump_typename(tree_node*, int) (error.c:569)

==26928==by 0x68590A: dump_template_parms(tree_node*, int, int)

(error.c:1647)

==26928==by 0x67E2F5: dump_type_prefix(tree_node*, int) (error.c:783)

==26928==by 0x68841B: dump_function_decl(tree_node*, int) (error.c:1406)

==26928==by 0x689D60: decl_as_string(tree_node*, int) (error.c:2613)

==26928==by 0x730E22: cxx_printable_name_internal(tree_node*, int, bool)

(tree.c:1879)

==26928==by 0xC5BE38: dump_function_he

[Bug fortran/56816] ICE in delete_root

[tkoenig at gcc dot gnu.org]

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



Thomas Koenig  changed:



   What|Removed |Added



 CC||mikael at gcc dot gnu.org,

   ||tkoenig at gcc dot gnu.org

Summary|f951.exe internal compiler  |ICE in delete_root

   |error. segmentation fault   |



--- Comment #5 from Thomas Koenig  2013-04-02 
20:41:03 UTC ---

The attachment at



http://gcc.gnu.org/bugzilla/attachment.cgi?id=29779



should really go to this bug.



The traceback (see below) makes me suspect



http://gcc.gnu.org/ml/gcc-cvs/2013-03/msg00054.html



Mikael, any idea?



Program received signal SIGSEGV, Segmentation fault.

0x0050005b in delete_root (t=0x165ac30) at

../../trunk/gcc/fortran/bbt.c:150

150   if (t->left->priority > t->right->priority)

(gdb) bt

#0  0x0050005b in delete_root (t=0x165ac30) at

../../trunk/gcc/fortran/bbt.c:150

#1  0x00500104 in delete_treap (old=old@entry=0x7fffd650,

t=, compare=compare@entry=

0x593140 ) at

../../trunk/gcc/fortran/bbt.c:185

#2  0x005000e9 in delete_treap (old=old@entry=0x7fffd650,

t=0x771ef678 , 

compare=compare@entry=0x593140 ) at

../../trunk/gcc/fortran/bbt.c:183

#3  0x005000e9 in delete_treap (old=old@entry=0x7fffd650,

t=0x165b8e0, 

compare=compare@entry=0x593140 ) at

../../trunk/gcc/fortran/bbt.c:183

#4  0x005000e9 in delete_treap (old=0x7fffd650, t=0x1656cd0,

compare=0x593140 )

at ../../trunk/gcc/fortran/bbt.c:183

#5  0x0050023f in gfc_delete_bbt (root=0x165ac40, old=,

compare=) at ../../trunk/gcc/fortran/bbt.c:197

#6  0x00595e88 in gfc_delete_symtree (root=0x165ac40,

name=0x771ef678  "\300$h\001")

at ../../trunk/gcc/fortran/symbol.c:2403

#7  0x005971ef in gfc_restore_last_undo_checkpoint () at

../../trunk/gcc/fortran/symbol.c:3123

#8  0x005623fb in reject_statement () at

../../trunk/gcc/fortran/parse.c:1745

#9  0x0056252d in match_word (subr=,

old_locus=old_locus@entry=0x7fffd760, str=0x0)

at ../../trunk/gcc/fortran/parse.c:70

#10 0x00562efc in match_word (old_locus=0x7fffd760, subr=, str=0x0) at ../../trunk/gcc/fortran/parse.c:366

#11 decode_statement () at ../../trunk/gcc/fortran/parse.c:366

#12 0x00564255 in next_free () at ../../trunk/gcc/fortran/parse.c:777

#13 next_statement () at ../../trunk/gcc/fortran/parse.c:970

#14 0x0056514d in parse_spec (st=, st@entry=ST_NONE) at

../../trunk/gcc/fortran/parse.c:2738

#15 0x00567149 in parse_progunit (st=st@entry=ST_NONE) at

../../trunk/gcc/fortran/parse.c:4118

#16 0x005674d1 in parse_contained (module=module@entry=1) at

../../trunk/gcc/fortran/parse.c:4057

#17 0x0056857a in parse_module () at

../../trunk/gcc/fortran/parse.c:4316

#18 gfc_parse_file () at ../../trunk/gcc/fortran/parse.c:4582

#19 0x005a40b6 in gfc_be_parse_file () at

../../trunk/gcc/fortran/f95-lang.c:189

#20 0x0094eca6 in compile_file () at ../../trunk/gcc/toplev.c:543

#21 0x00950b08 in do_compile () at ../../trunk/gcc/toplev.c:1864

#22 toplev_main (argc=2, argv=0x7fffdc08) at ../../trunk/gcc/toplev.c:1940

#23 0x76e71455 in __libc_start_main () from /lib64/libc.so.6

#24 0x004f9591 in _start () at ../sysdeps/x86_64/elf/start.S:113

[Bug debug/56805] DW_TAG_typedef missing when -fdebug-types-section is used (and -fno-eliminate-unused-debug-types)

[ccoutant at gcc dot gnu.org]

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



Cary Coutant  changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2013-04-02

 AssignedTo|unassigned at gcc dot   |ccoutant at gcc dot gnu.org

   |gnu.org |

 Ever Confirmed|0   |1

[Bug debug/56805] DW_TAG_typedef missing when -fdebug-types-section is used (and -fno-eliminate-unused-debug-types)

[ccoutant at gcc dot gnu.org]

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



--- Comment #4 from Cary Coutant  2013-04-02 
20:34:57 UTC ---

In GCC 4.6, type sections were the default for -gdwarf-4, but -gdwarf-2 was

still the default for 4.6, I think. If you explicitly ask for -gdwarf-4, you

can also add -gstrict-dwarf and it will not generate the type sections. The

-fdebug-types-section flag was added in 4.7 when -gdwarf-4 was made the

default.



So if all you need is DWARF-4 with GCC 4.6 and -fno-eliminate-unused-types, but

you don't need type sections, just add -gstrict-dwarf.

[Bug c/51628] __attribute__((packed)) is unsafe in some cases

[peter at axium dot co.nz]

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



--- Comment #18 from incrediball  2013-04-02 20:21:06 
UTC ---

Not sure if I can agree with (or understand) this comment. If we use my example

of the address of an int in a packed structure being assigned to an int* then

one could argue that there is a kind of implicit cast happening. The pointer is

to an integer WITH the default alignment which would be 4 on the ARM system I

work with. The int in the struct has an alignment of 1 and so the two types

need to be regarded as being incompatible and there should be an unconditional

warning or at least -Wcast-align should enable such a warning.



I don't know what BLKmode is but if you're speaking of making an int* type

generally able to access the int regardless of its alignment, I think this is

the wrong way to go because code size will explode and efficiency will go out

the window. However if the int* would be declared with some special attribute

then, sure, generate whatever code that is necessary to access the int and the

above mentioned warning can be suppressed in this case (wouldn't the code

generated be much the same code that is used to directly access the int in the

packed struct anyway?) However this would be the second (optional) step, the

first thing is that the compiler needs to emit a warning explaining that the

code that it is generating is broken.

[Bug fortran/56818] [meta-bug] fortran-dev bugs

[dominique.pelletier at polymtl dot ca]

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



--- Comment #2 from Dominique Pelletier  
2013-04-02 19:04:49 UTC ---

Created attachment 29779

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29779

modules from metcalf's modern fortran explainde



DP@P-DP /cygdrive/c/users/dp/Desktop/metcalf

$ gfortran -v -c bug_report.f03

Using built-in specs.

COLLECT_GCC=C:\Program Files (x86)\gfortran\bin\gfortran.exe

Target: mingw32

Configured with: ../gcc-trunk/configure --prefix=/mingw

--enable-languages=c,fortran,lto --with-gmp=/home/brad/gfortran/dependencies

--disable-werror --enable-threads --enable-nls --build=i586-pc-mingw32

--enable-libgomp --enable-shared --disable-win32-registry --with-dwarf2

--disable-sjlj-exceptions --enable-lto --build=mingw32

--enable-version-specific-runtime-libs

Thread model: win32

gcc version 4.8.0 20130302 (experimental) [trunk revision 196403] (GCC)

COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=i386' '-march=i386'

 c:/program files (x86)/gfortran/bin/../libexec/gcc/mingw32/4.8.0/f951.exe

bug_report.f03 -quiet -dumpbase bug_report.f03 -mtune=i386 -march=i386 -auxbase

bug_report -version -fintrinsic-modules-path c:/program files

(x86)/gfortran/bin/../lib/gcc/mingw32/4.8.0/finclude -o

C:\cygwin\tmp\cc7RQyBk.s

GNU Fortran (GCC) version 4.8.0 20130302 (experimental) [trunk revision 196403]

(mingw32)

compiled by GNU C version 4.8.0 20130302 (experimental) [trunk revision

196403], GMP version 5.0.2, MPFR version 3.1.0, MPC version 0.9

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

GNU Fortran (GCC) version 4.8.0 20130302 (experimental) [trunk revision 196403]

(mingw32)

compiled by GNU C version 4.8.0 20130302 (experimental) [trunk revision

196403], GMP version 5.0.2, MPFR version 3.1.0, MPC version 0.9

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

f951.exe: internal compiler error: Segmentation fault

libbacktrace could not find executable to open

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

[Bug fortran/56818] [meta-bug] fortran-dev bugs

[dominique.pelletier at polymtl dot ca]

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



Dominique Pelletier  changed:



   What|Removed |Added



 CC||dominique.pelletier at

   ||polymtl dot ca



--- Comment #1 from Dominique Pelletier  
2013-04-02 19:03:05 UTC ---

DP@P-DP /cygdrive/c/users/dp/Desktop/metcalf

$ gfortran -v -c bug_report.f03

Using built-in specs.

COLLECT_GCC=C:\Program Files (x86)\gfortran\bin\gfortran.exe

Target: mingw32

Configured with: ../gcc-trunk/configure --prefix=/mingw

--enable-languages=c,fortran,lto --with-gmp=/home/brad/gfortran/dependencies

--disable-werror --enable-threads --enable-nls --build=i586-pc-mingw32

--enable-libgomp --enable-shared --disable-win32-registry --with-dwarf2

--disable-sjlj-exceptions --enable-lto --build=mingw32

--enable-version-specific-runtime-libs

Thread model: win32

gcc version 4.8.0 20130302 (experimental) [trunk revision 196403] (GCC)

COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=i386' '-march=i386'

 c:/program files (x86)/gfortran/bin/../libexec/gcc/mingw32/4.8.0/f951.exe

bug_report.f03 -quiet -dumpbase bug_report.f03 -mtune=i386 -march=i386 -auxbase

bug_report -version -fintrinsic-modules-path c:/program files

(x86)/gfortran/bin/../lib/gcc/mingw32/4.8.0/finclude -o

C:\cygwin\tmp\cc7RQyBk.s

GNU Fortran (GCC) version 4.8.0 20130302 (experimental) [trunk revision 196403]

(mingw32)

compiled by GNU C version 4.8.0 20130302 (experimental) [trunk revision

196403], GMP version 5.0.2, MPFR version 3.1.0, MPC version 0.9

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

GNU Fortran (GCC) version 4.8.0 20130302 (experimental) [trunk revision 196403]

(mingw32)

compiled by GNU C version 4.8.0 20130302 (experimental) [trunk revision

196403], GMP version 5.0.2, MPFR version 3.1.0, MPC version 0.9

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

f951.exe: internal compiler error: Segmentation fault

libbacktrace could not find executable to open

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

[Bug fortran/56816] f951.exe internal compiler error. segmentation fault

[dominique.pelletier at polymtl dot ca]

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



--- Comment #4 from Dominique Pelletier  
2013-04-02 19:02:36 UTC ---

DP@P-DP /cygdrive/c/users/dp/Desktop/metcalf

$ gfortran -v -c bug_report.f03

Using built-in specs.

COLLECT_GCC=C:\Program Files (x86)\gfortran\bin\gfortran.exe

Target: mingw32

Configured with: ../gcc-trunk/configure --prefix=/mingw

--enable-languages=c,fortran,lto --with-gmp=/home/brad/gfortran/dependencies

--disable-werror --enable-threads --enable-nls --build=i586-pc-mingw32

--enable-libgomp --enable-shared --disable-win32-registry --with-dwarf2

--disable-sjlj-exceptions --enable-lto --build=mingw32

--enable-version-specific-runtime-libs

Thread model: win32

gcc version 4.8.0 20130302 (experimental) [trunk revision 196403] (GCC)

COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=i386' '-march=i386'

 c:/program files (x86)/gfortran/bin/../libexec/gcc/mingw32/4.8.0/f951.exe

bug_report.f03 -quiet -dumpbase bug_report.f03 -mtune=i386 -march=i386 -auxbase

bug_report -version -fintrinsic-modules-path c:/program files

(x86)/gfortran/bin/../lib/gcc/mingw32/4.8.0/finclude -o

C:\cygwin\tmp\cc7RQyBk.s

GNU Fortran (GCC) version 4.8.0 20130302 (experimental) [trunk revision 196403]

(mingw32)

compiled by GNU C version 4.8.0 20130302 (experimental) [trunk revision

196403], GMP version 5.0.2, MPFR version 3.1.0, MPC version 0.9

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

GNU Fortran (GCC) version 4.8.0 20130302 (experimental) [trunk revision 196403]

(mingw32)

compiled by GNU C version 4.8.0 20130302 (experimental) [trunk revision

196403], GMP version 5.0.2, MPFR version 3.1.0, MPC version 0.9

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

f951.exe: internal compiler error: Segmentation fault

libbacktrace could not find executable to open

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

[Bug fortran/56816] f951.exe internal compiler error. segmentation fault

[dominique.pelletier at polymtl dot ca]

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



Dominique Pelletier  changed:



   What|Removed |Added



  Attachment #29777|0   |1

is obsolete||



--- Comment #3 from Dominique Pelletier  
2013-04-02 19:02:07 UTC ---

Created attachment 29778

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29778

modules from metcalf's book Modern Fortran Explained



DP@P-DP /cygdrive/c/users/dp/Desktop/metcalf

$ gfortran -v -c bug_report.f03

Using built-in specs.

COLLECT_GCC=C:\Program Files (x86)\gfortran\bin\gfortran.exe

Target: mingw32

Configured with: ../gcc-trunk/configure --prefix=/mingw

--enable-languages=c,fortran,lto --with-gmp=/home/brad/gfortran/dependencies

--disable-werror --enable-threads --enable-nls --build=i586-pc-mingw32

--enable-libgomp --enable-shared --disable-win32-registry --with-dwarf2

--disable-sjlj-exceptions --enable-lto --build=mingw32

--enable-version-specific-runtime-libs

Thread model: win32

gcc version 4.8.0 20130302 (experimental) [trunk revision 196403] (GCC)

COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=i386' '-march=i386'

 c:/program files (x86)/gfortran/bin/../libexec/gcc/mingw32/4.8.0/f951.exe

bug_report.f03 -quiet -dumpbase bug_report.f03 -mtune=i386 -march=i386 -auxbase

bug_report -version -fintrinsic-modules-path c:/program files

(x86)/gfortran/bin/../lib/gcc/mingw32/4.8.0/finclude -o

C:\cygwin\tmp\cc7RQyBk.s

GNU Fortran (GCC) version 4.8.0 20130302 (experimental) [trunk revision 196403]

(mingw32)

compiled by GNU C version 4.8.0 20130302 (experimental) [trunk revision

196403], GMP version 5.0.2, MPFR version 3.1.0, MPC version 0.9

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

GNU Fortran (GCC) version 4.8.0 20130302 (experimental) [trunk revision 196403]

(mingw32)

compiled by GNU C version 4.8.0 20130302 (experimental) [trunk revision

196403], GMP version 5.0.2, MPFR version 3.1.0, MPC version 0.9

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

f951.exe: internal compiler error: Segmentation fault

libbacktrace could not find executable to open

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

[Bug fortran/56818] New: [meta-bug] fortran-dev bugs

[tkoenig at gcc dot gnu.org]

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



 Bug #: 56818

   Summary: [meta-bug] fortran-dev bugs

Classification: Unclassified

   Product: gcc

   Version: fortran-dev

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: fortran

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: tkoe...@gcc.gnu.org





This is a meta bug for bugs which should be fixed,

if possible, before fortran-dev is merged, either because

they are regressions or because the array descriptor reform

or other ABI changes.

[Bug tree-optimization/56817] New: [4.8/4.9 Regression] ICE in hide_evolution_in_other_loops_than_loop

[jakub at gcc dot gnu.org]

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

 Bug #: 56817
   Summary: [4.8/4.9 Regression] ICE in
hide_evolution_in_other_loops_than_loop
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org


// { dg-do compile }
// { dg-options "-O3 --param max-unroll-times=32" }

struct A {};
A **q;
struct B
{
  A **j;
  B () { j = q; }
  A *& operator[] (unsigned long x) { return j[x]; }
};
struct C
{
  C (int r) : v (), s (r) {}
  A *& operator () (int i, int j) { return v[i * s + j]; }
  B v;
  int s;
};
struct D
{
  D ()
  {
unsigned h = 2;
for (int i = 0; i < 1; ++i, h *= 2)
  {
C w (h);
for (unsigned j = 0; j < h; ++j)
  for (unsigned k = 0; k < h; ++k)
w (j, k) = new A;
  }
  }
};
void
foo ()
{
  for (int i = 0; i < 3; i++)
A (), A (), D ();
}

ICEs with:
rh947433.C: In function ‘void foo()’:
rh947433.C:34:1: internal compiler error: in
hide_evolution_in_other_loops_than_loop, at tree-chrec.c:716
 foo ()
 ^

starting with http://gcc.gnu.org/r193098

[Bug debug/56805] DW_TAG_typedef missing when -fdebug-types-section is used (and -fno-eliminate-unused-debug-types)

[jan.sm...@alcatel-lucent.com]

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



--- Comment #3 from Jan Smets  2013-04-02 
18:11:41 UTC ---

For me it's very important.  To briefly describe what we do: we have structures

that are sent to different platforms with configuration information for fail

over/redundancy/etc. First we use ccparse to parse our code and find all the

relevant types/structures/etc. We end up in the file where the type is defined,

not necessarily where it's used. Then we compile our entire project and parse

the objdump STABS output of these structures/files we found with ccparse. Then

that information is used to build a bunch of static asserts based on that

information. (eg, size of members, offsets, etc). This tool helps our software

designers.



I've just written a few thousand lines of perl code to parse DWARF output and

to  regenerate the compile time checks. GCC 4.6 seems to only support

type-sections anyway. Upgrading to 4.7 or 4.8 is not an option due to strict

release planning and limited test resources.



Anything you can do to make this work is appreciated. Thank you.

[Bug fortran/56816] f951.exe internal compiler error. segmentation fault

[Joost.VandeVondele at mat dot ethz.ch]

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



Joost VandeVondele  changed:



   What|Removed |Added



 CC||Joost.VandeVondele at mat

   ||dot ethz.ch



--- Comment #2 from Joost VandeVondele  
2013-04-02 17:59:28 UTC ---

you'll need to provide also the sources of the files that define the modules,

otherwise we get:



bug.f90:3.8:



use any_list_module

1

Fatal Error: Can't open module file 'any_list_module.mod' for reading at (1):

No such file or directory

[Bug fortran/56816] f951.exe internal compiler error. segmentation fault

[dominique.pelletier at polymtl dot ca]

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



Dominique Pelletier  changed:



   What|Removed |Added



Version|unknown |4.8.0



--- Comment #1 from Dominique Pelletier  
2013-04-02 17:49:18 UTC ---



DP@P-DP /cygdrive/c/users/dp/desktop/metcalf

$ gfortran -v -c myitem_list_module.f03

Using built-in specs.

COLLECT_GCC=C:\Program Files (x86)\gfortran\bin\gfortran.exe

Target: mingw32

Configured with: ../gcc-trunk/configure --prefix=/mingw

--enable-languages=c,fortran,lto --with-gmp=/home/brad/gfortran/dependencies

--disable-werror --enable-threads --enable-nls --build=i586-pc-mingw32

--enable-libgomp --enable-shared --disable-win32-registry --with-dwarf2

--disable-sjlj-exceptions --enable-lto --build=mingw32

--enable-version-specific-runtime-libs

Thread model: win32

gcc version 4.8.0 20130302 (experimental) [trunk revision 196403] (GCC)

COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=i386' '-march=i386'

 c:/program files (x86)/gfortran/bin/../libexec/gcc/mingw32/4.8.0/f951.exe

myitem_list_module.f03 -quiet -dumpbase myitem_list_module.f03 -mtune=i386

-march=i386 -auxbase myitem_list_module -version -fintrinsic-modules-path

c:/program files (x86)/gfortran/bin/../lib/gcc/mingw32/4.8.0/finclude -o

C:\cygwin\tmp\cckGnVj1.s

GNU Fortran (GCC) version 4.8.0 20130302 (experimental) [trunk revision 196403]

(mingw32)

compiled by GNU C version 4.8.0 20130302 (experimental) [trunk revision

196403], GMP version 5.0.2, MPFR version 3.1.0, MPC version 0.9

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

GNU Fortran (GCC) version 4.8.0 20130302 (experimental) [trunk revision 196403]

(mingw32)

compiled by GNU C version 4.8.0 20130302 (experimental) [trunk revision

196403], GMP version 5.0.2, MPFR version 3.1.0, MPC version 0.9

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

f951.exe: internal compiler error: Segmentation fault

libbacktrace could not find executable to open

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

[Bug fortran/56816] New: f951.exe internal compiler error. segmentation fault

[dominique.pelletier at polymtl dot ca]

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



 Bug #: 56816

   Summary: f951.exe internal compiler error. segmentation fault

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: fortran

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: dominique.pellet...@polymtl.ca





Created attachment 29777

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29777

problem  occured trying to compile Metcalf example in MODERN FORTRAN EXPLAINED



DP@P-DP /cygdrive/c/users/dp/desktop/metcalf

$ gfortran -v -c myitem_list_module.f03

Using built-in specs.

COLLECT_GCC=C:\Program Files (x86)\gfortran\bin\gfortran.exe

Target: mingw32

Configured with: ../gcc-trunk/configure --prefix=/mingw

--enable-languages=c,fortran,lto --with-gmp=/home/brad/gfortran/dependencies

--disable-werror --enable-threads --enable-nls --build=i586-pc-mingw32

--enable-libgomp --enable-shared --disable-win32-registry --with-dwarf2

--disable-sjlj-exceptions --enable-lto --build=mingw32

--enable-version-specific-runtime-libs

Thread model: win32

gcc version 4.8.0 20130302 (experimental) [trunk revision 196403] (GCC)

COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=i386' '-march=i386'

 c:/program files (x86)/gfortran/bin/../libexec/gcc/mingw32/4.8.0/f951.exe

myitem_list_module.f03 -quiet -dumpbase myitem_list_module.f03 -mtune=i386

-march=i386 -auxbase myitem_list_module -version -fintrinsic-modules-path

c:/program files (x86)/gfortran/bin/../lib/gcc/mingw32/4.8.0/finclude -o

C:\cygwin\tmp\cckGnVj1.s

GNU Fortran (GCC) version 4.8.0 20130302 (experimental) [trunk revision 196403]

(mingw32)

compiled by GNU C version 4.8.0 20130302 (experimental) [trunk revision

196403], GMP version 5.0.2, MPFR version 3.1.0, MPC version 0.9

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

GNU Fortran (GCC) version 4.8.0 20130302 (experimental) [trunk revision 196403]

(mingw32)

compiled by GNU C version 4.8.0 20130302 (experimental) [trunk revision

196403], GMP version 5.0.2, MPFR version 3.1.0, MPC version 0.9

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

f951.exe: internal compiler error: Segmentation fault

libbacktrace could not find executable to open

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

[Bug debug/56805] DW_TAG_typedef missing when -fdebug-types-section is used (and -fno-eliminate-unused-debug-types)

[ccoutant at gcc dot gnu.org]

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



Cary Coutant  changed:



   What|Removed |Added



 CC||ccoutant at gcc dot gnu.org



--- Comment #2 from Cary Coutant  2013-04-02 
17:40:09 UTC ---

When generating separate type units with -fdebug-types-section, we always prune

unused types after splitting the types out. As implemented, I think

-fdebug-types-section is incompatible with -fno-eliminate-unused-debug-types,

and a diagnostic should be printed.



How important is it that these two options work together?

[Bug fortran/56814] [4.8/4.9 Regression] Bogus Interface mismatch in dummy procedure

[burnus at gcc dot gnu.org]

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



--- Comment #1 from Tobias Burnus  2013-04-02 
17:25:18 UTC ---

The check is in interface.c's check_result_characteristics:



  /* Check PROCEDURE POINTER attribute.  */

  if (r1 != s1 && r1->attr.proc_pointer != r2->attr.proc_pointer)

{

  snprintf (errmsg, err_len, "PROCEDURE POINTER mismatch in "

"function result");





There are two things bogus here:

a) Passing a proc-pointer to a non-pointer procedure dummy is valid

b) There is no procedure(-pointer) function result, just a proc(-ptr)

actual/dummy argument.

[Bug c++/56815] void pointer arithmetic

[d.v.a at ngs dot ru]

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



--- Comment #3 from __vic  2013-04-02 17:10:15 UTC ---

(In reply to comment #2)

> void* arithmetic is a GCC extension.

But why my examples are treated differently?

[Bug c++/56815] void pointer arithmetic

[pinskia at gcc dot gnu.org]

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



--- Comment #2 from Andrew Pinski  2013-04-02 
17:04:31 UTC ---

Use -pedantic-errors if you want to have rejected invalid standard C++ code. 

void* arithmetic is a GCC extension.

[Bug c++/56815] void pointer arithmetic

[d.v.a at ngs dot ru]

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



--- Comment #1 from __vic  2013-04-02 17:00:23 UTC ---

Slightly modified:



int main()

{

void *p = 0;

p++;

}



$ gcc -std=c++98 source.cpp



source.cpp:4:6: error: arithmetic on a pointer to void

p++;

~^

[Bug c++/56815] New: void pointer arithmetic

[d.v.a at ngs dot ru]

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



 Bug #: 56815

   Summary: void pointer arithmetic

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: d@ngs.ru





int main()

{

void *p = 0;

p += 1;

}



$ gcc -std=c++98 source.cpp



source.cpp: In function 'int main()':

source.cpp:4:7: warning: pointer of type 'void *' used in arithmetic

[-Wpedantic]

 p += 1;

   ^



Why only warning? It must be error. Other compilers reject this code.

[Bug tree-optimization/50789] Gather vectorization

[vincenzo.innocente at cern dot ch]

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

vincenzo Innocente  changed:

   What|Removed |Added

 CC||vincenzo.innocente at cern
   ||dot ch

--- Comment #10 from vincenzo Innocente  
2013-04-02 16:49:53 UTC ---
I was trying to see how gcc behaves w.r.t. this example
http://software.intel.com/en-us/articles/bkm-coaxing-the-compiler-to-vectorize-structured-data-via-gathers

So I started from the example in comment 6 and "evolved" as follows
f21() and f22() are equivalent to my eyes
f21 vectorize, f22 not
also the variant f21b does not vectorize…

c++ -v
Using built-in specs.
COLLECT_GCC=c++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin12.2.0/4.8.0/lto-wrapper
Target: x86_64-apple-darwin12.2.0
Configured with: ./configure --enable-languages=c,c++,fortran
--disable-multilib --disable-bootstrap --enable-lto -disable-libitm :
(reconfigured) ./configure --enable-languages=c,c++,fortran --disable-multilib
--disable-bootstrap --enable-lto -disable-libitm : (reconfigured) ./configure
--enable-languages=c,c++,fortran --disable-multilib --disable-bootstrap
--enable-lto -disable-libitm
Thread model: posix
gcc version 4.8.0 20130313 (experimental) [trunk revision 196633] (GCC) 

c++ -std=c++11 -Ofast -mavx2 -S gather.cc -ftree-vectorizer-verbose=2  

struct float3 {
  float x;
  float y;
  float z;
};

#define N 1024
float fx[N], g[N];
float fy[N];
float fz[N]; 
int k[N];

float ff[3*N];
float3 f3[N];
void
f20 (void)
{
  int i;
  for (i = 0; i < N; i++)
g[i] = fx[k[i]]+fy[k[i]]+fz[k[i]];
}

void
f21 (void)
{
  int i;
  for (i = 0; i < N; i++)
g[i] = ff[3*k[i]]+ff[3*k[i]+1]+ff[3*k[i]+2];
}
void
f22 (void)
{
  int i;
  for (i = 0; i < N; i++)
g[i] = f3[k[i]].x+f3[k[i]].y+f3[k[i]].z;
}


void
f21b (void)
{
  int i;
  for (i = 0; i < N; i++) {
auto j = ff+3*k[i];
g[i] = j[0]+j[1]+j[2];
  }
}

[Bug fortran/56735] [4.6/4.7/4.8/4.9 Regression] Namelist Read Error with question marks

[burnus at gcc dot gnu.org]

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



--- Comment #10 from Tobias Burnus  2013-04-02 
16:31:25 UTC ---

Author: burnus

Date: Tue Apr  2 16:30:26 2013

New Revision: 197361



URL: http://gcc.gnu.org/viewcvs?rev=197361&root=gcc&view=rev

Log:

libgfortran/

2013-04-02  Tobias Burnus  



Backport from mainline:

2013-03-28  Tobias Burnus  



PR fortran/56735

* io/list_read.c (nml_query): Only abort when

an error occured.

(namelist_read): Add goto instead of falling through.





gcc/testsuite/

2013-04-02  Tobias Burnus  



Backport from mainline:

2013-03-28  Tobias Burnus  



PR fortran/56735

* gfortran.dg/namelist_80.f90: New.





Added:

branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/namelist_80.f90

Modified:

branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

branches/gcc-4_8-branch/libgfortran/ChangeLog

branches/gcc-4_8-branch/libgfortran/io/list_read.c

[Bug other/56811] [4.8 Regression] libbacktrace causes undefined symbol "_Unwind_GetIPInfo" on ia64-hpux

[pinskia at gcc dot gnu.org]

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



Andrew Pinski  changed:



   What|Removed |Added



  Component|c   |other

   Host||ia64-hpux

   Target Milestone|--- |4.8.1

Summary|gcc build fails:|[4.8 Regression]

   |Unsatisfied symbol  |libbacktrace causes

   |"_Unwind_GetIPInfo" |undefined symbol

   ||"_Unwind_GetIPInfo" on

   ||ia64-hpux

   Severity|blocker |normal

[Bug fortran/56814] [4.8/4.9 Regression] Bogus Interface mismatch in dummy procedure

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 CC||burnus at gcc dot gnu.org

   Target Milestone|--- |4.8.1

[Bug fortran/56814] New: [4.8/4.9 Regression] Bogus Interface mismatch in dummy procedure

[burnus at gcc dot gnu.org]

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



 Bug #: 56814

   Summary: [4.8/4.9 Regression] Bogus Interface mismatch in dummy

procedure

Classification: Unclassified

   Product: gcc

   Version: 4.9.0

Status: UNCONFIRMED

  Keywords: rejects-valid

  Severity: normal

  Priority: P3

 Component: fortran

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: bur...@gcc.gnu.org

CC: ja...@gcc.gnu.org





The following code compiles with ifort and gfortran 4.5 to 4.7. With 4.8 and

4.9 it fails with:



Error: Interface mismatch in dummy procedure 'fun' at (1): PROCEDURE POINTER

mismatch in function result



However, to me the interfaces look the same.





Reported at comp.lang.fortran by Macro Restelli,

https://groups.google.com/forum/?fromgroups=#!topic/comp.lang.fortran/rfoD-brnIqI





module m1

 abstract interface

  pure function i_f(x) result(d)

   real, intent(in) :: x(:,:)

   real :: d(size(x,1),size(x,2))

  end function i_f

 end interface



 procedure(i_f), pointer :: f => null()

end module m1



module m2

contains

 pure subroutine ns_dirdata(fun)

  interface

   pure function fun(x) result(d)

real, intent(in) :: x(:,:)

real :: d(size(x,1),size(x,2))

   end function fun

  end interface

 end subroutine ns_dirdata

end module m2



program p

 use m1

 use m2

  call ns_dirdata(f)

end program p

[Bug libfortran/56737] [4.6/4.7/4.8/4.9 Regression] Wrong I/O result with format cache for Hollerith strings

[burnus at gcc dot gnu.org]

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



--- Comment #7 from Tobias Burnus  2013-04-02 
15:43:19 UTC ---

Author: burnus

Date: Tue Apr  2 15:42:31 2013

New Revision: 197359



URL: http://gcc.gnu.org/viewcvs?rev=197359&root=gcc&view=rev

Log:

libgfortran/

2013-04-02  Tobias Burnus  



Backport from mainline:

2013-03-29  Tobias Burnus  



PR fortran/56737

* io/format.c (parse_format): With caching, copy

dtp->format string.

(save_parsed_format): Use dtp->format directly without

copying.



2012-03-29  Tobias Burnus  



PR fortran/56737

* io/format.c (parse_format_list): Also cache FMT_STRING.

(parse_format): Update call.



gcc/testsuite/

2013-04-02  Tobias Burnus  



Backport from mainline:

2013-03-29  Tobias Burnus  



PR fortran/56737

* testsuite/gfortran.dg/fmt_cache_3.f90: New.





Added:

branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/fmt_cache_3.f90

Modified:

branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

branches/gcc-4_8-branch/libgfortran/ChangeLog

branches/gcc-4_8-branch/libgfortran/io/format.c

[Bug bootstrap/56813] New: [4.9 regression] invalid assembly code for libiberty/cp-demangle.c on armv5tel-linux-gnueabi

[mikpe at it dot uu.se]

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



 Bug #: 56813

   Summary: [4.9 regression] invalid assembly code for

libiberty/cp-demangle.c on armv5tel-linux-gnueabi

Classification: Unclassified

   Product: gcc

   Version: 4.9.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: bootstrap

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: mi...@it.uu.se





Created attachment 29776

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29776

preprocessed source and generated assembly code



Attempting to bootstrap gcc-4.9-20130331 on armv5tel-linux-gnueabi fails with:



ln -s /mnt/scratch/gcc-4.9-20130331/libstdc++-v3/../libiberty/cp-demangle.c

cp-demangle.c

/bin/sh ../libtool --tag CC --tag disable-shared  --mode=compile

/mnt/scratch/objdir49/./gcc/xgcc -B/mnt/scratch/objdir49/./gcc/

-B/mnt/scratch/install49/armv5tel-unknown-linux-gnueabi/bin/

-B/mnt/scratch/install49/armv5tel-unknown-linux-gnueabi/lib/ -isystem

/mnt/scratch/install49/armv5tel-unknown-linux-gnueabi/include -isystem

/mnt/scratch/install49/armv5tel-unknown-linux-gnueabi/sys-include   

-DHAVE_CONFIG_H -I.. -I/mnt/scratch/gcc-4.9-20130331/libstdc++-v3/../libiberty

-I/mnt/scratch/gcc-4.9-20130331/libstdc++-v3/../include -prefer-pic

-D_GLIBCXX_SHARED

-I/mnt/scratch/objdir49/armv5tel-unknown-linux-gnueabi/libstdc++-v3/include/armv5tel-unknown-linux-gnueabi

-I/mnt/scratch/objdir49/armv5tel-unknown-linux-gnueabi/libstdc++-v3/include

-I/mnt/scratch/gcc-4.9-20130331/libstdc++-v3/libsupc++   -g -O2 -DIN_GLIBCPP_V3

-Wno-error -c cp-demangle.c

libtool: compile:  /mnt/scratch/objdir49/./gcc/xgcc

-B/mnt/scratch/objdir49/./gcc/

-B/mnt/scratch/install49/armv5tel-unknown-linux-gnueabi/bin/

-B/mnt/scratch/install49/armv5tel-unknown-linux-gnueabi/lib/ -isystem

/mnt/scratch/install49/armv5tel-unknown-linux-gnueabi/include -isystem

/mnt/scratch/install49/armv5tel-unknown-linux-gnueabi/sys-include

-DHAVE_CONFIG_H -I.. -I/mnt/scratch/gcc-4.9-20130331/libstdc++-v3/../libiberty

-I/mnt/scratch/gcc-4.9-20130331/libstdc++-v3/../include -D_GLIBCXX_SHARED

-I/mnt/scratch/objdir49/armv5tel-unknown-linux-gnueabi/libstdc++-v3/include/armv5tel-unknown-linux-gnueabi

-I/mnt/scratch/objdir49/armv5tel-unknown-linux-gnueabi/libstdc++-v3/include

-I/mnt/scratch/gcc-4.9-20130331/libstdc++-v3/libsupc++ -g -O2 -DIN_GLIBCPP_V3

-Wno-error -c cp-demangle.c  -fPIC -DPIC -o cp-demangle.o

/tmp/ccdHzBmd.s: Assembler messages:

/tmp/ccdHzBmd.s:13290: Error: bad immediate value for offset (4104)

make[5]: *** [cp-demangle.lo] Error 1

make[5]: Leaving directory

`/mnt/scratch/objdir49/armv5tel-unknown-linux-gnueabi/libstdc++-v3/libsupc++'

make[4]: *** [all-recursive] Error 1

make[4]: Leaving directory

`/mnt/scratch/objdir49/armv5tel-unknown-linux-gnueabi/libstdc++-v3'

make[3]: *** [all] Error 2

make[3]: Leaving directory

`/mnt/scratch/objdir49/armv5tel-unknown-linux-gnueabi/libstdc++-v3'

make[2]: *** [all-stage1-target-libstdc++-v3] Error 2

make[2]: Leaving directory `/mnt/scratch/objdir49'

make[1]: *** [stage1-bubble] Error 2

make[1]: Leaving directory `/mnt/scratch/objdir49'

make: *** [bootstrap] Error 2



This is a recent regression as the previous weekly snapshot, 4.9-20130324,

bootstrapped fine.



The preprocessed code for cp-demangle.c also compiles fine with current 4.8,

4.7, and 4.6 branches.



Binutils is based on 2.22.52.0.1 20120131.



Configuration options:

/mnt/scratch/gcc-4.9-20130331/configure --prefix=/mnt/scratch/install49

--enable-bootstrap --enable-shared --enable-threads=posix

--enable-checking=release --with-system-zlib --enable-__cxa_atexit

--disable-libunwind-exceptions --enable-languages=c,c++,fortran,ada

--disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre

--enable-libgcj-multifile --disable-java-maintainer-mode

--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib

--disable-sjlj-exceptions --with-arch=armv5te --with-tune=xscale

--build=armv5tel-unknown-linux-gnueabi --disable-plugin --disable-lto

--disable-libmudflap



I'll attach cp-demangle.{i,s}.

[Bug tree-optimization/56787] [4.8/4.9 Regression] Vectorization fails because of CLOBBER statements

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org



--- Comment #2 from Jakub Jelinek  2013-04-02 
14:50:18 UTC ---

Somewhat reduced testcase:

inline void

bar (const float s[5], float z[3][5])

{

  float a = s[0], b = s[1], c = s[2], d = s[3], e = s[4];

  float f = 1.0f / a;

  float u = f * b, v = f * c, w = f * d;

  float p = 0.4f * (e - 0.5f * (b * u + c * v + d * w));

  z[0][3] = b * w;

  z[1][3] = c * w;

  z[2][3] = d * w + p;

}



void

foo (unsigned long n, const float *__restrict u0,

 const float *__restrict u1, const float *__restrict u2,

 const float *__restrict u3, const float *__restrict u4,

 const float *__restrict s0, const float *__restrict s1,

 const float *__restrict s2, float *__restrict t3,

 float *__restrict t4)

{

  unsigned long i;

  for (i = 0; i < n; i++)

{

  float u[5], f[3][5];

  u[0] = u0[i]; u[1] = u1[i]; u[2] = u2[i]; u[3] = u3[i]; u[4] = u4[i];

  bar (u, f);

  t3[i] = s0[i] * f[0][3] + s1[i] * f[1][3] + s2[i] * f[2][3];

}

}

[Bug c++/22488] C++ frontend generates RECORD_TYPEs with overlapping FIELD_DECLs

[ebotcazou at gcc dot gnu.org]

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



Eric Botcazou  changed:



   What|Removed |Added



 CC||ebotcazou at gcc dot

   ||gnu.org



--- Comment #58 from Eric Botcazou  2013-04-02 
14:37:43 UTC ---

> The C++ frontend issue makes it impossible to implement a GENERIC verifier

> for RECORD_TYPEs (verify FIELD_DECLs are sorted after offset and not

> overlapping).



To be fair, I think that the Ada front-end still has the same issue.  We fixed

the biggest source (constrained subtypes of record types with variant part) a

few releases ago, but there is still one problematic case (record type with

variant part and partial representation clause).

[Bug middle-end/52436] BIT_FIELD_REF > should be canonicalized for non-bitfield accesses

[glisse at gcc dot gnu.org]

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



--- Comment #6 from Marc Glisse  2013-04-02 14:36:59 
UTC ---

(In reply to comment #5)

> No, get_addr_base_and_unit_offset_1 only is supposed to return the

> addressable offset into an object - it doesn't care about access sizes.



It is also allowed to say "bad idea, I will return NULL", but ok.



> But you can't really do what you do there.  You are possibly

> transforming

[...]



Good point, thanks.



> which is not correct, obviously.  "combining" with memory

> accesses isn't trivial, certainly not a task I would consider

> for forwprop.  I can't think of a suitable existing pass

> that would combine this, but value-numbering should eventually

> value-number both cases the same at least.



I guess that leaves the vector lowering pass as the easiest alternative for

PR55266: split all unsupported memory reads into supported reads and a

constructor (and similarly, split writes into bit_field_refs and writes) and

hope that nothing does the reverse transformation.

[Bug middle-end/52436] BIT_FIELD_REF > should be canonicalized for non-bitfield accesses

[rguenther at suse dot de]

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



--- Comment #5 from rguenther at suse dot de  
2013-04-02 14:21:56 UTC ---

On Tue, 2 Apr 2013, glisse at gcc dot gnu.org wrote:



> 

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

> 

> --- Comment #4 from Marc Glisse  2013-04-02 
> 14:08:57 UTC ---

> (In reply to comment #3)

> > I'd re-organize it like

> 

> Ok, I'll try something like that.

> 

> > it avoids building a tree just to feed it into get_addr_base_and_unit_offset

> 

> The idea was that there would be almost no cases where this was done and no

> simplification occurred. If a transformation is indeed done, building one tree

> is not that expensive, especially if it avoids code duplication.



AFAIK it really doesn't.



> > It also avoids it if the access is not of byte-granularity which

> > get_addr_base_and_unit_offset does not even consider (it assumes it is fed

> > the argument of an ADDR_EXPR which obviously is byte-aligned).

> > 

> > The tree-flow-inline.h bits look ok.

> 

> In get_addr_base_and_unit_offset_1 I already check if the offset is a multiple

> of BITS_PER_UNIT, I should probably check that the size is a multiple as well,

> no?



No, get_addr_base_and_unit_offset_1 only is supposed to return the

addressable offset into an object - it doesn't care about access sizes.



> > I'm not sure what you need the forwprop / tree-ssa-propagate changes for.

> 

> I need something to call fold on a bit_field_ref of a mem_ref. For PR55266, 
> the

> vector lowering pass produces a mem_ref and a bit_field_ref in two distinct

> gimple statements, and nothing tries to combine them.



But you can't really do what you do there.  You are possibly

transforming



  vecreg_2 = MEM[...];



  MEM[...] = ; // clobber the memory location 



  scalreg_3 = BIT_FIELD_REF ;



into



  vecreg_2 = MEM[...]; // possibly unused

...

  MEM[...] = ; // clobber the memory location

...

  scalreg_3 = MEM[...];



which is not correct, obviously.  "combining" with memory

accesses isn't trivial, certainly not a task I would consider

for forwprop.  I can't think of a suitable existing pass

that would combine this, but value-numbering should eventually

value-number both cases the same at least.



Richard.

[Bug middle-end/52436] BIT_FIELD_REF > should be canonicalized for non-bitfield accesses

[glisse at gcc dot gnu.org]

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



--- Comment #4 from Marc Glisse  2013-04-02 14:08:57 
UTC ---

(In reply to comment #3)

> I'd re-organize it like



Ok, I'll try something like that.



> it avoids building a tree just to feed it into get_addr_base_and_unit_offset



The idea was that there would be almost no cases where this was done and no

simplification occurred. If a transformation is indeed done, building one tree

is not that expensive, especially if it avoids code duplication.



> It also avoids it if the access is not of byte-granularity which

> get_addr_base_and_unit_offset does not even consider (it assumes it is fed

> the argument of an ADDR_EXPR which obviously is byte-aligned).

> 

> The tree-flow-inline.h bits look ok.



In get_addr_base_and_unit_offset_1 I already check if the offset is a multiple

of BITS_PER_UNIT, I should probably check that the size is a multiple as well,

no?



> I'm not sure what you need the forwprop / tree-ssa-propagate changes for.



I need something to call fold on a bit_field_ref of a mem_ref. For PR55266, the

vector lowering pass produces a mem_ref and a bit_field_ref in two distinct

gimple statements, and nothing tries to combine them.

[Bug tree-optimization/56812] Simple loop is not SLP-vectorized after r196872

[rguenth at gcc dot gnu.org]

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



--- Comment #6 from Richard Biener  2013-04-02 
14:06:12 UTC ---

The BB vectorization case ran into



  /* When vectorizing a basic block unknown depnedence can still mean

 grouped access.  */

  if (vect_check_interleaving (dra, drb))

 return false;



that is, whenever dra and drb are part of the same interleaving chain

it considers the accesses to be independent.  I'm not sure this is

a good idea in general, but it's easy to re-instantiate.



There is no reason why dependence analysis should fail here though

(it does because dr_may_alias_p does not use SCEV info as computed by

dr_analyze_innermost and used by interleaving chain analysis, but instead

it looks at the base DR_REF which is also used as DR_BASE_OBJECT).

[Bug tree-optimization/56812] Simple loop is not SLP-vectorized after r196872

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|WAITING |ASSIGNED

 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org

   |gnu.org |



--- Comment #5 from Richard Biener  2013-04-02 
13:36:11 UTC ---

Ah, I see.  Confirmed.

[Bug tree-optimization/56778] [4.9 Regression] ICE on several benchmarks after r196775.

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #4 from Richard Biener  2013-04-02 
13:31:40 UTC ---

Author: rguenth

Date: Tue Apr  2 13:31:05 2013

New Revision: 197355



URL: http://gcc.gnu.org/viewcvs?rev=197355&root=gcc&view=rev

Log:

2013-04-02  Richard Biener  



PR tree-optimization/56778

* tree-vect-data-refs.c (vect_analyze_data_ref_dependence):

Runtime alias tests are not supported for gather loads.

* tree-vect-loop-manip.c (vect_loop_versioning): Insert

stmts referenced from SSA operands before updating SSA form.



* gcc.dg/torture/pr56778.c: New testcase.



Added:

trunk/gcc/testsuite/gcc.dg/torture/pr56778.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/testsuite/ChangeLog

trunk/gcc/tree-vect-data-refs.c

trunk/gcc/tree-vect-loop-manip.c

[Bug fortran/50269] Wrongly rejects element of assumed-shape array in C_LOC

[burnus at gcc dot gnu.org]

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



--- Comment #8 from Tobias Burnus  2013-04-02 
13:28:00 UTC ---

(In reply to comment #7)

> (In reply to comment #6)

> > Are we sure? When running the code example given in comment #1, I get a

> > segfault.

> Yes, something seems to be still broken.



Actually, the compiler generates the correct code. The problem with the test

case of comment 0 and comment 1 is that "b" is a pointer but never allocated.



It works if one either removes "pointer" from the declaration of "b" or adds an

"allocate(b)".

[Bug tree-optimization/56812] Simple loop is not SLP-vectorized after r196872

[ysrumyan at gmail dot com]

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



--- Comment #4 from Yuri Rumyantsev  2013-04-02 
13:27:15 UTC ---

Yes, the test-case is correct. If we delete your changes we got thee following

(with -ftree-vectorizer-verbose-3):



t.cc:12: note: vectorizing stmts using SLP.BASIC BLOCK VECTORIZED



t.cc:12: note: basic block vectorized using SLP

[Bug lto/56804] lto1: internal compiler error: bytecode stream: found non-null terminated string

[rguenth at gcc dot gnu.org]

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



--- Comment #5 from Richard Biener  2013-04-02 
13:25:12 UTC ---

Works for me.  Are you sure -lvpx doesn't contain LTO bytecode?  Can you

reproduce it with -r -nostdlib?  Please provide the output of appending

-v to the link line - also look for the inputs to the WPA stage

(the lto1 command with -fwpa, there is a response file at the end,

save it with -save-temps and inspect it - there are all objects with

LTO bytecode listed).

[Bug libfortran/56810] record-repeat fails kind check on complex read

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



   Keywords||wrong-code

 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-04-02

 CC||burnus at gcc dot gnu.org,

   ||jvdelisle at gcc dot

   ||gnu.org

 Ever Confirmed|0   |1

  Known to fail||4.1.2, 4.3.4, 4.5.3, 4.6.3,

   ||4.7.2, 4.8.0, 4.9.0



--- Comment #1 from Tobias Burnus  2013-04-02 
13:22:33 UTC ---

> Fortran runtime error: Read kind 8 COMPLEX where kind 4 is required for item 2



That's a rather odd message for I/O: The I/O system should be agnostic too the

keal kinds. (Besides, there is only kind=4 in the example.)



It's not a regression, I get the same failure with GCC/gfortran 4.1 to 4.9

[Bug tree-optimization/56812] Simple loop is not SLP-vectorized after r196872

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |WAITING

   Last reconfirmed||2013-04-02

 Ever Confirmed|0   |1



--- Comment #3 from Richard Biener  2013-04-02 
13:20:47 UTC ---

It should not make a difference ... I see that vectorization is determined

to be not profitable though:



t.C:11: note: === vect_update_slp_costs_according_to_vf ===cost model: prologue

peel iters set to vf/2.cost model: epilogue peel iters set to vf/2 because

peeling for alignment is unknown.

t.C:11: note: Cost model analysis:

  Vector inside of loop cost: 1

  Vector prologue cost: 11

  Vector epilogue cost: 2

  Scalar iteration cost: 1

  Scalar outside cost: 0

  Vector outside cost: 13

  prologue iterations: 2

  epilogue iterations: 2

  Calculated minimum iters for profitability: 17



but it's not vectorized with 4.8 either.  -fno-vect-cost-model fixes this.



Are you sure you attached the correct testcase?

[Bug gcov-profile/56773] Programs crash if compiled with --coverage, although they run correctly without --coverage

[peter.hans.froehlich at gmail dot com]

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



--- Comment #4 from peter.hans.froehlich at gmail dot com 2013-04-02 13:10:22 
UTC ---

I am fine with your decision to declare this INVALID, I'd just like to

understand the reasoning. You're saying that it's okay for code injected by gcc

to crash depending on the context in which it is injected? From the perspective

of a mere user, that seems entirely unsatisfying. After all fopen() doesn't

crash when I define a symbol called open in my code, and fopen() presumably

needs to use the open() syscall eventually just like the code injected by gcc

for --coverage does. If gcc would inject code with suitably mangled names,

wouldn't this issue disappear? (Thank you to whoever takes the time to explain

this to me. BTW, I understand *why* fopen() doesn't crash, that's not the

issue.)

[Bug tree-optimization/56799] Runfail after r197060+r197082.

[law at redhat dot com]

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



Jeffrey A. Law  changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2013-04-02

 AssignedTo|unassigned at gcc dot   |law at redhat dot com

   |gnu.org |

 Ever Confirmed|0   |1

[Bug c++/56698] "array subscript is above array bounds" triggered on code that doesn't have that problem

[jason at gcc dot gnu.org]

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



Jason Merrill  changed:



   What|Removed |Added



 Status|UNCONFIRMED |WAITING

   Last reconfirmed||2013-04-02

 Ever Confirmed|0   |1

[Bug c++/56698] "array subscript is above array bounds" triggered on code that doesn't have that problem

[jason at gcc dot gnu.org]

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



Jason Merrill  changed:



   What|Removed |Added



 CC||jason at gcc dot gnu.org



--- Comment #2 from Jason Merrill  2013-04-02 
12:43:32 UTC ---

Could you attach a preprocessed file (compressed if needed) and the

configuration/flags that reproduce the issue?

[Bug c++/56768] [4.7] ICE in make_decl_rtl, at varasm.c:1147

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

  Known to work||4.7.3

 Resolution||FIXED

   Target Milestone|--- |4.7.3



--- Comment #5 from Richard Biener  2013-04-02 
12:25:59 UTC ---

Author: rguenth

Date: Tue Apr  2 12:23:13 2013

New Revision: 197349



URL: http://gcc.gnu.org/viewcvs?rev=197349&root=gcc&view=rev

Log:

2013-04-02  Richard Biener  



PR middle-end/56768

* g++.dg/torture/pr56768.C: New testcase.



Added:

trunk/gcc/testsuite/g++.dg/torture/pr56768.C

Modified:

trunk/gcc/testsuite/ChangeLog



Author: rguenth

Date: Tue Apr  2 12:24:04 2013

New Revision: 197350



URL: http://gcc.gnu.org/viewcvs?rev=197350&root=gcc&view=rev

Log:

2013-04-02  Richard Biener  



PR middle-end/56768

* g++.dg/torture/pr56768.C: New testcase.



Added:

branches/gcc-4_8-branch/gcc/testsuite/g++.dg/torture/pr56768.C

Modified:

branches/gcc-4_8-branch/gcc/testsuite/ChangeLog



Author: rguenth

Date: Tue Apr  2 12:25:00 2013

New Revision: 197351



URL: http://gcc.gnu.org/viewcvs?rev=197351&root=gcc&view=rev

Log:

2013-04-02  Richard Biener  



PR middle-end/56768

Backport from mainline

2012-05-16  Richard Guenther  



* tree-inline.c (declare_return_variable): Properly handle

DECL_BY_REFERENCE return vars in SSA form.



* g++.dg/torture/pr56768.C: New testcase.



Added:

branches/gcc-4_7-branch/gcc/testsuite/g++.dg/torture/pr56768.C

Modified:

branches/gcc-4_7-branch/gcc/ChangeLog

branches/gcc-4_7-branch/gcc/testsuite/ChangeLog

branches/gcc-4_7-branch/gcc/tree-inline.c

[Bug rtl-optimization/55611] Operand swapping for commutative operators

[glisse at gcc dot gnu.org]

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



--- Comment #5 from Marc Glisse  2013-04-02 12:11:12 
UTC ---

See the discussion at:



http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00692.html



which continues at:



http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00049.html



for why we won't do arbitrary canonicalization.

[Bug tree-optimization/56787] [4.8/4.9 Regression] Vectorization fails because of CLOBBER statements

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Keywords||missed-optimization

   Last reconfirmed||2013-04-02

  Component|c   |tree-optimization

 CC||matz at gcc dot gnu.org

 Ever Confirmed|0   |1

Summary|4.8.0 Vectorization |[4.8/4.9 Regression]

   |Regression Compared to  |Vectorization fails because

   |4.7.2   |of CLOBBER statements

   Target Milestone|--- |4.8.1



--- Comment #1 from Richard Biener  2013-04-02 
12:02:39 UTC ---

t.c:137: note: not vectorized: no vectype for stmt: u ={v} {CLOBBER};

 scalar_type: float[5]

t.c:137: note: bad data references.

t.c:137: note: * Re-trying analysis with vector size 16

[Bug tree-optimization/56812] Simple loop is not SLP-vectorized after r196872

[ysrumyan at gmail dot com]

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



--- Comment #2 from Yuri Rumyantsev  2013-04-02 
11:41:23 UTC ---

Sorry, i did a typo in -march option - it must be -march=corei7 -mavx.

[Bug tree-optimization/56778] [4.9 Regression] ICE on several benchmarks after r196775.

[rguenth at gcc dot gnu.org]

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



--- Comment #3 from Richard Biener  2013-04-02 
11:27:09 UTC ---

I have a fix.

[Bug tree-optimization/56812] Simple loop is not SLP-vectorized after r196872

[ysrumyan at gmail dot com]

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



--- Comment #1 from Yuri Rumyantsev  2013-04-02 
11:22:45 UTC ---

Created attachment 29775

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29775

testcase



Need to compile with -O3 -funroll-loops options.

[Bug tree-optimization/56812] New: Simple loop is not SLP-vectorized after r196872

[ysrumyan at gmail dot com]

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



 Bug #: 56812

   Summary: Simple loop is not SLP-vectorized after r196872

Classification: Unclassified

   Product: gcc

   Version: 4.9.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: tree-optimization

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: ysrum...@gmail.com





A simple loop in attached test-case is not SLP-vectorized after this fix with

message:



t.cc:12: note: can't determine dependence between this_4(D)->data[0] and

this_4(D)->data[i_14]

t.cc:12: note: not vectorized: unhandled data dependence in basic block.



To reproduce the failure it is sufficient to compile this test on x86 with the

following options:

  -O3 -funroll-loops -march=IVB

[Bug tree-optimization/56778] [4.9 Regression] ICE on several benchmarks after r196775.

[rguenth at gcc dot gnu.org]

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



--- Comment #2 from Richard Biener  2013-04-02 
11:19:35 UTC ---

The issue is that gimple_seq_add_seq updates stmts added.  But we update SSA

form _before_ adding the sequence into the IL stream:



  /* End loop-exit-fixes after versioning.  */



  update_ssa (TODO_update_ssa);

  if (cond_expr_stmt_list)

{

  cond_exp_gsi = gsi_last_bb (condition_bb);

  gsi_insert_seq_before (&cond_exp_gsi, cond_expr_stmt_list,

 GSI_SAME_STMT);

}



gimplify.c has a function that does gimple_seq_add_seq_without_update.



There are two ways to fix this, one is to insert the sequence before

updating SSA form, another is to consistently use

gimple_seq_add_seq_without_update.

Or to make gimple_seq_add_seq not update stmts (sequences are inserted

later anyway, which can do the update).  Not sure why it would make sense

at all to update stmt operands for sth not in the IL ...



Well.  I'm going for the first.



Which doesn't fix it because we create an alias-check for a load of a

load appearantly where the latter is not loop invariant.  I presume

this is GATHER support, and eventually the DDR mangling in data-ref

analysis I removed did avoid this to happen.

[Bug c/56811] New: gcc build fails: Unsatisfied symbol "_Unwind_GetIPInfo"

[mrcs.gcc at mailnull dot com]

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



 Bug #: 56811

   Summary: gcc build fails: Unsatisfied symbol

"_Unwind_GetIPInfo"

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: blocker

  Priority: P3

 Component: c

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: mrcs@mailnull.com





Building gcc 4.8.0 on HP-UX 11.23 IA64 fails.



The c compiler used for building the gcc 4.8.0 is gcc 4.5.2.

The last lines of output from make are:



g++  -DUSE_LIBUNWIND_EXCEPTIONS  -g -DIN_GCC   -fno-exceptions -fno-rtti

-fasynchronous-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual

-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros

-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -static-libstdc++

-static-libgcc -L/home/hendrik/gccgo1-HP-UX-B.11.23-ia64/lib

-L/home/hendrik/gccgo1-HP-UX-B.11.23-ia64/lib/hpux32 -o cc1 c/c-lang.o

c-family/stub-objc.o attribs.o c/c-errors.o c/c-decl.o c/c-typeck.o

c/c-convert.o c/c-aux-info.o c/c-objc-common.o c/c-parser.o c-family/c-common.o

c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o

c-family/c-gimplify.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o

c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o

c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o

tree-mudflap.o ia64-c.o default-c.o \

  cc1-checksum.o libbackend.a main.o tree-browser.o libcommon-target.a

libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a

../libcpp/libcpp.a ./../intl/libintl.a  ../libbacktrace/.libs/libbacktrace.a

../libiberty/libiberty.a ../libdecnumber/libdecnumber.a  

-L/home/hendrik/gccgo1-HP-UX-B.11.23-ia64/lib

-L/home/hendrik/gccgo1-HP-UX-B.11.23-ia64/lib

-L/home/hendrik/gccgo1-HP-UX-B.11.23-ia64/lib -lmpc -lmpfr -lgmp   -L../zlib

-lz

ld: Unsatisfied symbol "_Unwind_GetIPInfo" in file

../libbacktrace/.libs/libbacktrace.a[backtrace.o]

1 errors.

collect2: ld returned 1 exit status

make[3]: *** [cc1] Error 1

make[3]: Leaving directory

`/svnstore/unix/hendrik/git/gccgo/gccgo-build/build.HP-UX-B.11.23-ia64/gcc-4.8.0/host-ia64-hp-hpux11.23/gcc'

make[2]: *** [all-stage1-gcc] Error 2

make[2]: Leaving directory

`/svnstore/unix/hendrik/git/gccgo/gccgo-build/build.HP-UX-B.11.23-ia64/gcc-4.8.0'

make[1]: *** [stage1-bubble] Error 2

make[1]: Leaving directory

`/svnstore/unix/hendrik/git/gccgo/gccgo-build/build.HP-UX-B.11.23-ia64/gcc-4.8.0'

make: *** [all] Error 2

[Bug middle-end/56809] [4.9 Regression] Revision 197266 causes trunk ICE for arm-none-eabi targets

[ktkachov at gcc dot gnu.org]

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



ktkachov at gcc dot gnu.org changed:



   What|Removed |Added



 Target|arm-none-eabi,  |arm-none-eabi,

   |aarch64-none-elf|aarch64-none-elf,

   ||arm-none-linux-gnueabihf,

   ||arm-none-linux-gnueabi



--- Comment #3 from ktkachov at gcc dot gnu.org 2013-04-02 11:05:00 UTC ---

Also, r197266 causes arm-none-linux-gnueabi targets to fail building glibc

with:



/tmp/ccJoCcvx.s: Assembler messages:

/tmp/ccJoCcvx.s:79: Error: bad immediate value for offset (4228)

make[2]: *** [$SOURCE/build-linux/obj/glibc/stdio-common/vfwscanf.o] Error 1

make[2]: *** Waiting for unfinished jobs

/tmp/ccRTqSyv.s: Assembler messages:

/tmp/ccRTqSyv.s:47: Error: bad immediate value for offset (4556)

make[2]: *** [$SOURCE/build-linux/obj/glibc/stdio-common/vfscanf.o] Error 1

/tmp/ccxxOo62.s: Assembler messages:

/tmp/ccxxOo62.s:72: Error: bad immediate value for offset (4244)

/tmp/ccxxOo62.s:88: Error: bad immediate value for offset (4208)

/tmp/ccxxOo62.s:95: Error: bad immediate value for offset (4196)

/tmp/ccxxOo62.s:127: Error: bad immediate value for offset (4228)

make[2]: *** [$SOURCE/build-linux/obj/glibc/stdio-common/vfwscanf.os] Error 1

/tmp/ccuTrEWO.s: Assembler messages:

/tmp/ccuTrEWO.s:57: Error: bad immediate value for offset (4136)

/tmp/ccuTrEWO.s:79: Error: bad immediate value for offset (4104)

make[2]: *** [$SOURCE/build-linux/obj/glibc/stdio-common/vfscanf.os] Error 1

make[2]: Leaving directory `$SOURCE/glibc/libc/stdio-common'

make[1]: *** [stdio-common/subdir_lib] Error 2

make[1]: Leaving directory `$SOURCE/glibc/libc'

make: *** [all] Error 2

make: Leaving directory `$SOURCE/build-linux/obj/glibc

[Bug target/56771] Integer Overflow? Building arm-rtems libgcc2

[chris at contemporary dot net.au]

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



--- Comment #6 from Chris Johns  2013-04-02 
11:04:29 UTC ---

It looks to me like libcpp/configure.ac is not setting 'need_64bit_hwint' to

'yes'. It looks like the RTEMS ptch to change arm-rtems*eabi to arm-rtems*

needs to have this added.

[Bug c++/56768] [4.7] ICE in make_decl_rtl, at varasm.c:1147

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org

   |gnu.org |



--- Comment #4 from Richard Biener  2013-04-02 
10:40:26 UTC ---

I have a patch to backport.

[Bug libfortran/56810] New: record-repeat fails kind check on complex read

[jonathan.hogg at stfc dot ac.uk]

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



 Bug #: 56810

   Summary: record-repeat fails kind check on complex read

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: libfortran

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: jonathan.h...@stfc.ac.uk





The following code:

program test

   implicit none



   integer :: i

   complex :: a(4)



   read(*,*) a(:)

end program test



Fails at runtime with the following line of input:

4*(0.0,0.0)



It is fine with:

(0.0,0.0) (0.0,0.0) (0.0,0.0) (0.0,0.0)



Error message is:

$ gfortran -g -o bug bug.f90 && ./bug < bugdata 

At line 6 of file bug.f90 (unit = 5, file = 'stdin')

Fortran runtime error: Read kind 8 COMPLEX where kind 4 is required for item 2



Version:

$ gfortran -v

Using built-in specs.

COLLECT_GCC=gfortran

COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper

Target: x86_64-linux-gnu

Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro

4.7.2-4ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs

--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr

--program-suffix=-4.7 --enable-shared --enable-linker-build-id

--with-system-zlib --libexecdir=/usr/lib --without-included-gettext

--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7

--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu

--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object

--enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686

--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu

--host=x86_64-linux-gnu --target=x86_64-linux-gnu

Thread model: posix

gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-4ubuntu1)



Regards,



Jonathan.

[Bug c++/56768] [4.7] ICE in make_decl_rtl, at varasm.c:1147

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org



--- Comment #3 from Jakub Jelinek  2013-04-02 
10:11:25 UTC ---

http://gcc.gnu.org/r187593 fixed this on the trunk.

[Bug lto/56804] lto1: internal compiler error: bytecode stream: found non-null terminated string

[vchou79 at gmail dot com]

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



--- Comment #4 from Vincent  2013-04-02 09:45:29 UTC 
---

After rebuild all LTO objects the same happened.

[Bug middle-end/56809] [4.9 Regression] Revision 197266 causes trunk ICE for arm-none-eabi targets

[ktkachov at gcc dot gnu.org]

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



--- Comment #2 from ktkachov at gcc dot gnu.org 2013-04-02 09:43:57 UTC ---

Similar problem on aarch64-none-elf. The testcase produces this ICE with

aarch64-none-elf-gcc ice.c -S





ice.c:28:1: internal compiler error: in aarch64_output_casesi, at

config/aarch64/aarch64.c:4098

 }

 ^

0xb171fe aarch64_output_casesi(rtx_def**)

$SOURCE/gcc/gcc/config/aarch64/aarch64.c:4098

0x6b9579 final_scan_insn(rtx_def*, _IO_FILE*, int, int, int*)

$SOURCE/gcc/gcc/final.c:2854

0x6b9faf final(rtx_def*, _IO_FILE*, int)

$SOURCE/gcc/gcc/final.c:1958

0x6ba1d9 rest_of_handle_final

$SOURCE/gcc/gcc/final.c:4333

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/56809] [4.9 Regression] Revision 197266 causes trunk ICE for arm-none-eabi targets

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



  Component|c   |middle-end

   Target Milestone|--- |4.9.0

Summary|Revision 197266 causes  |[4.9 Regression] Revision

   |trunk ICE for arm-none-eabi |197266 causes trunk ICE for

   |targets |arm-none-eabi targets

[Bug lto/56804] lto1: internal compiler error: bytecode stream: found non-null terminated string

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Target||x86_64-w64-mingw32

 Status|UNCONFIRMED |WAITING

   Last reconfirmed||2013-04-02

 Ever Confirmed|0   |1



--- Comment #3 from Richard Biener  2013-04-02 
09:15:19 UTC ---

You need to re-build all LTO objects after the change.  Please make sure

that happened.

[Bug plugins/56795] gimple_seq_alloc and gimple_seq_free are still present in gcc-4.8's gimple.h

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-04-02

 CC||matz at gcc dot gnu.org

 Ever Confirmed|0   |1



--- Comment #1 from Richard Biener  2013-04-02 
09:11:48 UTC ---

Confirmed.

[Bug middle-end/56791] [4.8/4.9 Regression] Segmentation fault in stage2 gengenrtl -- Incorrect instruction sequence generated by reload

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Keywords||build, wrong-code

   Target Milestone|--- |4.8.1

Summary|Segmentation fault in   |[4.8/4.9 Regression]

   |stage2 gengenrtl -- |Segmentation fault in

   |Incorrect instruction   |stage2 gengenrtl --

   |sequence generated by   |Incorrect instruction

   |reload  |sequence generated by

   ||reload

[Bug tree-optimization/56790] VEC_COND_EXPR not constant folded

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-04-02

 Ever Confirmed|0   |1



--- Comment #1 from Richard Biener  2013-04-02 
09:10:14 UTC ---

Confirmed.

[Bug libfortran/56786] [4.6/4.7/4.8/4.9 Regression] Namelist read fails with designators containing embedded spaces

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Priority|P3  |P4

[Bug libstdc++/56779] [4.8/4.9 Regression] libstdc++.so: undefined reference to `libintl_textdomain'

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 CC||dnovillo at gcc dot gnu.org

   Target Milestone|--- |4.8.1

Summary|libstdc++.so: undefined |[4.8/4.9 Regression]

   |reference to|libstdc++.so: undefined

   |`libintl_textdomain'|reference to

   ||`libintl_textdomain'



--- Comment #1 from Richard Biener  2013-04-02 
09:05:57 UTC ---

Diego, this may be due to your patch as well.

[Bug tree-optimization/56778] [4.9 Regression] ICE on several benchmarks after r196775.

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Target Milestone|--- |4.9.0

Summary|ICE on several benchmarks   |[4.9 Regression] ICE on

   |after r196775.  |several benchmarks after

   ||r196775.

[Bug tree-optimization/56778] ICE on several benchmarks after r196775.

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2013-04-02

 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org

   |gnu.org |

 Ever Confirmed|0   |1



--- Comment #1 from Richard Biener  2013-04-02 
09:04:15 UTC ---

Confirmed.  I will have a look (there is a not properly removed stmt with

still has active immediate uses).

[Bug lto/56775] -flto and -fprofile-generate together result in a link-time internal compiler error (in "add_symbol_to_partition")

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |WAITING

   Last reconfirmed||2013-04-02

Version|unknown |4.8.0

 Ever Confirmed|0   |1



--- Comment #1 from Richard Biener  2013-04-02 
09:00:51 UTC ---

We need a testcase.

[Bug gcov-profile/56773] Programs crash if compiled with --coverage, although they run correctly without --coverage

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||INVALID



--- Comment #3 from Richard Biener  2013-04-02 
08:59:32 UTC ---

The code is indeed not valid.  Also happens with 4.6 for me, btw.

[Bug c++/56769] [4.7] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:2511

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||DUPLICATE



--- Comment #1 from Richard Biener  2013-04-02 
08:58:24 UTC ---

Yes, duplicate.



../../gcc47-g/gcc/cc1plus  -quiet t.ii -std=c++0x -O2

t.ii: In constructor 'M::M(const Container&)':

t.ii:36:1: error: PHI argument is not SSA_NAME, or invariant

PHI argument

retvalptr.7

for PHI node

b_10 = PHI 

t.ii:36:1: internal compiler error: verify_ssa failed

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.



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

[Bug c++/56768] [4.7] ICE in make_decl_rtl, at varasm.c:1147

[rguenth at gcc dot gnu.org]

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



--- Comment #2 from Richard Biener  2013-04-02 
08:58:24 UTC ---

*** Bug 56769 has been marked as a duplicate of this bug. ***

[Bug c++/56768] [4.7] ICE in make_decl_rtl, at varasm.c:1147

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-04-02

  Known to work||4.8.0

Version|unknown |4.7.3

 Ever Confirmed|0   |1

  Known to fail||4.7.2



--- Comment #1 from Richard Biener  2013-04-02 
08:57:27 UTC ---

Confirmed.  4.6 does not accept the testcase.



../../gcc47-g/gcc/cc1plus  -quiet t.ii -std=c++0x -O2

t.ii: In constructor 'M::M(const Container&)':

t.ii:36:1: error: PHI argument is not SSA_NAME, or invariant

PHI argument

retvalptr.4

for PHI node

b_10 = PHI 

t.ii:36:1: internal compiler error: verify_ssa failed

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.



this is inline transform going wrong.



Bisecting what fixed this would be nice.

[Bug other/28315] gcc doesn't use locale for default input charset

[bonzini at gnu dot org]

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



Paolo Bonzini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||WONTFIX



--- Comment #2 from Paolo Bonzini  2013-04-02 08:47:26 
UTC ---

It took me a while to reconstruct what that patch did, and I couldn't find

quickly the discussion about the hunk between me and Zack.



What I did find out was that GCC's configure at the time lacked

AM_LANGINFO_CODESET:



http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/configure.ac;h=45e5da59b7568804ce3a09551525acb3f43d9689;hb=d856c8a6



Hence that hunk was actually a no-op.



I agree with Laszlo's analysis, and I am closing this as WONTFIX.

[Bug c/51628] __attribute__((packed)) is unsafe in some cases

[rguenth at gcc dot gnu.org]

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



--- Comment #17 from Richard Biener  2013-04-02 
08:30:54 UTC ---

(In reply to comment #15)

> I believe the discussion here is missing the point. Currently (at least with

> version 4.5 and ARM, which I am currently using) the situation is that the

> compiler generates broken code WITHOUT COMMENT when the address of something

> like an integer in a packed structure is assigned to a int* . Since the 
> pointer

> type does not provide any information about the actual alignment of the

> integer, it is obviously impractical to fix when accessing the integer and we

> certainly do not want to have extra code inserted for handling the possibility

> that the int may not be aligned correctly. Therefore the compiler MUST see 
> this

> as a type conflict and at least warn that the address of the member in a 
> packed

> struct is incompatible with the pointer type.

> 

> I have several projects which require the use of packed structures and I 
> simply

> cannot rule out that that I have not at some point accidentally assigned the

> address of a member variable to a pointer. It would therefore be very handy if

> the compiler could point this out. -Wcast-align certainly doesn't do this.



Because there is no cast involved.  And that's because the types of the fields

are "wrong" as well.

[Bug c/51628] __attribute__((packed)) is unsafe in some cases

[rguenth at gcc dot gnu.org]

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



--- Comment #16 from Richard Biener  2013-04-02 
08:30:16 UTC ---

(In reply to comment #14)

> > What Ada does looks just like a workaround for what should be done properly 
> > in

> > the expander.  So no, IMHO we shouldn't be changing all other FEs and the

> > middle-end (when it wants to generate them e.g. for memcpy) to do what Ada

> > does, but we should change the expander.

> 

> Of course I have the exactly opposite viewpoint, since I think that we should

> keep the invariants we have: integral modes are naturally aligned and

> TYPE_ALIGN >= MODE_ALIGN (TYPE_MODE).  Breaking them for a few pathological

> cases that the C compiler has shun for years doesn't seem the best course of

> action.



Well.  I'm fine with forcing BLKmode for unaligned accesses, but not sure

if that is less invasive.  You'd basically have to change modes whenever

more precise knowledge about alignment appears ...