[Bug c++/57426] Application core dumps at __gnu_cxx::__exchange_and_add

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID
   Severity|major   |normal

--- Comment #1 from Andrew Pinski  ---
It is not __exchange_and_add which causing the abort but rather
TdrData::~TdrData which is not part of libstdc++ code.
__gnu_cxx::__exchange_and_add is inlined into TdrData::~TdrData which is why
gdb and the line numbers are a bit off for the abort.

[Bug c++/57426] Application core dumps at __gnu_cxx::__exchange_and_add

[rajagopal.maddi at plintron dot com]

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

--- Comment #2 from RajaGopal  ---
(In reply to Andrew Pinski from comment #1)
> It is not __exchange_and_add which causing the abort but rather
> TdrData::~TdrData which is not part of libstdc++ code.
> __gnu_cxx::__exchange_and_add is inlined into TdrData::~TdrData which is why
> gdb and the line numbers are a bit off for the abort.



The TdrData structure is as below:

#define TDR_COMMON_MAX_PARAMS10
#define TDR_APPLICATION_MAX_PARAMS   90

class TdrData
{
   public:
  string m_HDR[TDR_COMMON_MAX_PARAMS];
  string m_CDR[TDR_APPLICATION_MAX_PARAMS];
  TdrData();
  ~TdrData();

  void setChar(int , s8 );
  void setInteger(int , s32 );
  void setString(int , s8* );
  void setHex(int , s8* , u16 );

  //The functions below shall set the Header Data
  void setOpCode(u16 );
  void setMapVersion(u16 );
  void setRemoteAddr(s8* );
  void setTdrId();
  void setRemoteAddrSsn(int );
  void setOriginatingModule(char *);
  void setContextId(char *);
};

The TdrData constructor and destructor are defined as below:

TdrData::TdrData()
{
}

TdrData::~TdrData()
{
}


The following piece of code gets executed in the code multiple times. The m_tdr
is of type TdrData. m_tdr is newed at the application startup. The below code
gets executed at run-time almost once for processing a message. The system
dumps core upon the execution of the "delete(m_tdr)". Please let us know what
can be the issue.

if(NULL != m_tdr)
   delete(m_tdr);
m_tdr = new TdrData;

[Bug c++/57426] Application core dumps at __gnu_cxx::__exchange_and_add

[rajagopal.maddi at plintron dot com]

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

RajaGopal  changed:

   What|Removed |Added

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

--- Comment #3 from RajaGopal  ---
(In reply to Andrew Pinski from comment #1)
> It is not __exchange_and_add which causing the abort but rather
> TdrData::~TdrData which is not part of libstdc++ code.
> __gnu_cxx::__exchange_and_add is inlined into TdrData::~TdrData which is why
> gdb and the line numbers are a bit off for the abort.



The TdrData structure is as below:

#define TDR_COMMON_MAX_PARAMS10
#define TDR_APPLICATION_MAX_PARAMS   90

class TdrData
{
   public:
  string m_HDR[TDR_COMMON_MAX_PARAMS];
  string m_CDR[TDR_APPLICATION_MAX_PARAMS];
  TdrData();
  ~TdrData();

  void setChar(int , s8 );
  void setInteger(int , s32 );
  void setString(int , s8* );
  void setHex(int , s8* , u16 );

  //The functions below shall set the Header Data
  void setOpCode(u16 );
  void setMapVersion(u16 );
  void setRemoteAddr(s8* );
  void setTdrId();
  void setRemoteAddrSsn(int );
  void setOriginatingModule(char *);
  void setContextId(char *);
};

The TdrData constructor and destructor are defined as below:

TdrData::TdrData()
{
}

TdrData::~TdrData()
{
}


The following piece of code gets executed in the code multiple times. The m_tdr
is of type TdrData. m_tdr is newed at the application startup. The below code
gets executed at run-time almost once for processing a message. The system
dumps core upon the execution of the "delete(m_tdr)". Please let us know what
can be the issue.

if(NULL != m_tdr)
   delete(m_tdr);
m_tdr = new TdrData;

[Bug libstdc++/57426] Application core dumps at __gnu_cxx::__exchange_and_add

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2013-05-27
  Component|c++ |libstdc++
 Ever confirmed|0   |1

--- Comment #4 from Andrew Pinski  ---
Then it is string's string::~string which has the abort in it.

Can you try a newer version of GCC since 3.4.3 is no longer supported?

Also do you have any threads in your code?  If so are you sure you don't have
any non thread safe code?

Also are you sure you don't have any code which writes over an array length?

[Bug rtl-optimization/57425] [4.8/4.9 regression] RTL alias analysis unprepared to handle stack slot sharing

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-05-27
 CC||ebotcazou at gcc dot gnu.org
   Target Milestone|--- |4.8.1
Summary|RTL alias analysis  |[4.8/4.9 regression] RTL
   |unprepared to handle stack  |alias analysis unprepared
   |slot sharing|to handle stack slot
   ||sharing
 Ever confirmed|0   |1

--- Comment #3 from Eric Botcazou  ---
Confirmed, but the .172r.cse1 dump already looks suspicious to me.

[Bug tree-optimization/57343] [4.8/4.9 Regression] wrong code on x86_64-linux at -Os and above

[rguenther at suse dot de]

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

--- Comment #8 from rguenther at suse dot de  ---
On Fri, 24 May 2013, rakdver at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57343
> 
> --- Comment #7 from Zdenek Dvorak  ---
> (In reply to Richard Biener from comment #4)
> > We then fall to
> > 
> >   if (multiple_of_p (TREE_TYPE (c), c, s))
> > {
> >   /* If C is an exact multiple of S, then its value will be reached
> > before
> >  the induction variable overflows (unless the loop is exited in some
> >  other way before).  Note that the actual induction variable in the
> >  loop (which ranges from base to final instead of from 0 to C) may
> >  overflow, in which case BNDS.up will not be giving a correct upper
> >  bound on C; thus, BNDS_U_VALID had to be computed in advance.  */
> >   no_overflow = true;
> >   exit_must_be_taken = true;
> > 
> > which ends up with no_overflow = true and things going downhill from here.
> 
> This is the problem -- multiple_of_p claims that (var * 100) is a multiple of
> 100, which is not the case if the multiplication overflows.  I am not sure
> whether this is an expected behavior of multiple_of_p, or whether this could
> cause problems in its other uses.
> 
> A conservative fix here would be to replace the multiple_of_p test here by 
> some
> safer tests -- important special cases are:
> 1) both c and s are constants and c is a multiple of s
> 2) s = 1

Thanks.  I'll audit other uses of multiple_of_p to see whether the
current behavior is desired or a bug.

[Bug tree-optimization/57396] [4.8 Regression] Wrong code with -fpredictive-commoning in Fortran double-loop

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||4.9.0
   Target Milestone|4.7.4   |4.8.2
Summary|[4.8/4.9 Regression] Wrong  |[4.8 Regression] Wrong code
   |code with   |with -fpredictive-commoning
   |-fpredictive-commoning in   |in Fortran double-loop
   |Fortran double-loop |
  Known to fail|4.9.0   |4.8.1

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Mon May 27 07:48:37 2013
New Revision: 199350

URL: http://gcc.gnu.org/viewcvs?rev=199350&root=gcc&view=rev
Log:
2013-05-27  Richard Biener  

PR tree-optimization/57396
* tree-affine.c (double_int_constant_multiple_p): Properly
return false for val == 0 and div != 0.

* gfortran.fortran-torture/execute/pr57396.f90: New testcase.

Added:
trunk/gcc/testsuite/gfortran.fortran-torture/execute/pr57396.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-affine.c

[Bug tree-optimization/57398] [4.9 Regression] WRF and BWAVES miscompares with LTO

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug rtl-optimization/57425] [4.8/4.9 regression] RTL alias analysis unprepared to handle stack slot sharing

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Note that I only recently fixed a wrong alias query from using true_dependence
to anti_dependence.  Similar issues may exist elsewhere.

[Bug libstdc++/57426] Application core dumps at __gnu_cxx::__exchange_and_add

[rajagopal.maddi at plintron dot com]

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

--- Comment #5 from RajaGopal  ---
(In reply to Andrew Pinski from comment #4)
> Then it is string's string::~string which has the abort in it.
> 
> Can you try a newer version of GCC since 3.4.3 is no longer supported?
> 
> Also do you have any threads in your code?  If so are you sure you don't
> have any non thread safe code?
> 
> Also are you sure you don't have any code which writes over an array length?

Thanks Andrew for your feedback.

It's a huge application with several modules given with gcc 3.4.3 and is tough
to upgrade the compiler version for all these modules. We shall surely upgrade
in the near future.

There are threads in the code, but I am sure all the string operations are
performed by a single thread only.

As you see, m_HDR and m_CDR are the only attributes of the TdrData structure.
Both of these are string parameters and are capable of accepting any lengths.
Anyways, I checked the previous instantiation of the TdrData object was clean
and the parameters are cool. I am absolutely left with no clue why the
destruction of TdrData causes SIGSEGV.

Do you need any output from the dbx? If yes please let me know.

[Bug tree-optimization/57418] [4.9 Regression] Another verify_ssa failure

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||eraman at google dot com
  Component|c   |tree-optimization
   Target Milestone|--- |4.9.0
Summary|Another verify_ssa failure  |[4.9 Regression] Another
   ||verify_ssa failure

--- Comment #1 from Richard Biener  ---
Probably a dup.

[Bug tree-optimization/57417] [4.7/4.8/4.9 Regression] hang on volatile int array

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-05-27
  Component|rtl-optimization|tree-optimization
  Known to work||4.6.4
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |4.7.4
Summary|hang on volatile int array  |[4.7/4.8/4.9 Regression]
   ||hang on volatile int array
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Yeah, similar.  Mine.

[Bug c++/57416] internal compiler error: in gimple_expand_cfg, at cfgexpand.c:4575

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code

--- Comment #7 from Richard Biener  ---
Testcase still ICEs on the branch, errors on trunk.

[Bug middle-end/57412] [4.9 Regression] ICE: in verify_loop_structure, at cfgloop.c:1647: loop 1's latch does not have an edge to its header with -fopenmp -fipa-pure-const

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-05-27
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |4.9.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed, mine.

[Bug tree-optimization/57411] [4.9 Regression] ICE: verify_ssa failed: definition in block 4 does not dominate use in block 11 with -fno-tree-dce -ftree-vectorize

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-05-27
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |4.9.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed, mine.

[Bug rtl-optimization/57425] [4.8/4.9 regression] RTL alias analysis unprepared to handle stack slot sharing

[ebotcazou at gcc dot gnu.org]

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

--- Comment #5 from Eric Botcazou  ---
> Note that I only recently fixed a wrong alias query from using
> true_dependence to anti_dependence.  Similar issues may exist elsewhere.

That would point to cselib_invalidate_mem then.  It uses canon_true_dependence
but here we have an anti-dependence (WAR).

[Bug rtl-optimization/57410] [4.9 Regression] ICE: in emit_spill_move, at lra-constraints.c:863 with -fpeel-loops and uninitialised variable

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org
   Target Milestone|--- |4.9.0

[Bug tree-optimization/57407] Missing uninitialized warning following assert

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #3 from Richard Biener  ---
> gcc-4.6 -S t.c -O3 -Wall
t.c: In function 'main':
t.c:6:11: warning: 'e' is used uninitialized in this function [-Wuninitialized]
> gcc-4.7 -S t.c -O3 -Wall
t.c: In function 'main':
t.c:6:11: warning: 'e' is used uninitialized in this function [-Wuninitialized]
> gcc-4.8 -S t.c -O3 -Wall
t.c: In function 'main':
t.c:6:11: warning: 'e' is used uninitialized in this function [-Wuninitialized]
 printf("%d\n",e);
   ^

thus, works for me.

[Bug c++/57404] [4.9 Regression] [C++11] ICE: SIGSEGV in cp_classify_record with -g

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug c++/57402] [4.9 Regression] ICE: in make_decl_rtl, at varasm.c:1147 when initializing variable-sized array

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug tree-optimization/57400] ICE: verify_ssa failed (definition in block n follows the use)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||eraman at google dot com

--- Comment #1 from Richard Biener  ---
Probably a dup.

[Bug tree-optimization/57343] [4.8/4.9 Regression] wrong code on x86_64-linux at -Os and above

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
(In reply to rguent...@suse.de from comment #8)
> On Fri, 24 May 2013, rakdver at gcc dot gnu.org wrote:
> 
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57343
> > 
> > --- Comment #7 from Zdenek Dvorak  ---
> > (In reply to Richard Biener from comment #4)
> > > We then fall to
> > > 
> > >   if (multiple_of_p (TREE_TYPE (c), c, s))
> > > {
> > >   /* If C is an exact multiple of S, then its value will be reached
> > > before
> > >  the induction variable overflows (unless the loop is exited in 
> > > some
> > >  other way before).  Note that the actual induction variable in 
> > > the
> > >  loop (which ranges from base to final instead of from 0 to C) may
> > >  overflow, in which case BNDS.up will not be giving a correct 
> > > upper
> > >  bound on C; thus, BNDS_U_VALID had to be computed in advance.  */
> > >   no_overflow = true;
> > >   exit_must_be_taken = true;
> > > 
> > > which ends up with no_overflow = true and things going downhill from here.
> > 
> > This is the problem -- multiple_of_p claims that (var * 100) is a multiple 
> > of
> > 100, which is not the case if the multiplication overflows.  I am not sure
> > whether this is an expected behavior of multiple_of_p, or whether this could
> > cause problems in its other uses.
> > 
> > A conservative fix here would be to replace the multiple_of_p test here by 
> > some
> > safer tests -- important special cases are:
> > 1) both c and s are constants and c is a multiple of s
> > 2) s = 1
> 
> Thanks.  I'll audit other uses of multiple_of_p to see whether the
> current behavior is desired or a bug.

Most uses are ok, the extract_muldiv_1 use is questionable.  I'll fixup
the use in niter analysis like the following:

-  if (multiple_of_p (TREE_TYPE (c), c, s))
+  if (integer_onep (s)
+  || (TREE_CODE (c) == INTEGER_CST
+ && TREE_CODE (s) == INTEGER_CST
+ && tree_to_double_int (c).mod (tree_to_double_int (s),
+TYPE_UNSIGNED (type),
+EXACT_DIV_EXPR).is_zero ())
+  || (TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (c))
+ && multiple_of_p (type, c, s)))
 {

[Bug fortran/57423] Incorrect keyword argument names in Fortran OpenMP procedure interfaces in omp_lib

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Keywords||openmp
 CC||burnus at gcc dot gnu.org

--- Comment #1 from Tobias Burnus  ---
Author: burnus
Date: Mon May 27 09:28:48 2013
New Revision: 199351

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

PR fortran/57423
* libgomp.texi (omp_set_dynamic, omp_set_nested, omp_set_nested,
omp_set_num_threads, omp_init_lock, omp_set_lock, omp_test_lock,
omp_unset_lock, omp_destroy_lock, omp_init_nest_lock,
omp_set_nest_lock, omp_test_nest_lock, omp_unset_nest_lock,
omp_destroy_nest_lock): Correct arguments to match the one in
the OpenMP spec.
* omp_lib.f90.in (omp_init_lock, omp_init_nest_lock,  omp_destroy_lock
omp_destroy_nest_lock, omp_set_lock, omp_set_nest_lock, omp_unset_lock,
omp_unset_nest_lock, omp_set_dynamic, omp_set_nested,
omp_set_num_threads, omp_test_lock, omp_test_nest_lock): Ditto.


Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/libgomp.texi
trunk/libgomp/omp_lib.f90.in

[Bug fortran/57423] Incorrect keyword argument names in Fortran OpenMP procedure interfaces in omp_lib

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #2 from Tobias Burnus  ---
FIXED on the trunk (for GCC 4.9).

Thanks for the report!

[Bug tree-optimization/57417] [4.7/4.8/4.9 Regression] hang on volatile int array

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
The existing support for comparing addresses in operand_equal_p cannot handle
this as the volatile array is local.

It seems to me that there is no good reason to ever treat addresses of
TREE_SIDE_EFFECTS trees as different if there is not TREE_SIDE_EFFECTS
on offset determining pieces (though that would rely on gimplification
for COMPONENT_REFs?).

I wonder if this is the right time to introduce gimple_op_equal_p (),
wrapping operand_equal_p but handling a few cases less conservative...

[Bug c++/57427] New: ICE in gimplify_init_constructor

[y...@momonga-linux.org]

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

Bug ID: 57427
   Summary: ICE in gimplify_init_constructor
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: y...@momonga-linux.org

I found ICE with the following code;

$ cat test.cpp
struct A {
  A();
};
static const struct {
  A a;
} b[3] = {
};

$ g++-4.8 -c bug.cpp
bug.cpp: In function ‘void __static_initialization_and_destruction_0(int,
int)’:
bug.cpp:7:1: internal compiler error: in gimplify_init_constructor, at
gimplify.c:4269
 };
 ^

$ g++-4.8 -v 
Using built-in specs.
COLLECT_GCC=g++-4.8
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.8.0-7'
--with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
--with-system-zlib --enable-objc-gc --enable-multiarch --with-arch-32=i586
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --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.8.0 (Debian 4.8.0-7) 

It also ices with the following GCCs;
- gcc version 4.8.1 20130523
- gcc version 4.7.4 20130504

[Bug middle-end/57287] GCC 4.9.0 fails to build GDB on Ubuntu 12.04

[muhammad_bilal at mentor dot com]

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

hmb  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #12 from hmb  ---
I got enother error in gdb source code with same building step as I described
above:

/home/mbilal/gcc-svn/install/bin/gcc -save-temps -g -O2   -I. -I.././../src/gdb
-I.././../src/gdb/common -I.././../src/gdb/config
-DLOCALEDIR="\"/home/mbilal/gdb-git/gcc_install_bug_report/share/locale\""
-DHAVE_CONFIG_H -I.././../src/gdb/../include/opcode
-I.././../src/gdb/../opcodes/.. -I.././../src/gdb/../readline/.. -I../bfd
-I.././../src/gdb/../bfd -I.././../src/gdb/../include -I../libdecnumber
-I.././../src/gdb/../libdecnumber  -I.././../src/gdb/gnulib/import
-Ibuild-gnulib/import   -DTUI=1  -I/usr/include/python2.7
-I/usr/include/python2.7 -Wall -Wdeclaration-after-statement -Wpointer-arith
-Wpointer-sign -Wno-unused -Wunused-value -Wunused-function -Wno-switch
-Wno-char-subscripts -Wmissing-prototypes -Wdeclaration-after-statement
-Wempty-body -Wformat-nonliteral -Werror -c -o value.o -MT value.o -MMD -MP -MF
.deps/value.Tpo .././../src/gdb/value.c
.././../src/gdb/value.c: In function ‘show_convenience’:
.././../src/gdb/value.c:2247:21: error: ‘buf’ may be used uninitialized in this
function [-Werror=maybe-uninitialized]
   TRY_CATCH (ex, RETURN_MASK_ERROR)
 ^
cc1: all warnings being treated as errors
make[2]: *** [value.o] Error 1
make[2]: Leaving directory `/home/mbilal/gdb-git/gcc-obj_bug_report/gdb'
make[1]: *** [all-gdb] Error 2
make[1]: Leaving directory `/home/mbilal/gdb-git/gcc-obj_bug_report'
make: *** [all] Error 2

[Bug middle-end/57287] GCC 4.9.0 fails to build GDB on Ubuntu 12.04

[muhammad_bilal at mentor dot com]

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

--- Comment #13 from hmb  ---
Created attachment 30201
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30201&action=edit
preprocessed source code

Attaching the preprocessed source code

[Bug tree-optimization/57417] [4.7/4.8/4.9 Regression] hang on volatile int array

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Created attachment 30202
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30202&action=edit
prototype patch

Like the attached.

[Bug objc/57428] New: Objective C exceptions completely broken in gcc 4.7

[kostja.osipov at gmail dot com]

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

Bug ID: 57428
   Summary: Objective C exceptions completely broken in gcc 4.7
   Product: gcc
   Version: 4.7.3
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: objc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kostja.osipov at gmail dot com

/* Compile with: gcc gcc-objective-c-exceptions.m -fobjc-exceptions -o test
-lobjc */


#include 
#include 

#import 

@interface Object {
Class isa;
}
+ (id) alloc;
- (id) init;
- (void) free;
@end

@implementation Object
+ (id) alloc
{
return class_createInstance(self, 0);
}
- (id) init
{
return self;
}
- (void) free
{
object_dispose(self);
}
@end

@interface Frob: Object
@end

@implementation Frob: Object
@end

int proc() {
@throw [[Frob alloc] init];
}

int foo()
{
@try {
return proc();
}
@catch (Frob *) {
printf("Catch(Frob *)\n");
return 0;
}
@catch (Object *) {
printf("Catch(Object *)\n");
return 0;
}
@catch (id) {
printf("Catch(id)\n");
return 0;
}
}

int main(void)
{
foo();
return 0;
}



roman@work:~$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
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='Debian 4.7.2-5'
--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 --with-arch-32=i586 --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 (Debian 4.7.2-5)

roman@work:~$ gcc gcc-objective-c-exceptions.m -fobjc-exceptions -o test -lobjc
roman@work:~$ gdb ./test
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from test...(no debugging symbols found)...done.
(gdb) r
Starting program: test

Program received signal SIGSEGV, Segmentation fault.
__objc_responds_to (sel=, object=0x601340) at
/home/packages/gcc/4.7/w/gcc-4.7-4.7.2/src/libobjc/sendmsg.c:398
398 res = sarray_get_safe (dtable, (size_t) sel->sel_id);
(gdb) bt
#0 __objc_responds_to (sel=, object=0x601340) at
/home/packages/gcc/4.7/w/gcc-4.7-4.7.2/src/libobjc/sendmsg.c:398
#1 __objc_forward (object=0x601340, sel=0x6016a0, args=0x7fffe010) at
/home/packages/gcc/4.7/w/gcc-4.7-4.7.2/src/libobjc/sendmsg.c:905
#2 0x77bd24ed in __objc_word_forward (rcv=,
op=)
at /home/packages/gcc/4.7/w/gcc-4.7-4.7.2/src/libobjc/sendmsg.c:844
#3 0x00400a7c in proc ()
#4 0x00400ab0 in foo ()
#5 0x00400b1b in main ()

[Bug objc/57428] Objective C exceptions completely broken in gcc 4.7

[kostja.osipov at gmail dot com]

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

Konstantin Osipov  changed:

   What|Removed |Added

   Severity|blocker |critical

[Bug tree-optimization/57417] [4.7/4.8/4.9 Regression] hang on volatile int array

[ebotcazou at gcc dot gnu.org]

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

--- Comment #4 from Eric Botcazou  ---
> It seems to me that there is no good reason to ever treat addresses of
> TREE_SIDE_EFFECTS trees as different if there is not TREE_SIDE_EFFECTS
> on offset determining pieces (though that would rely on gimplification
> for COMPONENT_REFs?).

Yes, I agree that the handling of addresses looks overly conservative.

[Bug c++/57429] New: Dependent function call with one visible declaration, deleted

[potswa at mac dot com]

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

Bug ID: 57429
   Summary: Dependent function call with one visible declaration,
deleted
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: potswa at mac dot com

A dependent function call can't be resolved until instantiation time, but if
there's only one candidate visible from the template definition, that candidate
is accessed such as to produce an error if deleted, even if it would be
eliminated by the first stages of overload resolution.

Clang accepts this valid TU but GCC produces two errors. Also a good idea to
test in a SFINAE context, which is where this cropped up.

void f() = delete;

template< typename t >
void ft() { f( t() ); }

template< typename t >
struct ct { decltype( f( t() ) ) m; };

The workaround is to define another overload, which may also be deleted.

[Bug tree-optimization/57417] [4.7/4.8/4.9 Regression] hang on volatile int array

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de  ---
On Mon, 27 May 2013, ebotcazou at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57417
> 
> --- Comment #4 from Eric Botcazou  ---
> > It seems to me that there is no good reason to ever treat addresses of
> > TREE_SIDE_EFFECTS trees as different if there is not TREE_SIDE_EFFECTS
> > on offset determining pieces (though that would rely on gimplification
> > for COMPONENT_REFs?).
> 
> Yes, I agree that the handling of addresses looks overly conservative.

I suppose TREE_SIDE_EFFECTS matter on the offset expression of
a get_inner_reference call on op0 of the ADDR_EXPR.  For Ada that
would involve looking at SUBSTITUTE_PLACEHOLDER_IN_EXPR (DECL_FIELD_OFFSET 
(field), exp) for example - or do we somehow guarantee that the
offset expressions that do not appear in indexes like operand 1 of
ARRAY_REFs do not contain side-effects?

[Bug tree-optimization/57407] Missing uninitialized warning following assert

[stuff0003 at pobox dot com]

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

--- Comment #4 from Alex  ---
That's curious. It certainly doesn't work for me.

I wonder if it's possible that there is something wrong with subversion 4.6.3
(as opposed to version 4.6 tried above), or if Ubuntu/Linaro have somehow
introduced the problem when they ported it.

In any case, I'll take Andrew Pinski's suggestion and report it to Ubuntu. It
doesn't work for their current stable release, 12.04.

[Bug c/48088] -Werror=frame-larger-than=100 does not work as expected

[manu at gcc dot gnu.org]

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

--- Comment #6 from Manuel López-Ibáñez  ---
(In reply to Sergei Trofimovich from comment #5)
> Does it make sense to implement desired behaviour?

Probably not. We also don't accept two different values for
-Wframe-larger-than. But it would make sense to diagnose
-Werror=frame-larger-than=500 and only accept -Werror=frame-larger-than and
also fix the option printing issues.

[Bug tree-optimization/57430] New: Redundant move instruction is produced after function inlining

[ysrumyan at gmail dot com]

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

Bug ID: 57430
   Summary: Redundant move instruction is produced after function
inlining
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ysrumyan at gmail dot com

This is based on performance analysis of eembc2.0 suite on Atom processor in
comparison with clang compiler.

I prepared a simple reproducer that exhibits the issue.

Hottest loop (from function "remove") consists of 7 instructions if inlining
was applied:
.L48:
movl%edx, %ebp   <<--  it is redundant!!
movl%ecx, %edx
.L39:
cmpl%edx, %eax
je.L24
movl16(%edx), %ecx
testl%ecx, %ecx
jne.L48

but without inlining it consists of 6 instructions:

.L5:
cmpl%eax, %ecx
je.L4
movl%eax, %edx
.L7:
movl16(%edx), %eax
testl%eax, %eax
jne.L5

In result we can see performance drop on 4% (Atom 32-bit mode).

The reproducer will be attached.

[Bug tree-optimization/57430] Redundant move instruction is produced after function inlining

[ysrumyan at gmail dot com]

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

--- Comment #1 from Yuri Rumyantsev  ---
Created attachment 30203
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30203&action=edit
testcase

Need to compile with "-O2 -m32" options on x86.

[Bug target/57431] New: ICE in simplify_const_unary_operation vld1_dup_s64/vst1_s64

[christophe.lyon at st dot com]

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

Bug ID: 57431
   Summary: ICE in simplify_const_unary_operation
vld1_dup_s64/vst1_s64
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christophe.lyon at st dot com

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

The attached program makes GCC crash when using -O1, -O2 or -O3. Compiles fine
with -O0.

$ arm-none-linux-gnueabi-gcc -mcpu=cortex-a9 -mfloat-abi=softfp -mfpu=neon -O1
-c myref_vld1_dup.c
myref_vld1_dup.c: In function 'exec_vld1_dup':
myref_vld1_dup.c:16:1: internal compiler error: in
simplify_const_unary_operation, at simplify-rtx.c:1503
 }
 ^
0xa768aa simplify_const_unary_operation(rtx_code, machine_mode, rtx_def*,
machine_mode)
   
/work1/lyon/Work/ARM/Linaro/sources/gcc-fsf/trunk/gcc/simplify-rtx.c:1503
0xa743b4 simplify_unary_operation(rtx_code, machine_mode, rtx_def*,
machine_mode)
   
/work1/lyon/Work/ARM/Linaro/sources/gcc-fsf/trunk/gcc/simplify-rtx.c:791
0xffc467 fold_rtx
/work1/lyon/Work/ARM/Linaro/sources/gcc-fsf/trunk/gcc/cse.c:3287
0xfff4d0 cse_insn
/work1/lyon/Work/ARM/Linaro/sources/gcc-fsf/trunk/gcc/cse.c:4573
0x1004e2e cse_extended_basic_block
/work1/lyon/Work/ARM/Linaro/sources/gcc-fsf/trunk/gcc/cse.c:6405
0x10053ca cse_main
/work1/lyon/Work/ARM/Linaro/sources/gcc-fsf/trunk/gcc/cse.c:6583
0x10070b1 rest_of_handle_cse
/work1/lyon/Work/ARM/Linaro/sources/gcc-fsf/trunk/gcc/cse.c:7433

[Bug tree-optimization/57411] [4.9 Regression] ICE: verify_ssa failed: definition in block 4 does not dominate use in block 11 with -fno-tree-dce -ftree-vectorize

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
It's already DOM that breaks virtual SSA form by making life-ranges overlap
(something we do not verify ...)

  :
  # .MEM_14 = PHI <.MEM_9(3)>
  if (equal_4(D) != 0)
goto ;
  else
goto ;

  :
  # .MEM_5 = VDEF <.MEM_14>
  assert_fail ();

  :
  # .MEM_1 = PHI <.MEM_9(5), .MEM_5(6)>
  # VUSE <.MEM_1>
  return;

here .MEM_14 and .MEM_9 have overlapping life-ranges.

@@ -33,7 +50,7 @@
   assert_fail ();

   :
-  # .MEM_1 = PHI <.MEM_14(5), .MEM_5(6)>
+  # .MEM_1 = PHI <.MEM_9(5), .MEM_5(6)>
   # VUSE <.MEM_1>
   return;


It fails to update the

  # .MEM_5 = VDEF <.MEM_14>
  assert_fail ();

statement because it only walks over real operands when optimizing stmts
in cprop_into_stmt and because it refrains from

  /* Do not propagate copies if the propagated value is at a deeper loop
 depth than the propagatee.  Otherwise, this may move loop variant
 variables outside of their loops and prevent coalescing
 opportunities.  If the value was loop invariant, it will be hoisted
 by LICM and exposed for copy propagation.  */
  if (loop_depth_of_name (val) > loop_depth_of_name (op))
return;

thus it won't copyprop out the loop-closed PHI.

A simple solution is to never copy-propagate virtual operands if doing so
does not propagate into all uses.

[Bug bootstrap/57432] New: A mistake was appeared,when I build u-boot (arm-none-linux-gnueabi-gcc: Internal error: Bus error (program cc1))

[754550398 at qq dot com]

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

Bug ID: 57432
   Summary: A mistake was appeared,when I build u-boot
(arm-none-linux-gnueabi-gcc: Internal error: Bus error
(program cc1))
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 754550398 at qq dot com

Just like the Summary A mistake was appeared,when I build u-boot
(arm-none-linux-gnueabi-gcc: Internal error: Bus error (program cc1))
My gcc version is 4.4.3

[Bug c++/57433] New: Local classes have an associated namespace

[potswa at mac dot com]

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

Bug ID: 57433
   Summary: Local classes have an associated namespace
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: potswa at mac dot com

The example below should fail with access to a deleted function, but is
accepted by GCC 4.9. Clang correctly rejects it.

The issue is that [basic.lookup.argdep] §3.4.2/2 is defined in terms of
namespace membership, but a local class (such as a lambda) is not a member of a
namespace.

"If T is a class type (including unions), its associated classes are: the class
itself; the class of which it is a member, if any; and its direct and indirect
base classes. Its associated namespaces are the namespaces of which its
associated classes are members."


template< typename t, typename u >
void f( t, u ) = delete;

template< typename t >
void c( t o ) { f( o, 5 ); }

namespace n {
template< typename t >
void f( t, int ) {}

void p() { c( []{} ); }
}


For the sake of argument, the same Standardese forbids the following example
because n2 is only associated with n1, not s. None of its associated classes
are members of a namespace so it is not associated. Such behavior is
ridiculous. GCC and Clang accept this… it would be surprising if any
implementation didn't.

namespace n {
struct s { struct n1 { struct n2 {}; }; };
int f( s::n1::n2 ) { return 3; }
}
int i = f( n::s::n1::n2() );

[Bug tree-optimization/57417] [4.7/4.8 Regression] hang on volatile int array

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||4.9.0
Summary|[4.7/4.8/4.9 Regression]|[4.7/4.8 Regression] hang
   |hang on volatile int array  |on volatile int array
  Known to fail||4.8.1

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Mon May 27 12:44:29 2013
New Revision: 199356

URL: http://gcc.gnu.org/viewcvs?rev=199356&root=gcc&view=rev
Log:
2013-05-27  Richard Biener  

Revert
PR middle-end/57381
* fold-const.c (operand_equal_p): Compare FIELD_DECLs with
OEP_CONSTANT_ADDRESS_OF retained.

PR tree-optimization/57417
* tree-ssa-sccvn.c (vn_reference_fold_indirect): Fix test
for unchanged base.
(set_ssa_val_to): Compare addresses using
get_addr_base_and_unit_offset.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr57417.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-sccvn.c

[Bug tree-optimization/57343] [4.8 Regression] wrong code on x86_64-linux at -Os and above

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||4.9.0
   Target Milestone|4.8.1   |4.8.2
Summary|[4.8/4.9 Regression] wrong  |[4.8 Regression] wrong code
   |code on x86_64-linux at -Os |on x86_64-linux at -Os and
   |and above   |above
  Known to fail||4.8.1

--- Comment #10 from Richard Biener  ---
Author: rguenth
Date: Mon May 27 13:02:24 2013
New Revision: 199357

URL: http://gcc.gnu.org/viewcvs?rev=199357&root=gcc&view=rev
Log:
2013-05-27  Richard Biener  

PR tree-optimization/57343
* tree-ssa-loop-niter.c (number_of_iterations_ne_max): Do not
use multiple_of_p if not TYPE_OVERFLOW_UNDEFINED.
(number_of_iterations_cond): Do not build the folded tree.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr57343.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-niter.c

[Bug other/56183] [meta-bug][avr] Problems with register allocation

[amylaar at gcc dot gnu.org]

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

Bug 56183 depends on bug 56833, which changed state.

Bug 56833 Summary: [4.9 Regression] Valid register is over written by 
postreload pass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56833

   What|Removed |Added

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

[Bug rtl-optimization/56833] [4.9 Regression] Valid register is over written by postreload pass

[amylaar at gcc dot gnu.org]

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

Jorn Wolfgang Rennecke  changed:

   What|Removed |Added

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

--- Comment #4 from Jorn Wolfgang Rennecke  ---
http://gcc.gnu.org/ml/gcc-cvs/2013-05/msg00874.html
PR rtl-optimization/56833
* postreload.c (move2add_record_mode): New function.
(move2add_record_sym_value, move2add_valid_value_p): Likewise.
(move2add_use_add2_insn): Use move2add_record_sym_value.
(move2add_use_add3_insn): Likewise.
(reload_cse_move2add): Use move2add_valid_value_p and
move2add_record_mode.  Invalidate call-clobbered and REG_INC
affected regs by setting reg_mode to VOIDmode.
(move2add_note_store): Don't pretend the inside of a SUBREG is
the actual destination.  Invalidate single/leading registers by
setting reg_mode to VOIDmode.
Use move2add_record_sym_value, move2add_valid_value_p and
move2add_record_mode.

[Bug fortran/50405] allocation LOOP or SIGSEGV

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #2 from Tobias Burnus  ---
Author: burnus
Date: Mon May 27 14:16:36 2013
New Revision: 199358

URL: http://gcc.gnu.org/viewcvs?rev=199358&root=gcc&view=rev
Log:
2013-05-27  Bud Davis  

PR fortran/50405
* resolve.c (resolve_formal_arglist): Detect error when an
* argument
has the same name as the function.

2013-05-27  Bud Davis  

PR fortran/50405
* gfortran.dg/stfunc_8.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/stfunc_8.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/57434] New: [4.7 regression] -fprofile-arcs introduces unused TLS variables

[ro at gcc dot gnu.org]

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

Bug ID: 57434
   Summary: [4.7 regression] -fprofile-arcs introduces unused TLS
variables
   Product: gcc
   Version: 4.7.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: richard.guenther at gmail dot com
  Host: *-*-solaris2.[89]
Target: *-*-solaris2.[89]
 Build: *-*-solaris2.[89]

I only now noticed that several -fprofile-arcs testcases started to FAIL on
Solaris 8 and 9 with TLS support, e.g.

FAIL: gcc.misc-tests/gcov-1.c execution test
FAIL: gcc.misc-tests/gcov-1.c gcov failed: gcov-1.c.gov does not exist

The testcase tails to execute with

% gcc/xgcc -Bgcc/
/vol/gcc/src/hg/gcc-4.7-branch/solaris/gcc/testsuite/gcc.misc-tests/gcov-1.c
-fprofile-arcs -ftest-coverage -lm -o ./gcov-1.exe
% ./gcov-1.exe
ld.so.1: gcov-1.exe: fatal: gcov-1.exe: object requires TLS, but TLS failed to
initialize
Killed

A reghunt discovered that this is a regression introduced by this patch:

2012-09-11  Richard Guenther  

   PR debug/54534
   * cgraph.h (varpool_can_remove_if_no_refs): Restore dependence
   on flag_toplevel_reorder.

With it, gcov-1.s gains two unused definitions of TLS variables:

ro@luole 185 > diff -u 88*/*.s 
--- 880/gcov-1.s2013-05-27 16:07:38.106783000 +0200
+++ 881/gcov-1.s2013-05-27 16:07:32.227394000 +0200
@@ -70,10 +70,23 @@
.cfi_endproc
 .LFE1:
.size   main, .-main
+   .section.tbss,"awT",@nobits
+   .align 4
+   .type   __gcov_indirect_call_callee, @object
+   .size   __gcov_indirect_call_callee, 4
+__gcov_indirect_call_callee:
+   .zero   4
+   .align 4
+   .type   __gcov_indirect_call_counters, @object
+   .size   __gcov_indirect_call_counters, 4
+__gcov_indirect_call_counters:
+   .zero   4
.local  __gcov0.main
+   .bss
.comm   __gcov0.main,24,8
.comm   __gcov0.noop,8,8
+   .text
.type   _GLOBAL__sub_I_65535_0_noop, @function
 _GLOBAL__sub_I_65535_0_noop:
 .LFB2:

As a bad Solaris-specific hack, one could handle -fprofile-arcs like
-fprofile-generate in config/sol2.h LIB_SPEC and LINK_SPEC, but it would be
better to fix the underlying problem.

  Rainer
.local  __gcov0.noop

[Bug fortran/50405] allocation LOOP or SIGSEGV

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #3 from Tobias Burnus  ---
FIXED on the trunk (for GCC 4.9).

Thanks for the report!

[Bug middle-end/57434] [4.7 regression] -fprofile-arcs introduces unused TLS variables

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.4

[Bug middle-end/57434] [4.7 regression] -fprofile-arcs introduces unused TLS variables

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Working in 4.8 and 4.9?

[Bug middle-end/57434] [4.7 regression] -fprofile-arcs introduces unused TLS variables

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #1 from Richard Biener  ---
> Working in 4.8 and 4.9?

Working in both.

Rainer

[Bug middle-end/57366] gcc.dg/lto/attr-weakref-1 FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
I'd expect that: both the Solaris and Darwin assemblers have no weakref
support, so the results should be the same.

Rainer

[Bug fortran/57435] New: Ice on invalid: check_for_ambiguous

[bugs at stellardeath dot org]

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

Bug ID: 57435
   Summary: Ice on invalid: check_for_ambiguous
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugs at stellardeath dot org

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

When trying to reduce a test-case with "delta", I stumbled upon this
(unrelated) invalid code-snippet that triggers an ICE:

> cat gfortran_check_for_ambiguous.f90
> ~/sys/bin/gfortran gfortran_check_for_ambiguous.f90
gfortran_check_for_ambiguous.f90:4.15:

  use precision
   1
Error: Unexpected USE statement in CONTAINS section at (1)
gfortran_check_for_ambiguous.f90:5.19:

module stressten_rt
   1
Error: Unexpected MODULE statement in CONTAINS section at (1)
gfortran_check_for_ambiguous.f90:6.15:

  use precision
   1
Error: Unexpected USE statement in CONTAINS section at (1)
f951: internal compiler error: Segmentation fault
0x9b710f crash_signal
../.././gcc/toplev.c:333
0x5b4f13 check_for_ambiguous
../.././gcc/fortran/module.c:4535
0x5b4f13 read_module
../.././gcc/fortran/module.c:4731
0x5b4f13 gfc_use_module
../.././gcc/fortran/module.c:6406
0x5b73d3 gfc_use_modules()
../.././gcc/fortran/module.c:6530
0x5bc267 use_modules
../.././gcc/fortran/parse.c:86
0x5bdaf4 decode_statement
../.././gcc/fortran/parse.c:301
0x5bedf4 next_free
../.././gcc/fortran/parse.c:784
0x5bedf4 next_statement
../.././gcc/fortran/parse.c:977
0x5c165f parse_contained
../.././gcc/fortran/parse.c:4006
0x5c159e parse_progunit
../.././gcc/fortran/parse.c:4192
0x5c212a gfc_parse_file()
../.././gcc/fortran/parse.c:4597
0x5fe5a5 gfc_be_parse_file
../.././gcc/fortran/f95-lang.c:189
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
>


The gfortran version I used was a self-compiled version from trunk:

> ~/sys/bin/gfortran --version
GNU Fortran (GCC) 4.9.0 20130517 (experimental)
Copyright (C) 2013 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING


It also seems to trigger an ICE in 4.8.0, but behaves correctly in 4.7.2.

[Bug fortran/57435] Ice on invalid: check_for_ambiguous

[bugs at stellardeath dot org]

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

--- Comment #1 from Lorenz Hüdepohl  ---
Seems the output of "cat" got dropped, for those who do not want to look at the
attached file:

> cat gfortran_check_for_ambiguous.f90
module precision
end module precision
  contains
  use precision
module stressten_rt
  use precision
  implicit none
>

Ciao,
  Lorenz

[Bug fortran/57435] [4.8/4.9 Regression] Ice on invalid: check_for_ambiguous

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-05-27
Summary|Ice on invalid: |[4.8/4.9 Regression] Ice on
   |check_for_ambiguous |invalid:
   ||check_for_ambiguous
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Revision 194897 (2013-01-04) is OK, revision 195140 (2013-01-14) gives the ICE.

[Bug target/57432] A mistake was appeared,when I build u-boot (arm-none-linux-gnueabi-gcc: Internal error: Bus error (program cc1))

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|bootstrap   |target

--- Comment #1 from Andrew Pinski  ---
Can you provide the preprocessed source and even the options you using to
compile this specific source?  Also provide the output of
arm-none-linux-gnueabi-gcc -v.  Also try a newer version of GCC since 4.4.3 is
no longer supported.

[Bug fortran/57435] [4.8/4.9 Regression] Ice on invalid: check_for_ambiguous

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #3 from Dominique d'Humieres  ---
Likely due to revision 195065:

Program received signal SIGSEGV, Segmentation fault.
0x00010007279b in gfc_use_module (module=) at
../../work/gcc/fortran/module.c:4535
4535  if (st_sym->name == gfc_current_ns->proc_name->name)
(gdb) p st_sym->name
$1 = 0x14282a260 "precision"
(gdb) p gfc_current_ns->proc_name->name
Cannot access memory at address 0x0

[Bug c/57436] New: Linux kernel gives file system corruption when built with gcc 4.8.0

[a.radke at arcor dot de]

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

Bug ID: 57436
   Summary: Linux kernel gives file system corruption when built
with gcc 4.8.0
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: a.radke at arcor dot de

Our ArchLinux distribution gives sort of reproducable file system corruption
with all kernels built with gcc 4.8.0 (currently at snapshot 20130502). The
same kernel built with gcc 4.7.3 is stable. glibc is 2.17, binutils 2.23.2.
Architecture is x86_64. I'm testing only stable long term kernel 3.0.xx branch
but kernel 3.8 showed the same error.

Our default flags:
CPPFLAGS="-D_FORTIFY_SOURCE=2"
CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector
--param=ssp-buffer-size=4"
LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro"

The kernel builds well with gcc 4.8.0, the bug I'm running into is this: My
server running such a bad compiled kernel hosts a NFSv4 share on a XFS
formatted partition. On the same drive my dovecot imap server stores all mails.
When marking lots of small files on any fast client as read/unread the server
currupts the xfs file system with such messages:

imap(andyrtr):
Error:maildir_file_do(/mnt/share/andyrtr/Mail/.Mailinglisten.Linux-stable/cur/msg.MFVZBC:2,):
Filename keeps changing

Usually these are ACL related messages. After a reboot the related mail files
are sometimes gone and sometimes can be fixed with xfs_repair.

Any idea what this could be and how to track this down? It's a pretty nasty bug
in gcc it seems to me. I can provide further info if needed.

[Bug fortran/57435] [4.8/4.9 Regression] Ice on invalid: check_for_ambiguous

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
The following patch restores the 4.7 behavior:

--- ../_clean/gcc/fortran/module.c2013-04-17 12:21:20.0 +0200
+++ gcc/fortran/module.c2013-05-27 21:55:20.0 +0200
@@ -4532,7 +4532,7 @@ check_for_ambiguous (gfc_symbol *st_sym,
   module_locus locus;
   symbol_attribute attr;

-  if (st_sym->name == gfc_current_ns->proc_name->name)
+  if (gfc_current_ns->proc_name && st_sym->name ==
gfc_current_ns->proc_name->name)
 {
   gfc_error ("'%s' of module '%s', imported at %C, is also the name of the
"
  "current program unit", st_sym->name, module_name);

[Bug tree-optimization/57417] [4.7/4.8 Regression] hang on volatile int array

[ebotcazou at gcc dot gnu.org]

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

--- Comment #7 from Eric Botcazou  ---
> I suppose TREE_SIDE_EFFECTS matter on the offset expression of
> a get_inner_reference call on op0 of the ADDR_EXPR.  For Ada that
> would involve looking at SUBSTITUTE_PLACEHOLDER_IN_EXPR (DECL_FIELD_OFFSET 
> (field), exp) for example - or do we somehow guarantee that the
> offset expressions that do not appear in indexes like operand 1 of
> ARRAY_REFs do not contain side-effects?

No, we cannot guarantee that.  But AFAICS operand_equal_p rejects two
ADDR_EXPRs of the same expression when !OEP_ONLY_CONST only because it has
TREE_SIDE_EFFECTS and I don't see why, IOW my understanding is that it should
be possible to add a OEP_ADDRESS_OF flag when !OEP_ONLY_CONST and use it to be
less conservative.

[Bug c++/57437] New: C++11: mutable lambdas; gcc 4.7-4.8

[alxchk at alxchk dot me]

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

Bug ID: 57437
   Summary: C++11: mutable lambdas; gcc 4.7-4.8
   Product: gcc
   Version: 4.7.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alxchk at alxchk dot me

> cat test.cpp
#include 
#include 

int main(int argc, char *argv[])
{
  auto x = std::vector({1, 2, 3});

  auto y = [x] () 
mutable {
for (auto &i: x)
  i ++;
return x;
  };

  for (const auto &i: y())
std::cout << i << std::endl;

  for (const auto &i: y())
std::cout << i << std::endl;

  return 0;
}

> x86_64-pc-linux-gnu-g++-4.6.3 -o test test.cpp -std=gnu++0x
> ./test
2
3
4
3
4
5
> LC_ALL=C x86_64-pc-linux-gnu-g++-4.6.3 -v 
Using built-in specs.
COLLECT_GCC=x86_64-pc-linux-gnu-g++-4.6.3
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/portage/sys-devel/gcc-4.6.3/work/gcc-4.6.3/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.3
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-fixed-point --with-ppl --with-cloog --disable-ppl-version-check
--with-cloog-include=/usr/include/cloog-ppl --enable-lto --enable-nls
--without-included-gettext --with-system-zlib --enable-obsolete
--disable-werror --enable-secureplt --enable-multilib --enable-libmudflap
--disable-libssp --enable-esp --enable-libgomp
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/python
--enable-checking=release --disable-libgcj --enable-libstdcxx-time
--enable-languages=c,c++,objc,fortran --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo Hardened 4.6.3
p1.11, pie-0.5.2'
Thread model: posix
gcc version 4.6.3 (Gentoo Hardened 4.6.3 p1.11, pie-0.5.2)


> x86_64-pc-linux-gnu-g++-4.7.2 -o test2 test.cpp -std=gnu++0x 
> ./test2
2
3
4

> LC_ALL=C x86_64-pc-linux-gnu-g++-4.7.2 -v 
Using built-in specs.
COLLECT_GCC=x86_64-pc-linux-gnu-g++-4.7.2
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.2/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/portage/sys-devel/gcc-4.7.2-r1/work/gcc-4.7.2/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.7.2
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.2
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.2/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.2/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-fixed-point --with-ppl --with-cloog --disable-ppl-version-check
--with-cloog-include=/usr/include/cloog-ppl --enable-lto --enable-nls
--without-included-gettext --with-system-zlib --enable-obsolete
--disable-werror --enable-secureplt --enable-multilib
--with-multilib-list=m32,m64 --enable-libmudflap --disable-libssp --enable-esp
--enable-libgomp
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.7.2/python
--enable-checking=release --disable-libgcj --enable-libstdcxx-time
--enable-languages=c,c++,objc,fortran --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo Hardened
4.7.2-r1 p1.5, pie-0.5.5'
Thread model: posix
gcc version 4.7.2 (Gentoo Hardened 4.7.2-r1 p1.5, pie-0.5.5)

> x86_64-pc-linux-gnu-g++-4.8.0 -o test test.cpp -std=gnu++11
> ./test
2
3
4

> LC_ALL=C x86_64-pc-linux-gnu-g++-4.8.0 -v
Using built-in specs.
COLLECT_GCC=x86_64-pc-linux-gnu-g++-4.8.0
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/portage/sys-devel/gcc-4.8.0/work/gcc-4.8.0/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.0
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-fixed-point --with-ppl --with-cloog --disable-isl-version-check
--with-cloog --enable-lto --enable-nls --without-included-gettext
--with-system-zlib --enable-obsolete --disable-werror --enable-secureplt

[Bug bootstrap/57438] New: bootstrap fails on x86_64 darwin in stage2 linking cc1

[dhazeghi at yahoo dot com]

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

Bug ID: 57438
   Summary: bootstrap fails on x86_64 darwin in stage2 linking cc1
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dhazeghi at yahoo dot com

Created attachment 30206
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30206&action=edit
config.log.gz

As mentioned on gcc-help
(http://gcc.gnu.org/ml/gcc-help/2013-05/msg00120.html), bootstrap of gcc trunk
(and 4.8 as well) has been failing for me on x86_64-darwin.  System is running
OS X 10.8.3, with newest XCode 4.6.1 and associated tools.  I've run into the
problem on two different machines.

$ ../gcc-trunk/configure --enable-languages=c,c++,objc,obj-c++,fortran,lto
--disable-checking --prefix=/usr/local/gcc-trunk
$ make bootstrap-lean
...
/Users/dara/Downloads/objdir/./prev-gcc/xg++
-B/Users/dara/Downloads/objdir/./prev-gcc/
-B/usr/local/gcc-trunk/x86_64-apple-darwin12.3.0/bin/ -nostdinc++
-B/Users/dara/Downloads/objdir/prev-x86_64-apple-darwin12.3.0/libstdc++-v3/src/.libs
-B/Users/dara/Downloads/objdir/prev-x86_64-apple-darwin12.3.0/libstdc++-v3/libsupc++/.libs
-I/Users/dara/Downloads/objdir/prev-x86_64-apple-darwin12.3.0/libstdc++-v3/include/x86_64-apple-darwin12.3.0
-I/Users/dara/Downloads/objdir/prev-x86_64-apple-darwin12.3.0/libstdc++-v3/include
-I/Users/dara/Downloads/gcc-trunk/libstdc++-v3/libsupc++
-L/Users/dara/Downloads/objdir/prev-x86_64-apple-darwin12.3.0/libstdc++-v3/src/.libs
-L/Users/dara/Downloads/objdir/prev-x86_64-apple-darwin12.3.0/libstdc++-v3/libsupc++/.libs
  -g -O2 -mdynamic-no-pic -gtoggle -DIN_GCC   -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Werror   -DHAVE_CONFIG_H
-static-libstdc++ -static-libgcc -Wl,-no_pie -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 i386-c.o darwin-c.o \
  cc1-checksum.o libbackend.a main.o  libcommon-target.a libcommon.a
../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a
../libcpp/libcpp.a ./../intl/libintl.a -liconv 
../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a  -L/usr/local/gcc-trunk/lib -lcloog-isl
-L/usr/local/gcc-trunk/lib -lisl -L/usr/local/gcc-trunk/lib
-L/usr/local/gcc-trunk/lib -L/usr/local/gcc-trunk/lib -lmpc -lmpfr -lgmp  
-L../zlib -lz
0  0x102b49098  __assert_rtn + 144
1  0x102b60334 
mach_o::relocatable::Parser::parse(mach_o::relocatable::ParserOptions
const&) + 1044
2  0x102b4ff4b  mach_o::relocatable::Parser::parse(unsigned char
const*, unsigned long long, char const*, long, ld::File::Ordinal,
mach_o::relocatable::ParserOptions const&) + 313
3  0x102b4dadc  mach_o::relocatable::parse(unsigned char const*, unsigned long
long, char const*, long, ld::File::Ordinal, mach_o::relocatable::ParserOptions
const&) + 208
4  0x102b6f74c 
archive::File::makeObjectFileForMember(archive::File::Entry
const*) const + 794
5  0x102b6f261  archive::File::justInTimeforEachAtom(char const*,
ld::File::AtomHandler&) const + 139
6  0x102b7fb06  ld::tool::InputFiles::searchLibraries(char const*, bool, bool,
bool, ld::File::AtomHandler&) const + 210
7  0x102b86978  ld::tool::Resolver::resolveUndefines() + 200
8  0x102b888a3  ld::tool::Resolver::resolve() + 75
9  0x102b49380  main + 370
A linker snapshot was created at:
/tmp/cc1-2013-04-27-193733.ld-snapshot
ld: Assertion failed: (cfiStartsArray[i] != cfiStartsArray[i-1]), function
parse, file
/SourceCache/ld64/ld64-136/src/ld/parsers/macho_relocatable_file.cpp, line
1555.
collect2: error: ld returned 1 exit status
make[3]: *** [cc1] Error 1
make[2]: *** [all-stage2-gcc] Error 2
make[1]: *** [stage2-bubble] Error 2
make: *** [bootstrap-lean] Error 2

[Bug bootstrap/57438] bootstrap fails on x86_64 darwin in stage2 linking cc1

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
This seems better reported to Apple than here as it is Apple's provided ld that
is crashing.

[Bug middle-end/57436] Linux kernel gives file system corruption when built with gcc 4.8.0

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 CC||steven at gcc dot gnu.org

--- Comment #1 from Steven Bosscher  ---
(In reply to Andreas Radke from comment #0)
> Any idea what this could be and how to track this down? It's a pretty
> nasty bug in gcc it seems to me.

Jumping to conclusions like that isn't helpful (but unfortunately
typical for kernel folk): It *may* be a bug in gcc, but it may just
as well be a bug in the kernel. Relying on undefined behavior or
stuff like that.

Have you looked at some of the caveats in the GCC 4.8 relase notes?
(See http://gcc.gnu.org/gcc-4.8/changes.html).  The problem you're
seeing could be related to the aggressive loop optimizations that
GCC 4.8 has enabled.  You could try -fno-aggressive-loop-optimizations.
(IIRC it's enabled by default in recent linux kernel configurations,
but I'm not sure.)

Another common problem is alias violations. You could try compiling
with -Wstrict-aliasing=2 and see if there are any real alias rules
violations.

If that all fails, you could try compile individual files (or all of
XFS, perhaps) with -O1 or even just -O0, try to isolate the file that
causes the breakage, and start comparing assembly. All that, assuming
you have a file system you can repeatedly wreck, of course :-)

[Bug c++/57437] C++11: mutable lambdas; gcc 4.7-4.8

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
I can confirm the problem for my mingw-64-bit system using gcc 4.9.0 20130519
(experimental).

A variation of the program:

//-
#include 
#include 

int main()
{
  std::vector x{1, 2, 3};

  auto y = [x] () mutable {
for (auto &i: x)
  i++;
return x;
  };

  for (const auto &i : y()) {
std::cout << i << std::endl;
  }

  std::cout << "(1)" << std::endl;

  for (const auto &i : y()) {
std::cout << i << std::endl;
  }

  std::cout << "(2)" << std::endl;
}
//-

produces the output:

2
3
4
(1)
(2)

I *think* the following is going on here: The actual closure member x is
(incorrectly) considered as a local variable during RVO analysis, therefore the
first invocation invokes the move constructor on that member with the effect of
leaving an empty vector x within the closure.

The behavior looks incorrect to me: Neither 12.8 p31 b1 nor p32 can be applied
here, because x is neither a variable with automatic storage duration nor a
function parameter. It is correct the 5.1.2 p10 says 

"The identifier in a simple-capture is looked up using the usual rules for
unqualified name lookup (3.4.1); each such lookup shall find a variable with
automatic storage duration declared in the reaching scope of the local lambda
expression."

but this is an automatic variable *not* within the closure's function call
operator. And 5.1.2 p15

"For each entity captured by copy, an unnamed nonstatic data member is declared
in the closure type."

is clear that x is considered a data member within the closure and RVO shall
not be applied to it.