[Bug middle-end/57370] [4.9 Regression] compiler hangs in reassoc

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

Summary|[4.9 Regression] compile|[4.9 Regression] compiler
   |time hog in reassoc |hangs in reassoc

--- Comment #5 from Joost VandeVondele  
---
This is actually hanging and not just taking a long time. 

I've also create PR57393 which is an ICE that happened during an attempt to
reduce the testcase of this PR. This might or might not be related.

[Bug middle-end/57393] [4.9 Regression] error: definition in block 4 follows the use / internal compiler error: verify_ssa failed

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch
Summary|[4.8 Regression] error: |[4.9 Regression] error:
   |definition in block 4   |definition in block 4
   |follows the use / internal  |follows the use / internal
   |compiler error: verify_ssa  |compiler error: verify_ssa
   |failed  |failed

--- Comment #1 from Joost VandeVondele  
---
fine with 4.8 fails with 4.9

[Bug middle-end/57393] New: [4.8 Regression] error: definition in block 4 follows the use / internal compiler error: verify_ssa failed

[Joost.VandeVondele at mat dot ethz.ch]

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

Bug ID: 57393
   Summary: [4.8 Regression] error: definition in block 4 follows
the use / internal compiler error: verify_ssa failed
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Joost.VandeVondele at mat dot ethz.ch

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

With current trunk:

gfortran -c -g -O2 -ffast-math  -ffree-form -cpp bug.f90

bug.f90: In function ‘xb88_lr_adiabatic_lda_calc’:
bug.f90:1:0: error: definition in block 4 follows the use
   SUBROUTINE xb88_lr_adiabatic_lda_calc(rho, norm_drho,&
 ^
for SSA_NAME: _83 in statement:
# DEBUG D#20 => _83 + _54
bug.f90:1:0: internal compiler error: verify_ssa failed
0xb37624 verify_ssa(bool)
../../gcc/gcc/tree-ssa.c:1046
0x903f12 execute_function_todo
../../gcc/gcc/passes.c:1970
0x90486d execute_todo
../../gcc/gcc/passes.c:2002
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


Since the testcase is actually a reduced version of PR57370 the bug could be
related. However, since this one is ICE-ing while the other hangs, I'm assuming
this is a different issue.

[Bug c++/57392] New: The result of a .* expression is rvalue in a function template when its object expression is lvalue.

[kyusic at gmail dot com]

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

Bug ID: 57392
   Summary: The result of a .* expression is rvalue in a function
template when its object expression is lvalue.
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kyusic at gmail dot com

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

g++ rejects the following program in c++11 mode:

-- begin -
struct A
{
int i;
};

void g(int& p) {}

template 
void f()
{
A a;
int A::*pm = &A::i;
g(a.*pm); // (*)
}
- end 

It says the expression 'a.*pm' at the line marked with (*) is rvalue, which
should be lvalue because its object expression 'a' is lvalue.

It compiles fine when f() is not templated.

g++-4.8.0 has the same problem.

Following is the compiler message:

- begin 
$ g++ -v -save-temps -c -std=c++11 a.cc
Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.7.3/configure --enable-languages=c++
--disable-multilib
Thread model: posix
gcc version 4.7.3 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-std=c++11' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.7.3/cc1plus -E -quiet -v
-imultilib . -imultiarch x86_64-linux-gnu -D_GNU_SOURCE a.cc -mtune=generic
-march=x86-64 -std=c++11 -fpch-preprocess -o a.ii
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.7.3/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

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

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

/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.7.3/../../../../include/c++/4.7.3/backward
 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.7.3/include
 /usr/local/include
 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.7.3/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-std=c++11' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.7.3/cc1plus -fpreprocessed
a.ii -quiet -dumpbase a.cc -mtune=generic -march=x86-64 -auxbase a -std=c++11
-version -o a.s
GNU C++ (GCC) version 4.7.3 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.3, GMP version 5.0.5, MPFR version 3.1.1-p2,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (GCC) version 4.7.3 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.3, GMP version 5.0.5, MPFR version 3.1.1-p2,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: e27c3e349c650e830c6a08a9bf1d2e03
a.cc: In function ‘void f()’:
a.cc:13:12: error: invalid initialization of non-const reference of type ‘int&’
from an rvalue of type ‘int’
a.cc:6:6: error: in passing argument 1 of ‘void g(int&)’
-- end --

[Bug c++/57391] [4.9 Regression] ICE compiling AIX math.h caused by PR c++/56930

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Looks like cxx_eval_constant_expression needs to also handle FMA_EXPR

[Bug c++/57391] [4.9 Regression] ICE compiling AIX math.h caused by PR c++/56930

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-05-24
 CC||jason at gcc dot gnu.org
   Target Milestone|--- |4.9.0
 Ever confirmed|0   |1

--- Comment #1 from David Edelsohn  ---
Confirmed.

[Bug c++/57391] New: [4.9 Regression] ICE compiling AIX math.h caused by PR c++/56930

[dje at gcc dot gnu.org]

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

Bug ID: 57391
   Summary: [4.9 Regression] ICE compiling AIX math.h caused by PR
c++/56930
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org

The patch for PR c++/56930 breaks bootstrap on AIX when building libstdc++.  I
now receive the following error message:

/tmp/20130524/gcc/include-fixed/math.h: In function 'long double
fmal(long double, long double, long double)':
/tmp/20130524/gcc/include-fixed/math.h:879:135: internal compiler
error: unexpected expression '#'fma_expr' not supported by
dump_expr#' of kind fma_expr
 inline long double fmal(long double __x, long double __y, long double
__z) { return fma((double) (__x), (double) (__y), (double) (__z)); }

When not using long double 128, AIX math.h provides a number of
definitions, including

inline long double fmal(long double __x, long double __y, long double __z)
{ return fma((double) (__x), (double) (__y), (double) (__z)); }

Reverting

--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -6199,10 +6199,10 @@ convert_like_real (conversion *convs, tree expr, tree
fn, int argnum,
   if (convs->check_narrowing)
 check_narrowing (totype, expr);

-  if (issue_conversion_warnings && (complain & tf_warning))
-expr = convert_and_check (totype, expr);
+  if (issue_conversion_warnings)
+expr = cp_convert_and_check (totype, expr, complain);
   else
-expr = convert (totype, expr);
+expr = cp_convert (totype, expr, complain);

   return expr;
 }

removes the ICE.

[Bug c++/57390] Fixed point types on AVR are not available in C++ mode

[ambrop7 at gmail dot com]

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

--- Comment #2 from Ambroz Bizjak  ---
I've been reading the discussion there, but I don't see any interaction
problems with templates. Most of it is just useless arguing about whether fixed
point types can be implemented externally with templates. The support in the
GCC code is already there, what is the real obstacle to enabling that in C++?

[Bug c++/57390] Fixed point types on AVR are not available in C++ mode

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
There is no way to enable it for C++ because the extension has not been
designed to how it would interact with templates and such.

See the thread at http://gcc.gnu.org/ml/gcc/2011-11/msg00124.html for more
info.

[Bug c++/57390] New: Fixed point types on AVR are not available in C++ mode

[ambrop7 at gmail dot com]

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

Bug ID: 57390
   Summary: Fixed point types on AVR are not available in C++ mode
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ambrop7 at gmail dot com

As of version 4.8, GCC supports fixed point types for the AVR target. See:
http://gcc.gnu.org/wiki/avr-gcc#Fixed-Point_Support

However, this is only available in C and not in C++. Please enable fixed point
for C++ too. It may have to be hidden behind an option to not break existing
C++ code though.

[Bug c++/37140] type inherited from base class not recognized

[paolo.carlini at oracle dot com]

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

--- Comment #6 from Paolo Carlini  ---
Thanks a lot!

[Bug c++/57248] string parameter to constexpr functions

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini  ---
Thanks Daniel. In fact - I should have attached some code - nothing about
 & co matters, you can remove it completely and replace std::get with,
say,

template 
constexpr int get() { return 1; }

[Bug middle-end/56934] ICE folding a COND_EXPR involving vectors

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

  Known to work||4.9.0
  Known to fail|4.9.0   |

--- Comment #2 from Marc Glisse  ---
Fixed on trunk.

[Bug middle-end/57286] [4.9 regression] infinite recursion in fold-const.c:10037

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

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

--- Comment #8 from Marc Glisse  ---
.

[Bug c++/57384] can't expand a parameter pack into a list of function types or function pointer types

[eric.niebler at gmail dot com]

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

--- Comment #3 from Eric Niebler  ---
Interesting. I filed a similar bug against clang
(http://llvm.org/bugs/show_bug.cgi?id=16118), where Richard Smith seems to feel
the test cases should be:

  template
  struct list
  {};

  template
  struct S
  {
  using type1 = void(int...(Ts));// (1) fails
  using type2 = list;// (2) works
  using type3 = void(int(*...)(Ts)); // (3) fails
  using type4 = list; // (4) works
  };

This strikes me as ludicrously inconsistent. I think we need guidance from the
committee here. I was basing my bug report(s) on the example in 8.3.5/13 (which
shows:

   template void f(T (* ...t)(int, int));

The suggestion that the pack expansion syntax differs depending on the context
in which the expansion occurs is, um, unsatisfactory.

[Bug c++/57317] [4.8/4.9 Regression] bogus and unsuppressible warning: 'YYY' has a base 'ZZZ' whose type uses the anonymous namespace

[ppluzhnikov at google dot com]

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

--- Comment #5 from Paul Pluzhnikov  ---
(In reply to Jason Merrill from comment #4)

> Look again; it's commit 199104 on gcc-4_8-branch.

I can see it now. Thanks for the fix!

[Bug c++/57317] [4.8/4.9 Regression] bogus and unsuppressible warning: 'YYY' has a base 'ZZZ' whose type uses the anonymous namespace

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
(In reply to Paul Pluzhnikov from comment #3)
> but nothing on 4_8-branch.

Look again; it's commit 199104 on gcc-4_8-branch.

[Bug c++/57319] [4.8 Regression]: bogus "defaulted move assignment for ... calls a non-trivial move assignment operator for virtual base ..."

[richard-gccbugzilla at metafoo dot co.uk]

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

Richard Smith  changed:

   What|Removed |Added

 CC||richard-gccbugzilla@metafoo
   ||.co.uk

--- Comment #5 from Richard Smith  ---
(In reply to Jason Merrill from comment #1)
> (In reply to Paul Pluzhnikov from comment #0)
> >   However, this particular case *isn't* the problematic case, because
> >   (a) this sample code should not trigger the definition of C's move
> >   assignment operator, and
> 
> True, the warning is given at declaration time; it would be possible to move
> the warning to when the move assignment is used, but that might mean design
> errors don't get caught until later.

OK, that makes sense. However, delaying the check until the operator= is lazily
declared does not fully achieve this goal. Could the check be performed at the
end of the definition of class C (rather than, presumably, when looking for a
virtual C::operator= for D::operator= to override)?

> >   (b) there is only one inheritance path from C to B, so it won't be
> >   move-assigned multiple times, and
> 
> True, the warning is given at the point of first virtual derivation rather
> than when it appears in a diamond-shaped hierarchy.  But the purpose of
> virtual derivation is to support diamond-shaped hierarchies, so again it
> seems appropriate to warn sooner rather than later.

OK. The class which brings together the diamond may provide a move assignment
operator which does not blindly call the move assignment operators on the base
classes, so this can still have some false positives even if every virtual base
is involved in diamond inheritance.

[Bug rtl-optimization/57359] wrong code for union access at -O3 on x86_64-linux

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
NP, and thanks a lot for the bugreports, they are very much appreciated.

[Bug c++/57248] string parameter to constexpr functions

[daniel.kruegler at googlemail dot com]

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

--- Comment #3 from Daniel Krügler  ---
The code looks valid to me. I think that Paolo just wanted to point out that
the library implementation does not cause this. I agree with him and can
confirm that the code is also rejected when emulating the library such as in
the following way:

template
struct enable_if{};

template
struct enable_if{ typedef T type; };

template
struct tuple
{
  T1 t1;
  T2 t2;
};

template
constexpr
typename enable_if::type
get(tuple t) { return t.t1; }

template
constexpr
typename enable_if::type
get(tuple t) { return t.t2; }

template
constexpr tuple make_tuple(T1 t1, T2 t2)
{
  return tuple{t1, t2};
}

Same error here.

[Bug c++/57319] [4.8 Regression]: bogus "defaulted move assignment for ... calls a non-trivial move assignment operator for virtual base ..."

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
(In reply to Paul Pluzhnikov from comment #3)
> Can this be back-ported to 4.8 branch?

After 4.8.1, I think.

[Bug libstdc++/54354] TODO extended iomanip manipulators std::get_time and std::put_time (C++11, section 27.7.5)

[dmorilha at gmail dot com]

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

--- Comment #5 from Daniel Morilha  ---
I just realized I can use operating system functionality to achieve the same
goal. Please ignore my question and thanks for the quick follow up. Looking
forward to gcc 4.9.0

[Bug c++/57388] [C++11] ICE when function types with ref-qualifiers meet other function types

[daniel.kruegler at googlemail dot com]

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

--- Comment #2 from Daniel Krügler  ---
(In reply to Daniel Krügler from comment #0)
> While attempting to upgrade std::function for functions with ref-qualifiers 
> [..]

Oops, I meant std::is_function of-course.

[Bug debug/57389] New: ICE in dbx_reg_number, at dwarf2out.c:10507 on powerpc-spe target

[rmansfield at qnx dot com]

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

Bug ID: 57389
   Summary: ICE in dbx_reg_number, at dwarf2out.c:10507 on
powerpc-spe target
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rmansfield at qnx dot com
Target: powerpc-e500v2-linux-gnuspe

spe targets are failing to build libgcc.

$ ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: powerpc-e500v2-linux-gnuspe
Configured with: ../configure --target=powerpc-e500v2-linux-gnuspe
--prefix=/home/ryan/x-tools/powerpc-e500v2-linux-gnuspe
--with-sysroot=/home/ryan/x-tools/powerpc-e500v2-linux-gnuspe/powerpc-e500v2-linux-gnuspe/sys-root
--disable-multilib --with-cpu=8548 --with-tune=8548
--with-gmp=/home/ryan/x-tools/powerpc-e500v2-linux-gnuspe
--with-mpfr=/home/ryan/x-tools/powerpc-e500v2-linux-gnuspe
--enable-__cxa_atexit
--with-local-prefix=/home/ryan/x-tools/powerpc-e500v2-linux-gnuspe/powerpc-e500v2-linux-gnuspe/sys-root
--disable-nls --enable-threads=posix --enable-symvers=gnu --enable-c99
--enable-long-long --enable-target-optspace --enable-e500_double
--with-long-double-128 target_alias=powerpc-e500v2-linux-gnuspe
--enable-languages=c,c++,lto
Thread model: posix
gcc version 4.9.0 20130523 (experimental) [trunk revision 199267] (GCC) 


/home/ryan/gnu/gcc/trunk/spe-build/./gcc/xgcc
-B/home/ryan/gnu/gcc/trunk/spe-build/./gcc/
-B/home/ryan/x-tools/powerpc-e500v2-linux-gnuspe/powerpc-e500v2-linux-gnuspe/bin/
-B/home/ryan/x-tools/powerpc-e500v2-linux-gnuspe/powerpc-e500v2-linux-gnuspe/lib/
-isystem
/home/ryan/x-tools/powerpc-e500v2-linux-gnuspe/powerpc-e500v2-linux-gnuspe/include
-isystem
/home/ryan/x-tools/powerpc-e500v2-linux-gnuspe/powerpc-e500v2-linux-gnuspe/sys-include
   -g -Os -O2  -g -Os -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include   -fPIC
-mlong-double-128 -mno-minimal-toc -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector   -fPIC -mlong-double-128 -mno-minimal-toc -I. -I.
-I../.././gcc -I../../../libgcc -I../../../libgcc/. -I../../../libgcc/../gcc
-I../../../libgcc/../include -I../../../libgcc/../libdecnumber/dpd
-I../../../libgcc/../libdecnumber -DHAVE_CC_TLS  -o _powidf2.o -MT _powidf2.o
-MD -MP -MF _powidf2.dep -DL_powidf2 -c ../../../libgcc/libgcc2.c
-fvisibility=hidden -DHIDE_EXPORTS
../../../libgcc/libgcc2.c: In function '__powidf2':
../../../libgcc/libgcc2.c:1777:1: internal compiler error: in dbx_reg_number,
at dwarf2out.c:10507
 }
 ^
0x64377e dbx_reg_number
../../gcc/dwarf2out.c:10507
0x64377e dbx_reg_number
../../gcc/dwarf2out.c:10503
0x66b447 multiple_reg_loc_descriptor
../../gcc/dwarf2out.c:10664
0x66b447 reg_loc_descriptor
../../gcc/dwarf2out.c:10578
0x66eb43 loc_descriptor
../../gcc/dwarf2out.c:12951
0x66ee46 loc_descriptor
../../gcc/dwarf2out.c:12983
0x66f3b5 dw_loc_list_1
../../gcc/dwarf2out.c:13256
0x66b86b dw_loc_list
../../gcc/dwarf2out.c:13512
0x66b86b loc_list_from_tree
../../gcc/dwarf2out.c:13897
0x670de9 add_location_or_const_value_attribute
../../gcc/dwarf2out.c:15391
0x670de9 add_location_or_const_value_attribute
../../gcc/dwarf2out.c:15333
0x671261 gen_formal_parameter_die
../../gcc/dwarf2out.c:17190
0x65f694 gen_decl_die
../../gcc/dwarf2out.c:20191
0x65cb9b gen_subprogram_die
../../gcc/dwarf2out.c:18063
0x65f634 gen_decl_die
../../gcc/dwarf2out.c:20102
0x660688 dwarf2out_function_decl
../../gcc/dwarf2out.c:20492
0x6c1dc4 rest_of_handle_final
../../gcc/final.c:4393
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

[Bug rtl-optimization/57359] wrong code for union access at -O3 on x86_64-linux

[dhazeghi at yahoo dot com]

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

--- Comment #3 from Dara Hazeghi  ---
My apologies for the invalid report and thank you for the clear explanation. 
I've been using frama-c to check validity of the testcases, but clearly in this
case it's not sufficient.

[Bug c++/57378] gnu multiversioning gives assembler error: foo.resolver is already defined

[davidxl at google dot com]

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

--- Comment #3 from davidxl at google dot com ---

Can the resolver node be updated? or a new dispatcher/resolver is created?

The user code looks fine to me, which exposes the implementation limitation.

David

(In reply to Sriraman Tallam from comment #2)
> First, what is happening here is the first call to foo is only seeing 2
> versions and the second call to foo is seeing the 3rd corei7 version. Was
> this intentional?  
> 
> When the dispatcher/resovler decl is created, the cgraph nodes of all
> versions are mapped to this decl. However, the new version decl (corei7
> version) is created later, after the first call, and hence it is not mapped
> to the dispatcher function decl that was previously generated. Hence the
> second call re-generates it.
> 
> There are a couple of issues here. Should the first call to foo () even get
> access to the corei7 version which is not visible? If the corei7 version
> should not be visible to the first call I must create 2 resolvers, one for
> the first call and the other for the second call.  This gets complicated and
> I want to leave this for future enhancement.
> 
> Currently, what is supported is that all calls must see all the versions
> that will be created. I can create a patch to generate an appropriate error
> here  so that this is made clear.

[Bug c++/57378] gnu multiversioning gives assembler error: foo.resolver is already defined

[tmsriram at google dot com]

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

Sriraman Tallam  changed:

   What|Removed |Added

 CC||davidxl at google dot com

--- Comment #2 from Sriraman Tallam  ---
First, what is happening here is the first call to foo is only seeing 2
versions and the second call to foo is seeing the 3rd corei7 version. Was this
intentional?  

When the dispatcher/resovler decl is created, the cgraph nodes of all versions
are mapped to this decl. However, the new version decl (corei7 version) is
created later, after the first call, and hence it is not mapped to the
dispatcher function decl that was previously generated. Hence the second call
re-generates it.

There are a couple of issues here. Should the first call to foo () even get
access to the corei7 version which is not visible? If the corei7 version should
not be visible to the first call I must create 2 resolvers, one for the first
call and the other for the second call.  This gets complicated and I want to
leave this for future enhancement.

Currently, what is supported is that all calls must see all the versions that
will be created. I can create a patch to generate an appropriate error here  so
that this is made clear.

[Bug c++/57248] string parameter to constexpr functions

[sutambe at yahoo dot com]

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

--- Comment #2 from Sumant Tambe  ---
I'm a bit confused. Is the program illformed or supposed to compile but does
not.

[Bug c++/57375] gnu multiversioning selects different version depending on link order

[davidxl at google dot com]

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

--- Comment #3 from davidxl at google dot com ---
(In reply to Sriraman Tallam from comment #2)
> IMO, This is working as expected.
> 
> You define corei7 only in mv12-aux1.cc, so the compilation of mv12.C and
> mv12-aux.cc do not see the corei7 version.  The version resolver function
> that is generated is a comdat function, and there are 2 copies generated for
> the 2 source files with a call to foo, mv12.C and mv12-aux1.cc. However, one
> of the copies is different, that generated when compiling mv12-aux1.cc
> because it has the extra corei7  version.  So, depending on the link order
> whichever comdat copy gets kept either calls the corei7 version or not.
> Usually, the linker keeps the first comdat copy seen so if you put
> mv12-aux1.cc ahead of mv12.C, the corei7 version will be called and the
> reverse will not call it.
> 
> The fix is in the source. Either make every source file see the corei7
> version or hide it from all. 
> 
> The linker can be made to complain that the comdats differ if it could be
> taught about version resolvers. This may be more involved.


There is no need to conditionally declare/define corei7 version in one file
only -- the additional time cost is very small.

David

[Bug libstdc++/54354] TODO extended iomanip manipulators std::get_time and std::put_time (C++11, section 27.7.5)

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini  ---
We are trying to break the ABI for 4.9

[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 #10 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #9 from Jan Hubicka  ---
> Hi,
> the following patch sets IDENTIFIER_TRANSPARENT_ALIAS correctly from 
> lto-symtab
> (correct fix should do the same for variable aliases, too).  Now the testcase
> compiles for
> me on Linux with weakref disabled.  Does it work for you?

It does and is a considerable improvement: it fixes

-FAIL: g++.dg/lto/20091219 cp_lto_20091219_0.o-cp_lto_20091219_0.o link, -O3
-fl
to (internal compiler error)
-UNRESOLVED: g++.dg/lto/20091219 cp_lto_20091219_0.o-cp_lto_20091219_0.o
execute
 -O3 -flto

i.e. PR lto/47333 and several of the failures from this PR, but not all
of them:

 UNRESOLVED: gcc.dg/lto/attr-weakref-1
c_lto_attr-weakref-1_0.o-c_lto_attr-weakr
ef-1_2.o execute -O2 -flto -flto-partition=none 
 FAIL: gcc.dg/lto/attr-weakref-1
c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2
.o link, -O0 -flto -flto-partition=1to1  (internal compiler error)
 UNRESOLVED: gcc.dg/lto/attr-weakref-1
c_lto_attr-weakref-1_0.o-c_lto_attr-weakr
ef-1_2.o execute -O0 -flto -flto-partition=1to1 
-FAIL: gcc.dg/lto/attr-weakref-1
c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2
.o link, -O2 -flto -flto-partition=1to1 
-UNRESOLVED: gcc.dg/lto/attr-weakref-1
c_lto_attr-weakref-1_0.o-c_lto_attr-weakr
ef-1_2.o execute -O2 -flto -flto-partition=1to1 
-FAIL: gcc.dg/lto/attr-weakref-1
c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2
.o link, -O0 -flto 
-UNRESOLVED: gcc.dg/lto/attr-weakref-1
c_lto_attr-weakref-1_0.o-c_lto_attr-weakr
ef-1_2.o execute -O0 -flto 
-FAIL: gcc.dg/lto/attr-weakref-1
c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2
.o link, -O2 -flto
-UNRESOLVED: gcc.dg/lto/attr-weakref-1
c_lto_attr-weakref-1_0.o-c_lto_attr-weakr
ef-1_2.o execute -O2 -flto

i.e. those failures remain:

FAIL: gcc.dg/lto/attr-weakref-1
c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2.o link, -O0 -flto
-flto-partition=none 
UNRESOLVED: gcc.dg/lto/attr-weakref-1
c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2.o execute -O0 -flto
-flto-partition=none 
FAIL: gcc.dg/lto/attr-weakref-1
c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2.o link, -O2 -flto
-flto-partition=none 
UNRESOLVED: gcc.dg/lto/attr-weakref-1
c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2.o execute -O2 -flto
-flto-partition=none 
FAIL: gcc.dg/lto/attr-weakref-1
c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2.o link, -O0 -flto
-flto-partition=1to1  (internal compiler error)
UNRESOLVED: gcc.dg/lto/attr-weakref-1
c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2.o execute -O0 -flto
-flto-partition=1to1 

Btw., the patch has a few formatting issues: indentation and line
length.

Thanks.
Rainer

[Bug c++/57375] gnu multiversioning selects different version depending on link order

[tmsriram at google dot com]

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

Sriraman Tallam  changed:

   What|Removed |Added

 CC||davidxl at google dot com

--- Comment #2 from Sriraman Tallam  ---
IMO, This is working as expected.

You define corei7 only in mv12-aux1.cc, so the compilation of mv12.C and
mv12-aux.cc do not see the corei7 version.  The version resolver function that
is generated is a comdat function, and there are 2 copies generated for the 2
source files with a call to foo, mv12.C and mv12-aux1.cc. However, one of the
copies is different, that generated when compiling mv12-aux1.cc because it has
the extra corei7  version.  So, depending on the link order whichever comdat
copy gets kept either calls the corei7 version or not. Usually, the linker
keeps the first comdat copy seen so if you put mv12-aux1.cc ahead of mv12.C,
the corei7 version will be called and the reverse will not call it.

The fix is in the source. Either make every source file see the corei7 version
or hide it from all. 

The linker can be made to complain that the comdats differ if it could be
taught about version resolvers. This may be more involved.

[Bug c++/57317] [4.8/4.9 Regression] bogus and unsuppressible warning: 'YYY' has a base 'ZZZ' whose type uses the anonymous namespace

[ppluzhnikov at google dot com]

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

--- Comment #3 from Paul Pluzhnikov  ---
(In reply to Jason Merrill from comment #2)
> Fixed the false positive for 4.8.1.

Did you mean "fixed on trunk" ?

On trunk I see

  2013-05-20  Jason Merrill  

PR c++/57317
* decl2.c (determine_visibility): Use PRIMARY_TEMPLATE_P to decide
whether a template has its own args.

but nothing on 4_8-branch.

Can this be back-ported to 4.8?

Thanks,

[Bug c++/57388] [C++11] ICE when function types with ref-qualifiers meet other function types

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug target/49146] segv from libgcc_s when raising an exception, or unwinding stack with backtrace with ms_abi

[rth at gcc dot gnu.org]

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

--- Comment #10 from Richard Henderson  ---
(In reply to Ben Woodard from comment #9)
> Created attachment 30177 [details]
> updated patch that includes __builtin_expect

The patch in #8 is better, and indeed has a bug fix relative to this
in that the condition should be <= DWARF_FRAME_REGISTERS.  Note that
the array size is DWARF_FRAME_REGISTERS + 1.

[Bug target/49146] segv from libgcc_s when raising an exception, or unwinding stack with backtrace with ms_abi

[woodard at redhat dot com]

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

Ben Woodard  changed:

   What|Removed |Added

  Attachment #30127|0   |1
is obsolete||

--- Comment #9 from Ben Woodard  ---
Created attachment 30177
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30177&action=edit
updated patch that includes __builtin_expect

[Bug libstdc++/54354] TODO extended iomanip manipulators std::get_time and std::put_time (C++11, section 27.7.5)

[dmorilha at gmail dot com]

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

Daniel Morilha  changed:

   What|Removed |Added

 CC||dmorilha at gmail dot com

--- Comment #3 from Daniel Morilha  ---
any update on that? is there any workaround? I am trying to parse from ISO 8601
date/time format to C++11 time_points and relied on std::get_time to do the
parsing work. Any ideas on how to accomplish that by other means? Thanks

[Bug c++/57319] [4.8 Regression]: bogus "defaulted move assignment for ... calls a non-trivial move assignment operator for virtual base ..."

[ppluzhnikov at google dot com]

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

--- Comment #3 from Paul Pluzhnikov  ---
Thanks for the fix.
Confirmed for both the reduced test case, and the original source.

Can this be back-ported to 4.8 branch?

[Bug c++/57388] [C++11] ICE when function types with ref-qualifiers meet other function types

[paolo.carlini at oracle dot com]

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

--- Comment #1 from Paolo Carlini  ---
Let's add Jason in CC.

[Bug c++/57384] can't expand a parameter pack into a list of function types or function pointer types

[daniel.kruegler at googlemail dot com]

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

--- Comment #2 from Daniel Krügler  ---
I have the impression that this *could* be related to

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1488

This is unchecked yet, because I'm leaving my place here.

[Bug c++/57388] New: [C++11] ICE when function types with ref-qualifiers meet other function types

[daniel.kruegler at googlemail dot com]

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

Bug ID: 57388
   Summary: [C++11] ICE when function types with ref-qualifiers
meet other function types
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.kruegler at googlemail dot com

While attempting to upgrade std::function for functions with ref-qualifiers I
found that the following code gives an ICE for gcc 4.9.0 20130519
(experimental). The compiler flags are:

-std=c++11 -Wall -pedantic

//--
template struct A
{
  static constexpr bool value = false;
};

template
struct A
{
  static constexpr bool value = true;
};

template
struct A
{
  static constexpr bool value = true;
};

template
struct A
{
  static constexpr bool value = true;
};

static_assert(A::value, "Ouch");
static_assert(A::value, ""); // #1
static_assert(A::value, ""); // #2
//--

The error being (at line #1 or if this is commented on line #2):

"main.cpp|25|internal compiler error: canonical types differ for identical
types void() const && and void() const &&"

The conditions seem to depend on type ordering. The ICE doesn't occur, when the
last three lines are inverted to

static_assert(A::value, "");
static_assert(A::value, "");
static_assert(A::value, "Ouch");

or if typedefs are introduces for functions with ref-qualifiers up-front such
as in the following replacement of the last three lines:

typedef void FClref() const &;
static_assert(A::value, "Ouch");
static_assert(A::value, "");
static_assert(A::value, "");

Interestingly the following variant

typedef void FClref() const &&;
static_assert(A::value, "Ouch");
static_assert(A::value, ""); // #1
static_assert(A::value, "");

still ICEs for #1 (but the previous one didn't ICE on the last line)

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

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Created attachment 30176
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30176&action=edit
more reduced

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

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Created attachment 30175
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30175&action=edit
somewhat reduced testcase

Autoreduced on level 0.

[Bug c++/57387] Passing parameter pack to emplace stl function cause compilation bug

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||4.8.0

--- Comment #1 from Jonathan Wakely  ---
Seems to be fixed for 4.8 already.

[Bug debug/57351] ICE: internal compiler error: in dbx_reg_number, at dwarf2out.c:10507 on arm-none-eabi

[chrbr at gcc dot gnu.org]

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

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #16 from chrbr at gcc dot gnu.org ---
Fixed on trunk #199261.

[Bug libstdc++/57386] ICE: hash-long-double-tr1-aux.cc:54:7: error: unrecognizable insn

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||powerpc-spe
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2013-05-23
   Host||powerpc-spe
 Ever confirmed|0   |1
  Build||powerpc-spe

--- Comment #1 from Richard Biener  ---
Can you check gcc 4.8.1 RC1?

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||xinliangli at gmail dot com

--- Comment #7 from Richard Biener  ---
tree-ssa-uninit.c somehow fails to properly handle abnormal edges.

Index: tree-ssa-uninit.c
===
--- tree-ssa-uninit.c   (revision 199249)
+++ tree-ssa-uninit.c   (working copy)
@@ -1919,7 +1919,8 @@ find_uninit_use (gimple phi, unsigned un
 }

   worklist->safe_push (use_stmt);
-  pointer_set_insert (possibly_undefined_names, phi_result);
+ if (!SSA_NAME_OCCURS_IN_ABNORMAL_PHI (phi_result))
+   pointer_set_insert (possibly_undefined_names, phi_result);
 }
 }

fixes the issue but that doesn't look the very best place to fix it
and it doesn't look fully correct.  It should be enough to not consider
values flowing across abnormal edges - but that's already done (but somehow
not in a complete manner).

I'm trying to reduce the testcase to get a better idea what is going wrong
here.

[Bug c++/57387] New: Passing parameter pack to emplace stl function cause compilation bug

[avraammauridis at gmail dot com]

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

Bug ID: 57387
   Summary: Passing parameter pack to emplace stl function cause
compilation bug
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: avraammauridis at gmail dot com

Created attachment 30174
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30174&action=edit
bug output

g++ -std=c++0x stlstudy.cc
‘
Internal compiler error: Error reporting routines re-entered.
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/cc7q32tE.out file, please attach this to
your bugreport.

[Bug middle-end/57347] [4.8/4.9 Regression] wrong code for bitfield on x86_64-linux at -Os and above

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Jambor  ---
Author: jamborm
Date: Thu May 23 13:25:23 2013
New Revision: 199253

URL: http://gcc.gnu.org/viewcvs?rev=199253&root=gcc&view=rev
Log:
2013-05-23  Martin Jambor  

PR middle-end/57347
* tree.h (contains_bitfld_component_ref_p): Declare.
* tree-sra.c (contains_bitfld_comp_ref_p): Move...
* tree.c (contains_bitfld_component_ref_p): ...here.  Adjust its caller.
* ipa-prop.c (determine_known_aggregate_parts): Check that LHS does
not access a bit-field.  Assert all final offsets are byte-aligned.

testsuite/
* gcc.dg/ipa/pr57347.c: New test.


Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/ipa/pr57347.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/ipa-prop.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
branches/gcc-4_8-branch/gcc/tree-sra.c
branches/gcc-4_8-branch/gcc/tree.c
branches/gcc-4_8-branch/gcc/tree.h

[Bug middle-end/57347] [4.8/4.9 Regression] wrong code for bitfield on x86_64-linux at -Os and above

[jamborm at gcc dot gnu.org]

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

--- Comment #5 from Martin Jambor  ---
Author: jamborm
Date: Thu May 23 13:20:41 2013
New Revision: 199252

URL: http://gcc.gnu.org/viewcvs?rev=199252&root=gcc&view=rev
Log:
2013-05-22  Martin Jambor  

PR middle-end/57347
* tree.h (contains_bitfld_component_ref_p): Declare.
* tree-sra.c (contains_bitfld_comp_ref_p): Move...
* tree.c (contains_bitfld_component_ref_p): ...here.  Adjust its caller.
* ipa-prop.c (determine_known_aggregate_parts): Check that LHS does
not access a bit-field.  Assert all final offsets are byte-aligned.

testsuite/
* gcc.dg/ipa/pr57347.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/ipa/pr57347.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-prop.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-sra.c
trunk/gcc/tree.c
trunk/gcc/tree.h

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

[hubicka at ucw dot cz]

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

--- Comment #9 from Jan Hubicka  ---
Hi,
the following patch sets IDENTIFIER_TRANSPARENT_ALIAS correctly from lto-symtab
(correct fix should do the same for variable aliases, too).  Now the testcase
compiles for
me on Linux with weakref disabled.  Does it work for you?
I can not bootstrap with the weakref disabling hack because of some
transational memory issue, but I think it is independent.

Honza

Index: lto-symtab.c
===
--- lto-symtab.c(revision 199251)
+++ lto-symtab.c(working copy)
@@ -623,6 +623,15 @@ lto_symtab_merge_cgraph_nodes (void)
   if ((cnode->thunk.thunk_p || cnode->alias)
   && cnode->thunk.alias && DECL_P (cnode->thunk.alias))
 cnode->thunk.alias = lto_symtab_prevailing_decl (cnode->thunk.alias);
+#ifndef ASM_OUTPUT_WEAKREF
+  if (lookup_attribute ("weakref", DECL_ATTRIBUTES (cnode->symbol.decl)))
+{
+  IDENTIFIER_TRANSPARENT_ALIAS (DECL_ASSEMBLER_NAME (cnode->symbol.decl))
= 1;
+  TREE_CHAIN (DECL_ASSEMBLER_NAME (cnode->symbol.decl))
+  = (DECL_P (cnode->thunk.alias) ? DECL_ASSEMBLER_NAME
(cnode->thunk.alias)
+ : cnode->thunk.alias);
+}
+#endif
   cnode->symbol.aux = NULL;
 }
   FOR_EACH_VARIABLE (vnode)

[Bug libstdc++/57386] New: ICE: hash-long-double-tr1-aux.cc:54:7: error: unrecognizable insn

[stigge at antcom dot de]

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

Bug ID: 57386
   Summary: ICE: hash-long-double-tr1-aux.cc:54:7: error:
unrecognizable insn
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stigge at antcom dot de

Created attachment 30173
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30173&action=edit
debug file from ICE

ICE: hash-long-double-tr1-aux.cc:54:7: error: unrecognizable insn

Hi,

on powerpc SPE (e500v2) native compiling of gcc 4.8.0 (on current Debian
"sid"), I get:

libtool: compile:  /home/ernie/gcc-4.8-4.8.0/build/./gcc/xgcc -shared-libgcc
-B/home/ernie/gcc-4.8-4.8.0/build/./gcc -nostdinc++
-L/home/ernie/gcc-4.8-4.8.0/build/powerpc-linux-gnuspe/libstdc++-v3/src
-L/home/ernie/gcc-4.8-4.8.0/build/powerpc-linux-gnuspe/libstdc++-v3/src/.libs
-B/usr/powerpc-linux-gnuspe/bin/ -B/usr/powerpc-linux-gnuspe/lib/ -isystem
/usr/powerpc-linux-gnuspe/include -isystem
/usr/powerpc-linux-gnuspe/sys-include -isystem
/home/ernie/gcc-4.8-4.8.0/build/sys-include
-I/home/ernie/gcc-4.8-4.8.0/src/libstdc++-v3/../libgcc
-I/home/ernie/gcc-4.8-4.8.0/build/powerpc-linux-gnuspe/libstdc++-v3/include/powerpc-linux-gnuspe
-I/home/ernie/gcc-4.8-4.8.0/build/powerpc-linux-gnuspe/libstdc++-v3/include
-I/home/ernie/gcc-4.8-4.8.0/src/libstdc++-v3/libsupc++ -D_GLIBCXX_SHARED
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=hash_tr1.lo -gdwarf-4 -g3 -O0 -c
../../../../../../src/libstdc++-v3/src/c++98/hash_tr1.cc  -fPIC -DPIC
-D_GLIBCXX_SHARED -o hash_tr1.o
/bin/bash ../../../libtool --tag CXX --tag disable-shared   --mode=compile
/home/ernie/gcc-4.8-4.8.0/build/./gcc/xgcc -shared-libgcc
-B/home/ernie/gcc-4.8-4.8.0/build/./gcc -nostdinc++
-L/home/ernie/gcc-4.8-4.8.0/build/powerpc-linux-gnuspe/libstdc++-v3/src
-L/home/ernie/gcc-4.8-4.8.0/build/powerpc-linux-gnuspe/libstdc++-v3/src/.libs
-B/usr/powerpc-linux-gnuspe/bin/ -B/usr/powerpc-linux-gnuspe/lib/ -isystem
/usr/powerpc-linux-gnuspe/include -isystem
/usr/powerpc-linux-gnuspe/sys-include -isystem
/home/ernie/gcc-4.8-4.8.0/build/sys-include   
-I/home/ernie/gcc-4.8-4.8.0/src/libstdc++-v3/../libgcc
-I/home/ernie/gcc-4.8-4.8.0/build/powerpc-linux-gnuspe/libstdc++-v3/include/powerpc-linux-gnuspe
-I/home/ernie/gcc-4.8-4.8.0/build/powerpc-linux-gnuspe/libstdc++-v3/include
-I/home/ernie/gcc-4.8-4.8.0/src/libstdc++-v3/libsupc++  -prefer-pic
-D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings
-Wcast-qual -Wabi  -fdiagnostics-show-location=once   -ffunction-sections
-fdata-sections  -frandom-seed=hashtable_tr1.lo -gdwarf-4 -g3 -O0  -c -o
hashtable_tr1.lo ../../../../../../src/libstdc++-v3/src/c++98/hashtable_tr1.cc
libtool: compile:  /home/ernie/gcc-4.8-4.8.0/build/./gcc/xgcc -shared-libgcc
-B/home/ernie/gcc-4.8-4.8.0/build/./gcc -nostdinc++
-L/home/ernie/gcc-4.8-4.8.0/build/powerpc-linux-gnuspe/libstdc++-v3/src
-L/home/ernie/gcc-4.8-4.8.0/build/powerpc-linux-gnuspe/libstdc++-v3/src/.libs
-B/usr/powerpc-linux-gnuspe/bin/ -B/usr/powerpc-linux-gnuspe/lib/ -isystem
/usr/powerpc-linux-gnuspe/include -isystem
/usr/powerpc-linux-gnuspe/sys-include -isystem
/home/ernie/gcc-4.8-4.8.0/build/sys-include
-I/home/ernie/gcc-4.8-4.8.0/src/libstdc++-v3/../libgcc
-I/home/ernie/gcc-4.8-4.8.0/build/powerpc-linux-gnuspe/libstdc++-v3/include/powerpc-linux-gnuspe
-I/home/ernie/gcc-4.8-4.8.0/build/powerpc-linux-gnuspe/libstdc++-v3/include
-I/home/ernie/gcc-4.8-4.8.0/src/libstdc++-v3/libsupc++ -D_GLIBCXX_SHARED
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=hashtable_tr1.lo -gdwarf-4 -g3 -O0 -c
../../../../../../src/libstdc++-v3/src/c++98/hashtable_tr1.cc  -fPIC -DPIC
-D_GLIBCXX_SHARED -o hashtable_tr1.o
/bin/bash ../../../libtool --tag CXX --tag disable-shared   --mode=compile
/home/ernie/gcc-4.8-4.8.0/build/./gcc/xgcc -shared-libgcc
-B/home/ernie/gcc-4.8-4.8.0/build/./gcc -nostdinc++
-L/home/ernie/gcc-4.8-4.8.0/build/powerpc-linux-gnuspe/libstdc++-v3/src
-L/home/ernie/gcc-4.8-4.8.0/build/powerpc-linux-gnuspe/libstdc++-v3/src/.libs
-B/usr/powerpc-linux-gnuspe/bin/ -B/usr/powerpc-linux-gnuspe/lib/ -isystem
/usr/powerpc-linux-gnuspe/include -isystem
/usr/powerpc-linux-gnuspe/sys-include -isystem
/home/ernie/gcc-4.8-4.8.0/build/sys-include   
-I/home/ernie/gcc-4.8-4.8.0/src/libstdc++-v3/../libgcc
-I/home/ernie/gcc-4.8-4.8.0/build/powerpc-linux-gnuspe/libstdc++-v3/include/powerpc-linux-gnuspe
-I/home/ernie/gcc-4.8-4.8.0/build/powerpc-linux-gnuspe/libstdc++-v3/include
-I/home/ernie/gcc-4.8-4.8.0/src/libstdc++-v3/libsupc++  -prefer-pic
-D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings
-Wcast-qual -Wabi  -fdiagnostics-show-location=once  

[Bug target/56446] Generate one fewer relocation when calling a checked weakref function

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #9 from Jan Hubicka  ---
default_binds_local_p should do the job, but it doesn't follow the aliases.
With LTO the weakref target can be brought local and then the weakref can be
translated to normal static alias, but we don't do this at the moment.
I am in progress of making my mind on when this is valid.

Honza

[Bug tree-optimization/57385] [tree-ssa] Possible segfault in fully_constant_vn_reference_p

[aivchenk at gmail dot com]

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

--- Comment #3 from Alexander Ivchenko  ---
Testing is in progress, will send to gcc-patches rigth after that.

[Bug tree-optimization/57385] [tree-ssa] Possible segfault in fully_constant_vn_reference_p

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
True.  Please post to gcc-patches and do a bootstrap/test with it.

[Bug tree-optimization/57380] [4.7/4.8 Regression] GCC 4.9.0 will not vectorize std::max and similar functions

[rguenth at gcc dot gnu.org]

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

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] GCC
   |GCC 4.9.0 will not  |4.9.0 will not vectorize
   |vectorize std::max and  |std::max and similar
   |similar functions   |functions
  Known to fail|4.9.0   |4.8.1

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Thu May 23 12:23:59 2013
New Revision: 199246

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

PR tree-optimization/57380
* tree-ssa-phiprop.c (propagate_with_phi): Do not require at
least one invariant or re-used load.
* passes.c (init_optimization_passes): Move pass_phiprop before
pass_forwprop.

* g++.dg/tree-ssa/pr57380.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/tree-ssa/pr57380.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/passes.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-phiprop.c

[Bug tree-optimization/57385] [tree-ssa] Possible segfault in fully_constant_vn_reference_p

[aivchenk at gmail dot com]

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

--- Comment #1 from Alexander Ivchenko  ---
Following fix could solve the problem:

diff --git a/gcc-4.6/gcc/tree-ssa-sccvn.c b/gcc-4.6/gcc/tree-ssa-sccvn.c
index eb88969..704a86c 100644
--- a/gcc-4.6/gcc/tree-ssa-sccvn.c
+++ b/gcc-4.6/gcc/tree-ssa-sccvn.c
@@ -1115,6 +1115,7 @@ fully_constant_vn_reference_p (vn_reference_t ref)
  == TYPE_MODE (TREE_TYPE (TREE_TYPE (arg0->op0
  && GET_MODE_CLASS (TYPE_MODE (op->type)) == MODE_INT
  && GET_MODE_SIZE (TYPE_MODE (op->type)) == 1
+ && tree_int_cst_sgn (op->op0) >= 0
  && compare_tree_int (op->op0, TREE_STRING_LENGTH (arg0->op0)) < 0)
return build_int_cst_type (op->type,
   (TREE_STRING_POINTER (arg0->op0)

[Bug tree-optimization/57385] New: [tree-ssa] Possible segfault in fully_constant_vn_reference_p

[aivchenk at gmail dot com]

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

Bug ID: 57385
   Summary: [tree-ssa] Possible segfault in
fully_constant_vn_reference_p
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aivchenk at gmail dot com
CC: aivchenk at gmail dot com

The following code crashes android ndk gcc-4.6 on 64 bit windows with segfault 
on at least -O1:

int c;

void foo(int f)
{
int wbi=-1;
c = (f ? "012346":"01345:6008")[wbi];
}

However, potentially it can appear on trunk as well: the reason for this is
that in fully_constant_vn_reference_p we have a bound violation:

1303|   if (arg0->opcode == STRING_CST
1304|   && (TYPE_MODE (op->type)
1305|   == TYPE_MODE (TREE_TYPE (TREE_TYPE (arg0->op0
1306|   && GET_MODE_CLASS (TYPE_MODE (op->type)) == MODE_INT
1307|   && GET_MODE_SIZE (TYPE_MODE (op->type)) == 1
1308|   && compare_tree_int (op->op0, TREE_STRING_LENGTH (arg0->op0)) <
0)
1309| return build_int_cst_type (op->type,
1310+>   (TREE_STRING_POINTER (arg0->op0)
1311| [TREE_INT_CST_LOW (op->op0)]));

here the TREE_INT_CST_LOW (op->op0) is 0x ("wbi" from the code snippet
above and int_cst.low is unsigned). but here:

1308|   && compare_tree_int (op->op0, TREE_STRING_LENGTH (arg0->op0)) <
0)

compare_tree_int thinks that op->op0 equals to "-1" and so the check for bound
violation passes.

I think we need to add another check that op->op0 is not less than zero here.

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

[hubicka at gcc dot gnu.org]

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

--- Comment #8 from Jan Hubicka  ---
Thanks. Obviously RTL world translates through the weakrefs w/o LTO but not
with LTO.  I will look into it.

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

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Created attachment 30172
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30172&action=edit
preprocessed source

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #5 from Richard Biener  ---
Confirmed with -O2 -Wall.

[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 #4 from hmb  ---
I am attaching the all preprocessed source code of GDB
here is the link https://www.dropbox.com/s/ldml34p3lov867w/gcc-bug.zip

[Bug target/57341] [4.8/4.9 Regression] wrong code on x86_64-linux at -O3 in 32-bit mode

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #10 from Richard Biener  ---
Author: rguenth
Date: Thu May 23 10:36:55 2013
New Revision: 199242

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

PR rtl-optimization/57341
* ira.c (validate_equiv_mem_from_store): Use anti_dependence
instead of true_dependence.

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

Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr57341.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/ira.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/57381] [4.8 Regression] array of volatile pointers hangs gcc

[rguenth at gcc dot gnu.org]

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

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] array  |[4.8 Regression] array of
   |of volatile pointers hangs  |volatile pointers hangs gcc
   |gcc |
  Known to fail||4.8.1

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Thu May 23 10:08:33 2013
New Revision: 199240

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

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

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr57381.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

[Bug target/57341] [4.8/4.9 Regression] wrong code on x86_64-linux at -O3 in 32-bit mode

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Author: rguenth
Date: Thu May 23 08:37:24 2013
New Revision: 199237

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

PR rtl-optimization/57341
* ira.c (validate_equiv_mem_from_store): Use anti_dependence
instead of true_dependence.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr57341.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira.c
trunk/gcc/testsuite/ChangeLog

[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 #7 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #2 from Rainer Orth  ---
> (In reply to Jan Hubicka from comment #1)
>> I solved the infinite loop problem on plugin enabled setups with
>> http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00847.html
>> Are you still seeing the infinite loop?
>
> My last bootstrap with gld was at rev 199009, i.e. before that patch went in. 
> New ones are currently running (as/ld though, thus it will take a bit to 
> verify
> that the failures with gld are gone).

That gas/gld bootstrap has now completed and the failures are indeed gone.

Thanks.
Rainer

[Bug rtl-optimization/57344] [4.7 Regression] wrong code with pragma pack(1) and -O1 on x86

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Known to work||4.8.1, 4.9.0
Summary|[4.7/4.8/4.9 Regression]|[4.7 Regression] wrong code
   |wrong code with pragma  |with pragma pack(1) and -O1
   |pack(1) and -O1 on x86  |on x86
  Known to fail|4.9.0   |

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Thu May 23 09:17:34 2013
New Revision: 199238

URL: http://gcc.gnu.org/viewcvs?rev=199238&root=gcc&view=rev
Log:
PR middle-end/57344
* expmed.c (store_split_bit_field): If op0 is a REG or
SUBREG of a REG, don't lower unit.  Handle unit not being
always BITS_PER_WORD.

* gcc.c-torture/execute/pr57344-1.c: New test.
* gcc.c-torture/execute/pr57344-2.c: New test.
* gcc.c-torture/execute/pr57344-3.c: New test.
* gcc.c-torture/execute/pr57344-4.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr57344-1.c
trunk/gcc/testsuite/gcc.c-torture/execute/pr57344-2.c
trunk/gcc/testsuite/gcc.c-torture/execute/pr57344-3.c
trunk/gcc/testsuite/gcc.c-torture/execute/pr57344-4.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/expmed.c
trunk/gcc/testsuite/ChangeLog

Author: jakub
Date: Thu May 23 09:18:57 2013
New Revision: 199239

URL: http://gcc.gnu.org/viewcvs?rev=199239&root=gcc&view=rev
Log:
PR middle-end/57344
* expmed.c (store_split_bit_field): If op0 is a REG or
SUBREG of a REG, don't lower unit.  Handle unit not being
always BITS_PER_WORD.

* gcc.c-torture/execute/pr57344-1.c: New test.
* gcc.c-torture/execute/pr57344-2.c: New test.
* gcc.c-torture/execute/pr57344-3.c: New test.
* gcc.c-torture/execute/pr57344-4.c: New test.

Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.c-torture/execute/pr57344-1.c
branches/gcc-4_8-branch/gcc/testsuite/gcc.c-torture/execute/pr57344-2.c
branches/gcc-4_8-branch/gcc/testsuite/gcc.c-torture/execute/pr57344-3.c
branches/gcc-4_8-branch/gcc/testsuite/gcc.c-torture/execute/pr57344-4.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/expmed.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

Fixed for 4.8/4.9+ so far.

[Bug tree-optimization/57380] [4.7/4.8/4.9 Regression] GCC 4.9.0 will not vectorize std::max and similar functions

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
There was a deliberate change to require at least one invariant address or
a re-use of a previous load.

 2010-07-08  Richard Guenther  

+   PR tree-optimization/44831
+   * tree-ssa-phiprop.c (phiprop_insert_phi): Properly build
+   a MEM_REF preserving TBAA info of the original dereference.
+   Dereference the original pointer if the address is not
+   invariant.
+   (propagate_with_phi): Fixup type checks wrt MEM_REFs.  Require
+   at least one invariant address that we are going to dereference.

I have a fix.

[Bug c++/57384] can't expand a parameter pack into a list of function types or function pointer types

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Eric Niebler from comment #0)
> I believe all of the following 4 test cases should pass:

I'll leave it to someone else to rule on that, they make my head hurt ;)

I will note that this works:

  using type2 = list;

and this works:

  using type4 = list;

And of course all these work:

  template 
using F = int(X);   
  using type1 = void(F...); 
  using type2 = list...>;
  template 
using Fp = int(*)(X);   
  using type3 = void(Fp...);   
  using type4 = list...>;

[Bug c++/57378] gnu multiversioning gives assembler error: foo.resolver is already defined

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-05-23
 CC||tmsriram at google dot com
Version|unknown |4.8.0
 Ever confirmed|0   |1

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

[Bug target/57379] [4.9 Regression]: Segfault in invalidate_any_buried_refs (x=0x0) at ../../gcc-svn/trunk/gcc/gcse.c:3850

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug tree-optimization/57380] [4.7/4.8/4.9 Regression] GCC 4.9.0 will not vectorize std::max and similar functions

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-05-23
  Known to work||4.5.4
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |4.7.4
Summary|GCC 4.9.0 will not  |[4.7/4.8/4.9 Regression]
   |vectorize std::max and  |GCC 4.9.0 will not
   |similar functions   |vectorize std::max and
   ||similar functions
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
For some reason phiprop doesn't work here.  I'll investigate, but I guess
it is because the addresses are not constant but depend on the loop IV:

  :
  _3 = &b.data[i_2];
  _4 = &a.data[i_2];
  _10 = MEM[(const int &)&a].data[i_2];
  _11 = MEM[(const int &)&b].data[i_2];
  if (_10 < _11)
goto ;
  else
goto ;

  :

  :
  # iftmp.0_12 = PHI <_3(3), _4(4)>

  :
  _6 = *iftmp.0_12;

[Bug target/53854] ICE in find_constant_pool_ref

[dan at danny dot cz]

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

--- Comment #6 from Dan Horák  ---
FYI the error is still present in
gcc version 4.8.0 20130412 (Red Hat 4.8.0-2) (GCC) 

Target: s390-redhat-linux

[Bug rtl-optimization/57381] [4.8/4.9 Regression] array of volatile pointers hangs gcc

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
The usual &a.b.c with volatile fields do not compare equal thing ...

Value numbering l_61$0$0$0_6 stmt = l_61$0$0$0_6 = MEM[(volatile int *[5][2][2]
*)&*.LC0];
RHS MEM[(volatile int *[5][2][2] *)&*.LC0] simplified to &s.f2.f0 has constants
1
Setting value number of l_61$0$0$0_6 to &s.f2.f0 (changed)

and &s.f2.f0 never comparing equal because we unshare it in every iteration.
Which is because operand_equal_p compares the FIELD_DECLs of COMPONENT_REFs
after clearing OEP_CONSTANT_ADDRESS_OF but those have TREE_SIDE_EFFECTS set
as well and we hit

  /* If ARG0 and ARG1 are the same SAVE_EXPR, they are necessarily equal.
 We don't care about side effects in that case because the SAVE_EXPR
 takes care of that for us. In all other cases, two expressions are
 equal if they have no side effects.  If we have two identical
 expressions with side effects that should be treated the same due
 to the only side effects being identical SAVE_EXPR's, that will
 be detected in the recursive calls below.
 If we are taking an invariant address of two identical objects
 they are necessarily equal as well.  */
  if (arg0 == arg1 && ! (flags & OEP_ONLY_CONST)
  && (TREE_CODE (arg0) == SAVE_EXPR
  || (flags & OEP_CONSTANT_ADDRESS_OF)
  || (! TREE_SIDE_EFFECTS (arg0) && ! TREE_SIDE_EFFECTS (arg1
return 1;

[Bug rtl-optimization/57381] [4.8/4.9 Regression] array of volatile pointers hangs gcc

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-05-23
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |4.8.1
Summary|array of volatile pointers  |[4.8/4.9 Regression] array
   |hangs gcc   |of volatile pointers hangs
   ||gcc
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Mine.  Hangs in

0x00caeac6 in visit_use (use=0x76e3eee8)
at /space/rguenther/src/svn/trunk/gcc/tree-ssa-sccvn.c:3469
3469changed = visit_reference_op_store (lhs, rhs1, stmt);