[Bug tree-optimization/61518] [4.10 Regression] wrong code (by tree vectorizer) at -O3 on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-06-16
 CC||jakub at gcc dot gnu.org,
   ||kyukhin at gcc dot gnu.org
   Target Milestone|--- |4.10.0
Summary|wrong code (by tree |[4.10 Regression] wrong
   |vectorizer) at -O3 on   |code (by tree vectorizer)
   |x86_64-linux-gnu|at -O3 on x86_64-linux-gnu
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r209972.

[Bug c++/61512] libstd++ postfix operator hangs

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
Invalid, do not increment a non-incrementable iterator.

[Bug tree-optimization/61517] [4.10 Regression] wrong code at -Os and above on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-06-16
 CC||jakub at gcc dot gnu.org,
   ||thopre01 at gcc dot gnu.org
   Target Milestone|--- |4.10.0
Summary|wrong code at -Os and above |[4.10 Regression] wrong
   |on x86_64-linux-gnu |code at -Os and above on
   ||x86_64-linux-gnu
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r210843.

[Bug libstdc++/61519] New: Seemingly incorrect vtable reference when libstdc++ built with RTTI

[matthew at theiselins dot net]

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

Bug ID: 61519
   Summary: Seemingly incorrect vtable reference when libstdc++
built with RTTI
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matthew at theiselins dot net

I have run into a problem today with a GCC toolchain and libstdc++ for a custom
OS target, and the x86_64 architecture (https://github.com/pcmattman/pedigree).
The problem is "solved" by building the toolchain and libstdc++ with -fno-rtti
(as the code paths inside libstdc++ are protected by preprocessor checks for
__GXX_RTTI).

GCC 4.8.2, with one patch applied:
https://github.com/pcmattman/pedigree/blob/develop/compilers/pedigree-gcc.patch
(adding the x86_64-pedigree target).

The behaviour seen is a segfault, which seems to be caused by an incorrect
vtable offset in __dynamic_cast. This segfault happens when running global
constructors when loading a program that pulls in global objects (a simple C++
Hello World is enough).

The basic trace is as follows:

1. libstdc++-v3/src/c++98/ios_init.cc:91

new (&cout) ostream(&buf_cout_sync);

1.5 ... basic_ios constructors ...

2. libstdc++-v3/include/bits/basic_ios.tcc:131

  // Cache locale data and specific facets used by iostreams.
  _M_cache_locale(_M_ios_locale);

3. libstdc++-v3/include/bits/basic_ios.tcc:155

  template
void
basic_ios<_CharT, _Traits>::_M_cache_locale(const locale& __loc)
{
  if (__builtin_expect(has_facet<__ctype_type>(__loc), true)) // <--
_M_ctype = &use_facet<__ctype_type>(__loc);


4. libstdc++-v3/include/bits/locale_classes.tcc:102

  template
bool
has_facet(const locale& __loc) throw()
{
  const size_t __i = _Facet::id._M_id();
  const locale::facet** __facets = __loc._M_impl->_M_facets;
  return (__i < __loc._M_impl->_M_facets_size
#ifdef __GXX_RTTI
  && dynamic_cast(__facets[__i])); // <--
#else
  && static_cast(__facets[__i]));
#endif
}

5. libstdc++-v3/libsupc++/dyncast.cc:59

  whole_type->__do_dyncast (src2dst, __class_type_info::__contained_public,
dst_type, whole_ptr, src_type, src_ptr, result);

6: libstdc++-v3/libsupc++/class_type_info.cc:45

  bool __class_type_info::
  __do_upcast (const __class_type_info *dst_type,
   void **obj_ptr) const
  {
__upcast_result result (__vmi_class_type_info::__flags_unknown_mask);

__do_upcast (dst_type, *obj_ptr, result); // <--
if (!contained_public_p (result.part2dst))
  return false;
*obj_ptr = const_cast  (result.dst_ptr);
return true;
  }



For the 'whole_type->__do_dyncast' call, the following is the case (registers
adjusted for shared object base, 'nm' and 'c++filt' output added):

vtable for whole_type RAX 0x2a7d80
002a7d80 V _ZTVN10__cxxabiv121__vmi_class_type_infoE [Vtable for
__cxxabiv1::__vmi_class_type_info]

whole_type RDI 0x2a7e80
002a7e80 V _ZTISt5ctypeIcE [typeinfo for std::ctype]

src2dst RSI 0

__class_type_info::__contained_public RDX 0x6

dst_type RCX 0x2a7e80
002a7e80 V _ZTISt5ctypeIcE [typeinfo for std::ctype]

whole_ptr R8  0x2ae6a0
002ae6a0 b _ZN12_GLOBAL__N_17ctype_cE [(anonymous namespace)::ctype_c]

src_type R9  0x2a7fb0
002a7fb0 V _ZTINSt6locale5facetE [typeinfo for std::locale::facet]

Disassembly:
   42bd4:   ff 50 38callq  *0x38(%rax)

Looking at the vtable (via -fdump-class-hierarchy), it seems offset 0x38 is a
__do_upcast, not __do_dyncast.

Vtable for __cxxabiv1::__vmi_class_type_info
__cxxabiv1::__vmi_class_type_info::_ZTVN10__cxxabiv121__vmi_class_type_infoE:
11u entries
0 (int (*)(...))0
8 (int (*)(...))(& _ZTIN10__cxxabiv121__vmi_class_type_infoE)
16(int (*)(...))__cxxabiv1::__vmi_class_type_info::~__vmi_class_type_info
24(int (*)(...))__cxxabiv1::__vmi_class_type_info::~__vmi_class_type_info
32(int (*)(...))std::type_info::__is_pointer_p
40(int (*)(...))std::type_info::__is_function_p
48(int (*)(...))__cxxabiv1::__class_type_info::__do_catch
56(int (*)(...))__cxxabiv1::__class_type_info::__do_upcast
64(int (*)(...))__cxxabiv1::__vmi_class_type_info::__do_upcast
72(int (*)(...))__cxxabiv1::__vmi_class_type_info::__do_dyncast
80(int (*)(...))__cxxabiv1::__vmi_class_type_info::__do_find_public_src

The segfault takes place when __do_upcast attempts to dereference obj_ptr,
because obj_ptr == (void **) 6.

I'm not completely sure where to begin looking on this. I have a temporary
workaround, as mentioned, but would be interested in determining what happened
here.

The ideal outcome would be to be able to build libstdc++ without -fno-rtti,
without running into this segfault in programs linked against it.

[Bug regression/61516] [4.10 Regression]: build fails on auto-inc-dec.c or libgcc2.c with obvious patch

[rsandifo at gcc dot gnu.org]

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

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Mon Jun 16 07:40:17 2014
New Revision: 211694

URL: https://gcc.gnu.org/viewcvs?rev=211694&root=gcc&view=rev
Log:
gcc/
PR bootstrap/61516
* auto-inc-dec.c (merge_in_block): Fix location of insn_info
initialization.  Replace remaining use of uid.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/auto-inc-dec.c

[Bug regression/61516] [4.10 Regression]: build fails on auto-inc-dec.c or libgcc2.c with obvious patch

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

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

[Bug sanitizer/61475] Building Firefox with ASan is broken in the packaging step

[kcc at gcc dot gnu.org]

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

--- Comment #6 from Kostya Serebryany  ---
So, clang trunk works and gcc trunk fails, right? 
Could be a miscompile by GCC.
I'd suggest to find the guilty module somehow (e.g. build all modules w/ and
w/o asan and then mix them in different proportions until you have just 
one asan-ified module and FF still fails).

(I may not get to reproducing this myself any time soon, sorry)

[Bug plugins/45078] config/vxworks-dummy.h not installed as a plugin header on some archs

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Mon Jun 16 08:12:40 2014
New Revision: 211696

URL: https://gcc.gnu.org/viewcvs?rev=211696&root=gcc&view=rev
Log:
PR plugins/45078
* config.gcc (arm*-*-linux-*): Include vxworks-dummy.h in tm_file.

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

[Bug tree-optimization/61511] [4.10 Regression] ICE: in vect_can_force_dr_alignment_p, at tree-vect-data-refs.c:5320 with -fno-toplevel-reorder -ftree-slp-vectorize

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-06-16
 CC||hubicka at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org
   Target Milestone|--- |4.10.0
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r211599.

[Bug plugins/45078] config/vxworks-dummy.h not installed as a plugin header on some archs

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Mon Jun 16 08:15:35 2014
New Revision: 211697

URL: https://gcc.gnu.org/viewcvs?rev=211697&root=gcc&view=rev
Log:
PR plugins/45078
* config.gcc (arm*-*-linux-*): Include vxworks-dummy.h in tm_file.

Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config.gcc

[Bug sanitizer/61475] Building Firefox with ASan is broken in the packaging step

[y.gribov at samsung dot com]

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

--- Comment #7 from Yury Gribov  ---
Have you tried patch proposed in bug 61422?

[Bug tree-optimization/61518] [4.10 Regression] wrong code (by tree vectorizer) at -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Priority|P3  |P1

[Bug tree-optimization/61517] [4.10 Regression] wrong code at -Os and above on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Priority|P3  |P1

[Bug regression/61516] [4.10 Regression]: build fails on auto-inc-dec.c or libgcc2.c with obvious patch

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.10.0

[Bug tree-optimization/61515] Extremely long compile time for generated code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||compile-time-hog,
   ||memory-hog
 CC||rguenth at gcc dot gnu.org

--- Comment #4 from Richard Biener  ---
Also seems to use a lot of memory, even at -O0 with 4.9.  Let's see if I can
find
a machine with enough memory to do some comparisons.

[Bug tree-optimization/61511] [4.10 Regression] ICE: in vect_can_force_dr_alignment_p, at tree-vect-data-refs.c:5320 with -fno-toplevel-reorder -ftree-slp-vectorize

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #2 from Jan Hubicka  ---
Mine.

[Bug regression/61510] [4.10 Regression]: 20_util/scoped_allocator/requirements/explicit_instantiation.cc and tr1/6_containers/tuple/requirements/explicit_instantiation.cc

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Version|4.7.0   |4.10.0
   Target Milestone|--- |4.10.0

[Bug rtl-optimization/61509] GCC miscompilation on ARM during RTL optimization when compiled with -O2

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Still waiting for reporter to try a still supported compiler which would be
GCC 4.8.3 or 4.9.0.

[Bug bootstrap/61508] [4.10 regression] fold-const.c:14863:55: error: cannot convert 'const char*' to 'const_tree

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.10.0

[Bug target/61506] [4.10 Regression] ICE triggered by solution to #61446

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*
  Component|c++ |target
   Target Milestone|--- |4.10.0
Summary|ICE [4.10 Regression]   |[4.10 Regression] ICE
   |triggered by solution to|triggered by solution to
   |#61446  |#61446

[Bug tree-optimization/61482] [4.10 regression] ICE in set_value_range, at tree-vrp.c:453 when compiling Firefox ESR 24

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #8 from Richard Biener  ---
I'll have a look.

[Bug bootstrap/61388] [4.8 Regression] linux/microblaze fails to build: undefined machine-specific constraint at this point: "Q"

[nmekala at xilinx dot com]

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

Nagaraju Mekala  changed:

   What|Removed |Added

 CC||nmekala at xilinx dot com

--- Comment #4 from Nagaraju Mekala  ---
I have checked it with 4.9.0 and it is working fine for me.
As indicated by Mike constraint "Q" is already defined in constraint.md file.

Can you please share the GCC version and the configuration option that you are
using to build.

[Bug tree-optimization/61517] [4.10 Regression] wrong code at -Os and above on x86_64-linux-gnu

[thopre01 at gcc dot gnu.org]

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

--- Comment #2 from thopre01 at gcc dot gnu.org ---
I already got a patch for that which is currently under test. I checked against
this particular testcase and it indeed solves the problem. I'll add the
testcase to the patch and hopefully post something tomorrow or before.

[Bug middle-end/61430] [4.10 regression] ICE in lra_create_copy

[christophe.lyon at st dot com]

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

--- Comment #4 from christophe.lyon at st dot com ---
Since commit 211625:
2014-06-13  Richard Biener  

* tree-ssa-pre.c (eliminate_dom_walker::before_dom_children):
Rewrite to propagate the VN result into all uses where
possible and to remove stmts becoming dead because of that.
(eliminate): Generalize stmt removal handling, remove in
reverse dominator order to support proper debug stmt
generation.  Update stmts before removing stmts.
* tree-ssa-propagate.c (propagate_tree_value): Remove
bogus assert.

The same error now appears when building other GCC configurations:
--target   mode --with-cpu  --with-fpu
arm-none-linux-gnueabiarm cortex-a9 default
arm-none-linux-gnueabihf   arm cortex-a9 neon-fp16
arm-none-linux-gnueabihf   arm cortex-a9 vfp
arm-none-linux-gnueabihf   arm cortex-a15 neon-vfpv4
armeb-none-linux-gnueabihf arm cortex-a9 neon-fp16

Vladimir, can you have a look?

[Bug tree-optimization/61515] Extremely long compile time for generated code

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
4.8 and 4.9 at -O0 take ~32s and ~2.4GB of ram (and IRA taking 28% of the time)
4.8 at -O1 takes ~15min and ~5.5GB of ram (RTL loop invariant motion taking 80%
of the time - ugh)
4.9 at -O1 takes ~5min and ~2GB of ram (30% compile time in SSA incremental,
27% in DF)

Now -O[s2] will enable passes that are not really "tamed" and may show
quadratic behavior (PRE and VRP for example, off the top of my head).  You're
supposed to drop to -O1 whenever you hit this kind of bug ...

Building release checking trunk now.

[Bug tree-optimization/61515] Extremely long compile time for generated code

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
4.9 at -Os takes 5min and ~2.2GB of ram (points-to takes 20%, DF 33%)

[Bug middle-end/61430] [4.10 regression] ICE in lra_create_copy

[jgreenhalgh at gcc dot gnu.org]

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

jgreenhalgh at gcc dot gnu.org changed:

   What|Removed |Added

 CC||jgreenhalgh at gcc dot gnu.org

--- Comment #5 from jgreenhalgh at gcc dot gnu.org ---
This looks like:
  https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00971.html

Which has been approved by Vladimir. I guess if I don't hear anything from
Chung-Lin in the next few hours I'll commit this on their behalf.

[Bug middle-end/61430] [4.10 regression] ICE in lra_create_copy

[cltang at gcc dot gnu.org]

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

--- Comment #6 from Chung-Lin Tang  ---
Author: cltang
Date: Mon Jun 16 09:58:34 2014
New Revision: 211701

URL: https://gcc.gnu.org/viewcvs?rev=211701&root=gcc&view=rev
Log:
2014-06-16  Chung-Lin Tang  

PR middle-end/61430
* lra-lives.c (process_bb_lives): Skip creating copy during
insn scan when src/dest has constrained to same regno.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-lives.c

[Bug fortran/34500] Bind(C): Character returning function with ENTRY gives ICE

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

   Keywords||rejects-valid
 CC||fxcoudert at gcc dot gnu.org

--- Comment #3 from Francois-Xavier Coudert  ---
Since 4.9, the code is now rejected (though it's valid):

$ gfortran a.f90
a.f90:4.43:

  character(len=1,kind=c_char) :: test, bar
   1
a.f90:5.9:

entry bar() bind(C)
 2
Error: Procedure bar with binding label bar at (1) uses the same global
identifier as entity at (2)

[Bug sanitizer/61408] r205695 breaks packaging step of Firefox 24 ESR on Ubuntu Lucid building with ASan

[gk at torproject dot org]

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

--- Comment #11 from Georg Koppen  ---
Working around was tricky, so I started bisecting LLVM/clang/compiler-rt. The
first bad revision there is r193602. Might be worth filing an upstream bug (I
don't have a Google account), I guess.

[Bug fortran/34500] Bind(C): Character returning function with ENTRY gives ICE

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
> Since 4.9, the code is now rejected (though it's valid): ...

The change occurred between r199034 (ICE, 2013-05-17) and r199221 (error,
2013-05-22).
I suspect r199120 (pr48858 and pr55465), although r199118 and r199119 are also
candidates.

[Bug tree-optimization/61515] [4.10 Regression] Extremely long compile time for generated code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-06-16
 CC||law at gcc dot gnu.org
Version|unknown |4.10.0
   Target Milestone|--- |4.10.0
Summary|Extremely long compile time |[4.10 Regression] Extremely
   |for generated code  |long compile time for
   ||generated code
 Ever confirmed|0   |1

--- Comment #7 from Richard Biener  ---
(In reply to Richard Biener from comment #6)
> 4.9 at -Os takes 5min and ~2.2GB of ram (points-to takes 20%, DF 33%)

trunk at -Os takes 15min and ~2.1GB of ram (dominator optimization takes 67%)

trunk at -O1 takes 14min and ~2GB of ram (still DOM at 62%)

So it seems that on trunk DOM regressed a lot.  Confirmed as 4.10 regression.

[Bug sanitizer/61408] r205695 breaks packaging step of Firefox 24 ESR on Ubuntu Lucid building with ASan

[kcc at gcc dot gnu.org]

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

--- Comment #12 from Kostya Serebryany  ---
I am not sure what does your bisection of LLVM/clang/compiler-rt mean
if you say that clang trunk works fine.

[Bug sanitizer/61408] r205695 breaks packaging step of Firefox 24 ESR on Ubuntu Lucid building with ASan

[gk at torproject dot org]

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

--- Comment #13 from Georg Koppen  ---
(In reply to Kostya Serebryany from comment #12)
> I am not sure what does your bisection of LLVM/clang/compiler-rt mean
> if you say that clang trunk works fine.

There are two different issues here in this bug: one got moved to bug 61475 and
*there* clang trunk is working fine. BUT for the original issue mentioned in
this bug trunk is *not* working. See comment 8 above. I was referring to that
comment when I talked about the bisection in my last comment. Anyway, I backed
out the corresponding code parts in my GCC 4.9.0 and now everything is working
when I am compiling with GCC 4.9.0 on Ubuntu Lucid.

[Bug c++/61500] [C++11] [4.8/4.9 Regression] Can't take pointer to member referenced via member pointer template parameter.

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Mon Jun 16 11:45:37 2014
New Revision: 211703

URL: https://gcc.gnu.org/viewcvs?rev=211703&root=gcc&view=rev
Log:
PR c++/61500
* tree.c (lvalue_kind): Handle MEMBER_REF and DOTSTAR_EXPR.

Added:
trunk/gcc/testsuite/g++.dg/template/ptrmem27.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/tree.c

[Bug c++/61488] [4.9/4.10 regression] Regression in template argument substitution in 4.9+

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Mon Jun 16 11:50:14 2014
New Revision: 211704

URL: https://gcc.gnu.org/viewcvs?rev=211704&root=gcc&view=rev
Log:
PR c++/61488
* pt.c (check_valid_ptrmem_cst_expr): Fix for template context.

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

[Bug c/60439] No warning for case overflow in switch statement.

[mpolacek at gcc dot gnu.org]

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

--- Comment #13 from Marek Polacek  ---
Author: mpolacek
Date: Mon Jun 16 12:38:07 2014
New Revision: 211707

URL: https://gcc.gnu.org/viewcvs?rev=211707&root=gcc&view=rev
Log:
PR c/60439
* c.opt (Wswitch-bool): Add Var.

Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c.opt

[Bug tree-optimization/61518] [4.10 Regression] wrong code (by tree vectorizer) at -O3 on x86_64-linux-gnu

[ysrumyan at gmail dot com]

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

Yuri Rumyantsev  changed:

   What|Removed |Added

 CC||ysrumyan at gmail dot com

--- Comment #2 from Yuri Rumyantsev  ---
This is my fault - forgot to check that reduction variable is used in reduction
statement or in phi-function only. I will provide a patch after required
testing completion.

[Bug rtl-optimization/54555] (set (REGX) (CONST_INT B)) -> (set (STRICT_LOW_PART (REGX)) (CONST_INT B)) is pessimising

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

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

--- Comment #1 from Andreas Schwab  ---
Introduced in r63426.

[Bug c/61520] New: False warning: array subscript is below array bounds (-Warray-bounds -O -ftree-vrp -funroll-loops)

[svojtovich at gmail dot com]

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

Bug ID: 61520
   Summary: False warning: array subscript is below array bounds
(-Warray-bounds -O -ftree-vrp -funroll-loops)
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: svojtovich at gmail dot com

gcc emits false warning for the following code:

gcc -Warray-bounds -O -ftree-vrp -funroll-loops -c dec.c -o dec.o
or gcc -Warray-bounds -O3 -c dec.c -o dec.o

static const int powers10[2 + 1]= { 1, 10, 100 };

int remove_leading_zeroes(int decimals, int var)
{
  decimals%= 2;
  while (var < powers10[decimals--]) /* no-op */;
  return decimals;
}

This is simplified code, original code is available here:
http://bazaar.launchpad.net/~maria-captains/maria/10.0/view/head:/strings/decimal.c#L251

Note that original code ensures (within the same function) that array subscript
won't underrun array bounds.

4.8.2 seem to be also affected, look for compile results for decimal.c:
https://buildbot.askmonty.org/buildbot/builders/kvm-deb-trusty-amd64/builds/261/steps/compile/logs/stdio

[Bug c++/61512] libstd++ postfix operator hangs

[srohit.pda at gmail dot com]

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

--- Comment #5 from Rohit Sharma  ---
Thank you Marc for the flag.

Compiling with that flag and running it, code "abort (core dumped)" - which I
take is reasonable behavior on a bad code.

bests.
-Rohit

[Bug middle-end/61521] New: [4.10 regression] build broken after LRA patch

[christophe.lyon at st dot com]

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

Bug ID: 61521
   Summary: [4.10 regression] build broken after LRA patch
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christophe.lyon at st dot com

Hello,

Commit 211655:
2014-06-13  Vladimir Makarov  

* lra-assign.c (assign_by_spills): Add code to assign vector regs
to inheritance pseudos.
* config/i386/i386.c (ix86_spill_class): Add check on NO_REGS.

causes GCC trunk to fail to build on ARM & AArch64 targets.

See https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01146.html for more details.

[Bug rtl-optimization/61521] [4.10 regression] build broken after LRA patch

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||build, ra
 Target||arm, aarch64
   Priority|P3  |P1
  Component|middle-end  |rtl-optimization
   Target Milestone|--- |4.10.0

[Bug rtl-optimization/61522] New: [4.10 regression] ICE while building libgcc in LRA

[ramana at gcc dot gnu.org]

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

Bug ID: 61522
   Summary: [4.10 regression] ICE while building libgcc in LRA
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ramana at gcc dot gnu.org

./cc1 -O2 -march=armv7-a fixed-bit.i

#0  0x in ?? ()
#1  0x0052b152 in assign_by_spills () at /work/gcc/gcc/lra-assigns.c:1434
#2  0x0052b3b6 in lra_assign () at /work/gcc/gcc/lra-assigns.c:1499
#3  0x0052631c in lra (f=0x0) at /work/gcc/gcc/lra.c:2230
#4  0x004e6a04 in do_reload () at /work/gcc/gcc/ira.c:5325
#5  0x004e6d66 in (anonymous namespace)::pass_reload::execute (this=0x1104d20)
at /work/gcc/gcc/ira.c:5486
#6  0x0059ca64 in execute_one_pass (pass=0x1104d20) at
/work/gcc/gcc/passes.c:2180
#7  0x0059cc3a in execute_pass_list_1 (pass=0x1104d20) at
/work/gcc/gcc/passes.c:2233
#8  0x0059cc5c in execute_pass_list_1 (pass=0x11040c0) at
/work/gcc/gcc/passes.c:2234
#9  0x0059cc86 in execute_pass_list (fn=0xb67cc820, pass=0x1101cc0) at
/work/gcc/gcc/passes.c:2244
#10 0x002fea08 in expand_function (node=0xb697fc40) at
/work/gcc/gcc/cgraphunit.c:1787
#11 0x002feef8 in expand_all_functions () at /work/gcc/gcc/cgraphunit.c:1921
#12 0x002ff760 in compile () at /work/gcc/gcc/cgraphunit.c:2265
#13 0x002ff8b2 in finalize_compilation_unit () at
/work/gcc/gcc/cgraphunit.c:2342
#14 0x001b30ea in c_write_global_declarations () at
/work/gcc/gcc/c/c-decl.c:10452
#15 0x006629d2 in compile_file () at /work/gcc/gcc/toplev.c:562
#16 0x00664de4 in do_compile () at /work/gcc/gcc/toplev.c:1918
#17 0x00664f64 in toplev_main (argc=4, argv=0xbefff484) at
/work/gcc/gcc/toplev.c:1994
#18 0x00bf8dba in main (argc=4, argv=0xbefff484) at /work/gcc/gcc/main.c:36

[Bug rtl-optimization/61522] [4.10 regression] ICE while building libgcc in LRA

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Target||arm-none-linux-gnueabihf
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-06-16
  Known to work||4.9.0
 Ever confirmed|0   |1

[Bug rtl-optimization/61521] [4.10 regression] build broken after LRA patch

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

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

--- Comment #1 from Ramana Radhakrishnan  ---
Looks like a dup of 61522 but that has pre-processed file etc.

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

[Bug rtl-optimization/61522] [4.10 regression] ICE while building libgcc in LRA

[ramana at gcc dot gnu.org]

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

--- Comment #2 from Ramana Radhakrishnan  ---
Same failure also with 

./cc1 -O2 -fPIC -march=armv7-a test.c


$> cat test.c


typedef int(__kernel_cmpxchg64_t)(const long long *oldval,
  const long long *newval, long long *ptr);
long long __attribute__((visibility("hidden")))
__sync_fetch_and_nand_8(long long *ptr, long long val) {
  int failure;
  long long tmp, tmp2;
  do {
tmp = *ptr;
tmp2 = ~(tmp & val);
failure = (*(__kernel_cmpxchg64_t *)0x0f60)(&tmp, &tmp2, ptr);
  } while (failure != 0);
}

[Bug rtl-optimization/61522] [4.10 regression] ICE while building libgcc in LRA

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||christophe.lyon at st dot com

--- Comment #1 from Ramana Radhakrishnan  ---
*** Bug 61521 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/61522] [4.10 regression] ICE while building libgcc in LRA

[ramana at gcc dot gnu.org]

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

--- Comment #3 from Ramana Radhakrishnan  ---
Appears to begin with


Commit 211655:
2014-06-13  Vladimir Makarov  

* lra-assign.c (assign_by_spills): Add code to assign vector regs
to inheritance pseudos.
* config/i386/i386.c (ix86_spill_class): Add check on NO_REGS.

causes GCC trunk to fail to build on ARM & AArch64 targets.

[Bug tree-optimization/61523] New: [4.10 regression] Commit 211600 appears to have caused section type conflicts for ARM

[ramana at gcc dot gnu.org]

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

Bug ID: 61523
   Summary: [4.10 regression] Commit 211600 appears to have caused
section type conflicts for ARM
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ramana at gcc dot gnu.org

Created attachment 32946
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32946&action=edit
compressed testcase

./xgcc -B`pwd` -c -O2 -ffunction-sections -fdata-sections /tmp/strstream.ii
-fPIC -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-16 

In file included from /work/gcc/libstdc++-v3/src/c++98/strstream.cc:44:0:
/work/trunk-nightlies/builds/build-210913/armv7l-unknown-linux-gnueabihf/libstdc++-v3/include/backward/strstream:126:9:
error: std::istrstream::_ZTVSt10istrstream.localalias.0 causes a section type
conflict with std::istrstream::_ZTVSt10istrstream
   class istrstream : public basic_istream
 ^
/work/trunk-nightlies/builds/build-210913/armv7l-unknown-linux-gnueabihf/libstdc++-v3/include/backward/strstream:126:9:
note: _std::istrstream::_ZTVSt10istrstream_ was declared here
/work/trunk-nightlies/builds/build-210913/armv7l-unknown-linux-gnueabihf/libstdc++-v3/include/backward/strstream:143:9:
error: std::ostrstream::_ZTVSt10ostrstream.localalias.1 causes a section type
conflict with std::ostrstream::_ZTVSt10ostrstream
   class ostrstream : public basic_ostream
 ^
/work/trunk-nightlies/builds/build-210913/armv7l-unknown-linux-gnueabihf/libstdc++-v3/include/backward/strstream:143:9:
note: _std::ostrstream::_ZTVSt10ostrstream_ was declared here
/work/trunk-nightlies/builds/build-210913/armv7l-unknown-linux-gnueabihf/libstdc++-v3/include/backward/strstream:160:9:
error: std::strstream::_ZTVSt9strstream.localalias.2 causes a section type
conflict with std::strstream::_ZTVSt9strstream
   class strstream : public basic_iostream
 ^
/work/trunk-nightlies/builds/build-210913/armv7l-unknown-linux-gnueabihf/libstdc++-v3/include/backward/strstream:160:9:
note: _std::strstream::_ZTVSt9strstream_ was declared here

[Bug tree-optimization/61523] [4.10 regression] Commit 211600 appears to have caused section type conflicts for ARM

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Target||arm-none-linux-gnueabihf
 Status|UNCONFIRMED |NEW
  Known to work||4.9.0
   Keywords||build
   Last reconfirmed||2014-06-16
 CC||hubicka at gcc dot gnu.org
   Host||arm-none-linux-gnueabihf
 Ever confirmed|0   |1
   Target Milestone|--- |4.10.0

[Bug rtl-optimization/61522] [4.10 regression] ICE while building libgcc in LRA

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.10.0

[Bug rtl-optimization/61522] [4.10 regression] ICE while building libgcc in LRA

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
  if (lra_reg_info[regno].restore_regno < 0
  || ! bitmap_bit_p (&lra_inheritance_pseudos, regno)
  || (spill_class
  = ((enum reg_class)
 targetm.spill_class
 ((reg_class_t) rclass,
  PSEUDO_REGNO_MODE (regno == NO_REGS)


doesn't check if targetm.spill_class is non-NULL

[Bug tree-optimization/61482] [4.10 regression] ICE in set_value_range, at tree-vrp.c:453 when compiling Firefox ESR 24

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Author: rguenth
Date: Mon Jun 16 14:21:53 2014
New Revision: 211709

URL: https://gcc.gnu.org/viewcvs?rev=211709&root=gcc&view=rev
Log:
2014-06-16  Richard Biener  

PR tree-optimization/61482
* tree-vrp.c (adjust_range_with_scev): Avoid setting of
[-INF(OVF), +INF(OVF)] range.

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

Added:
trunk/gcc/testsuite/g++.dg/torture/pr61482.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vrp.c

[Bug tree-optimization/61482] [4.10 regression] ICE in set_value_range, at tree-vrp.c:453 when compiling Firefox ESR 24

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug lto/48200] linking shared library with LTO results in different exported symbols

[khimov at altell dot ru]

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

Roman Khimov  changed:

   What|Removed |Added

 CC||khimov at altell dot ru

--- Comment #10 from Roman Khimov  ---
I can confirm the same bug with pciutils 3.2.1 and GCC 4.9.0, although now it's
pci_fill_info_v32().

[Bug libstdc++/61519] Seemingly incorrect vtable reference when libstdc++ built with RTTI

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Surely this is a target-specific bug in the dynamic_cast implementation, not
libstdc++?

[Bug rtl-optimization/61522] [4.10 regression] ICE while building libgcc in LRA

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug bootstrap/61524] New: cgraph visibility aix bootstrap failure

[dje at gcc dot gnu.org]

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

Bug ID: 61524
   Summary: cgraph visibility aix bootstrap failure
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org

Revision 211600 causes GCC Bootstrap to fail on AIX in stage 2. The gen*
programs built by the stage 1 compiler all hang.

[Bug bootstrap/61524] cgraph visibility aix bootstrap failure

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Target||powerpc-ibm-aix
   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
URL||https://gcc.gnu.org/ml/gcc-
   ||cvs/2014-06/msg00498.html
   Keywords||wrong-code
   Last reconfirmed||2014-06-16
 CC||hubicka at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1
   Target Milestone|--- |4.10.0
   Severity|normal  |blocker

[Bug ipa/61525] New: [4.9 Regression] ipa visibility TLC 2/n failures on AIX

[dje at gcc dot gnu.org]

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

Bug ID: 61525
   Summary: [4.9 Regression] ipa visibility TLC 2/n failures on
AIX
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org

The ipa visibility patch introduces a massive number of new testsuite failures
on AIX.

[Bug lto/61526] New: relocation R_X86_64_PC32 in shared object with static and extern

[khimov at altell dot ru]

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

Bug ID: 61526
   Summary: relocation R_X86_64_PC32 in shared object with static
and extern
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: khimov at altell dot ru

Created attachment 32947
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32947&action=edit
two source files and workaround patch

Compiling Quagga 0.99.22.4 with GCC 4.9.0 (compiler bootstrapped to
cross-compile from x86_64 Debian GNU/Linux to x86_64 uClibc system) with LTO
enabled fails:

| x86_64-altell-linux-uclibc-libtool: link: ccache
x86_64-altell-linux-uclibc-gcc -march=x86-64 -mtune=generic
--sysroot=/home/rik/neo-1.5/tmp/sysroots/x86_64-altell-linux-uclibc -shared 
-fPIC -DPIC  .libs/network.o .libs/pid_output.o .libs/getopt.o .libs/getopt1.o
.libs/daemon.o .libs/checksum.o .libs/vector.o .libs/linklist.o .libs/vty.o
.libs/command.o .libs/sockunion.o .libs/prefix.o .libs/thread.o .libs/if.o
.libs/memory.o .libs/buffer.o .libs/table.o .libs/hash.o .libs/filter.o
.libs/routemap.o .libs/distribute.o .libs/stream.o .libs/str.o .libs/log.o
.libs/plist.o .libs/zclient.o .libs/sockopt.o .libs/smux.o .libs/agentx.o
.libs/snmp.o .libs/md5.o .libs/if_rmap.o .libs/keychain.o .libs/privs.o
.libs/sigevent.o .libs/pqueue.o .libs/jhash.o .libs/memtypes.o
.libs/workqueue.o   -lcrypt
-L/home/rik/neo-1.5/tmp/sysroots/x86_64-altell-linux-uclibc/usr/lib
/home/rik/neo-1.5/tmp/sysroots/x86_64-altell-linux-uclibc/usr/lib/libnetsnmpmibs.so
-ldl
/home/rik/neo-1.5/tmp/sysroots/x86_64-altell-linux-uclibc/usr/lib/libnetsnmpagent.so
/home/rik/neo-1.5/tmp/sysroots/x86_64-altell-linux-uclibc/usr/lib/libnetsnmp.so
-lcrypto -lm -lpthread -lrt  -march=x86-64 -mtune=generic
--sysroot=/home/rik/neo-1.5/tmp/sysroots/x86_64-altell-linux-uclibc -O2 -flto
-O2 -flto -Wl,-O1 -Wl,--hash-style=gnu -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,-O1
-Wl,--hash-style=gnu -Wl,-z -Wl,relro -Wl,-z -Wl,now -flto   -Wl,-soname
-Wl,libzebra.so.0 -o .libs/libzebra.so.0.0.0
|
/home/rik/neo-1.5/tmp/sysroots/x86_64-altell-linux-uclibc/usr/lib/libnetsnmp.so:
warning: gethostbyaddr is obsolescent, use getaddrinfo() instead.
|
/home/rik/neo-1.5/tmp/sysroots/x86_64-altell-linux-uclibc/usr/lib/libnetsnmp.so:
warning: gethostbyname is obsolescent, use getnameinfo() instead.
|
/home/rik/neo-1.5/tmp/sysroots/x86_64-linux/usr/libexec/x86_64-altell-linux-uclibc/gcc/x86_64-altell-linux-uclibc/4.9.0/ld:
/tmp/ccYjxIMj.ltrans1.ltrans.o: relocation R_X86_64_PC32 against undefined
symbol `master' can not be used when making a shared object; recompile with
-fPIC
|
/home/rik/neo-1.5/tmp/sysroots/x86_64-linux/usr/libexec/x86_64-altell-linux-uclibc/gcc/x86_64-altell-linux-uclibc/4.9.0/ld:
final link failed: Bad value


Turns out that the problem can be reproduced with just two objects, vty.o and
zclient.o, preprocessed sources attached. Compiling with:

$ x86_64-altell-linux-uclibc-gcc -fno-strict-aliasing -pipe -O2
-fomit-frame-pointer -frename-registers -flto -c vty.prepr.c  -fPIC -DPIC -o
vty.o
$ x86_64-altell-linux-uclibc-gcc -fno-strict-aliasing -pipe -O2
-fomit-frame-pointer -frename-registers -flto -c zclient.prepr.c  -fPIC -DPIC
-o zclient.o
$ x86_64-altell-linux-uclibc-gcc -shared  -fPIC -DPIC  vty.o zclient.o -O2
-flto -o lib.so

gives the same result:

/home/rik/neo-1.5/tmp/sysroots/x86_64-linux/usr/libexec/x86_64-altell-linux-uclibc/gcc/x86_64-altell-linux-uclibc/4.9.0/ld:
/tmp/cc3LxvY0.ltrans1.ltrans.o: relocation R_X86_64_PC32 against undefined
symbol `master.lto_priv.3' can not be used when making a shared object;
recompile with -fPIC
/home/rik/neo-1.5/tmp/sysroots/x86_64-linux/usr/libexec/x86_64-altell-linux-uclibc/gcc/x86_64-altell-linux-uclibc/4.9.0/ld:
final link failed: Bad value
collect2: error: ld returned 1 exit status

Compiling with -flto-partition=none solves the problem as does my current
workaround patch to rename static variable in vty.o (attached, although the
patch is for original Quagga package).

[Bug ipa/61525] [4.9 Regression] ipa visibility TLC 2/n failures on AIX

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Target||powerpc-ibm-aix
   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Keywords||wrong-code
   Last reconfirmed||2014-06-16
 CC||hubicka at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1
   Target Milestone|--- |4.10.0
   Severity|normal  |critical

--- Comment #1 from David Edelsohn  ---
Temporarily reverted.

[Bug fortran/61527] New: class/extends, multiple generic assignment, accept invalid

[mrestelli at gmail dot com]

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

Bug ID: 61527
   Summary: class/extends, multiple generic assignment, accept
invalid
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mrestelli at gmail dot com

Hi,
   I see that gfortran accepts the following code (even with strict
debug flags) which is ambiguous in the resolution of the generic. The
code is correctly rejected if disp2 uses CLASS(t2) instead of
TYPE(t2), while with TYPE(T2) the code compiles and DISP2 is called,
which I think should not be allowed.


$ gfortran --version
GNU Fortran (GCC) 4.10.0 20140613 (experimental)



module m
 implicit none

 private
 public :: t1, t2, disp

 type :: t1
  integer :: i = 1
 end type t1

 type, extends(t1) :: t2
  real :: r = 2.0
 end type t2

 interface disp
  module procedure disp1, disp2
 end interface

contains

 subroutine disp1(x)
  class(t1), intent(in) :: x
   write(*,*) "Disp 1: ",x%i
 end subroutine disp1

 subroutine disp2(x)
  type(t2), intent(in) :: x ! <- accepted
  !class(t2), intent(in) :: x ! <- rejected
   write(*,*) "Disp 2: ",x%r
 end subroutine disp2

end module m


program p
 use m
 implicit none

 type(t1) :: a
 type(t2) :: b

 call disp(a)
 call disp(b)

end program p

[Bug rtl-optimization/61522] [4.10 regression] ICE while building libgcc in LRA

[vmakarov at gcc dot gnu.org]

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

--- Comment #5 from Vladimir Makarov  ---
Author: vmakarov
Date: Mon Jun 16 15:55:03 2014
New Revision: 211711

URL: https://gcc.gnu.org/viewcvs?rev=211711&root=gcc&view=rev
Log:
2014-06-16  Vladimir Makarov  

PR rtl-optimization/61522
* lra-assigns.c (assign_by_spills): Check null
targetm.spill_class.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-assigns.c

[Bug fortran/61527] class/extends, multiple generic assignment, accept invalid

[dominiq at lps dot ens.fr]

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

--- Comment #1 from Dominique d'Humieres  ---
Up to r200946 (2013-07-14, 4.9) gfortran gives an error

Error: Ambiguous interfaces 'disp2' and 'disp1' in generic interface 'disp' at
(1)

>From at least r201266 (2013-07-26) gfortran accepts the code. I did not find
any obvious culprit in this range for the change in behavior. I also don't know
what is the correct behavior.

[Bug fortran/61527] class/extends, multiple generic assignment, accept invalid

[mrestelli at gmail dot com]

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

--- Comment #2 from mrestelli  ---
I am no expert, but I think that the correct behaviour is that of the
older version: the two interfaces indeed are ambiguous, since a call
like

 type(t2) :: b
 call disp(b)

could call both disp1 and disp2.

[Bug c++/61512] libstd++ postfix operator hangs

[glisse at gcc dot gnu.org]

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

--- Comment #6 from Marc Glisse  ---
Really? With _GLIBCXX_DEBUG, your program is supposed to print the following
message (even with the old gcc-4.4 you reported this against):

/usr/include/c++/4.8/debug/safe_iterator.h:307:error: attempt to increment 
a past-the-end iterator.

Objects involved in the operation:
iterator "this" @ 0x0x7fff4a666fb0 {
type =
N11__gnu_debug14_Safe_iteratorISt23_Rb_tree_const_iteratorIiENSt7__debug3setIiSt4lessIiESaIiE
(mutable iterator);
  state = past-the-end;
  references sequence with type `NSt7__debug3setIiSt4lessIiESaIiEEE' @
0x0x7fff4a666fe0
}

[Bug c++/61512] libstd++ postfix operator hangs

[srohit.pda at gmail dot com]

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

--- Comment #7 from Rohit Sharma  ---
Yes, it did print that message clearly before core-dump.

thank you much.
-Rohit

[Bug c++/61528] std::min std::max and RValue

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
Yes, that's required by the standard, nothing we can do about it.

[Bug c++/61528] New: std::min std::max and RValue

[lisp2d at lisp2d dot net]

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

Bug ID: 61528
   Summary: std::min std::max and RValue
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lisp2d at lisp2d dot net

Declaring reference of result of functions MIN or MAX we get a DEAD memory when
one of arguments is an RValue.

// gcc -std=c++11 -Os bug.cpp
// gcc -std=c++11 -O2 bug.cpp
#include

void  f(size_t  const & x){
  std::cout <<  "f:x="  <<  x <<  std::endl;}

int main(void){
  size_t  x{1};
  size_t  y{2};
  size_t  z{4};
  size_t  const & i=std::min(z,x  + y);
  f(i);
  size_t  const & a=std::max(x,y  + z);
  f(a);}

[Bug c++/61528] std::min std::max and RValue

[lisp2d at lisp2d dot net]

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

--- Comment #2 from Lisp2D  ---
Issue a warning would not hurt.

[Bug libstdc++/56785] std::tuple of two elements does not apply empty base class optimization when one of its elements is a std::tuple with two elements

[gcc-bugzilla at contacts dot eelis.net]

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

Eelis  changed:

   What|Removed |Added

 CC||gcc-bugzilla at contacts dot 
eelis
   ||.net

--- Comment #2 from Eelis  ---
Another manifestation of this is that 

  sizeof(pair,pair>) == 4

while

  sizeof(tuple,tuple>) == 5 (!!).

I think that at the moment, GCC users are best advised to avoid using stdlib
tuples if efficiency is a concern.

[Bug c++/61528] std::min std::max and RValue

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
The warning is discussed in PR 60517.

[Bug c++/61528] std::min std::max and RValue

[lisp2d at lisp2d dot net]

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

--- Comment #4 from Lisp2D  ---
 Likely error in the standard. The right set of functions must return a copy of
the data and return a the temporary link with real data.
 Working version of it:

size_t  const & min2(size_t const & x,size_t  const & y){
  return  std::min(x,y);}

size_t  min2(size_t const &&  x,size_t  const & y){
  return  {std::min(x,y)};}

size_t  min2(size_t const &  x,size_t  const && y){
  return  {std::min(x,y)};}  


May be do like this?

[Bug c++/61528] std::min std::max and RValue

[glisse at gcc dot gnu.org]

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

--- Comment #5 from Marc Glisse  ---
Feel free to post a message on
https://groups.google.com/a/isocpp.org/forum/#!forum/std-proposals to suggest
this. https://isocpp.org/std gives information on making official proposals. In
gcc we only implement what the standard tells us.

[Bug rtl-optimization/61325] [4.10 regression] aarch64_be build fails

[vmakarov at gcc dot gnu.org]

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

--- Comment #10 from Vladimir Makarov  ---
Author: vmakarov
Date: Mon Jun 16 21:40:28 2014
New Revision: 211716

URL: https://gcc.gnu.org/viewcvs?rev=211716&root=gcc&view=rev
Log:
2014-06-16  Vladimir Makarov  

PR rtl-optimization/61325
* lra-constraints.c (valid_address_p): Add forward declaration.
(simplify_operand_subreg): Check address validity before and after
alter_reg of memory subreg.


Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/lra-constraints.c

[Bug rtl-optimization/61325] [4.10 regression] aarch64_be build fails

[vmakarov at gcc dot gnu.org]

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

--- Comment #9 from Vladimir Makarov  ---
Author: vmakarov
Date: Mon Jun 16 21:39:42 2014
New Revision: 211715

URL: https://gcc.gnu.org/viewcvs?rev=211715&root=gcc&view=rev
Log:
2014-06-16  Vladimir Makarov  

PR rtl-optimization/61325
* lra-constraints.c (valid_address_p): Add forward declaration.
(simplify_operand_subreg): Check address validity before and after
alter_reg of memory subreg.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-constraints.c

[Bug libstdc++/56785] std::tuple of two elements does not apply empty base class optimization when one of its elements is a std::tuple with two elements

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Eelis from comment #2)
> Another manifestation of this is that 
> 
>   sizeof(pair,pair>) == 4
> 
> while
> 
>   sizeof(tuple,tuple>) == 5 (!!).

Oh noes, one byte more for a silly edge case!

> I think that at the moment, GCC users are best advised to avoid using stdlib
> tuples if efficiency is a concern.

That's a ridiculous conclusion to reach based on an edge case.

There are many realistic situations where std::tuple is more compact that
std::pair.

[Bug libstdc++/56785] std::tuple of two elements does not apply empty base class optimization when one of its elements is a std::tuple with two elements

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
The cause is that every N-tuple hierarchy ends with an empty _Tuple_impl
base, so when there are several of those in the same hierarchy they need to
have separate addresses.

It should be possible to fix by eliminating that terminal objet in the
inheritance hierarchy. The obvious way duplicates a chunk of code, I think it
should be possible to do it in a nicer way, which I'm experimenting with.

[Bug tree-optimization/61529] New: ICE on valid code at -O3 on x86_64-linux-gnu in check_probability, at basic-block.h:953

[su at cs dot ucdavis.edu]

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

Bug ID: 61529
   Summary: ICE on valid code at -O3 on x86_64-linux-gnu in
check_probability, at basic-block.h:953
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu

The following code causes an ICE when compiled with the current gcc trunk at
-O3 on x86_64-linux-gnu in both 32-bit and 64-bit modes.

It is a regression from 4.9.x.

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 4.10.0 20140616 (experimental) [trunk revision 211707] (GCC) 
$ 
$ gcc-trunk -O2 small.c; a.out
$ gcc-4.9 -O3 small.c; a.out
$ 
$ gcc-trunk -O3 small.c
small.c: In function ‘fn1’:
small.c:4:1: internal compiler error: in check_probability, at
basic-block.h:953
 fn1 ()
 ^
0xb905e6 check_probability
../../gcc-trunk/gcc/basic-block.h:953
0xb8dde1 check_probability
../../gcc-trunk/gcc/tree-vect-loop-manip.c:653
0xb8dde1 combine_probabilities
../../gcc-trunk/gcc/basic-block.h:962
0xb8dde1 slpeel_tree_peel_loop_to_edge
../../gcc-trunk/gcc/tree-vect-loop-manip.c:1371
0xb8e154 vect_do_peeling_for_loop_bound(_loop_vec_info*, tree_node*,
tree_node*, unsigned int, bool)
../../gcc-trunk/gcc/tree-vect-loop-manip.c:1761
0xb7f3a7 vect_transform_loop(_loop_vec_info*)
../../gcc-trunk/gcc/tree-vect-loop.c:5852
0xb9c286 vectorize_loops()
../../gcc-trunk/gcc/tree-vectorizer.c:476
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ 





char a, b, c, d, e, f, g;

void
fn1 ()
{
  char h = 0;
lbl:
  for (c = 0; c; c = 0)
for (; a;)
  for (d = 1; d; d++)
if ((b & ((g > 0) >= h)) ^ 2)
  goto lbl;
  for (f = 1; f; f++)
e ^= 1;
}

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

[Bug libstdc++/61519] Seemingly incorrect vtable reference when libstdc++ built with RTTI

[matthew at theiselins dot net]

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

--- Comment #2 from Matthew Iselin  ---
Where would I start in identifying what about the target is causing the issue?

The best I can come up with is an issue with the vtable prefix and/or the math
to determine the deepest object, but can't (yet) see how the target would
affect that.

[Bug target/61423] Incorrect conversion from unsigned int to floating point

[uros at gcc dot gnu.org]

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

--- Comment #12 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Jun 17 05:00:52 2014
New Revision: 211723

URL: https://gcc.gnu.org/viewcvs?rev=211723&root=gcc&view=rev
Log:
Backport from mainline
2014-06-06  Uros Bizjak  

PR target/61423
* config/i386/i386.md (*floatunssi2_i387_with_xmm): New
define_insn_and_split pattern, merged from *floatunssi2_1
and corresponding splitters.  Zero extend general register
or memory input operand to XMM temporary.  Enable for
TARGET_SSE2 and TARGET_INTER_UNIT_MOVES_TO_VEC only.
(floatunssi2): Update expander predicate.

testsuite/ChangeLog:

Backport from mainline
2014-06-06  Uros Bizjak  

PR target/61423
* gcc.target/i386/pr61423.c: New test.


Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/i386/pr61423.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/i386/i386.md
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug sanitizer/61530] New: [4.10 Regression] segfault with asan

[Joost.VandeVondele at mat dot ethz.ch]

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

Bug ID: 61530
   Summary: [4.10 Regression] segfault with asan
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Joost.VandeVondele at mat dot ethz.ch
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org

Current trunk started failing in the day between good: r211692 bad: r211720


> gfortran -c -fsanitize=address bug.f90 
bug.f90: In function ‘mainlb’:
bug.f90:3:0: internal compiler error: Segmentation fault
   SUBROUTINE mainlb(n, m, x, l, u, nbd, f, g, factr, pgtol, ws, wy, &
 ^
0xa5ba8f crash_signal
../../gcc/gcc/toplev.c:337
0xa6f206 contains_struct_check
../../gcc/gcc/tree.h:2835
0xa6f206 build_check_stmt
../../gcc/gcc/asan.c:1824
0xa74dbb instrument_mem_region_access
../../gcc/gcc/asan.c:1984
0xa759a1 instrument_builtin_call
../../gcc/gcc/asan.c:2105
0xa759a1 maybe_instrument_call
../../gcc/gcc/asan.c:2178
0xa759a1 transform_statements
../../gcc/gcc/asan.c:2245
0xa7663c asan_instrument
../../gcc/gcc/asan.c:2625
0xa7663c execute
../../gcc/gcc/asan.c:2700
Please submit a full bug report,

> cat bug.f90 
MODULE cp_lbfgs
CONTAINS
  SUBROUTINE mainlb(n, m, x, l, u, nbd, f, g, factr, pgtol, ws, wy, &
   csave, lsave, isave, dsave)
CHARACTER(len=60):: task
IF (task == 'START') THEN
   IF (task(1:5) == 'NEW_X') GOTO 777
   IF (task(1:4) == 'STOP') THEN
  IF (task(7:9) == 'CPU') THEN
 CALL dcopy(n,t,1,x,1)
  ENDIF
   ENDIF
ENDIF
222 CONTINUE
IF (info /= 0 .OR. iback >= 20) THEN
   IF (col == 0) THEN
  IF (info == 0) THEN
  ENDIF
  task = 'ABNORMAL_TERMINATION_IN_LNSRCH'
  GOTO 222
   ENDIF
ENDIF
777 CONTINUE
  END SUBROUTINE mainlb
END MODULE cp_lbfgs

[Bug target/61330] [4.10 Regression] Thumb ICE for case 920507-1.c

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Target|aarch64*-*-*, arm*-*-*, |aarch64*-*-*, arm*-*-*,
   |powerpc*-*-*|powerpc*-*-*, alpha*-*-*
 CC||ubizjak at gmail dot com

--- Comment #4 from Uroš Bizjak  ---
Also happens on alpha-linux-gnu. The backtrace with -O2 -ffat-lto-objects,
obtained from x86_64-pc-linux-gnu crosscompiler is:

920507-1.c: In function ‘x’:
920507-1.c:5:16: error: invalid register name for ‘a’
  register int *a asm("unknown_register");  /* { dg-error "invalid register" }
*/
^
920507-1.c:3:1: internal compiler error: in symtab_get_node, at cgraph.h:1073
 x(void)
 ^
0xc6d5ab decl_section_name(tree_node const*)
../../gcc-svn/trunk/gcc/cgraph.h:1070
0xcd690b alpha_in_small_data_p
../../gcc-svn/trunk/gcc/config/alpha/alpha.c:683
0xcb8271 default_encode_section_info(tree_node*, rtx_def*, int)
../../gcc-svn/trunk/gcc/varasm.c:6573
0x90c349 rest_of_decl_compilation(tree_node*, int, int)
../../gcc-svn/trunk/gcc/passes.c:215
0x6139fa expand_one_hard_reg_var
../../gcc-svn/trunk/gcc/cfgexpand.c:1109
0x6139fa expand_one_var
../../gcc-svn/trunk/gcc/cfgexpand.c:1296
0x613cd9 expand_used_vars_for_block
../../gcc-svn/trunk/gcc/cfgexpand.c:1339
0x61f0ee expand_used_vars
../../gcc-svn/trunk/gcc/cfgexpand.c:1806
0x6200d3 execute
../../gcc-svn/trunk/gcc/cfgexpand.c:5671

[Bug target/58945] Improve atomic_compare_and_swap*_doubleword pattern

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak  ---
Steven, do you have any ETA for this fix?

[Bug bootstrap/61508] [4.10 regression] fold-const.c:14863:55: error: cannot convert 'const char*' to 'const_tree

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-06-17
 CC||hubicka at gcc dot gnu.org,
   ||tschwinge at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |tschwinge at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Thomas Schwinge  ---
.

[Bug middle-end/61430] [4.10 regression] ICE in lra_create_copy

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

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

--- Comment #7 from Ramana Radhakrishnan  ---
Presumably fixed now.