[Bug fortran/18918] Eventually support Fortran 2008's coarrays [co-arrays]

[dominiq at lps dot ens.fr]

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

--- Comment #61 from Dominique d'Humieres dominiq at lps dot ens.fr 
2011-06-21 06:20:29 UTC ---
 On Linux/x86, I got

 FAIL: gfortran.dg/coarray_lock_3.f90  -O   (test for errors, line 72)

On x86_64-apple-darwin10 too. The following reduced code does not give the
expected error:

subroutine lock_test2
  use iso_fortran_env
  implicit none
  type t
  end type t
  type(t) :: x
  type(lock_type), save :: lock[*],lock2(2)[*]
  lock(lock)
  lock(lock2(1))
  lock(lock[1]) ! { dg-error must be a scalar coarray of type LOCK_TYPE } !
-- no error
end subroutine lock_test2

[Bug middle-end/49139] always_inline attribute inconsistencies on failure

[chrbr at gcc dot gnu.org]

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

--- Comment #10 from chrbr at gcc dot gnu.org 2011-06-21 06:42:08 UTC ---
Author: chrbr
Date: Tue Jun 21 06:42:05 2011
New Revision: 175239

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175239
Log:
PR middle-end/49139 fix always_inline diagnostics

Added:
trunk/gcc/testsuite/gcc.dg/fail_always_inline.c
Modified:
trunk/gcc/cgraphunit.c
trunk/gcc/ipa-inline-transform.c
trunk/gcc/testsuite/g++.dg/ipa/devirt-7.C
trunk/gcc/testsuite/gcc.dg/20051201-1.c
trunk/gcc/testsuite/gcc.dg/always_inline.c
trunk/gcc/testsuite/gcc.dg/always_inline2.c
trunk/gcc/testsuite/gcc.dg/always_inline3.c
trunk/gcc/testsuite/gcc.dg/debug/pr41264-1.c
trunk/gcc/testsuite/gcc.dg/inline-22.c
trunk/gcc/testsuite/gcc.dg/lto/20090218-1_0.c
trunk/gcc/testsuite/gcc.dg/lto/20090218-1_1.c
trunk/gcc/testsuite/gcc.dg/torture/pta-structcopy-1.c
trunk/gcc/testsuite/gcc.dg/uninit-pred-5_a.c
trunk/gcc/testsuite/gcc.dg/uninit-pred-5_b.c
trunk/gcc/tree-inline.c

[Bug middle-end/49139] always_inline attribute inconsistencies on failure

[chrbr at gcc dot gnu.org]

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

--- Comment #11 from chrbr at gcc dot gnu.org 2011-06-21 06:43:28 UTC ---
Author: chrbr
Date: Tue Jun 21 06:43:26 2011
New Revision: 175240

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175240
Log:
PR middle-end/49139 fix always_inline diagnostics

Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/49139] always_inline attribute inconsistencies on failure

[chrbr at gcc dot gnu.org]

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

--- Comment #12 from chrbr at gcc dot gnu.org 2011-06-21 06:45:09 UTC ---
Author: chrbr
Date: Tue Jun 21 06:45:05 2011
New Revision: 175241

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175241
Log:
PR middle-end/49139 PR other/43564 make sure the inline function is inlined

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-inline.c

[Bug other/43564] ICE on code with optimize attribute and inlining

[chrbr at gcc dot gnu.org]

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

--- Comment #10 from chrbr at gcc dot gnu.org 2011-06-21 06:45:09 UTC ---
Author: chrbr
Date: Tue Jun 21 06:45:05 2011
New Revision: 175241

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175241
Log:
PR middle-end/49139 PR other/43564 make sure the inline function is inlined

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-inline.c

[Bug middle-end/49139] always_inline attribute inconsistencies on failure

[chrbr at gcc dot gnu.org]

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

--- Comment #13 from chrbr at gcc dot gnu.org 2011-06-21 06:48:50 UTC ---
Author: chrbr
Date: Tue Jun 21 06:48:45 2011
New Revision: 175242

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175242
Log:
PR middle-end/49139 fix always_inline diagnostics

Added:
trunk/gcc/testsuite/gcc.dg/fail_always_inline2.c
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/inline_1.c
trunk/gcc/testsuite/gcc.dg/inline_2.c
trunk/gcc/testsuite/gcc.dg/inline_3.c
trunk/gcc/testsuite/gcc.dg/inline_4.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr40087.c

[Bug c++/49482] New: [regression][4.6.1-RC-20110620][C++0x] unused parameter warning on lambda in function template

[gintensubaru at gmail dot com]

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

   Summary: [regression][4.6.1-RC-20110620][C++0x] unused
parameter warning on lambda in function template
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gintensub...@gmail.com


testsuite (bug.cc):

templateclass T
void f() {
  []( bool b ){ return b; };
}

int main()
{
  fint();
}


message:

bug.cc: In static member function 'static bool f() [with T =
int]::lambda(bool)
::_FUN(bool)':
bug.cc:3:4:   instantiated from 'f() [with T = int]::lambda(bool)'
bug.cc:3:3:   instantiated from 'void f() [with T = int]'
bug.cc:8:10:   instantiated from here
bug.cc:3:14: warning: parameter 'b' set but not used
[-Wunused-but-set-parameter
]


version:

gcc-4.6.1-RC-20110620


note:

gcc-4.6-20110527 doesn't raise such a warning.

[Bug middle-end/49478] ice in expand_widen_pattern_expr with -O3

[irar at il dot ibm.com]

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

Ira Rosen irar at il dot ibm.com changed:

   What|Removed |Added

 CC||irar at il dot ibm.com

--- Comment #2 from Ira Rosen irar at il dot ibm.com 2011-06-21 07:33:15 UTC 
---
I am testing this patch:

Index: tree-vect-loop.c
===
--- tree-vect-loop.c(revision 175238)
+++ tree-vect-loop.c(working copy)
@@ -4591,6 +4591,29 @@ vectorizable_reduction (gimple stmt, gim
   return false;
 }

+  /* In case of widenning multiplication by a constant, we update the type
+ of the constant to be the type of the other operand.  We check that the
+ constant fits the type in the pattern recognition pass.  */
+  if (code == DOT_PROD_EXPR
+   !types_compatible_p (TREE_TYPE (ops[0]), TREE_TYPE (ops[1])))
+{
+  if (TREE_CODE (ops[0]) == INTEGER_CST)
+ops[0] = build_int_cst_wide (TREE_TYPE (ops[1]),
+TREE_INT_CST_LOW (ops[0]),
+TREE_INT_CST_HIGH (ops[0]));
+  else if (TREE_CODE (ops[1]) == INTEGER_CST)
+ops[1] = build_int_cst_wide (TREE_TYPE (ops[0]),
+TREE_INT_CST_LOW (ops[1]),
+TREE_INT_CST_HIGH (ops[1]));
+  else
+{
+  if (vect_print_dump_info (REPORT_DETAILS))
+fprintf (vect_dump, invalid types in dot-prod);
+
+  return false;
+}
+}
+
   if (!vec_stmt) /* transformation not required.  */
 {
   if (!vect_model_reduction_cost (stmt_info, epilog_reduc_code, ncopies))

[Bug fortran/18918] Eventually support Fortran 2008's coarrays [co-arrays]

[burnus at gcc dot gnu.org]

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

--- Comment #62 from Tobias Burnus burnus at gcc dot gnu.org 2011-06-21 
07:34:52 UTC ---
(In reply to comment #61)
  FAIL: gfortran.dg/coarray_lock_3.f90  -O   (test for errors, line 72)
 The following reduced code does not give the expected error:
   lock(lock[1]) ! { dg-error must be a scalar coarray of type LOCK_TYPE } !

Thanks for the report. There are three bugs:

a) The code is valid and there should be no dg-error. Seemingly, I forget to
apply the update patch for that file.

b) The wording of the error message is wrong. As the error message correctly
states, lock[1] is *not* a coarray - but no coarray is required. Being
coindexed or being the component of a coarray is also sufficient.

c) LOCK(a%lock) in the following example is valid, but it is rejected:

use iso_fortran_env
implicit none
type t
  type(lock_type) :: lock
end type t

type t2
  type(lock_type), allocatable :: lock(:)[:]
end type t2

type(t) :: a[*]
type(t2) :: b

allocate(b%lock(1)[*])
LOCK(a%lock)! FAILS
LOCK(a[1]%lock)

LOCK(b%lock(1))
LOCK(b%lock(1)[1])
end

[Bug rtl-optimization/49472] [4.7 regression] Compiler segfault on valid code

[jakub at gcc dot gnu.org]

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

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot
   ||gnu.org

--- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-21 
07:51:34 UTC ---
--- gcc/simplify-rtx.c.jj2011-06-08 08:53:15.0 +0200
+++ gcc/simplify-rtx.c2011-06-21 09:46:27.0 +0200
@@ -686,13 +686,13 @@ simplify_unary_operation_1 (enum rtx_cod
   return simplify_gen_binary (MINUS, mode, temp, XEXP (op, 1));
 }

-  /* (neg (mult A B)) becomes (mult (neg A) B).
+  /* (neg (mult A B)) becomes (mult A (neg B)).
  This works even for floating-point values.  */
   if (GET_CODE (op) == MULT
!HONOR_SIGN_DEPENDENT_ROUNDING (mode))
 {
-  temp = simplify_gen_unary (NEG, mode, XEXP (op, 0), mode);
-  return simplify_gen_binary (MULT, mode, temp, XEXP (op, 1));
+  temp = simplify_gen_unary (NEG, mode, XEXP (op, 1), mode);
+  return simplify_gen_binary (MULT, mode, XEXP (op, 0), temp);
 }

   /* NEG commutes with ASHIFT since it is multiplication.  Only do

stops the moving of the operands around, with this it keeps being called with
the same operands again and again, but still an endless recursion.  Eric, any
preferences where to prevent this from happening?

[Bug rtl-optimization/49472] [4.7 regression] Compiler segfault on valid code

[ebotcazou at gcc dot gnu.org]

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

--- Comment #10 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-06-21 
08:31:22 UTC ---
 --- gcc/simplify-rtx.c.jj2011-06-08 08:53:15.0 +0200
 +++ gcc/simplify-rtx.c2011-06-21 09:46:27.0 +0200
 @@ -686,13 +686,13 @@ simplify_unary_operation_1 (enum rtx_cod
return simplify_gen_binary (MINUS, mode, temp, XEXP (op, 1));
  }
 
 -  /* (neg (mult A B)) becomes (mult (neg A) B).
 +  /* (neg (mult A B)) becomes (mult A (neg B)).
   This works even for floating-point values.  */
if (GET_CODE (op) == MULT
 !HONOR_SIGN_DEPENDENT_ROUNDING (mode))
  {
 -  temp = simplify_gen_unary (NEG, mode, XEXP (op, 0), mode);
 -  return simplify_gen_binary (MULT, mode, temp, XEXP (op, 1));
 +  temp = simplify_gen_unary (NEG, mode, XEXP (op, 1), mode);
 +  return simplify_gen_binary (MULT, mode, XEXP (op, 0), temp);
  }
 
/* NEG commutes with ASHIFT since it is multiplication.  Only do
 
 stops the moving of the operands around, with this it keeps being called with
 the same operands again and again, but still an endless recursion.  Eric, any
 preferences where to prevent this from happening?

ISTM that pursuing in the above way, according to swap_commutative_operands_p,
is a sensible approach, so I'd remove the simplify_binary_operation_1 bits.

[Bug fortran/49479] [4.6/4.7 Regression] reshape / optionals / zero sized arrays

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2011-06-21 
08:58:31 UTC ---
(In reply to comment #3)
 I think gfortran's convention is - and also TR 29113 requires - that the
 addr_expr is not NULL if the variable is allocated - even if it is zero sized.

The TR 29113 draft (Interop ML version) has (5.2.3 CFI_cdesc_t)
ftp://ftp.nag.co.uk/sc22wg5/N1851-N1900/N1854.pdf

void * base addr; If the object is an unallocated allocatable or a pointer
that is disassociated, the value is NULL. If the object has zero size, the
value is not NULL but is otherwise processor-dependent. Otherwise [...]


And trans.c has for gfc_call_malloc:
/* Call malloc to allocate size bytes of memory, with special conditions:
  + if size == 0, return a malloced area of size 1,


If one looks at RESHAPE in the library:
 
http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgfortran/intrinsics/reshape_generic.c;hb=HEAD
one sees:

  86   if (ret-data == NULL)
  87 {
  88   rs = 1;
  89   for (n = 0; n  rdim; n++)
  90 {
  91   rex = shape_data[n];
  93   GFC_DIMENSION_SET(ret-dim[n],0,rex - 1,rs);
  95   rs *= rex;
  96 }
  98   ret-data = internal_malloc_size ( rs * size );

Thus, if shape_data[n] == 0 -- which is here the case --, rs == 0 and thus
one calls malloc with zero size. POSIX states:
If size is 0, either a null pointer or a unique pointer that can be
successfully passed to free() shall be returned.

Hence, the rs*size should be replaced by MAX(1, rs*size).

I think other intrinsics will have the same problem.

[Bug testsuite/49443] gcc.dg/vect/vect-peel-3.c and vect-peel-4.c fail on IA64 after testsuite change

[irar at gcc dot gnu.org]

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

--- Comment #4 from irar at gcc dot gnu.org 2011-06-21 09:01:29 UTC ---
Author: irar
Date: Tue Jun 21 09:01:23 2011
New Revision: 175246

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175246
Log:

PR testsuite/49443
* gcc.dg/vect/vect-peel-3.c: Expect to fail on vect_no_align
targets.
* gcc.dg/vect/vect-peel-4.c: Likewise.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/vect-peel-3.c
trunk/gcc/testsuite/gcc.dg/vect/vect-peel-4.c

[Bug testsuite/49443] gcc.dg/vect/vect-peel-3.c and vect-peel-4.c fail on IA64 after testsuite change

[irar at il dot ibm.com]

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

Ira Rosen irar at il dot ibm.com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #5 from Ira Rosen irar at il dot ibm.com 2011-06-21 09:02:39 UTC 
---
Fixed.

[Bug tree-optimization/49483] New: unable to vectorize code equivalent to scalbnf

[vincenzo.innocente at cern dot ch]

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

   Summary: unable to vectorize code equivalent to scalbnf
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincenzo.innoce...@cern.ch


I'm trying to write simplified versions of trigonometric and trascendental
functions that gcc can auto-vectorize.

at the moment I'm blocked with the vectorization of scalbnf
I'm using code equivalent to the one in glibc 
sysdeps/ieee754/flt-32/s_scalbnf.c
and
math/math_private.h

which in my c++ version reads

cat vldexpf.cc
inline float i2f(int x) {
  union { float f; int i; } tmp;
  tmp.i=x;
 return tmp.f;
}
inline float vect_ldexpf(float x, int n) {
  n =(n+0x7f)23;
  return x * i2f(n);
}

float __attribute__ ((aligned(16))) a[1024];
float __attribute__ ((aligned(16))) b[1024];
float __attribute__ ((aligned(16))) c[1024];

void tV() {
  for (int i=0; i!=1024; ++i) {
float z = a[i];
int n = b[i];
c[i] = vect_ldexpf(z,n);
  }
}

compiling it produces

c++ -Ofast  -c vldexpf.cc -msse4.2 -ftree-vectorizer-verbose=7

vldexpf.cc:16: note: vect_model_load_cost: aligned.
vldexpf.cc:16: note: vect_get_data_access_cost: inside_cost = 1, outside_cost =
0.
vldexpf.cc:16: note: vect_model_load_cost: aligned.
vldexpf.cc:16: note: vect_get_data_access_cost: inside_cost = 2, outside_cost =
0.
vldexpf.cc:16: note: vect_model_store_cost: aligned.
vldexpf.cc:16: note: vect_get_data_access_cost: inside_cost = 3, outside_cost =
0.
vldexpf.cc:16: note: vect_model_load_cost: aligned.
vldexpf.cc:16: note: vect_model_load_cost: inside_cost = 1, outside_cost = 0 .
vldexpf.cc:16: note: vect_model_load_cost: aligned.
vldexpf.cc:16: note: vect_model_load_cost: inside_cost = 1, outside_cost = 0 .
vldexpf.cc:16: note: vect_model_simple_cost: inside_cost = 1, outside_cost = 1
.
vldexpf.cc:16: note: vect_model_simple_cost: inside_cost = 1, outside_cost = 1
.
vldexpf.cc:16: note: not vectorized: relevant stmt not supported: D.2243_14 =
VIEW_CONVERT_EXPRfloat(n_13);

vldexpf.cc:15: note: vectorized 0 loops in function.

I'm using

c++ -v
Using built-in specs.
COLLECT_GCC=c++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin10.7.0/4.7.0/lto-wrapper
Target: x86_64-apple-darwin10.7.0
Configured with: ./configure --enable-languages=c,c++,fortran --enable-lto
--with-build-config=bootstrap-lto CFLAGS='-O2 -ftree-vectorize -fPIC'
CXXFLAGS='-O2 -fPIC -ftree-vectorize -fvisibility-inlines-hidden'
Thread model: posix
gcc version 4.7.0 20110528 (experimental) (GCC)

[Bug gcov-profile/49484] New: gcov crash if two(or more) forks happen at the same time

[cobexer at gmail dot com]

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

   Summary: gcov crash if two(or more) forks happen at the same
time
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: gcov-profile
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: cobe...@gmail.com


gcov crashes the application if the application forks in multiple threads at
the same time.

#0  0x003612430265 in raise () from /lib64/libc.so.6
#1  0x003612431d10 in abort () from /lib64/libc.so.6
#2  0x0085e2ae in __gcov_open ()
#3  0x0085e559 in gcov_exit ()
#4  0x0085ef7f in __gcov_flush ()
#5  0x0085f019 in __gcov_fork ()


#0  0x0085effc in __gcov_merge_add ()
#1  0x0085ef1a in gcov_exit ()
#2  0x0085ef7f in __gcov_flush ()
#3  0x0085f019 in __gcov_fork ()

gcov (GCC) 4.1.2 20080704 (Red Hat 4.1.2-48)

uname -a
Linux hostname 2.6.18-194.el5 #1 SMP Fri Apr 2 14:58:14 EDT 2010 x86_64 x86_64
x86_64 GNU/Linux

[Bug middle-end/48493] [ICE] [ARM] in expand_expr_addr_expr_1, at expr.c

[mikpe at it dot uu.se]

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

Mikael Pettersson mikpe at it dot uu.se changed:

   What|Removed |Added

 CC||mikpe at it dot uu.se,
   ||rguenth at gcc dot gnu.org

--- Comment #4 from Mikael Pettersson mikpe at it dot uu.se 2011-06-21 
09:04:00 UTC ---
It's triggered by the big MEM-REF merge in r161655:

Author: rguenth
Date: Thu Jul  1 08:49:19 2010
New Revision: 161655

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161655
Log:
2010-07-01  Richard Guenther  rguent...@suse.de

PR middle-end/42834
PR middle-end/44468
* doc/gimple.texi (is_gimple_mem_ref_addr): Document.
* doc/generic.texi (References to storage): Document MEM_REF.
* tree-pretty-print.c (dump_generic_node): Handle MEM_REF.
...

[Bug gcov-profile/49484] gcov crash if two(or more) forks happen at the same time

[mikpe at it dot uu.se]

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

--- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2011-06-21 
09:24:20 UTC ---
gcc-4.1.2 is no longer supported upstream.  Please try again with gcc-4.3.5 or
newer, preferably gcc-4.6.0 or 4.5.3.  Or report this to Red Hat who delivered
your 4.1.2-based compiler.

[Bug tree-optimization/49483] unable to vectorize code equivalent to scalbnf

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.06.21 09:26:57
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-21 
09:26:57 UTC ---
We at the moment only handle sign-changes, but obviously
we in principle can handle all VIEW_CONVERT_EXPRs.

I'm testing the following, which works for your testcase.

Index: gcc/tree-vect-stmts.c
===
--- gcc/tree-vect-stmts.c   (revision 175205)
+++ gcc/tree-vect-stmts.c   (working copy)
@@ -2089,6 +2089,9 @@ vectorizable_assignment (gimple stmt, gi
   else
 return false;

+  if (code == VIEW_CONVERT_EXPR)
+op = TREE_OPERAND (op, 0);
+
   if (!vect_is_simple_use_1 (op, loop_vinfo, bb_vinfo,
 def_stmt, def, dt[0], vectype_in))
 {
@@ -2099,7 +2102,8 @@ vectorizable_assignment (gimple stmt, gi

   /* We can handle NOP_EXPR conversions that do not change the number
  of elements or the vector size.  */
-  if (CONVERT_EXPR_CODE_P (code)
+  if ((CONVERT_EXPR_CODE_P (code)
+   || code == VIEW_CONVERT_EXPR)
(!vectype_in
  || TYPE_VECTOR_SUBPARTS (vectype_in) != nunits
  || (GET_MODE_SIZE (TYPE_MODE (vectype))
@@ -2134,7 +2138,8 @@ vectorizable_assignment (gimple stmt, gi
   /* Arguments are ready. create the new vector stmt.  */
   FOR_EACH_VEC_ELT (tree, vec_oprnds, i, vop)
{
-if (CONVERT_EXPR_CODE_P (code))
+if (CONVERT_EXPR_CODE_P (code)
+|| code == VIEW_CONVERT_EXPR)
   vop = build1 (VIEW_CONVERT_EXPR, vectype, vop);
  new_stmt = gimple_build_assign (vec_dest, vop);
  new_temp = make_ssa_name (vec_dest, new_stmt);

[Bug fortran/49479] [4.6/4.7 Regression] reshape / optionals / zero sized arrays

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2011-06-21 
09:30:32 UTC ---
Actually, thinking about it: RESHAPE(allocatable_array, shape) is *not*
allocatable.

trans-expr.c has:
 147   if (!sym-attr.pointer  !sym-attr.allocatable
 148sym-as  sym-as-type == AS_ASSUMED_SHAPE
 149(gfc_option.allow_std  GFC_STD_F2008) != 0)

One probably needs to check the actual argument, i.e. gfc_expr_attr(actual)
with allocatable or pointer attribute - or type being C_PTR (including
C_NULL_PTR).

For the latter:
   expr-ts.type == BT_DERIVED  expr-ts.u.derived
 expr-ts.u.derived-attr.is_iso_c
 ??? (some check for ISOCBINDING_PTR)

[Bug target/49480] internal compiler error: output_operand: invalid expression as operand

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Target||i?86-*-*
 Status|UNCONFIRMED |NEW
   Keywords||ice-on-valid-code
   Last reconfirmed||2011.06.21 09:36:34
  Component|c++ |target
 Ever Confirmed|0   |1
  Known to fail||4.1.2, 4.3.5, 4.4.5, 4.5.2,
   ||4.6.0

--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-21 
09:36:34 UTC ---
Confirmed.  The code has undefined behavior at runtime.

[Bug middle-end/49478] ice in expand_widen_pattern_expr with -O3

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-21 
09:39:47 UTC ---
(In reply to comment #2)
 I am testing this patch:
 
 Index: tree-vect-loop.c
 ===
 --- tree-vect-loop.c(revision 175238)
 +++ tree-vect-loop.c(working copy)
 @@ -4591,6 +4591,29 @@ vectorizable_reduction (gimple stmt, gim
return false;
  }
 
 +  /* In case of widenning multiplication by a constant, we update the type
 + of the constant to be the type of the other operand.  We check that the
 + constant fits the type in the pattern recognition pass.  */
 +  if (code == DOT_PROD_EXPR
 +   !types_compatible_p (TREE_TYPE (ops[0]), TREE_TYPE (ops[1])))
 +{
 +  if (TREE_CODE (ops[0]) == INTEGER_CST)
 +ops[0] = build_int_cst_wide (TREE_TYPE (ops[1]),
 +TREE_INT_CST_LOW (ops[0]),
 +TREE_INT_CST_HIGH (ops[0]));
 +  else if (TREE_CODE (ops[1]) == INTEGER_CST)
 +ops[1] = build_int_cst_wide (TREE_TYPE (ops[0]),
 +TREE_INT_CST_LOW (ops[1]),
 +TREE_INT_CST_HIGH (ops[1]));
 +  else
 +{
 +  if (vect_print_dump_info (REPORT_DETAILS))
 +fprintf (vect_dump, invalid types in dot-prod);
 +
 +  return false;
 +}
 +}

Please instead simply do

   if (code == DOT_PROD_EXPR
!types_compatible_p (TREE_TYPE (ops[0]), TREE_TYPE (ops[1])))
 {
   if (TREE_CODE (ops[0]) == INTEGER_CST)
 ops[0] = fold_convert (TREE_TYPE (ops[1]), ops[0]);
   else if (TREE_CODE (ops[1]) == INTEEGER_CST)
 ops[1] = fold_convert (TREE_TYPE (ops[0]), ops[1]);
 +  else
 +{
 +  if (vect_print_dump_info (REPORT_DETAILS))
 +fprintf (vect_dump, invalid types in dot-prod);
 +
 +  return false;
   }
 }

Thanks.

 +
if (!vec_stmt) /* transformation not required.  */
  {
if (!vect_model_reduction_cost (stmt_info, epilog_reduc_code, ncopies))

[Bug rtl-optimization/49477] Should have user/debugger-oriented fine-tuning of optimizations available

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.06.21 09:48:59
 CC||hubicka at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-21 
09:48:59 UTC ---
Confirmed.

We should

 1) disable unneeded optimization at -O0 (we do a lot of folding)
 2) look at -O1 (it's basically untuned for the last years), make
it the intended reasonable optimization with good compile-time
and debugging experience again.

For -O1 my idea was to simply _only_ do early optimizations, thus drop
any IPA optimizations from it and not execute pass_all_optimizations.
In addition to that from early optimizations disable
pass_sra_early, pass_early_ipa_sra and pass_convert_switch.  Eventually
insert a DSE pass early (not really sure).

It'll of course change fundamentally what code we emit for -O1, but at
least we have strong CSE/DCE passes and early inlining that is able
to remove C++ abstraction.

Patch that will arrive there half-way (eventually needs fixing so we
still handle some special builtins):

Index: gcc/tree-optimize.c
===
--- gcc/tree-optimize.c (revision 175205)
+++ gcc/tree-optimize.c (working copy)
@@ -53,7 +53,7 @@ along with GCC; see the file COPYING3.
 static bool
 gate_all_optimizations (void)
 {
-  return (optimize = 1
+  return (optimize  1
  /* Don't bother doing anything if the program has errors.
 We have to pass down the queue if we already went into SSA */
   (!seen_error () || gimple_in_ssa_p (cfun)));

[Bug rtl-optimization/49474] [4.7 Regression] GCC 4.7-20110618 fails to bootstrap on stage 2: gcc/fortran/resolve.c:5360:1: internal compiler error: vector VEC(edge,base) index domain error, in find_i

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

  Component|bootstrap   |rtl-optimization
   Target Milestone|--- |4.7.0
Summary|GCC 4.7-20110618 fails to   |[4.7 Regression] GCC
   |bootstrap on stage 2:   |4.7-20110618 fails to
   |gcc/fortran/resolve.c:5360: |bootstrap on stage 2:
   |1: internal compiler error: |gcc/fortran/resolve.c:5360:
   |vector VEC(edge,base) index |1: internal compiler error:
   |domain error, in|vector VEC(edge,base) index
   |find_implicit_sets at   |domain error, in
   |cprop.c:1346|find_implicit_sets at
   ||cprop.c:1346

[Bug middle-end/49478] ice in expand_widen_pattern_expr with -O3

[irar at il dot ibm.com]

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

--- Comment #4 from Ira Rosen irar at il dot ibm.com 2011-06-21 10:03:05 UTC 
---
OK.
Thanks,
Ira

[Bug bootstrap/49072] Error building the compiler

[franck.z.bugzilla at orange dot fr]

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

Franck Z franck.z.bugzilla at orange dot fr changed:

   What|Removed |Added

 CC||franck.z.bugzilla at orange
   ||dot fr

--- Comment #5 from Franck Z franck.z.bugzilla at orange dot fr 2011-06-21 
10:31:45 UTC ---
(In reply to comment #4)

During my first attempts to compile gcc, I also encountered problem with
in-tree compilation of GMP/MPFR/MPC, up to the point that I used the compiled
(but not up-to-date) version provided with the Cygwin distribution.

It took then place with the trunk.

Amont the weird things I observed stood out:
- a file gmpxx.h could be found and stopped compilation (with or without
--enable-xx flag in gcc's configure script)
- the architecture recognized by gmp's configure script was different when this
script was launched by me (pentium4--something from what I recall...) or by
gcc's makefile. When with gcc's makefile, gmp opted for a cross-compilation for
i686-pc-cygwin to none-pc-cygwin - although my gcc build was native.

About the architecture point, I can't tell much. But about the gmpxx.h file, I
suspect that it is a mostly silent bug and that a file
/usr/local/include/gmpxx.h provided by Cygwin is used if present.
Apparently, gmp's scripts create a gmp.h file when configure is run, but the
gmpxx.h wrapper is copied only when a command make install is issued, so that
gcc multi-stage compilation process may not have it, and this as soon as mpfr
(or mpc, I can't remember) needs to link to gmp. The failure telling that
gmpxx.h was missing occured during a configure script in mpfr (or mpc, again).

When the unavailability of gmpxx.h was by-passed by a local installation of gmp
from Cygwin, I also got a division by zero error or such later in the build
process.

I'm trying to confirm it with 4.6.0 release. I've added a choke me line at
the beginning of /usr/local/include/gmpxx.h. Right now, the gcc make command
is running (it's entered configuring stage 1 in ./gmp). It may take time
before I can get an answer.

Hope this piece of information is useful. :-)
I can't propose a patch for this if it confirms, for want of skills in
makefiles as big as gcc's.

[Bug ada/46350] s-taprop.adb:891:40: warning: redundant conversion, expression is of type Interrupt_ID

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou ebotcazou at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot
   ||gnu.org

--- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-06-21 
10:40:41 UTC ---
Try to remove the cast to System.Interrupt_Management.Interrupt_ID in the call.

[Bug tree-optimization/49483] unable to vectorize code equivalent to scalbnf

[vincenzo.innocente at cern dot ch]

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

--- Comment #2 from vincenzo Innocente vincenzo.innocente at cern dot ch 
2011-06-21 10:42:01 UTC ---
great!

unfortunately
gcc-4.7-20110528 $ patch -p0  vect.patch 
patching file gcc/tree-vect-stmts.c
Hunk #1 FAILED at 2089.
Hunk #2 FAILED at 2099.
Hunk #3 FAILED at 2134.
3 out of 3 hunks FAILED -- saving rejects to file gcc/tree-vect-stmts.c.rej

so I edit gcc/tree-vect-stmts.c by hand 
and worked!

vldexpf.cc:16: note: LOOP VECTORIZED.

hope it will make it for 4.6.1 :-)

I'm will wait that it gets in a snapshot to update all my machines to a new
version.

v.


On 21 Jun, 2011, at 11:26 AM, rguenth at gcc dot gnu.org wrote:

 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49483
 
 Richard Guenther rguenth at gcc dot gnu.org changed:
 
   What|Removed |Added
 
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.06.21 09:26:57
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1
 
 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-21 
 09:26:57 UTC ---
 We at the moment only handle sign-changes, but obviously
 we in principle can handle all VIEW_CONVERT_EXPRs.
 
 I'm testing the following, which works for your testcase.
 
 Index: gcc/tree-vect-stmts.c
 ===
 --- gcc/tree-vect-stmts.c   (revision 175205)
 +++ gcc/tree-vect-stmts.c   (working copy)
 @@ -2089,6 +2089,9 @@ vectorizable_assignment (gimple stmt, gi
   else
 return false;
 
 +  if (code == VIEW_CONVERT_EXPR)
 +op = TREE_OPERAND (op, 0);
 +
   if (!vect_is_simple_use_1 (op, loop_vinfo, bb_vinfo,
 def_stmt, def, dt[0], vectype_in))
 {
 @@ -2099,7 +2102,8 @@ vectorizable_assignment (gimple stmt, gi
 
   /* We can handle NOP_EXPR conversions that do not change the number
  of elements or the vector size.  */
 -  if (CONVERT_EXPR_CODE_P (code)
 +  if ((CONVERT_EXPR_CODE_P (code)
 +   || code == VIEW_CONVERT_EXPR)
(!vectype_in
  || TYPE_VECTOR_SUBPARTS (vectype_in) != nunits
  || (GET_MODE_SIZE (TYPE_MODE (vectype))
 @@ -2134,7 +2138,8 @@ vectorizable_assignment (gimple stmt, gi
   /* Arguments are ready. create the new vector stmt.  */
   FOR_EACH_VEC_ELT (tree, vec_oprnds, i, vop)
{
 -if (CONVERT_EXPR_CODE_P (code))
 +if (CONVERT_EXPR_CODE_P (code)
 +|| code == VIEW_CONVERT_EXPR)
   vop = build1 (VIEW_CONVERT_EXPR, vectype, vop);
  new_stmt = gimple_build_assign (vec_dest, vop);
  new_temp = make_ssa_name (vec_dest, new_stmt);
 
 -- 
 Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
 --- You are receiving this mail because: ---
 You reported the bug.

--
Il est bon de suivre sa pente, pourvu que ce soit en montant. 
A.G.
http://www.flickr.com/photos/vin60/1320965757/

[Bug middle-end/48493] [ICE] [ARM] in expand_expr_addr_expr_1, at expr.c

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-21 
10:45:20 UTC ---
Of course it was.  The branch merge allows s to be allocated in registers
so we expand from

  MEM[(T * {ref-all})s + 1B] = x_2(D);

and we run into the movmisalign_optab code in expand_assignment which
is supported for DImode with the commandline args.  But we probably
shouldn't try the movmisalign path when the destination is a CONCAT.

So something like the following might work (fixes the testcase, otehrwise
completely untested)

Index: expr.c
===
--- expr.c  (revision 175138)
+++ expr.c  (working copy)
@@ -4122,6 +4122,12 @@ expand_assignment (tree to, tree from, b
   rtx result;
   enum machine_mode mode;
   int align, icode;
+  enum machine_mode mode1;
+  HOST_WIDE_INT bitsize, bitpos;
+  tree offset;
+  int unsignedp;
+  int volatilep = 0;
+  tree tem;

   /* Don't crash if the lhs of the assignment was erroneous.  */
   if (TREE_CODE (to) == ERROR_MARK)
@@ -4134,9 +4140,18 @@ expand_assignment (tree to, tree from, b
   if (operand_equal_p (to, from, 0))
 return;

+  tem = get_inner_reference (to, bitsize, bitpos, offset, mode1,
+unsignedp, volatilep, true);
+
+  /* If we are going to use store_bit_field and extract_bit_field,
+ make sure to_rtx will be safe for multiple use.  */
+
+  to_rtx = expand_normal (tem);
+
   mode = TYPE_MODE (TREE_TYPE (to));
-  if ((TREE_CODE (to) == MEM_REF
-   || TREE_CODE (to) == TARGET_MEM_REF)
+  if (MEM_P (to_rtx)
+   (TREE_CODE (to) == MEM_REF
+ || TREE_CODE (to) == TARGET_MEM_REF)
mode != BLKmode
((align = MAX (TYPE_ALIGN (TREE_TYPE (to)),
get_object_alignment (to, BIGGEST_ALIGNMENT)))
@@ -4150,39 +4165,7 @@ expand_assignment (tree to, tree from, b
   reg = expand_expr (from, NULL_RTX, VOIDmode, EXPAND_NORMAL);
   reg = force_not_mem (reg);

-  if (TREE_CODE (to) == MEM_REF)
-   {
- addr_space_t as
- = TYPE_ADDR_SPACE (TREE_TYPE (TREE_TYPE (TREE_OPERAND (to, 1;
- tree base = TREE_OPERAND (to, 0);
- address_mode = targetm.addr_space.address_mode (as);
- op0 = expand_expr (base, NULL_RTX, VOIDmode, EXPAND_NORMAL);
- op0 = convert_memory_address_addr_space (address_mode, op0, as);
- if (!integer_zerop (TREE_OPERAND (to, 1)))
-   {
- rtx off
- = immed_double_int_const (mem_ref_offset (to), address_mode);
- op0 = simplify_gen_binary (PLUS, address_mode, op0, off);
-   }
- op0 = memory_address_addr_space (mode, op0, as);
- mem = gen_rtx_MEM (mode, op0);
- set_mem_attributes (mem, to, 0);
- set_mem_addr_space (mem, as);
-   }
-  else if (TREE_CODE (to) == TARGET_MEM_REF)
-   {
- addr_space_t as = TYPE_ADDR_SPACE (TREE_TYPE (to));
- struct mem_address addr;
-
- get_address_description (to, addr);
- op0 = addr_for_mem_ref (addr, as, true);
- op0 = memory_address_addr_space (mode, op0, as);
- mem = gen_rtx_MEM (mode, op0);
- set_mem_attributes (mem, to, 0);
- set_mem_addr_space (mem, as);
-   }
-  else
-   gcc_unreachable ();
+  mem = to_rtx;
   if (TREE_THIS_VOLATILE (to))
MEM_VOLATILE_P (mem) = 1;

@@ -4211,21 +4194,7 @@ expand_assignment (tree to, tree from, b
   TREE_CODE (TREE_OPERAND (to, 0)) == ADDR_EXPR)
   || TREE_CODE (TREE_TYPE (to)) == ARRAY_TYPE)
 {
-  enum machine_mode mode1;
-  HOST_WIDE_INT bitsize, bitpos;
-  tree offset;
-  int unsignedp;
-  int volatilep = 0;
-  tree tem;
-
   push_temp_slots ();
-  tem = get_inner_reference (to, bitsize, bitpos, offset, mode1,
-unsignedp, volatilep, true);
-
-  /* If we are going to use store_bit_field and extract_bit_field,
-make sure to_rtx will be safe for multiple use.  */
-
-  to_rtx = expand_normal (tem);

   /* If the bitfield is volatile, we want to access it in the
 field's mode, not the computed mode.

[Bug tree-optimization/49483] unable to vectorize code equivalent to scalbnf

[rguenther at suse dot de]

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

--- Comment #3 from rguenther at suse dot de rguenther at suse dot de 
2011-06-21 10:50:14 UTC ---
On Tue, 21 Jun 2011, vincenzo.innocente at cern dot ch wrote:

 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49483
 
 --- Comment #2 from vincenzo Innocente vincenzo.innocente at cern dot ch 
 2011-06-21 10:42:01 UTC ---
 great!
 
 unfortunately
 gcc-4.7-20110528 $ patch -p0  vect.patch 
 patching file gcc/tree-vect-stmts.c
 Hunk #1 FAILED at 2089.
 Hunk #2 FAILED at 2099.
 Hunk #3 FAILED at 2134.
 3 out of 3 hunks FAILED -- saving rejects to file gcc/tree-vect-stmts.c.rej
 
 so I edit gcc/tree-vect-stmts.c by hand 
 and worked!
 
 vldexpf.cc:16: note: LOOP VECTORIZED.
 
 hope it will make it for 4.6.1 :-)

Unlikely unless it is a regression ;)  It'll make 4.7.0 though if
testing succeeds.

Richard.

[Bug bootstrap/49072] Error building the compiler

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2011-06-21 
10:51:55 UTC ---
(In reply to comment #5)
 Apparently, gmp's scripts create a gmp.h file when configure is run, but the
 gmpxx.h wrapper is copied only when a command make install is issued, so 
 that
 gcc multi-stage compilation process may not have it, and this as soon as mpfr
 (or mpc, I can't remember) needs to link to gmp. The failure telling that
 gmpxx.h was missing occured during a configure script in mpfr (or mpc, again).

gmpxx.h is part of the GMP source distribution, it's not generated

 Hope this piece of information is useful. :-)

Not really, if you don't say which versions of GCC and GMP/MFPR/MPC you're
using, and your exact configure command, then it's not reproducable or
verifiable.

It also seems to be completely unrelated to this bug report, which is about
segfaults (almost certainly due to faulty hardware) not incorrectly-detected
system properties during configuration.

[Bug tree-optimization/49483] unable to vectorize code equivalent to scalbnf

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-21 
11:02:42 UTC ---
Author: rguenth
Date: Tue Jun 21 11:02:38 2011
New Revision: 175252

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175252
Log:
2011-06-21  Richard Guenther  rguent...@suse.de

PR tree-optimization/49483
* tree-vect-stmts.c (vectorizable_assignment): Also handle
VIEW_CONVERT_EXPR conversions.

* gcc.dg/vect/vect-120.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/vect/vect-120.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-stmts.c

[Bug tree-optimization/49483] unable to vectorize code equivalent to scalbnf

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-21 
11:03:45 UTC ---
Fixed for 4.7.

[Bug middle-end/48493] [ICE] [ARM] in expand_expr_addr_expr_1, at expr.c

[mikpe at it dot uu.se]

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

--- Comment #6 from Mikael Pettersson mikpe at it dot uu.se 2011-06-21 
11:24:39 UTC ---
I can do a bootstrap and regtest with Richard's patch in #c5 tomorrow, but as
my HW is armv5te I can't catch any neon-related runtime regressions.  Does
anyone else want to do the bootstrap+regtest on more modern HW?

[Bug middle-end/48493] [ICE] [ARM] in expand_expr_addr_expr_1, at expr.c

[rguenther at suse dot de]

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

--- Comment #7 from rguenther at suse dot de rguenther at suse dot de 
2011-06-21 11:40:18 UTC ---
On Tue, 21 Jun 2011, mikpe at it dot uu.se wrote:

 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48493
 
 --- Comment #6 from Mikael Pettersson mikpe at it dot uu.se 2011-06-21 
 11:24:39 UTC ---
 I can do a bootstrap and regtest with Richard's patch in #c5 tomorrow, but as
 my HW is armv5te I can't catch any neon-related runtime regressions.  Does
 anyone else want to do the bootstrap+regtest on more modern HW?

The patch probably breaks the movmisalign path

[Bug tree-optimization/49478] ice in expand_widen_pattern_expr with -O3

[irar at gcc dot gnu.org]

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

--- Comment #5 from irar at gcc dot gnu.org 2011-06-21 11:58:36 UTC ---
Author: irar
Date: Tue Jun 21 11:58:33 2011
New Revision: 175255

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175255
Log:

PR tree-optimization/49478
* tree-vect-loop.c (vectorizable_reduction): Handle DOT_PROD_EXPR
with constant operand.


Added:
trunk/gcc/testsuite/gcc.dg/vect/pr49478.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-loop.c

[Bug libgcj/49314] md5test, shatest output FAILs on Tru64 UNIX

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot 
Uni-Bielefeld.DE 2011-06-21 12:09:30 UTC ---
 The question now is what's a clean fix for this issue, rather than
 hardcoding the result?

I've now checked this with native and GNU iconv: feff.utf-8 is the input
sequence from iconv_init:

 od -x feff.utf-8
000 bbef 0abf

At first everything seemed to work with both tools, except that I need
byte swapping with native iconv, but not with GNU iconv:

 /usr/bin/iconv -f UTF-8 -t UCS-2  feff.utf-8 | od -x
000 feff 000a
 /vol/gnu/bin/iconv -f UTF-8 -t UCS-2  feff.utf-8 | od -x
000 fffe 0a00

But when I removed the newline from the input file, results differ:

 od -x feff.utf-8-nonl 
000 bbef 00bf

 /usr/bin/iconv -f UTF-8 -t UCS-2  feff.utf-8-nonl | od -x
000 feff feff
 /vol/gnu/bin/iconv -f UTF-8 -t UCS-2  feff.utf-8-nonl | od -x
000 fffe

As result, I've simply added a padding NUL byte to the input sequence.
This let the iconv succeed and my arraycopy testcase and both md5test
and shatest pass.

I'm running a full rebuild and check of libjava for good measure.

Rainer

[Bug fortran/49112] [4.6/4.7 Regression] [OOP] Missing type-bound procedure, duplicate save warnings and internal compiler error

[janus at gcc dot gnu.org]

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

--- Comment #12 from janus at gcc dot gnu.org 2011-06-21 12:12:58 UTC ---
Author: janus
Date: Tue Jun 21 12:12:51 2011
New Revision: 175257

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175257
Log:
2011-06-21  Janus Weil  ja...@gcc.gnu.org

PR fortran/49112
* class.c (gfc_find_derived_vtab): Make vtab and default initialization
symbols SAVE_IMPLICIT.

2011-06-21  Janus Weil  ja...@gcc.gnu.org

PR fortran/49112
* gfortran.dg/class_44.f03: New.

Added:
trunk/gcc/testsuite/gfortran.dg/class_44.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/class.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/49478] ice in expand_widen_pattern_expr with -O3

[irar at il dot ibm.com]

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

Ira Rosen irar at il dot ibm.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #6 from Ira Rosen irar at il dot ibm.com 2011-06-21 12:14:09 UTC 
---
Fixed.

[Bug fortran/49112] [4.6/4.7 Regression] [OOP] Missing type-bound procedure, duplicate save warnings and internal compiler error

[janus at gcc dot gnu.org]

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

--- Comment #13 from janus at gcc dot gnu.org 2011-06-21 12:20:33 UTC ---
Author: janus
Date: Tue Jun 21 12:20:28 2011
New Revision: 175259

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175259
Log:
2011-06-21  Janus Weil  ja...@gcc.gnu.org

PR fortran/49112
* class.c (gfc_find_derived_vtab): Make vtab and default initialization
symbols SAVE_IMPLICIT.

2011-06-21  Janus Weil  ja...@gcc.gnu.org

PR fortran/49112
* gfortran.dg/class_44.f03: New.

Added:
branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/class_44.f03
Modified:
branches/gcc-4_6-branch/gcc/fortran/ChangeLog
branches/gcc-4_6-branch/gcc/fortran/class.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug fortran/49112] [4.6/4.7 Regression] [OOP] Missing type-bound procedure, duplicate save warnings and internal compiler error

[janus at gcc dot gnu.org]

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

--- Comment #14 from janus at gcc dot gnu.org 2011-06-21 12:26:44 UTC ---
The duplicate save regression is fixed on trunk and 4.6. Remaining problems:

1) The structure constructor regression in comment #6.
2) The ICE in comment #7.

[Bug c++/49485] New: Performance problem with C++ code

[ismail at namtrac dot org]

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

   Summary: Performance problem with C++ code
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ism...@namtrac.org


Created attachment 24570
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24570
Testcase

Attached testcase when compiled with gcc 4.3.4;


 g++ -O3 -ffast-math -o reduced_dlasr_gcc43 reduced_dlasr.cpp 

 time ./reduced_dlasr_gcc43
./reduced_dlasr_gcc43  0.15s user 0.00s system 94% cpu 0.168 total

When compiled with gcc 4.6;

 g++ -O3 -ffast-math -o reduced_dlasr_gcc46 reduced_dlasr.cpp

 time ./reduced_dlasr_gcc46
./reduced_dlasr_gcc46  0.20s user 0.00s system 99% cpu 0.209 total


gcc versions:

gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux) 
gcc version 4.6.0 20110607 [gcc-4_6-branch revision 174741] (SUSE Linux)

[Bug c++/49485] Performance problem with C++ code

[ismail at namtrac dot org]

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

--- Comment #1 from İsmail cartman Dönmez ismail at namtrac dot org 
2011-06-21 12:37:49 UTC ---
Test machine has Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz CPU with 8GB of RAM.

[Bug tree-optimization/49442] [4.5/4.6/4.7 Regression] Misaligned store support pessimization

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-21 
12:43:04 UTC ---
Created attachment 24571
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24571
gcc47-builtins.patch

Prerequisite patch for __builtin_assume_aligned patch.  These are just random
things I've noticed when working on that patch.

[Bug target/49423] [arm] internal compiler error: in push_minipool_fix

[jamborm at gcc dot gnu.org]

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

--- Comment #4 from Martin Jambor jamborm at gcc dot gnu.org 2011-06-21 
12:48:36 UTC ---
Possibly, yes.  I plan to submit a fix for PR49094 this week, please
try after that.

[Bug tree-optimization/49442] [4.5/4.6/4.7 Regression] Misaligned store support pessimization

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-21 
12:50:11 UTC ---
Created attachment 24572
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24572
gcc47-assume-aligned.patch

Current version of the __builtin_assume_aligned support.  On top of the
previous 
patch.
Still unfinished areas:
1) vectorizer/data-refs unfortunately ignores the computed alignment,
   should use get_pointer_alignment/get_object_alignment.
2) it would be nice if the builtin was special cased in the C/C++ FEs and
   acted like
   template typename T T __builtin_assume_aligned (T, size_t, ...);
   (for pointer types only) instead of
   void *__builtin_assume_aligned (const void *, size_t, ...);
3) testcases need to be added.

[Bug tree-optimization/49442] [4.5/4.6/4.7 Regression] Misaligned store support pessimization

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-21 
12:50:47 UTC ---
Of course something like #c4 is highly desirable independently on this.

[Bug bootstrap/49486] New: [4.7 Regression] Bootstrap failure

[hjl.tools at gmail dot com]

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

   Summary: [4.7 Regression] Bootstrap failure
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


On Linux/x86, revision 1752553 gave

../../../src-trunk/libgcc/config/libbid/bid64_mul.c:56:1: internal compiler
error: in update_ssa, at tree-into-ssa.c:3245
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
make[6]: *** [bid64_mul.o] Error 1
../../../src-trunk/libgcc/config/libbid/bid64_div.c: In function '__bid64_div':
../../../src-trunk/libgcc/config/libbid/bid64_div.c:80:1: internal compiler
error: in update_ssa, at tree-into-ssa.c:3245
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
make[6]: *** [bid64_div.o] Error 1

Revision 175251 is OK.

[Bug bootstrap/49486] [4.7 Regression] Bootstrap failure

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.7.0

--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-21 
13:00:54 UTC ---
Fixed with rev.175256.

[Bug target/45885] ICE in arm_dbx_register_number, at config/arm/arm.c:22071

[rmansfield at qnx dot com]

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

--- Comment #5 from Ryan Mansfield rmansfield at qnx dot com 2011-06-21 
13:03:18 UTC ---
(In reply to comment #4)
 (In reply to comment #0)
  $ ./xgcc -B. -c -O3 -mtune=cortex-a8 -mfloat-abi=softfp -mfpu=neon -g 
  ~/ice.i
 
 
 What happens if you do a -mcpu=cortex-a8 ?

The ICE doesn't happen if -mcpu=cortex-a8 is specified. I no longer reproduce
the ICE on trunk, only the 4.6 branch now. The ICE no longer happens with rev
171649 + 171713 applied.

[Bug c++/49418] openmp default(none) in template function

[jakub at gcc dot gnu.org]

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

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-21 
13:32:06 UTC ---
The problem seems to be that x has T const type before instantiation, but
int (without const) after instantiation.
The spot where the const is lost is:
type = type_decays_to (type);
TREE_TYPE (r) = type;  
cp_apply_type_quals_to_decl (cp_type_quals (type), r);
Does C++ really mandate stripping the toplevel qualifiers from the PARM_DECLs
here?  It isn't stripped from VAR_DECLs.
OpenMP 2.5/OpenMP 3.0 says that const qualified parameters and variables are
predetermined shared.  While it hopefully changes in some way in OpenMP 3.1
(though, the current 3.1 draft wording is likely to change, as it is backwards
incompatible with default(none)), for older standards the presence/lack of
const
makes a big difference.

[Bug c++/49418] openmp default(none) in template function

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-21 
13:34:35 UTC ---
Perhaps the top-level quals from the older type could be used, if the standard
doesn't disallow it?  Like, if T const arg is instantiated with T int or const
int, it would be int const arg, while if it is T arg instantiated with int or
const int, it would be int arg.

[Bug ada/46350] s-taprop.adb:891:40: warning: redundant conversion, expression is of type Interrupt_ID

[dave at hiauly1 dot hia.nrc.ca]

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

--- Comment #3 from dave at hiauly1 dot hia.nrc.ca 2011-06-21 13:38:12 UTC ---
 Try to remove the cast to System.Interrupt_Management.Interrupt_ID in the 
 call.

It fixes the compile error.  Testing in progress...

Dave

[Bug c++/49418] openmp default(none) in template function

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-21 
13:41:19 UTC ---
template typename T
void f (int const x)
{
#pragma omp parallel default(none)
  int y = x;
}

template typename T
void g (int const x)
{
#pragma omp parallel default(none) shared(x)
  int y = x;
}

void h ()
{
  fint (0);
  gint (0);
}

fails the same way, while after removing template typename T and int
the toplevel qualifier stays and it works as expected.
If the current C++ FE behavior is mandated by the standard, i.e. toplevel
qualifiers must be always dropped from function arguments when in templates and
not otherwise, OpenMP C++ support could just ignore TREE_READONLY on PARM_DECLs
in templates or something, but it looks very weird to me.

[Bug libgcj/49314] md5test, shatest output FAILs on Tru64 UNIX

[ro at gcc dot gnu.org]

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

Rainer Orth ro at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2011-06/msg01596.htm
   ||l
   Last reconfirmed||2011.06.21 13:58:15
 AssignedTo|unassigned at gcc dot   |ro at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #15 from Rainer Orth ro at gcc dot gnu.org 2011-06-21 13:58:15 
UTC ---
Patch posted.

[Bug target/46551] Generate complex addressing mode CMP instruction in x86-64

[dgohman at gmail dot com]

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

Dan Gohman dgohman at gmail dot com changed:

   What|Removed |Added

 CC||dgohman at gmail dot com

--- Comment #2 from Dan Gohman dgohman at gmail dot com 2011-06-21 14:26:23 
UTC ---
Something has noticed that in the else block, a is equal to the value loaded
from vm-cell[vm-index[0] - 2], so it is replacing the use of a and CSE'ing it
with the loaded value. That's what causes the loaded value to have multiple
uses, which presumably is why GCC subsequently declines to fold the addresssing
into the compare.

[Bug c++/49418] openmp default(none) in template function

[jason at gcc dot gnu.org]

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

Jason Merrill jason at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.06.21 14:35:35
 AssignedTo|unassigned at gcc dot   |jason at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #5 from Jason Merrill jason at gcc dot gnu.org 2011-06-21 
14:35:35 UTC ---
This is a bug, an unintended consequence of the change to type_decays_to.

[Bug c/49487] New: Internal compiler error in AVR code

[gandalf at winds dot org]

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

   Summary: Internal compiler error in AVR code
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gand...@winds.org
CC: eric.wedding...@atmel.com
  Host: x86_64-unknown-linux-gnu
Target: avr-unknown-none
 Build: x86_64-unknown-linux-gnu


Compiling the following function triggers an internal compiler error in (at
least) GCC versions 4.2, 4.3, 4.5 and the latest 4.7.0-20110620:

unsigned int test(unsigned int *ptr, unsigned int len)
{
  unsigned int sum=0, *p=ptr;

  while(p  ptr+len)
sum += ({ unsigned int _x=(*p++); (_x  8) | (_x  8); });

  if(__builtin_expect(len  1, 0))
sum += *p;

  return ~sum;
}

Compiler command and resulting output:

avr-gcc -O3 -Wall -mmcu=atmega644   -c -o test3.o test3.c
test3.c: In function 'test':
test3.c:12:1: error: could not split insn
(insn 40 38 41 (parallel [
(set (reg:HI 20 r20 [92])
(rotate:HI (reg/v:HI 20 r20 [orig:67 _x ] [67])
(const_int 8 [0x8])))
(clobber (mem/c:QI (plus:HI (reg/f:HI 28 r28)
(const_int 1 [0x1])) [4 %sfp+1 S1 A8]))
]) test3.c:6 64 {*rotbhi}
 (nil))
test3.c:12:1: internal compiler error: in final_scan_insn, at final.c:2724

This was compiled using a cross-compiler on an x86_64 system as outlined below:

Target: avr
Configured with: ../configure --target=avr --prefix=/usr/local/avr
--disable-nls --enable-languages=c --disable-bootstrap --disable-libssp
Thread model: single
gcc version 4.7.0 20110620 (experimental) (GCC)

[Bug rtl-optimization/49429] [4.7 Regression] dse.c changes to fix PR44194 (r175063) cause execution failures

[sje at cup dot hp.com]

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

--- Comment #14 from Steve Ellcey sje at cup dot hp.com 2011-06-21 15:21:44 
UTC ---
The bootstrap and testing of this patch on IA64 looks good.  There were no
regressions and it seems to have fixed all the test cases that started breaking
on IA64 with the patch to PR 44194.

Unfortunately, this patch does not seem to fix PR 49454, the PA bootstrap
failure, which also broke at the same time.  Perhaps there are some other
places where mark_addressable needs to be called?

[Bug c++/49488] New: [C++0x] Use 'final' for devirtualization purposes

[paolo.carlini at oracle dot com]

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

   Summary: [C++0x] Use 'final' for devirtualization purposes
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: paolo.carl...@oracle.com


This is an internal reminder for this issue, which I already briefly discussed
with Jason in private email and also @ Google GCC Gathering a few days ago,
where the issue has been classified by the knowledgeable attendees largely as a
c++ front-end one. Link to Vincenzo' message on the gcc mailing list raising
explicitly the issue for the first time:

  http://gcc.gnu.org/ml/gcc/2011-05/msg00319.html

[Bug target/49487] Internal compiler error in AVR code

[eric.weddington at atmel dot com]

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

Eric Weddington eric.weddington at atmel dot com changed:

   What|Removed |Added

  Component|c   |target

--- Comment #1 from Eric Weddington eric.weddington at atmel dot com 
2011-06-21 15:27:41 UTC ---
(In reply to comment #0)
 Compiling the following function triggers an internal compiler error in (at
 least) GCC versions 4.2, 4.3, 4.5 and the latest 4.7.0-20110620:

Could you be a bit more specific on the version numbers for 4.2, 4.3, and 4.5?

I've just tried building on 4.3.3 (WinAVR 20100110) and it compiled
successfully for -O[0123s].

snip 
 This was compiled using a cross-compiler on an x86_64 system as outlined 
 below:

Could you try using a 32-bit host?

[Bug target/49454] [4.7 Regression] /usr/include/libio.h:336:3: internal compiler error: Segmentation fault

[sje at cup dot hp.com]

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

--- Comment #2 from Steve Ellcey sje at cup dot hp.com 2011-06-21 15:48:14 
UTC ---
I built an hppa2.0w-hp-hpux11.11 compiler with --disable-bootstrap and then ran
the test suite to see if I could get a smaller test case.  The tests are still
running but there are many failures with -O1 and higher levels of optimization.

One small example is gcc.c-torture/execute/2717-1.c, which fails during
execution at -O1, -O2, -O3, -Os.

Here are some other tests that fail at -O1:

FAIL: gcc.c-torture/execute/2706-1.c execution,  -O1 
FAIL: gcc.c-torture/execute/2706-2.c execution,  -O1 
FAIL: gcc.c-torture/execute/2706-5.c execution,  -O1 
FAIL: gcc.c-torture/execute/2717-5.c execution,  -O1 
FAIL: gcc.c-torture/execute/2003-1.c execution,  -O1 
FAIL: gcc.c-torture/execute/20020215-1.c execution,  -O1

[Bug middle-end/49489] New: [4.7 Regression] gcc.c-torture/execute/builtin-bitops-1.c fails on x86_64-linux

[jakub at gcc dot gnu.org]

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

   Summary: [4.7 Regression]
gcc.c-torture/execute/builtin-bitops-1.c fails on
x86_64-linux
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: ja...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
Target: x86_64-linux


__builtin_clrsb is broken on x86_64 (and other targets where it is only
supported by a library call in DImode).

[Bug middle-end/49489] [4.7 Regression] gcc.c-torture/execute/builtin-bitops-1.c fails on x86_64-linux

[jakub at gcc dot gnu.org]

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

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.06.21 15:56:01
   Target Milestone|--- |4.7.0
 Ever Confirmed|0   |1

[Bug c++/36848] const/nonconst virtual function ambiguity deserves a warning

[redi at gcc dot gnu.org]

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

Jonathan Wakely redi at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME

--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-06-21 
15:56:26 UTC ---
You probably want the -Woverloaded-virtual warning, present for many years.



Additionally, G++ 4.7 implements C++0x explicit override control, so you can
change your derived classes like so:

class A_noconst : public A {
public:
  void sayhi() override { /* ... */ }
  void saybye() override { /* ... */ }
};

class A_const : public A {
public:
  void sayhi() const override { /* ... */ }
  void saybye() const override { /* ... */ }
};


This causes the compiler to reject the program:

final.cc:9:8: error: 'void A_noconst::sayhi()' marked override, but does not
override
final.cc:16:8: error: 'void A_const::saybye() const' marked override, but does
not override

[Bug target/49487] Internal compiler error in AVR code

[j at uriah dot heep.sax.de]

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

Joerg Wunsch j at uriah dot heep.sax.de changed:

   What|Removed |Added

 CC||j at uriah dot heep.sax.de

--- Comment #2 from Joerg Wunsch j at uriah dot heep.sax.de 2011-06-21 
15:57:50 UTC ---
Confirmed for current SVN trunk (r175263).

I cannot reproduce it on GCC 4.3.4.

[Bug c++/17920] add __attribute__((reimpl)) as a replacement for the (optional) virtual keyword for reimplementations of virtual functions

[redi at gcc dot gnu.org]

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

Jonathan Wakely redi at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.7.0

--- Comment #14 from Jonathan Wakely redi at gcc dot gnu.org 2011-06-21 
16:00:11 UTC ---
G++ 4.7 supports C++0x explicit override control, so the example can be changed
to:

struct A { virtual void foo() const; };
struct B : public A { void foo() override; };

And you get:

final.cc:2:28: error: 'void B::foo()' marked override, but does not override

[Bug c++/49488] [C++0x] Use 'final' for devirtualization purposes

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-06-21 
16:03:43 UTC ---
*cough* PR 46043 *cough*

[Bug c++/49488] [C++0x] Use 'final' for devirtualization purposes

[paolo.carlini at oracle dot com]

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

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.06.21 16:10:35
 Ever Confirmed|0   |1

--- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-06-21 
16:10:35 UTC ---
Indeed, Honza suggested that final could be also a c++03 attribute (no idea if
he knows about that older PR...)

[Bug c++/31397] Useful compiler warning missing (virtual functions in derived classes used without 'virtual')

[redi at gcc dot gnu.org]

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

--- Comment #13 from Jonathan Wakely redi at gcc dot gnu.org 2011-06-21 
16:12:42 UTC ---
G++ 4.7 implements C++0x explicit override control so you can add 'override'

class B : public A
{
  B( int y );
  ~B();
  int f( int x ) override;
};

and you'll get an error if it doesn't actually override a virtual function from
a base class.

It's not *quite* what you want, but you could use it to check whether B::f
overrides a virtual (and so you want to add 'virtual' to it) without checking
the declaration of A::f

[Bug target/49487] Internal compiler error in AVR code

[eric.weddington at atmel dot com]

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

Eric Weddington eric.weddington at atmel dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.06.21 16:15:37
 Ever Confirmed|0   |1

[Bug c++/49488] [C++0x] Use 'final' for devirtualization purposes

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-06-21 
16:16:22 UTC ---
Last I checked G++ supported 'final' with -std=c++98 -pedantic-errors, I don't
know if that's been fixed yet.  It's definitely useful to support it in c++98
mode, I don't care whether it's via an attribute or a virt-specifier

[Bug middle-end/49489] [4.7 Regression] gcc.c-torture/execute/builtin-bitops-1.c fails on x86_64-linux

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-21 
16:26:03 UTC ---
Author: jakub
Date: Tue Jun 21 16:25:57 2011
New Revision: 175265

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175265
Log:
PR middle-end/49489
* builtins.c (expand_builtin_unop): Call expand_unop with 0 as
unsignedp argument instead of 1 for clrsb_optab.
(fold_builtin_bitop): Fix masking for width  HOST_BITS_PER_WIDE_INT
and  2 * HOST_BITS_PER_WIDE_INT.  Optimize BUILT_IN_CLRSB*.
(fold_builtin_1): Call fold_builtin_binop for BUILT_IN_CLRSB*.
* optabs.c (widen_leading): Call widen_operand and expand_unop
with 0 as unsignedp argument instead of 1 for clrsb_optab.
(expand_unop): Subtract difference of mode sizes also for
clrsb_optab.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/optabs.c

[Bug target/49454] [4.7 Regression] /usr/include/libio.h:336:3: internal compiler error: Segmentation fault

[sje at cup dot hp.com]

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

--- Comment #3 from Steve Ellcey sje at cup dot hp.com 2011-06-21 16:26:44 
UTC ---
I should have mentioned in comment #2 that the build and test I did included
the proposed patch in comment #11 pf PR 49429.

[Bug libgomp/49490] New: suboptimal load balancing in loops

[dennis.jespersen at nasa dot gov]

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

   Summary: suboptimal load balancing in loops
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: libgomp
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dennis.jesper...@nasa.gov


Created attachment 24573
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24573
test code to show how a compiler/runtime splits an OpenMP loop

The OpenMP runtime library produces a correct but suboptimal load balance
in parallel loops.
For example, a loop of length 33 with 8 OpenMP threads will give the
threads work of lengths 5, 5, 5, 5, 5, 5, 3, 0 respectively.  This is logically
correct, but imagine a dual-socket 4 core + 4 core configuration; then
the left socket has 20 units of work while the right socket has 13
units of work.  This could put undue pressure on the left cache(s) and/or
memory connection.  It would be better to spread out the work as much
as possible, so in the example in question the threads would get work
of lengths 5, 4, 4, 4, 4, 4, 4, 4.

It should be fairly easy to modify libgomp/iter.c to produce the better
load balancing (at least I think that's where the modification would go).

The attached Fortran code will show the load balance; the Portland Group and
Intel products give the desired even balance.

[Bug libgcj/49314] md5test, shatest output FAILs on Tru64 UNIX

[ro at gcc dot gnu.org]

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

--- Comment #16 from Rainer Orth ro at gcc dot gnu.org 2011-06-21 17:10:02 
UTC ---
Author: ro
Date: Tue Jun 21 17:09:57 2011
New Revision: 175266

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175266
Log:
PR libgcj/49314
* gnu/gcj/convert/natIconv.cc (iconv_init): Pad in[] with NUL byte.

Modified:
trunk/libjava/ChangeLog
trunk/libjava/gnu/gcj/convert/natIconv.cc

[Bug libgcj/49314] md5test, shatest output FAILs on Tru64 UNIX

[ro at gcc dot gnu.org]

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

Rainer Orth ro at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #17 from Rainer Orth ro at gcc dot gnu.org 2011-06-21 17:12:26 
UTC ---
Fixed for 4.7.0.

[Bug target/49487] Internal compiler error in AVR code

[gandalf at winds dot org]

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

--- Comment #3 from gandalf at winds dot org 2011-06-21 17:17:20 UTC ---
(In reply to comment #1)
 (In reply to comment #0)
  Compiling the following function triggers an internal compiler error in (at
  least) GCC versions 4.2, 4.3, 4.5 and the latest 4.7.0-20110620:
 
 Could you be a bit more specific on the version numbers for 4.2, 4.3, and 4.5?
 
 I've just tried building on 4.3.3 (WinAVR 20100110) and it compiled
 successfully for -O[0123s].
 
 snip 
  This was compiled using a cross-compiler on an x86_64 system as outlined 
  below:
 
 Could you try using a 32-bit host?

Sorry about being vague on the previous GCC versions--I didn't think it
mattered that much. I very well could have been using patches from Atmel back
then (it was a while ago). I cannot reproduce the problem today on vanilla GCC
4.3.5 and 4.4.6.

However I am able to reproduce the problem on 4.5.3 right now too (on a 64-bit
host).

[Bug target/49454] [4.7 Regression] /usr/include/libio.h:336:3: internal compiler error: Segmentation fault

[dave at hiauly1 dot hia.nrc.ca]

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

--- Comment #4 from dave at hiauly1 dot hia.nrc.ca 2011-06-21 17:23:27 UTC ---
 I should have mentioned in comment #2 that the build and test I did included
 the proposed patch in comment #11 pf PR 49429.

I assumed so.  Richard's comments regarding the patch indicated that
it was unlikely to fix all the problems on hppa (a callee copies target).

Dave

[Bug middle-end/49491] New: Superflouos move because of unnecessary spill for 2-operand insn.

[gjl at gcc dot gnu.org]

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

   Summary: Superflouos move because of unnecessary spill for
2-operand insn.
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: missed-optimization, ra
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@gcc.gnu.org
Target: avr


This is an optimization flaw I observe in current 4.7 trunk (r175201) and also
in upcoming 4.6.1.

This is the C source:

unsigned int shift1 (unsigned char x, unsigned char y)
{
return (x|y)  3;
}

The machine (AVR) just has 2-operand instructions.  It occurs for AVR but
presumably is not target-specific and so I chose middle-end as component
because reload generates insn 27.

Function shift1 gets x in r24, y in r22 and has to return the result in r24
(LSB) and r25 (MSB).

The code produced is:

shift1:
or r22,r24 ;  7iorqi3/1[length = 1]
mov r24,r22 ;  27*movqi/1[length = 1]
lsr r24 ;  24*lshrqi3/5[length = 3]
lsr r24
lsr r24
ldi r25,lo8(0) ;  25*movqi/1[length = 1]
ret ;  30return[length = 1]

Instead of a simple

or r24,r22

there is  

or r22,r24
mov r24,r22

There is nothing I can see in avr BE that forces this move; iorqi3 insn is
commutative and no insn involved needs an (early) clobber.

Without the shift, code is as expected:

unsigned int or1 (unsigned char x, unsigned char y)
{
return x|y;
}

or1:
or r24,r22 ;  23iorqi3/1[length = 1]
ldi r25,lo8(0) ;  24*movqi/1[length = 1]
ret ;  28return[length = 1]

===

Command line:

avr-gcc shr.c -Os -dp -S -v

===

Using built-in specs.
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/local/gnu/install/gcc-4.7/libexec/gcc/avr/4.7.0/lto-wrapper
Target: avr
Configured with: ../../gcc.gnu.org/trunk/configure --target=avr
--prefix=/local/gnu/install/gcc-4.7 --disable-nls --disable-shared
--enable-languages=c,c++ --with-dwarf2
Thread model: single
gcc version 4.7.0 20110620 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-Os' '-dp' '-S' '-v'
 /local/gnu/install/gcc-4.7/libexec/gcc/avr/4.7.0/cc1 -quiet -v shr.c -quiet
-dumpbase shr.c -dp -auxbase shr -Os -version -o shr.s
GNU C (GCC) version 4.7.0 20110620 (experimental) (avr)
compiled by GNU C version 4.3.2 [gcc-4_3-branch revision 141291], GMP
version 5.0.1, MPFR version 3.0.0-p8, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

[Bug target/33049] [avr] bit extraction non optimal, inversing logic solves problem

[gjl at gcc dot gnu.org]

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

--- Comment #18 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-06-21 
17:30:57 UTC ---
Author: gjl
Date: Tue Jun 21 17:30:54 2011
New Revision: 175269

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175269
Log:
PR target/33049
* config/avr/avr.md (extzv): New expander.
(*extzv): New insn.
(*extzv.qihi1, *extzv.qihi2): New insn-and-split.
* config/avr/constraints.md (C04): New constraint.
* doc/md.texi (Machine Constraints): Document it.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/avr.md
trunk/gcc/config/avr/constraints.md
trunk/gcc/doc/md.texi

[Bug middle-end/49492] New: FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution

[hjl.tools at gmail dot com]

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

   Summary: FAIL:  gcc.c-torture/execute/builtin-bitops-1.c
execution
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


On Linux/x86, revision 175263 gave

FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution,  -O0 
FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution,  -O1 
FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution,  -O2 
FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution,  -O2 -flto 
FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution,  -O2 -flto
-flto-partition=none 
FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution,  -O3
-fomit-frame-pointer 
FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution,  -O3
-fomit-frame-pointer -funroll-all-loops -finline-functions 
FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution,  -O3
-fomit-frame-pointer -funroll-loops 
FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution,  -O3 -g 
FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution,  -Os 

Revision 175259 is OK.

[Bug target/33049] [avr] bit extraction non optimal, inversing logic solves problem

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay gjl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #19 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-06-21 
17:36:35 UTC ---
Closing as resolved+fixed according to applied patch.

[Bug middle-end/49492] FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution

[pinskia at gcc dot gnu.org]

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

Andrew Pinski pinskia at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-06-21 
17:39:20 UTC ---
This was just fixed.

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

[Bug middle-end/49489] [4.7 Regression] gcc.c-torture/execute/builtin-bitops-1.c fails on x86_64-linux

[pinskia at gcc dot gnu.org]

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

Andrew Pinski pinskia at gcc dot gnu.org changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2011-06-21 
17:39:20 UTC ---
*** Bug 49492 has been marked as a duplicate of this bug. ***

[Bug middle-end/49489] [4.7 Regression] gcc.c-torture/execute/builtin-bitops-1.c fails on x86_64-linux

[jakub at gcc dot gnu.org]

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

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-21 
17:46:45 UTC ---
Fixed.

[Bug target/29560] [avr] Poor optimization for byte shifts

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay gjl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID

--- Comment #6 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-06-21 
18:24:44 UTC ---
Closing this PR as invalid.

As Andy already explained, for shift offsets 7 and 15 there has to be a
defined result because int for avr-gcc is 16 bits, and this is actually *not* a
byte shift.

With alternative code that tested for these offsets at runtime, jumped around
and loaded 0 if appropriate, you were not better of than with the current code
-- in the contrary.

Note that gcc deflates you function calls to just one instruction in main.

So maybe what you really want here is to make these functions static inline so
that you do no more see the code in the functions.  Presumably you always call
this functions with compile time constants.

If you really need to quench out the last tick and call with non-constants, you
could invent inline assembler with an instruction sequence that is similar to
(1  (R24  7)), perhaps together with __builtin_constant_p magic:

   LDI  R24, 1
   SBRC R24, 1
   LDI  R24, 4
   SBRC R24, 0
   LSL  R24
   SBRC R24, 2
   SWAP R24

Note that with -mint8, int is 8 bits.  That is still present as option, but no
more supported and perhaps non-functional.

--

Just for reference; here is a source without external #include:

#define PORTC (*((unsigned char volatile*) 53))

void setpin(unsigned char pin, unsigned char val)
{
if (val == 1) PORTC |= (1pin);
else PORTC = ~(1pin);
}

void setpin1(unsigned char pin, unsigned char val)
{
const unsigned char one = 1;
if (val == 1) PORTC |= (one(pin));
else PORTC = ~(onepin);
}

int main(void)
{
setpin(3, 1);
setpin1(3, 1);
return 0;
}

[Bug tree-optimization/49493] New: ICE: in insert_vi_for_tree, at tree-ssa-structalias.c:2637 with -O -fipa-pta

[zsojka at seznam dot cz]

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

   Summary: ICE: in insert_vi_for_tree, at
tree-ssa-structalias.c:2637 with -O -fipa-pta
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
CC: rgue...@gcc.gnu.org
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


Created attachment 24574
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24574
reduced testcase

Maybe the same as PR41378

Compiler output:
$ gcc -O -fipa-pta testcase.c 
testcase.c:3:1: internal compiler error: in insert_vi_for_tree, at
tree-ssa-structalias.c:2637
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.


(gdb) bt
#0  fancy_abort (file=0x11fb598
/mnt/svn/gcc-trunk/gcc/tree-ssa-structalias.c, line=2637, function=0x11fbe40
insert_vi_for_tree)
at /mnt/svn/gcc-trunk/gcc/diagnostic.c:892
#1  0x00a6ab1b in insert_vi_for_tree (t=Unhandled dwarf expression
opcode 0xf3
) at /mnt/svn/gcc-trunk/gcc/tree-ssa-structalias.c:2637
#2  0x00a6ab32 in associate_varinfo_to_alias_1 (node=Unhandled dwarf
expression opcode 0xf3
) at /mnt/svn/gcc-trunk/gcc/tree-ssa-structalias.c:6694
#3  0x00b314b0 in varpool_for_node_and_aliases (node=0x75901138,
callback=0xa6ab20 associate_varinfo_to_alias_1, data=0x18bf820, 
include_overwritable=1 '\001') at /mnt/svn/gcc-trunk/gcc/varpool.c:757
#4  0x00b3153b in varpool_for_node_and_aliases (node=0x759010d0,
callback=0xa6ab20 associate_varinfo_to_alias_1, data=0x18bf820, 
include_overwritable=1 '\001') at /mnt/svn/gcc-trunk/gcc/varpool.c:765
#5  0x00a77f3c in ipa_pta_execute () at
/mnt/svn/gcc-trunk/gcc/tree-ssa-structalias.c:6734
#6  0x0086352e in execute_one_pass (pass=0x16c34c0) at
/mnt/svn/gcc-trunk/gcc/passes.c:2023
#7  0x00863c9a in execute_ipa_pass_list (pass=0x16c34c0) at
/mnt/svn/gcc-trunk/gcc/passes.c:2390
#8  0x00616cf9 in ipa_passes () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:2034
#9  cgraph_optimize () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:2069
#10 0x00616eea in cgraph_finalize_compilation_unit () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1292
#11 0x004fe6f8 in c_write_global_declarations () at
/mnt/svn/gcc-trunk/gcc/c-decl.c:9844
#12 0x0094e3e4 in compile_file (argc=14, argv=0x7fffdae8) at
/mnt/svn/gcc-trunk/gcc/toplev.c:587
#13 do_compile (argc=14, argv=0x7fffdae8) at
/mnt/svn/gcc-trunk/gcc/toplev.c:1924
#14 toplev_main (argc=14, argv=0x7fffdae8) at
/mnt/svn/gcc-trunk/gcc/toplev.c:1996
#15 0x76414d2d in __libc_start_main () from /lib64/libc.so.6
#16 0x004e2835 in _start ()

Tested revisions:
r175265 - crash

[Bug c++/49418] [4.6/4.7 regression] G++ discards cv-quals from template parameter types

[jason at gcc dot gnu.org]

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

Jason Merrill jason at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.6.2
Summary|openmp default(none) in |[4.6/4.7 regression] G++
   |template function   |discards cv-quals from
   ||template parameter types

--- Comment #6 from Jason Merrill jason at gcc dot gnu.org 2011-06-21 
18:58:53 UTC ---
Changing the summary to reflect the underlying issue.

[Bug c++/49418] [4.6/4.7 regression] G++ discards cv-quals from template parameter types

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill jason at gcc dot gnu.org 2011-06-21 
19:05:28 UTC ---
Author: jason
Date: Tue Jun 21 19:05:25 2011
New Revision: 175271

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175271
Log:
PR c++/49418
* call.c (cxx_type_promotes_to): Don't strip cv-quals.
* semantics.c (lambda_return_type): Strip them here.

Added:
trunk/gcc/testsuite/g++.dg/template/param3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/49418] [4.6 regression] G++ discards cv-quals from template parameter types

[jason at gcc dot gnu.org]

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

Jason Merrill jason at gcc dot gnu.org changed:

   What|Removed |Added

Summary|[4.6/4.7 regression] G++|[4.6 regression] G++
   |discards cv-quals from  |discards cv-quals from
   |template parameter types|template parameter types

--- Comment #8 from Jason Merrill jason at gcc dot gnu.org 2011-06-21 
19:07:21 UTC ---
Fixed on trunk.

[Bug tree-optimization/49494] New: ICE: in remap_predicate at ipa-inline-analysis.c:1876 with -findirect-inlining -finline-small-functions

[zsojka at seznam dot cz]

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

   Summary: ICE: in remap_predicate at ipa-inline-analysis.c:1876
with -findirect-inlining -finline-small-functions
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


Created attachment 24575
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24575
reduced testcase (the same as gfortran.dg/pr49179.f90)

Compiler output:
$ gcc -O -findirect-inlining -fno-guess-branch-probability -finline-functions
-finline-small-functions testcase.f90
testcase.f90:8:0: internal compiler error: vector VEC(int,base) index domain
error, in remap_predicate at ipa-inline-analysis.c:1876
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.

Tested revisions:
r175265 - crash

[Bug c++/49495] New: -O3 causes error message edge points to wrong declaration:

[dcb314 at hotmail dot com]

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

   Summary: -O3 causes error message edge points to wrong
declaration:
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dcb...@hotmail.com


Created attachment 24576
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24576
C++ source code

I just tried to compile the icedtea6-1.10.2 package with the latest
trunk snapshot 20110618 on an AMD x86_64 box.

The compiler said

/home/dcb/rpmbuild/BUILD/icedtea6-1.10.2/openjdk/hotspot/src/share/vm/adlc/formssel.cpp:4089:1:
error: edge points to wrong declaration:
 function_decl 0x7ff30ed2d500 _ZN9MatchNodeC2ER8ArchDescRS_i.constprop.30
type method_type 0x7ff30f6f4498

...

Preprocessed source code attached. Flag -O3 required.
It compiles fine with -O2.

[Bug fortran/49430] ICE with allocatable length character in interface block

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org

--- Comment #2 from janus at gcc dot gnu.org 2011-06-21 19:40:25 UTC ---
The same error occurs for the test case in PR 49112 comment 7:


module datetime_mod

implicit none
private

type :: DateTime
contains
procedure :: getFormattedString
end type

contains

function getTimeString(dt, FMT) result(string)
character(:), allocatable :: string
class(DateTime), intent(IN) :: dt
integer, optional, intent(IN) :: FMT

string = dt%getFormattedString(2, FMT)
end function 

function getFormattedString(this, FILTER, FMT) 
result(string)
character(:), allocatable :: string
class(DateTime), intent(IN) :: this
integer, optional, intent(IN) :: FILTER, FMT

end function

end module 


c7.f90: In function ‘gettimestring’:
c7.f90:18:0: internal compiler error: tree check: expected tree that contains
‘typed’ structure, have ‘’ in fold_convert_loc, at fold-const.c:1859

[Bug lto/44149] -fuse-linker-plugin lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:610

[paolo.carlini at oracle dot com]

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

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||4.6.1
 Resolution||FIXED

--- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2011-06-21 
19:48:22 UTC ---
Closing as fixed per:  http://gcc.gnu.org/ml/gcc/2011-06/msg00296.html

[Bug lto/44149] -fuse-linker-plugin lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:610

[paolo.carlini at oracle dot com]

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

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

   Target Milestone|--- |4.6.1

[Bug lto/44149] -fuse-linker-plugin lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:610

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres dominiq at lps dot ens.fr changed:

   What|Removed |Added

   Target Milestone|4.6.1   |---

--- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-06-21 
19:52:28 UTC ---
On behalf of Toon Moene (see http://gcc.gnu.org/ml/gcc/2011-06/msg00296.html )
closing as fixed.

[Bug c++/49482] [4.6/4.7 regression][C++0x] unused parameter warning on lambda in function template

[jason at gcc dot gnu.org]

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

Jason Merrill jason at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.06.21 19:59:12
 CC||jason at gcc dot gnu.org
 AssignedTo|unassigned at gcc dot   |jason at gcc dot gnu.org
   |gnu.org |
Summary|[regression][4.6.1-RC-20110 |[4.6/4.7 regression][C++0x]
   |620][C++0x] unused  |unused parameter warning on
   |parameter warning on lambda |lambda in function template
   |in function template|
 Ever Confirmed|0   |1

[Bug c++/49482] [4.6/4.7 regression][C++0x] unused parameter warning on lambda in function template

[jason at gcc dot gnu.org]

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

Jason Merrill jason at gcc dot gnu.org changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jason Merrill jason at gcc dot gnu.org 2011-06-21 
19:59:52 UTC ---
This is a minor regression relative to 4.6.0 with a trivial fix I'm testing
now.

[Bug tree-optimization/49496] New: [4.7 Regression] -fcompare-debug failure (length) with -O -ftree-vectorize

[zsojka at seznam dot cz]

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

   Summary: [4.7 Regression] -fcompare-debug failure (length) with
-O -ftree-vectorize
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
CC: aol...@gcc.gnu.org
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


Created attachment 24577
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24577
reduced testcase

This still happens after fixing PR49352

Compiler output:
$ gcc -O -ftree-vectorize -fcompare-debug testcase.c
gcc: error: testcase.c: -fcompare-debug failure (length)

Generated code differs a lot with/without -g.

Tested revisions:
r175265 - fail
4.6 r175269 - OK