[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[thenlich at users dot sourceforge.net]

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

--- Comment #8 from Thomas Henlich  
2011-04-16 06:42:52 UTC ---
(In reply to comment #7)
> -  if ((m > 0.0 && m < 0.1 - 0.05 * rexp_d) || (rexp_d * (m + 0.5) >= 1.0) ||\
> +  if ((m > 0.0 && m < 0.1 - r * rexp_d) || (rexp_d * (m + r) >= 1.0) ||\

This can't be right, replacing 0.05 with r. It must be r / 10 or 0.1 * r.

m < 0.1 - 0.1 * r * rexp_d
m < 0.1 * (1.0 - r * rexp_d)

[Bug inline-asm/48637] New: %c in ARM inline asm leads to ICE (in arm_print_operand)

[rabin at rab dot in]

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

   Summary: %c in ARM inline asm leads to ICE (in
arm_print_operand)
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ra...@rab.in


Created attachment 24009
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24009
minimized test case

Compiling the attached file leads to ICE with a GCC 4.6.0 ARM cross-compiler. 
It uses inline asm with %c and an element of a structure.  If the referenced
"state" element is made the first element of the structure, the file compiles
successfully.

~/tmp$ ~/x-tools/arm-unknown-eabi/bin/arm-unknown-eabi-gcc -c test.c
test.c: In function 'test':
test.c:25:1: internal compiler error: in arm_print_operand, at
config/arm/arm.c:16147
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

~/tmp$ ~/x-tools/arm-unknown-eabi/bin/arm-unknown-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=/home/rabin/x-tools/arm-unknown-eabi/bin/arm-unknown-eabi-gcc
COLLECT_LTO_WRAPPER=/home/rabin/x-tools/arm-unknown-eabi/libexec/gcc/arm-unknown-eabi/4.6.0/lto-wrapper
Target: arm-unknown-eabi
Configured with: /home/rabin/dev/crosstool-ng/.build/src/gcc-4.6.0/configure
--build=x86_64-build_unknown-linux-gnu --host=x86_64-build_unknown-linux-gnu
--target=arm-unknown-eabi --prefix=/home/rabin/x-tools/arm-unknown-eabi
--with-local-prefix=/home/rabin/x-tools/arm-unknown-eabi/arm-unknown-eabi/sysroot
--disable-multilib --disable-libmudflap
--with-sysroot=/home/rabin/x-tools/arm-unknown-eabi/arm-unknown-eabi/sysroot
--with-newlib --enable-threads=no --disable-shared
--with-pkgversion=crosstool-NG-hg_default@2404_8988576c491a --with-arch=armv5
--disable-__cxa_atexit
--with-gmp=/home/rabin/dev/crosstool-ng/.build/arm-unknown-eabi/build/static
--with-mpfr=/home/rabin/dev/crosstool-ng/.build/arm-unknown-eabi/build/static
--with-mpc=/home/rabin/dev/crosstool-ng/.build/arm-unknown-eabi/build/static
--with-ppl=no --with-cloog=no --with-libelf=no --disable-lto
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--disable-nls --enable-symvers=gnu --enable-languages=c
Thread model: single
gcc version 4.6.0 (crosstool-NG-hg_default@2404_8988576c491a)

gcc-bugs@gcc.gnu.org

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.04.16 04:31:12
 Ever Confirmed|0   |1

--- Comment #1 from Jonathan Wakely  2011-04-16 
04:31:12 UTC ---
yep, that diagnostic is pretty poor, see also c8 on PR 31423

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[jvdelisle at gcc dot gnu.org]

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

--- Comment #7 from Jerry DeLisle  2011-04-16 
04:30:04 UTC ---
Here is a patch for testing.

Index: io/write_float.def
===
--- io/write_float.def(revision 172502)
+++ io/write_float.def(working copy)
@@ -822,7 +822,7 @@ output_float_FMT_G_ ## x (st_parameter_dt *dtp, co
   int d = f->u.real.d;\
   int w = f->u.real.w;\
   fnode *newf;\
-  GFC_REAL_ ## x rexp_d;\
+  GFC_REAL_ ## x rexp_d, r = 0.5;\
   int low, high, mid;\
   int ubound, lbound;\
   char *p, pad = ' ';\
@@ -832,8 +832,26 @@ output_float_FMT_G_ ## x (st_parameter_dt *dtp, co
   save_scale_factor = dtp->u.p.scale_factor;\
   newf = (fnode *) get_mem (sizeof (fnode));\
 \
+  switch (dtp->u.p.current_unit->round_status)\
+{\
+  case ROUND_ZERO:\
+r = sign_bit ? 0.0 : 1.0;\
+break;\
+  case ROUND_UP:\
+r = 1.0;\
+break;\
+  case ROUND_DOWN:\
+r = 0.0;\
+break;\
+  case ROUND_NEAREST:\
+  case ROUND_PROCDEFINED:\
+  case ROUND_UNSPECIFIED:\
+  case ROUND_COMPATIBLE:\
+break;\
+}\
+\
   rexp_d = calculate_exp_ ## x (-d);\
-  if ((m > 0.0 && m < 0.1 - 0.05 * rexp_d) || (rexp_d * (m + 0.5) >= 1.0) ||\
+  if ((m > 0.0 && m < 0.1 - r * rexp_d) || (rexp_d * (m + r) >= 1.0) ||\
   ((m == 0.0) && !(compile_options.allow_std & GFC_STD_F2003)))\
 { \
   newf->format = FMT_E;\
@@ -855,7 +873,7 @@ output_float_FMT_G_ ## x (st_parameter_dt *dtp, co
   GFC_REAL_ ## x temp;\
   mid = (low + high) / 2;\
 \
-  temp = (calculate_exp_ ## x (mid - 1) * (1 - 0.5 * rexp_d));\
+  temp = (calculate_exp_ ## x (mid - 1) * (1 - r * rexp_d));\
 \
   if (m < temp)\
 { \

[Bug libstdc++/48631] [C++0x] default_delete accepts pointer conversions in function call operator

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #5 from Paolo Carlini  2011-04-16 
02:09:46 UTC ---
Jason, in case the issue is not known and your are interested: after the
library fix we reject the snippet but we give the error message twice.

[Bug libstdc++/48631] [C++0x] default_delete accepts pointer conversions in function call operator

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Paolo Carlini  2011-04-16 
02:05:43 UTC ---
Done. Fixed mainline and 4_6-branch.

[Bug libstdc++/48631] [C++0x] default_delete accepts pointer conversions in function call operator

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  
2011-04-16 02:05:01 UTC ---
Author: paolo
Date: Sat Apr 16 02:04:56 2011
New Revision: 172535

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172535
Log:
2011-04-15  Daniel Krugler  
Paolo Carlini  

PR libstdc++/48631
* include/bits/unique_ptr.h (default_delete<_Tp[]>): Add deleted
function call operator.
* testsuite/20_util/default_delete/48631_neg.cc: New.
* testsuite/20_util/weak_ptr/comparison/cmp_neg.cc: Adjust dg-error
line numbers.

Added:
   
branches/gcc-4_6-branch/libstdc++-v3/testsuite/20_util/default_delete/48631_neg.cc
Modified:
branches/gcc-4_6-branch/libstdc++-v3/ChangeLog
branches/gcc-4_6-branch/libstdc++-v3/include/bits/unique_ptr.h
   
branches/gcc-4_6-branch/libstdc++-v3/testsuite/20_util/weak_ptr/comparison/cmp_neg.cc

[Bug libstdc++/48631] [C++0x] default_delete accepts pointer conversions in function call operator

[paolo at gcc dot gnu.org]

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

--- Comment #2 from paolo at gcc dot gnu.org  
2011-04-16 02:02:35 UTC ---
Author: paolo
Date: Sat Apr 16 02:02:29 2011
New Revision: 172534

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172534
Log:
2011-04-15  Daniel Krugler  
Paolo Carlini  

PR libstdc++/48631
* include/bits/unique_ptr.h (default_delete<_Tp[]>): Add deleted
function call operator.
* testsuite/20_util/default_delete/48631_neg.cc: New.
* testsuite/20_util/weak_ptr/comparison/cmp_neg.cc: Adjust dg-error
line numbers.

Added:
trunk/libstdc++-v3/testsuite/20_util/default_delete/48631_neg.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/unique_ptr.h
trunk/libstdc++-v3/testsuite/20_util/weak_ptr/comparison/cmp_neg.cc

[Bug libstdc++/48631] [C++0x] default_delete accepts pointer conversions in function call operator

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.04.16 01:19:45
 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot
   |gnu.org |com
   Target Milestone|--- |4.6.1
 Ever Confirmed|0   |1

--- Comment #1 from Paolo Carlini  2011-04-16 
01:19:45 UTC ---
I'm handling this one too.

[Bug libstdc++/48635] [C++0x] unique_ptr moves the deleter instead of copying it

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #5 from Paolo Carlini  2011-04-16 
00:56:57 UTC ---
Done. Fixed mainline and 4_6-branch.

[Bug libstdc++/48635] [C++0x] unique_ptr moves the deleter instead of copying it

[paolo at gcc dot gnu.org]

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

--- Comment #4 from paolo at gcc dot gnu.org  
2011-04-16 00:55:59 UTC ---
Author: paolo
Date: Sat Apr 16 00:55:53 2011
New Revision: 172533

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172533
Log:
2011-04-15  Daniel Krugler  
Paolo Carlini  

PR libstdc++/48635
* include/bits/unique_ptr.h (unique_ptr<>::operator=(unique_ptr&&),
unique_ptr<>::operator=(unique_ptr<>&&),
unique_ptr<_Tp[],>::operator=(unique_ptr&&),
unique_ptr<_Tp[],>::operator=(unique_ptr<>&&)): Forward the deleter
instead of moving it.
* testsuite/20_util/unique_ptr/assign/48635.cc: New.

Added:
   
branches/gcc-4_6-branch/libstdc++-v3/testsuite/20_util/unique_ptr/assign/48635.cc
Modified:
branches/gcc-4_6-branch/libstdc++-v3/ChangeLog
branches/gcc-4_6-branch/libstdc++-v3/include/bits/unique_ptr.h

[Bug libstdc++/48635] [C++0x] unique_ptr moves the deleter instead of copying it

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  
2011-04-16 00:55:49 UTC ---
Author: paolo
Date: Sat Apr 16 00:55:43 2011
New Revision: 172532

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172532
Log:
2011-04-15  Daniel Krugler  
Paolo Carlini  

PR libstdc++/48635
* include/bits/unique_ptr.h (unique_ptr<>::operator=(unique_ptr&&),
unique_ptr<>::operator=(unique_ptr<>&&),
unique_ptr<_Tp[],>::operator=(unique_ptr&&),
unique_ptr<_Tp[],>::operator=(unique_ptr<>&&)): Forward the deleter
instead of moving it.
* testsuite/20_util/unique_ptr/assign/48635.cc: New.

Added:
trunk/libstdc++-v3/testsuite/20_util/unique_ptr/assign/48635.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/unique_ptr.h

[Bug target/48495] ICE in in reload_cse_simplify_operands

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.04.16 00:34:52
 Ever Confirmed|0   |1

--- Comment #2 from Peter Bergner  2011-04-16 
00:34:52 UTC ---
Talking with Pat off line, I used the same system and configure options he used
and can now recreate the ICE.  Looking.

[Bug libstdc++/48635] [C++0x] unique_ptr moves the deleter instead of copying it

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.04.16 00:25:26
 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot
   |gnu.org |com
   Target Milestone|--- |4.6.1
 Ever Confirmed|0   |1

--- Comment #2 from Paolo Carlini  2011-04-16 
00:25:26 UTC ---
Thanks, Daniel. I'll fix this momentarily.

[Bug target/48629] ICE on gcc.dg/pr42389.c on ia64-*-* with -fsched-pressure

[bernds at gcc dot gnu.org]

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

--- Comment #1 from Bernd Schmidt  2011-04-15 
23:32:58 UTC ---
Author: bernds
Date: Fri Apr 15 23:32:55 2011
New Revision: 172525

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172525
Log:
PR target/48629
* haifa-sched.c (prune_ready_list, schedule_block): Use
sched_pressure_p rather than flag_sched_pressure.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/haifa-sched.c

[Bug lto/48492] [4.7 Regression] LTO bootstrap failure in copy_constant

[ebotcazou at gcc dot gnu.org]

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

--- Comment #3 from Eric Botcazou  2011-04-15 
22:52:08 UTC ---
The scenario is as follows:
  1. during LTO stage, copy-prop eliminates a DECL_IN_CONSTANT_POOL variable
from the GIMPLE IR, except for a reference in a GIMPLE_DEBUG statement
(ADDR_EXPR of the variable is the debug value),
  2. the variable is streamed out in the object file, as well as its associated
varpool entry,
  3. during WPA stage, both are streamed in, then reachability analysis is run
and computes that the variable is unreachable so removes the varpool entry.
As a consequence, when the variable is streamed out again, its initializer gets
replaced with ERROR_MARK.
  4. during LTRANS stage, the variable is again streamed in, with ERROR_MARK as
initializer and this blows up when the GIMPLE_DEBUG statement is processed.

So ISTM that the problem is in the reachability analysis during the WPA stage.

[Bug c/48623] gcc 4.6.0 generates no code for a function with __attribute__((always_inline))

[richard at nod dot at]

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

--- Comment #11 from Richard Weinberger  2011-04-15 
22:27:19 UTC ---
(In reply to comment #10)
> You have to make use of 'p' of course.  Your return value still is based
> on &ti.

Damn, you're right!

Now gcc produces a functional UML kernel. :-)

I fear current_thread_info() is not the only function in the kernel
which returns a local stack address.

Thanks,
//richard

[Bug rtl-optimization/44194] struct returned by value generates useless stores

[eraman at google dot com]

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

--- Comment #15 from Easwaran Raman  2011-04-15 
22:22:15 UTC ---
(In reply to comment #14)
> On Fri, 15 Apr 2011, eraman at google dot com wrote:
> 
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
> > 
> > Easwaran Raman  changed:
> > 
> >What|Removed |Added
> > 
> >  CC||eraman at google dot com
> > 
> > --- Comment #13 from Easwaran Raman  2011-04-15 
> > 19:18:25 UTC ---
> > Richard, did you mean to write
> > 
> > static bool
> > can_escape (tree expr)
> > {
> >   tree base;
> >   if (!expr)
> > return true;
> >   base = get_base_address (expr);
> >   if (DECL_P (base)
> >   && (!may_be_aliased (base)
> >   && !pt_solution_includes (&cfun->gimple_df->escaped, base)))
> > return false;
> >   return true;
> > }
> > 
> > Only case when we know it doesn't escape is if bas is a DECL_P and is not in
> > cfun->gimple_df->escaped and not aliased, right? Actually, I'm wondering if 
> > it
> > is sufficient to test just
> > DECL_P (base) && !pt_solution_includes (&cfun->gimple_df->escaped, base).
> 
> No, because if the escaped solution for example includes ANYTHING then
> the test will return true.  That !may-aliased variables are not
> contained in ANYTHING isn't known w/o context.
> 
> Richard.

Correct me if I am wrong. If I understand you right, just using DECL_P (base)
&& !pt_solution_includes is conservative since pt_solution_includes may return
true if the escaped solution contains ANYTHING. To make it less conservative,
you're suggesting

  if (DECL_P (base)
  && (!may_be_aliased (base)
  || !pt_solution_includes (&cfun->gimple_df->escaped, base)))
return false;

 I tried that and most Fortran tests are failing. One of the tests
(default_format_1.f90) has the following RTL sequence:


(insn 30 29 32 4 (set (mem/s/c:SI (plus:DI (reg/f:DI 20 frame)
(const_int -608 [0xfda0])) [2
dt_parm.0.common.flags+0 S4 A64])
(const_int 16512 [0x4080])) default_format_1.inc:56 64
{*movsi_internal}
 (nil))

(insn 32 30 33 4 (set (reg:DI 5 di)
(reg/f:DI 106)) default_format_1.inc:56 62 {*movdi_internal_rex64}
 (expr_list:REG_EQUAL (plus:DI (reg/f:DI 20 frame)
(const_int -608 [0xfda0]))
(nil)))

(call_insn 33 32 36 4 (call (mem:QI (symbol_ref:DI ("_gfortran_st_write")
[flags 0x41]  ) [0
_gfortran_st_write S1 A8])
(const_int 0 [0])) default_format_1.inc:56 618 {*call_0}
 (expr_list:REG_DEAD (reg:DI 5 di)
(nil))
(expr_list:REG_DEP_TRUE (use (reg:DI 5 di))
(nil)))

For the DECL dt_parm, pt_solution_includes (&cfun->gimple_df->escaped, base)
returns false, even though its location is passed as a parameter to
_gfortran_st_write.

I did test  with 
if (DECL_P (base)
  && (!may_be_aliased (base)
  && !pt_solution_includes (&cfun->gimple_df->escaped, base)))

which has no regressions. Is that what you suggest?

[Bug c/48623] gcc 4.6.0 generates no code for a function with __attribute__((always_inline))

[matz at gcc dot gnu.org]

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

Michael Matz  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||matz at gcc dot gnu.org
 Resolution||INVALID

--- Comment #10 from Michael Matz  2011-04-15 22:03:05 
UTC ---
You didn't change the current_thread_info carefully enough as per
comment #3.  It still reads:

static inline __attribute__((always_inline)) struct thread_info
*current_thread_info(void)
{
 struct thread_info *ti;
 void *p;
 unsigned long mask = ((1 << 0) * ((1UL) << 12)) - 1;
 asm volatile ("" : "=r" (p) : "0" (&ti));
 ti = (struct thread_info *) (((unsigned long) &ti) & ~mask);
 return ti;
}

You have to make use of 'p' of course.  Your return value still is based
on &ti.

[Bug libstdc++/48635] [C++0x] unique_ptr moves the deleter instead of copying it

[daniel.kruegler at googlemail dot com]

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

--- Comment #1 from Daniel Krügler  
2011-04-15 21:44:56 UTC ---
(In reply to comment #0)

The exactly same problem exists for the specialization std::unique_ptr.

[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 #36 from Tobias Burnus  2011-04-15 
21:41:28 UTC ---
Author: burnus
Date: Fri Apr 15 21:41:25 2011
New Revision: 172522

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172522
Log:
2011-04-15  Tobias Burnus  

PR fortran/18918
* trans-intrinsic.c (conv_intrinsic_cobound): Remove unused
code which is also causing an ICE.

2011-04-15  Tobias Burnus  

PR fortran/18918
* gfortran.dg/coarray_15.f90: Change to dg-do run.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-intrinsic.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/coarray_15.f90

[Bug rtl-optimization/48633] IRA causes ICE in compensate_edge

[matz at gcc dot gnu.org]

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

--- Comment #1 from Michael Matz  2011-04-15 21:17:22 
UTC ---
During reducing the testcase I had this hunk applied for ira-build.c:

Index: ira-build.c
===
--- ira-build.c (Revision 172515)
+++ ira-build.c (Arbeitskopie)
@@ -1861,6 +1861,7 @@ mark_loops_for_removal (void)
ira_loop_nodes[i].to_remove_p
  = (low_pressure_loop_node_p (ira_loop_nodes[i].parent)
 && low_pressure_loop_node_p (&ira_loop_nodes[i]));
+   ira_loop_nodes[i].to_remove_p = false;
   }
   qsort (sorted_loops, n, sizeof (ira_loop_tree_node_t), loop_compare_func);
   for (i = 0; n - i + 1 > IRA_MAX_LOOPS_NUM; i++)

This disables the merging of the loop with its parent which also hides
the problem.  Without that hunk a failing testcase looks for instance like so
(artificially increasing reg pressure for the body):

% cat pr48633.cc
/* { dg-do compile} */
/* { dg-options "-O2 -fira-region=all -fnon-call-exceptions" } */
extern long double getme (void);
extern void useme (long double);
struct Frame {
long double tmp;
};
void bugme (int n, long double ld1, long double ld2, long double ld3,
long double ld4, long double ld5)
{
  Frame f;
  int i;
  f.tmp = getme();
  try {
for (i = 0; i < n; i++)
  {
f.tmp += 1.0;
  }
  } catch (...) {
f.tmp += 1.0;
  }
  ld1++;
  ld2++;
  ld3++;
  ld4++;
  ld5++;
  useme (f.tmp);
}

The allocno and instruction numbers will change relative to the initial
comment of course.  It's still pseudo 61, but now allocno a7 for loop0,
a23 for loop1, and the compensation code is insn 106.

[Bug fortran/48624] gfortran DECL issues in function declaration

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  2011-04-15 
21:16:20 UTC ---
The reason for the issue can be found in trans-decl.c:

gfc_get_extern_function_decl (gfc_symbol * sym)
[...]
  /* Do not use procedures that have a procedure argument because this
 can result in problems of multiple decls during inlining.  */
  proc_formal_arg = false;
  if (gsym && gsym->ns && gsym->ns->proc_name)

[Bug fortran/48636] New: Enable more inlining with -O2 and higher

[tkoenig at gcc dot gnu.org]

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

   Summary: Enable more inlining with -O2 and higher
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tkoe...@gcc.gnu.org


See http://gcc.gnu.org/ml/fortran/2011-04/msg00144.html .

We whould inline more for Fortran at higher optimization levels.

Options to consider:

- Set -finline-limit=600 for -O2 and higher

- Consider heuristics to mark functions as inline in the front end:

- If it has many arguments (argument processing has a lot of effect)

- If it uses assumed-shape arrays (setting up that array descriptor
  may take a lot of time

- Mark everything as inline

[Bug libstdc++/48635] New: [C++0x] unique_ptr moves the deleter instead of copying it

[daniel.kruegler at googlemail dot com]

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

   Summary: [C++0x] unique_ptr moves the deleter instead of
copying it
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com


The following program using 4.7.0 20110409 (experimental) should print "copy",
but it prints "move" instead:

//-
#include 
#include 
#include 

struct Deleter {
  Deleter() = default;
  Deleter(const Deleter&) = default;
  Deleter(Deleter&&) = default;
  Deleter& operator=(const Deleter&) {
std::cout << "copy" << std::endl;
return *this;
  }
  Deleter& operator=(Deleter&&) {
std::cout << "move" << std::endl;
return *this;
  }
  template
  void operator()(T* p) const
  {
delete p;
  }
};

int main() {
  Deleter d1, d2;
  std::unique_ptr p1(new int, d1), p2(nullptr, d2);
  p2 = std::move(p1);
}
//-

The reason for the failure is, that the library implementation of the
move-assignment operator of std::unique_ptr (and of it's templated variant)
uses std::move to transfer the deleter from the source to the target, but as of
[unique.ptr.single.asgn] p. 2 and p. 6 it shall use std::forward instead. Doing
it correctly will ensure that the deleter is copied and not moved in this case,
which is an intended design aim of std::unique_ptr with deleters that are
lvalue-references.

The necessary fix is to replace the usage of std::move at the two places by
std::forward.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[jvdelisle at gcc dot gnu.org]

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

--- Comment #6 from Jerry DeLisle  2011-04-15 
20:57:31 UTC ---
Ha, OK thanks. I see it.

[Bug target/48634] New: Missed optimization for use of __builtin_ctzll() and __builtin_clzll

[svfuerst at gmail dot com]

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

   Summary: Missed optimization for use of __builtin_ctzll() and
__builtin_clzll
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: svfue...@gmail.com
Target: amd64


unsigned long long foo(unsigned long long x)
{
return __builtin_ctzll(x);
}

Compiles into

bsf%rdi,%rax
cltq
retq

at -O3 with 4.6.0
The cltq instruction isn't needed because the bitscan instruction will zero out
the upper 32 bits of rax.  Basically, the return value of these intrinsics
should be unsigned long long instead of int on 64 bit machines.  The ABI means
that the reverse process of truncating back down to an int costs zero
instructions.

[Bug fortran/48462] [4.6/4.7 Regression] realloc on assignment: matmul Segmentation Fault with Allocatable Array

[pault at gcc dot gnu.org]

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

--- Comment #6 from Paul Thomas  2011-04-15 20:40:58 
UTC ---
Created attachment 24008
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24008
A fix for the PR

This fixes the PR and bootstraps/regtests on FC9/x86_64.

I will continue to look for something more elegant but I think that is is
possible the best that can be done whilst using the library to do the
allocation.

Paul

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[thenlich at users dot sourceforge.net]

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

--- Comment #5 from Thomas Henlich  
2011-04-15 20:41:02 UTC ---
(In reply to comment #4)
> OK I knew I was "looking" at it wrong. The formulas you mention we are using
> and are in write_float.def starting at line 798. The table is there as well. I
> have been exploring the code here but have not spotted it yet.  The issue 
> could
> either be in this formula implementation or in the rounding code which is
> nearby.

Ok, found something: The table has 0.5 hardcoded instead of the correct
(rounding-mode dependent) r. And the code in line 836 (and 858?) also.

[Bug fortran/48426] [patch] Quad precision promotion

[jvdelisle at gcc dot gnu.org]

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

--- Comment #14 from Jerry DeLisle  2011-04-15 
20:30:44 UTC ---
Super! If you have not already figured it out.  We are really short on help.

[Bug c/48623] gcc 4.6.0 generates no code for a function with __attribute__((always_inline))

[richard at nod dot at]

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

--- Comment #9 from Richard Weinberger  2011-04-15 
20:26:48 UTC ---
Created attachment 24007
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24007
preprocessed softirq.c

[Bug c/48623] gcc 4.6.0 generates no code for a function with __attribute__((always_inline))

[richard at nod dot at]

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

--- Comment #8 from Richard Weinberger  2011-04-15 
20:26:03 UTC ---
Created attachment 24006
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24006
preprocessed __local_bh_enable function

[Bug c/47939] Missing DW_TAG_typedef for qualified types

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #11 from Richard Guenther  2011-04-15 
20:14:04 UTC ---
Fixed.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[jvdelisle at gcc dot gnu.org]

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

--- Comment #4 from Jerry DeLisle  2011-04-15 
20:13:12 UTC ---
OK I knew I was "looking" at it wrong. The formulas you mention we are using
and are in write_float.def starting at line 798. The table is there as well. I
have been exploring the code here but have not spotted it yet.  The issue could
either be in this formula implementation or in the rounding code which is
nearby.

[Bug rtl-optimization/48633] New: IRA causes ICE in compensate_edge

[matz at gcc dot gnu.org]

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

   Summary: IRA causes ICE in compensate_edge
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@gcc.gnu.org


Since r172516 the Ada testcase cxg2001 fails with an ICE in compensate_edge
on x86_64-linux.

The problem is not specific to Ada an can be reproduced with a C++ testcase
simulating what Ada does.  This testcase does not need the patch from r172516
and also fails before:

% cat ira-bug.cc
/* { dg-do compile} */
/* { dg-options "-O2 -fira-region=all -fnon-call-exceptions" } */
extern long double getme (void);
extern void useme (long double);
struct Frame {
long double tmp;
};
void bugme (int n)
{
  Frame f;
  int i;
  f.tmp = getme();
  try {
for (i = 0; i < n; i++)
  {
f.tmp += 1.0;
  }
  } catch (...) {
f.tmp += 1.0;
  }
  useme (f.tmp);
}

% ./cc1plus -O2 -fnon-call-exceptions -fira-region=all ira-bug.cc
ira-bug.cc: In function ‘void bugme(int)’:
ira-bug.cc:22:1: internal compiler error: in compensate_edge, at
reg-stack.c:2781

-fnon-call-exceptions is needed as Ada effectively sets it, -fira-region=all
is needed to make IRA fail on this small testcase, otherwise IRA assigned
registers for the subloops here due to low reg pressure.  The Ada testcase
has much higher pressure causing IRA to go into the same code-paths as
with ira-region=all.

The problem is the allocation of pseudo 61 to hardreg 10 (a stackreg).
pseudo 61 gets two allocnos, a1 for loop0 which conflicts with the stackregs
because it's live over abnormal edges, and a8 for loop1 which doesn't
conflict with those stackregs (which is okay).

The problem is the transition from loop1 (a8 alloced to hardreg 10) to loop0
(a1, spilled), which requires a memory store from h10 to stack.  But the
transition itself goes over an EH edge, and the compensation code is inserted
into the EH block:

(code_label/s 65 36 67 11 8 "" [1 uses])

(note 67 65 84 11 [bb 11] NOTE_INSN_BASIC_BLOCK)

(insn 84 67 40 11 (set (mem/c:XF (plus:DI (reg/f:DI 7 sp)
(const_int 32 [0x20])) [4 %sfp+-16 S16 A128])
(reg:XF 10 st(2) [orig:61 f$tmp ] [61])) 105 {*movxf_internal}
 (nil))

This is the compensation code, requiring hardreg 10 to be set, but this
bb 11 is the target of an EH edge.  This then later is checked in the
reg-stack pass and asserts.

The IRA dump is somewhat interesting:

  Loop 0 (parent -1, header bb0, depth 0)
bbs: 12 11 10 9 8 7 3(->5:l1) 2
all: 0r62 1r61 2r73 3r70 4r69 5r74 6r63 7r66
modified regnos: 61 62 63 66 69 70 73 74
border:
Pressure: GENERAL_REGS=2 FLOAT_REGS=4
Hard reg set forest:
  0:( 0-6 8-15 21-51)@0
1:( 0-6 37-44)@24004
  2:( 0 3 5 6 41-44)@14
3:( 8-15)@60040
  Spill a1(r61,l0)

So, for loop0 r61 is spilled, fine.

  Loop 1 (parent 0, header bb5, depth 1)
bbs: 6(->7:l0) 5(->11:l0) 4

So we have two exits from this region, via 6->7 (the normal loop exit)
and via 5->11 (the EH edge).

all: 8r61 9r63 10r66 11r73 12r74 13r62
modified regnos: 61 62 63
border: 8r61 9r63 10r66 11r73 12r74 13r62
Pressure: GENERAL_REGS=2 FLOAT_REGS=4
Hard reg set forest:
  0:( 0-6 8-15 21-51)@0
1:( 0-6 37-44)@22920
2:( 8 10-15)@72856
  Allocno a8r61 of FLOAT_REGS(8) has 7 avail. regs 8 10-15
  ...
  Popping a8(r61,l1)  -- assign reg 10

So, r61 in the loop gets hardreg 10.  Then we go on:

New iteration of spill/restore move
  Changing RTL for loop 1 (header bb5)
  10 vs parent -1:  Creating newreg=75 from oldreg=61

So, it noticed that the two regions have different dispositions for the
same pseudo, and generates compensation code:

rescanning insn with uid = 18.
deleting insn with uid = 18.
rescanning insn with uid = 7.
deleting insn with uid = 7.
scanning new insn with uid = 84.

insn 84 is the compensation code, and it's placed in a region where the source
(a8 == hardreg 10) isn't live anymore.

[Bug c/48623] gcc 4.6.0 generates no code for a function with __attribute__((always_inline))

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011.04.15 20:11:31
 Ever Confirmed|0   |1

--- Comment #7 from Richard Guenther  2011-04-15 
20:11:31 UTC ---
Please provide preprocessed source for the translation unit that has the
broken function.

[Bug tree-optimization/48616] -ftree-vectorize -mxop miscompiles right shift

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Guenther  2011-04-15 
20:08:19 UTC ---
See PR48317 for one reason why vector stuff isn't optimized too well.

[Bug rtl-optimization/48628] ICE in reload

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Target||arm-eabi

--- Comment #2 from Richard Guenther  2011-04-15 
20:09:04 UTC ---
Please specify the compiler version you used.

[Bug c++/48632] Internal compiler error when using OpenMP with template

[phelippeneveu at gmail dot com]

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

--- Comment #1 from Phelippe Neveu  2011-04-15 
20:06:07 UTC ---
Created attachment 24005
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24005
Preprocessed source file.

[Bug c++/48632] New: Internal compiler error when using OpenMP with template

[phelippeneveu at gmail dot com]

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

   Summary: Internal compiler error when using OpenMP with
template
   Product: gcc
   Version: 4.5.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: phelippene...@gmail.com


Created attachment 24004
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24004
Source code to reproduce the problem.

Hi,

I'm getting a internal compiler error when trying to compile a piece of code
that uses OpenMP inside of templated code. I use pointer arithmetic using a
template type inside the for loop header. I'm not sure if my code is legal for
OpenMP, but it should not cause a internal compiler error.


Output of "gcc -v":

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/pneveu/apps/gcc-4.5-src/libexec/gcc/x86_64-unknown-linux-gnu/4.5.3/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: src/gcc/configure
--with-mpc=/home/pneveu/apps/gcc-4.5-src/prerequisites
--with-mpfr=/home/pneveu/apps/gcc-4.5-src/prerequisites
--with-gmp=/home/pneveu/apps/gcc-4.5-src/prerequisites
--with-ppl=/home/pneveu/apps/gcc-4.5-src/prerequisites
--with-cloog=/home/pneveu/apps/gcc-4.5-src/prerequisites
--prefix=/home/pneveu/apps/gcc-4.5-src
Thread model: posix
gcc version 4.5.3 20110412 (prerelease) (GCC) 


Command to reproduce the problem:

g++ -fopenmp -c test.cpp


Output of the problem:

test.cpp: In function ‘void CopyData(TDataType*, unsigned int, unsigned int,
TDataType*, unsigned int, unsigned int, unsigned int, unsigned int, unsigned
int)’:
test.cpp:25:54: internal compiler error: in build2_stat, at tree.c:3680
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Cheers,

Phelippe

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[thenlich at users dot sourceforge.net]

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

--- Comment #3 from Thomas Henlich  
2011-04-15 19:58:55 UTC ---
(In reply to comment #2)
> I am missing something here:
> 
> "print "(RU,G15.2)", .991d0
> prints 1.00 but the expected result is 1.0 because 1 - r * 10**-2 < .991 with 
> r
> = 1 because of UP rounding mode"
> 
> We are asking for two decimal digits in g15.2 above so 1.00 looks right to me.

No. The d in G editing describes the number of significant digits, not the
number of decimal digits.

Fortran 2008: 10.7.5.2.2 states clearly (first table in clause 4) that for a
value which rounds to a value greater or equal to 1 and smaller than 10 the
equivalent conversion is F(w-n).(d-1) and n blanks.

Thus the number of significant digits is d, because 1 digit comes before the
decimal separator and (d-1) digits after it.

GFortran does it right in most cases, except the ones described in this bug:
UP/DOWN rounding with values close to 1 (or other powers of 10) which would
round differently if COMPATIBLE rounding was in effect.

[Bug libstdc++/48631] New: [C++0x] default_delete accepts pointer conversions in function call operator

[daniel.kruegler at googlemail dot com]

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

   Summary: [C++0x] default_delete accepts pointer
conversions in function call operator
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com


The following program using 4.7.0 20110409 (experimental) should be rejected,
but is accepted:

//
#include 

struct B {};
struct D : B {};

int main() {
  D d;
  std::default_delete db;
  typedef decltype(db(&d)) type;
}
//

Reason for this deviation of the spec is the missing deleted function call
operator as described in [unique.ptr.dltr.dflt1]:

template  struct default_delete {
  constexpr default_delete() noexcept = default;
  void operator()(T*) const;
  template  void operator()(U*) const = delete;
};

[Bug fortran/48426] [patch] Quad precision promotion

[inform at tiker dot net]

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

--- Comment #13 from Andreas Kloeckner  2011-04-15 
19:46:45 UTC ---
Just requested the assignment forms. I'll let you know when we've returned
them.

gcc-bugs@gcc.gnu.org

[ian at airs dot com]

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

   Summary: Poor g++ suggestion: did you forget the ‘&’
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: i...@airs.com


If I compile this C++ test case with current mainline:

class C { public: C* f(); int get(); };
int f(C* p) { return p->f->get(); }

I get this:

foo.cc: In function ‘int f(C*)’:
foo.cc:2:26: error: invalid use of member (did you forget the ‘&’ ?)
foo.cc:2:26: error: base operand of ‘->’ is not a pointer

When I get this error message, it has never been the case that I forgot the
'&'.  It has always been the case that I forgot the '()', or that I typed a
method name where I meant to type a member name.  This particular suggestion
hurts more than it helps.

Some examination of context could probably produce a better suggestion. 
However, if that turns out to be too difficult, I think that overall we would
be better off if this particular suggestion were dropped.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[jvdelisle at gcc dot gnu.org]

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

--- Comment #2 from Jerry DeLisle  2011-04-15 
19:31:06 UTC ---
I am missing something here:

"print "(RU,G15.2)", .991d0
prints 1.00 but the expected result is 1.0 because 1 - r * 10**-2 < .991 with r
= 1 because of UP rounding mode"

We are asking for two decimal digits in g15.2 above so 1.00 looks right to me.

I do see a problem with this:

print "(RU,G15.1)", .991d0
print "(RU,G15.2)", .991d0
print "(RU,G15.3)", .991d0
print "(RU,G15.4)", .991d0
print "(RU,G15.5)", .991d0

Which gives:

 1.   <--This should be 1.0 I believe 
   1.00
  0.991
 0.9910
0.99100   


On the rounding down side we have:

print "(RD,G15.1)", .991d0
print "(RD,G15.2)", .991d0
print "(RD,G15.3)", .991d0
print "(RD,G15.4)", .991d0
print "(RD,G15.5)", .991d0

Gives:

 0.  <-- This should be 0.9 I believe
   0.99
  0.990
 0.9909
0.99099 

What do you think Thomas?

[Bug rtl-optimization/44194] struct returned by value generates useless stores

[rguenther at suse dot de]

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

--- Comment #14 from rguenther at suse dot de  
2011-04-15 19:31:36 UTC ---
On Fri, 15 Apr 2011, eraman at google dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
> 
> Easwaran Raman  changed:
> 
>What|Removed |Added
> 
>  CC||eraman at google dot com
> 
> --- Comment #13 from Easwaran Raman  2011-04-15 
> 19:18:25 UTC ---
> Richard, did you mean to write
> 
> static bool
> can_escape (tree expr)
> {
>   tree base;
>   if (!expr)
> return true;
>   base = get_base_address (expr);
>   if (DECL_P (base)
>   && (!may_be_aliased (base)
>   && !pt_solution_includes (&cfun->gimple_df->escaped, base)))
> return false;
>   return true;
> }
> 
> Only case when we know it doesn't escape is if bas is a DECL_P and is not in
> cfun->gimple_df->escaped and not aliased, right? Actually, I'm wondering if it
> is sufficient to test just
> DECL_P (base) && !pt_solution_includes (&cfun->gimple_df->escaped, base).

No, because if the escaped solution for example includes ANYTHING then
the test will return true.  That !may-aliased variables are not
contained in ANYTHING isn't known w/o context.

Richard.

[Bug rtl-optimization/44194] struct returned by value generates useless stores

[eraman at google dot com]

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

Easwaran Raman  changed:

   What|Removed |Added

 CC||eraman at google dot com

--- Comment #13 from Easwaran Raman  2011-04-15 
19:18:25 UTC ---
Richard, did you mean to write

static bool
can_escape (tree expr)
{
  tree base;
  if (!expr)
return true;
  base = get_base_address (expr);
  if (DECL_P (base)
  && (!may_be_aliased (base)
  && !pt_solution_includes (&cfun->gimple_df->escaped, base)))
return false;
  return true;
}

Only case when we know it doesn't escape is if bas is a DECL_P and is not in
cfun->gimple_df->escaped and not aliased, right? Actually, I'm wondering if it
is sufficient to test just
DECL_P (base) && !pt_solution_includes (&cfun->gimple_df->escaped, base).

[Bug tree-optimization/48616] -ftree-vectorize -mxop miscompiles right shift

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  2011-04-15 
19:08:50 UTC ---
Created attachment 24003
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24003
gcc46-pr48616.patch

This untested patch seems to work for me, though the generated code is in some
cases still less than ideal, because it doesn't figure it can just use a vector
computed in the earlier bb.  It would be nice if it could figure that out or
some later pass be able to clean that up.

Additionally, it doesn't seem to SLP optimize fn3's first bb, where it very
well could use a scalar shift.

The testcase will fail without the patch just when testing with -mxop in flags,
we don't have unfortunately yet xop and xop_runtime effective targets in
testsuite/lib/

[Bug middle-end/48585] [4.7 Regression] 483.xalancbmk in SPEC CPU 2006 failed to build

[jamborm at gcc dot gnu.org]

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

--- Comment #7 from Martin Jambor  2011-04-15 
18:34:30 UTC ---
Well, I guess I should have verified this but it seems that
&__comp_dtor is not actually one of the constants propagated by
IPA-CP.  So we'll have to figure out where it actually comes from
first.

[Bug middle-end/48600] [4.6 regression] ICE when using cold attribute

[matt at use dot net]

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

--- Comment #3 from Matt Hargett  2011-04-15 18:30:23 UTC 
---
I added the attachment; are you still waiting on something from me? Let me know
:)

[Bug middle-end/48601] [4.7 Regression] ICE in lower_emutls_function_body, at tree-emutls.c:623

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #8 from Martin Jambor  2011-04-15 
18:26:05 UTC ---
Thanks, so this should be fixed with
http://gcc.gnu.org/ml/gcc-patches/2011-04/msg01227.html

[Bug middle-end/48601] [4.7 Regression] ICE in lower_emutls_function_body, at tree-emutls.c:623

[jamborm at gcc dot gnu.org]

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

--- Comment #7 from Martin Jambor  2011-04-15 
18:20:51 UTC ---
Author: jamborm
Date: Fri Apr 15 18:20:46 2011
New Revision: 172512

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172512
Log:
2011-04-15  Martin Jambor  

PR middle-end/48601
* tree-emutls.c (lower_emutls_function_body): Call
cgraph_get_create_node instead of cgraph_get_node.  Do not assert the
result is non-NULL.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-emutls.c

[Bug target/48629] New: ICE on gcc.dg/pr42389.c on ia64-*-* with -fsched-pressure

[sje at cup dot hp.com]

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

   Summary: ICE on gcc.dg/pr42389.c on ia64-*-* with
-fsched-pressure
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: s...@cup.hp.com


The test gcc.dg/pr42389.c started failing at r171845 on IA64 HP-UX and Linux.

obj_gcc/gcc/cc1 -O2 -fselective-scheduling -fsel-sched-pipelining
-fsched-pressure -quiet pr42389.c


pr42389.c: In function 'reset_path_costs':
pr42389.c:49:1: internal compiler error: in bundling, at
config/ia64/ia64.c:8842
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

ChangeLog:


2011-04-01  Bernd Schmidt  

* dwarf2out.h (dwarf2out_frame_debug_init): Declare.
* dwarf2out.c (dwarf2out_frame_debug_init): New function, broken
out of ...
(dwarf2out_frame_debug): ... here. Don't handle a NULL argument.
* final.c (final_start_function): Call the new function rather
than using a NULL argument for dwarf2out_frame_debug.

* ifcvt.c (cond_exec_process_insns): Disallow converting a block
that contains the prologue.

* haifa-sched.c (queue_insn): New arg REASON.  All callers
changed.  Print it in debugging output.

* sched-ebb.c (schedule_ebbs): Honor the BB_DISABLE_SCHEDULE flag.

* sched-ebb.c (begin_schedule_ready): Remove second argument.
Split most of the code into...
(begin_move_insn): ... here.  New function.
(ebb_sched_info): Add a pointer to it.
* haifa-sched.c (scheduled_insns): New static variable.
(sched_extend_ready_list): Allocate it.
(schedule_block): Use it to record the order of scheduled insns.
Perform RTL changes to move insns only after all scheduling
decisions have been made.
* modulo-sched.c (sms_sched_haifa_sched_info): Add NULL entry for the
begin_move_insn field.
* sel-sched-ir.c (sched_sel_haifa_sched_info): Likewise.
* sched-int.h (struct haifa_sched_info): Remove second argument
from begin_schedule_ready hook.  Add new member begin_move_insn.
* sched-rgn.c (begin_schedule_ready): Remove second argument.
(rgn_const_sched_info): Add NULL entry for the begin_move_insn field.

* haifa-sched.c (prune_ready_list): New function, broken out of
schedule_block.
(schedule_block): Use it.

[Bug middle-end/48585] [4.7 Regression] 483.xalancbmk in SPEC CPU 2006 failed to build

[jamborm at gcc dot gnu.org]

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

--- Comment #6 from Martin Jambor  2011-04-15 
17:48:01 UTC ---
Unfortunately it seems that cgraph_create_virtual_clone already does
that... so either this information is not actually used to create the
node in the LTRANS stage or it gets lost along the way.

[Bug rtl-optimization/48628] ICE in reload

[belagod at gcc dot gnu.org]

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

--- Comment #1 from belagod at gcc dot gnu.org 2011-04-15 17:40:38 UTC ---
Created attachment 24002
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24002
test case with complex expressions

[Bug c/48623] gcc 4.6.0 generates no code for a function with __attribute__((always_inline))

[richard at nod dot at]

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

--- Comment #6 from Richard Weinberger  2011-04-15 
17:38:55 UTC ---
Created attachment 24001
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24001
objdump of __local_bh_enable

[Bug rtl-optimization/48628] New: ICE in reload

[belagod at gcc dot gnu.org]

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

   Summary: ICE in reload
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bela...@gcc.gnu.org


The attached test causes gcc to ICE when compiled with -O0.

$ arm-eabi-gcc -c foo.c 
foo.c: In function 'f0a':
foo.c:16:1: warning: left shift count >= width of type [enabled by default]
foo.c:16:1: warning: left shift count >= width of type [enabled by default]
foo.c:16:1: warning: right shift count >= width of type [enabled by default]
foo.c:16:1: warning: right shift count >= width of type [enabled by default]
foo.c:16:1: warning: right shift count >= width of type [enabled by default]
foo.c:16:1: warning: left shift count >= width of type [enabled by default]
foo.c:16:1: warning: left shift count >= width of type [enabled by default]
foo.c:16:1: warning: right shift count >= width of type [enabled by default]
foo.c:16:1: warning: right shift count >= width of type [enabled by default]
foo.c:16:1: warning: right shift count >= width of type [enabled by default]
foo.c:18:1: internal compiler error: in elimination_costs_in_insn, at
reload1.c:3643
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug c/48623] gcc 4.6.0 generates no code for a function with __attribute__((always_inline))

[richard at nod dot at]

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

Richard Weinberger  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |

--- Comment #5 from Richard Weinberger  2011-04-15 
17:37:23 UTC ---
(In reply to comment #3)

It's not that easy.
Your trick solves the problem only for the test case.

Within the kernel again no code has been produced.
I have the objdump of the __local_bh_enable function attached.
See line 86.

Sorry for not providing a standalone test.

Here you can see the source code of __local_bh_enable, it's a pretty simple
function.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=kernel/softirq.c;h=174f976c2874a19f1d06fee972468e2c730bc7f9;hb=HEAD#l134

Thanks,
//richard

[Bug c/48623] gcc 4.6.0 generates no code for a function with __attribute__((always_inline))

[richard at nod dot at]

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

--- Comment #4 from Richard Weinberger  2011-04-15 
17:34:33 UTC ---
Created attachment 24000
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24000
objdump of __local_bh_enable

[Bug ada/48621] Can't install gcc because Ada doctool installation process uses wrong gcc, thus producing incompatible ALI file

[bauhaus at futureapps dot de]

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

--- Comment #4 from Georg Bauhaus  2011-04-15 
16:55:15 UTC ---
(In reply to comment #3)

> > I have started again using a absolute path to configure, as you have 
> > suggested.
> 
> Thanks, let's see whether this changes something.

Findings so far:

I omitted $ make check this time and everything, including the
gcc  driver program, was properly installed into /usr/local/bin .

GNAT Lib v4.4 is still on line 1 of  gcc/ada/doctools/xgnatugn.ali
but there is no sign of a problem with it.

A possible cause for the issue might have been here:
I have run $ make check now, and apparently it
hit a memory limit and tore the machine down
(up to "no processes to kill").

Since I had run $ make check before I had tried # make install
during the previous attempt, the missing "gcc" executable might
simply have been a lost when at some point the file system
needed fixing. Or some other unknown. My bad.

Setting ulimits for $ make check accordingly looks promising.
If everything runs well, I will be happy, and silent.

[Bug libobjc/48627] New: libobjc_gc should be tested

[ro at gcc dot gnu.org]

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

   Summary: libobjc_gc should be tested
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libobjc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: nic...@gcc.gnu.org, pins...@gcc.gnu.org


I noticed that even when you enable libobjc_gc with --enable-objc-gc, the
library
isn't tested anywhere.  This is bad.

[Bug libobjc/32037] --enable-objc-gc on OS X won't build

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2011-04/msg01221.htm
   ||l
 CC||ro at gcc dot gnu.org
 Resolution||FIXED
 AssignedTo|pinskia at gcc dot gnu.org  |ro at gcc dot gnu.org
   Target Milestone|--- |4.7.0

--- Comment #4 from Rainer Orth  2011-04-15 16:57:21 UTC 
---
Fixed for 4.7.0.

[Bug fortran/48426] [patch] Quad precision promotion

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #12 from Steve Kargl  
2011-04-15 16:59:41 UTC ---
On Fri, Apr 15, 2011 at 04:41:06PM +, jvdelisle at gcc dot gnu.org wrote:
> Steve, I can clean this up but i am not clear on copyright assignment.  Any
> issues on this?

The patch touches several files and more than a few lines,
so I think it may exceed the threshold of a patch without
copyright assignment.  We should probably check with  
Andreas Kloeckner if he has an assignment on file. 

Note, the manual changes to add a warning is needed because
these options effective storage association, which has an impact
on EQUIVALENCE and COMMON and perhaps others.

[Bug tree-optimization/48616] -ftree-vectorize -mxop miscompiles right shift

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  2011-04-15 
16:49:36 UTC ---
extern void abort (void);
int a[4] __attribute__((aligned (32)));
int b[4] __attribute__((aligned (32)));
int c[4] __attribute__((aligned (32)));
int d[4] __attribute__((aligned (32)));
int e[4] __attribute__((aligned (32)));

__attribute__((noinline, noclone))
void
foo (int i)
{
  a[0] = b[0] << c[0];
  a[1] = b[1] << c[1];
  a[2] = b[2] << c[2];
  a[3] = b[3] << c[3];
  if (i)
{
  d[0] = e[0] >> c[0];
  d[1] = e[1] >> c[1];
  d[2] = e[2] >> c[2];
  d[3] = e[3] >> c[3];
}
}

int
main ()
{
  int i;
  int *t;
  for (i = 0; i < 4; i++)
{
  b[i] = 32;
  c[i] = i;
  e[i] = 32;
}
  asm volatile ("" : : "r" (b) : "memory");
  asm volatile ("" : : "r" (c) : "memory");
  asm volatile ("" : "=r" (t) : "0" (d) : "memory");
  foo (t != 0);
  for (i = 0; i < 4; i++)
if (a[i] != (32 << i) || d[i] != (32 >> i))
  abort ();
  return 0;
}

is reduced testcase for -O2 -ftree-vectorize -mxop.  I might try to fix this on
Monday, unless Ira beats me to do it.

[Bug libobjc/48626] New: --enable-objc-gc should be automatic

[ro at gcc dot gnu.org]

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

   Summary: --enable-objc-gc should be automatic
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libobjc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: nic...@gcc.gnu.org, pins...@gcc.gnu.org


Currently, --enable-objc-gc, which isn't documented in install.texi, is
required
to enable building libobjc_gc.la.  This could (and should) be automatic: either
automatically build boehm-gc if libobjc is enabled or only build libobjc_gc if
boehm-gc is already built.

The fewer necessary configure options, the better.

[Bug libfortran/48589] Invalid G0/G0.d editing for NaN/infinity

[jvdelisle at gcc dot gnu.org]

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

--- Comment #5 from Jerry DeLisle  2011-04-15 
16:42:13 UTC ---
Fixed on trunk.  Shall we backport to 4.6.1?

[Bug fortran/48426] [patch] Quad precision promotion

[jvdelisle at gcc dot gnu.org]

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

--- Comment #11 from Jerry DeLisle  2011-04-15 
16:40:58 UTC ---
Steve, I can clean this up but i am not clear on copyright assignment.  Any
issues on this?

[Bug libfortran/48589] Invalid G0/G0.d editing for NaN/infinity

[jvdelisle at gcc dot gnu.org]

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

--- Comment #4 from Jerry DeLisle  2011-04-15 
16:33:14 UTC ---
Author: jvdelisle
Date: Fri Apr 15 16:33:07 2011
New Revision: 172503

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172503
Log:
2011-04-15  Jerry DeLisle  

PR libgfortran/48589
* gfortran.dg/fmt_g0_5.f08: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/fmt_g0_5.f08
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug libfortran/48589] Invalid G0/G0.d editing for NaN/infinity

[jvdelisle at gcc dot gnu.org]

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

--- Comment #3 from Jerry DeLisle  2011-04-15 
16:29:50 UTC ---
Author: jvdelisle
Date: Fri Apr 15 16:29:44 2011
New Revision: 172502

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172502
Log:
2011-04-15  Jerry DeLisle  

PR libgfortran/48589
* io/write_float.def (write_infnan): Set width properly for G0.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/write_float.def

[Bug target/40171] GCC does not pass -mtune and -march options to assembler!

[mahatma at eu dot by]

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

Dzianis Kahanovich  changed:

   What|Removed |Added

  Attachment #22444|0   |1
is obsolete||

--- Comment #8 from Dzianis Kahanovich  2011-04-15 
16:30:58 UTC ---
Created attachment 23999
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23999
atune-4.6.patch

Cleanup (+ unused macros), reduce code (ASM_SPEC_MTUNE moved to i386.h), adopt
to 4.6.

[Bug tree-optimization/48625] New: Segfault in libitm when compiling with -O2

[martin at gcc dot gnu.org]

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

   Summary: Segfault in libitm when compiling with -O2
   Product: gcc
   Version: trans-mem
Status: UNCONFIRMED
  Keywords: trans-mem
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mar...@gcc.gnu.org
  Host: x86_64 GNU/Linux
Target: x86_64 GNU/Linux
 Build: transactional-memory branch Revision 172498


Created attachment 23998
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23998
Reduced Kmeans benchmarks from the STAMP suite that segfaults in libitm

The kmeans benchmark from the STAMP TM suite segfaults at run time when
compiled with -O2. 

I attached a reduced version of the kmeans program (one file containing all
functions plus header and input files - it is still quite large). 

Compiling the file works fine:

martin:~/GCC_STAMP/stamp-0.9.10/kmeans_red$
~/GCC_TM_BRANCH/gcc_install/bin/gcc-tm -I../include
-I~/GCC_TM_BRANCH/transactional-memory/libitm -g -O2 -Wall -fgnu-tm -o
kmeans_all kmeans_all.c -lpthread -litm -lm
kmeans_all.c: In function 'main':
kmeans_all.c:162:13: warning: variable 'len' set but not used

At run time it crashes with a segfault in the libitm. The crash is related to
the barrier optimization (using ReadforWrite barriers). When compiled with -O1
instead of -O2 the program runs fine. 
Please see the gdb's backtrace of the segfault:

martin:~/GCC_STAMP/stamp-0.9.10/kmeans_red$ gdb --args ./kmeans_all -m15 -n15
-i inputs/random-n2048-d16-c16.txt -p 4
GNU gdb (GDB) 7.1-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from ~/GCC_STAMP/stamp-0.9.10/kmeans_red/kmeans_all...done.
(gdb) run
Starting program: ~/GCC_STAMP/stamp-0.9.10/kmeans_red/kmeans_all -m15 -n15 -i
inputs/random-n2048-d16-c16.txt -p 4
[Thread debugging using libthread_db enabled]
[New Thread 0x7698a700 (LWP 27681)]
[New Thread 0x76189700 (LWP 27682)]
[New Thread 0x75988700 (LWP 27683)]

Program received signal SIGSEGV, Segmentation fault.
do_write_lock (this=0x64f730, addr=) at
../../../transactional-memory/libitm/method-wbetl.cc:265
265   *line = *addr;
(gdb) backtrace
#0  do_write_lock (this=0x64f730, addr=) at
../../../transactional-memory/libitm/method-wbetl.cc:265
#1  0x771b64a9 in do_read (ptr=0x81,
lock=GTM::gtm_dispatch::RfW) at
../../../transactional-memory/libitm/barrier.tpl:47
#2  0x00401e0f in work (argPtr=) at
kmeans_all.c:559
#3  0x00401c75 in threadWait (argPtr=) at
kmeans_all.c:948
#4  0x00401cd5 in thread_start (funcPtr=,
argPtr=) at kmeans_all.c:1020
#5  0x00402443 in normal_exec (nthreads=4, feature=0x625260,
nfeatures=16, npoints=2048, nclusters=15, threshold=0.0010005,
membership=, 
randomPtr=0x64d770) at kmeans_all.c:684
#6  0x004026a1 in cluster_exec (nthreads=4, numObjects=2048,
numAttributes=16, attributes=0x625260, use_zscore_transform=, min_nclusters=15, 
max_nclusters=15, threshold=0.0010005, best_nclusters=0x7fffddec,
cluster_centres=0x7fffddd8, cluster_assign=0x649750) at kmeans_all.c:1404
#7  0x00402c5e in main (argc=6312528, argv=) at
kmeans_all.c:299

Any help is appreciated :-)

[Bug fortran/48624] New: gfrtran DECL issues in function declaration

[burnus at gcc dot gnu.org]

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

   Summary: gfrtran DECL issues in function declaration
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org


Split off from 48286. Richard writes there:

Btw, fndecl issue - if you build at least cray_pointers_8.f90 with
-fwhole-program
I get

/tmp/ccBnfOGf.o: In function `main':
cray_pointers_8.f90:(.text.startup+0x76): undefined reference to `euler_'
collect2: ld returned 1 exit status

which means the euler fn has a different decl than the one called from main.


I can reproduce this with:
  gfortran -fcray-pointer -O2 -fwhole-program cray_pointers_8.f90

[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 #35 from Tobias Burnus  2011-04-15 
16:13:35 UTC ---
Author: burnus
Date: Fri Apr 15 16:13:28 2011
New Revision: 172499

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172499
Log:
2011-04-15  Tobias Burnus  

PR fortran/18918
* Makefile.am: Build and install caf/single.c as
libcaf_single.a.
* Makefile.in: Regenerate.


Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/Makefile.am
trunk/libgfortran/Makefile.in

[Bug fortran/48426] [patch] Quad precision promotion

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #10 from Steve Kargl  
2011-04-15 16:02:17 UTC ---
On Fri, Apr 15, 2011 at 03:29:36PM +, jvdelisle at gcc dot gnu.org wrote:
> 
> I have looked over the patch.  I need to do some tests and I have about three
> bugs in front of this one so please give me a few days.
> 

I skimmed the patch.  It is still wrong.

These parts should not be needed:

+if (!saw_r8)
+  fatal_error ("real kind=8 not available for -freal-4-real-8 option");

+if (!saw_r4)
+  fatal_error ("real kind=4 not available for -freal-8-real-4 option");

gfortran always has real(4) and real(8) on all important targets.

I also think that the description is the manual is lacking.  For example,

+freal-4-real-8
+Fortran RejectNegative
+Interpret any 4-byte real as an 8-byte real

I think the word 'any' is incorrect.

There also should be a warning here.  "Warning: This option is provided
for debugging purposes, and may give unexpected results for general
use."

[Bug ada/48621] Can't install gcc because Ada doctool installation process uses wrong gcc, thus producing incompatible ALI file

[ebotcazou at gcc dot gnu.org]

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

--- Comment #3 from Eric Botcazou  2011-04-15 
16:02:34 UTC ---
> I did first run
> 
> $ make boostrap
> 
> which I should have stated less implicitly, sorry.

Just run "make", this is how it is tested nowadays.

> I have started again using a absolute path to configure, as you have 
> suggested.

Thanks, let's see whether this changes something.

[Bug tree-optimization/48616] -ftree-vectorize -mxop miscompiles right shift

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  2011-04-15 
16:00:43 UTC ---
Created attachment 23997
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23997
pr48616.ii.bz2

Preprocessed, for -O2 -ftree-vectorize -mxop -m64.

The bug is during the second vect_schedule_slp call on that testcase, or
perhaps in its analysis.  The first vect_schedule_slp call is on a bb that
reads from
shift and is vectorized correctly.  The problem on the second bb is that all
the
4 rhs2s of the shifts don't have the definition in the current bb (thus
vect_is_simple_use does:
  if ((loop && !flow_bb_inside_loop_p (loop, bb))
  || (!loop && bb != BB_VINFO_BB (bb_vinfo))
  || (!loop && gimple_code (*def_stmt) == GIMPLE_PHI))
*dt = vect_external_def;
and vectorizable_shift assumes that vect_external_def means vector shift by
scalar and nothing during the analysis checks that if it assumes it is a shift
by scalar, the shift count must be actually the same between all the to be slp
replaced stmts.
In this case if it remembered the vector_var_ from the defining BB it could
very well just use it as the rhs2 operand of the vector shift, but that assumes
the bb in which it is defined has been slp vectorized already.

[Bug middle-end/48601] [4.7 Regression] ICE in lower_emutls_function_body, at tree-emutls.c:623

[jojelino at gmail dot com]

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

--- Comment #6 from gee  2011-04-15 15:40:56 UTC ---
(In reply to comment #5)
> Created attachment 23996 [details]
> Proposed fix
> 
> I don't have (easy) access to a platform exhibiting this bug but this
> patch should rather obviously fix it.  It would be nice if someone
> with an affected platform could test it but I guess I'm going to
> bootstrap it on x86_64-linux and submit it now anyway.
fixed

[Bug fortran/48426] [patch] Quad precision promotion

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.04.15 15:27:59
 CC||jvdelisle at gcc dot
   ||gnu.org
 AssignedTo|unassigned at gcc dot   |jvdelisle at gcc dot
   |gnu.org |gnu.org
 Ever Confirmed|0   |1

--- Comment #9 from Jerry DeLisle  2011-04-15 
15:27:59 UTC ---
I have looked over the patch.  I need to do some tests and I have about three
bugs in front of this one so please give me a few days.

[Bug tree-optimization/48622] [4.7 Regression] ICE: in estimate_size_after_inlining, at ipa-inline-analysis.c:425 with -flto -finline-small-functions -fno-early-inlining

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug fortran/48426] [patch] Quad precision promotion

[inform at tiker dot net]

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

--- Comment #8 from Andreas Kloeckner  2011-04-15 
14:53:52 UTC ---
Ping?

[Bug libstdc++/48476] [C++0x] conversion between std::tuple which have reference member is rejected

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.6.1

--- Comment #12 from Paolo Carlini  2011-04-15 
14:54:10 UTC ---
Done.

[Bug libstdc++/48476] [C++0x] conversion between std::tuple which have reference member is rejected

[paolo at gcc dot gnu.org]

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

--- Comment #11 from paolo at gcc dot gnu.org  
2011-04-15 14:53:02 UTC ---
Author: paolo
Date: Fri Apr 15 14:52:57 2011
New Revision: 172498

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172498
Log:
2011-04-15  Takaya Saito  

PR libstdc++/48476
* include/std/tuple (_Tuple_impl<>::_Tuple_impl(_Tuple_impl<>&&),
_Tuple_impl<>::operator=(_Tuple_impl&&), _Tuple_impl<>::operator=
(_Tuple_impl<>&&), tuple_cat): Use std::forward where appropriate.
* testsuite/20_util/tuple/cons/48476.cc: New.
* testsuite/20_util/tuple/48476.cc: Likewise.
* testsuite/20_util/tuple/creation_functions/48476.cc: Likewise.

Added:
branches/gcc-4_6-branch/libstdc++-v3/testsuite/20_util/tuple/48476.cc
branches/gcc-4_6-branch/libstdc++-v3/testsuite/20_util/tuple/cons/48476.cc
   
branches/gcc-4_6-branch/libstdc++-v3/testsuite/20_util/tuple/creation_functions/48476.cc
Modified:
branches/gcc-4_6-branch/libstdc++-v3/ChangeLog
branches/gcc-4_6-branch/libstdc++-v3/include/std/tuple

[Bug c/48623] gcc 4.6.0 generates no code for a function with __attribute__((always_inline))

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2011-04-15 
14:52:04 UTC ---
Instead using

static inline struct thread_info *current_thread_info(void)
{
  struct thread_info *ti;
  void *p;
  asm volatile ("" : "=r" (p) : "0" (&ti));
  ti = (struct thread_info *) (((unsigned long) p) & ~mask);
  return ti;
}

might confuse GCC enough and is still architecture independent.

[Bug c/48623] gcc 4.6.0 generates no code for a function with __attribute__((always_inline))

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #2 from Richard Guenther  2011-04-15 
14:46:32 UTC ---
Because current_thread_info() returns garbage (an address derived from an
address of a stack local).

[Bug middle-end/48601] [4.7 Regression] ICE in lower_emutls_function_body, at tree-emutls.c:623

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |jamborm at gcc dot gnu.org
   |gnu.org |

--- Comment #5 from Martin Jambor  2011-04-15 
14:22:09 UTC ---
Created attachment 23996
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23996
Proposed fix

I don't have (easy) access to a platform exhibiting this bug but this
patch should rather obviously fix it.  It would be nice if someone
with an affected platform could test it but I guess I'm going to
bootstrap it on x86_64-linux and submit it now anyway.

[Bug c/48623] New: gcc 4.6.0 generates no code for a function with __attribute__((always_inline))

[richard at nod dot at]

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

   Summary: gcc 4.6.0 generates no code for a function with
__attribute__((always_inline))
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rich...@nod.at


gcc 4.6.0 builds a non-functional User Mode Linux kernel.
It seems to optimize away the function sub_preempt_count() used in
kernel/softirq.c:__local_bh_enable().
Thus, the preempt counter gets out of balance and the kernel crashes.

A standalone test case is attached.
Just compile it with:
gcc testcase.c -Os -g -c -o testcase.o

Using objdump you can see that no code was generated for sub_preempt_count().
gcc 4.3, 4.4 and 4.5 generate code.
Without __attribute__((always_inline)) 4.6.0 produces code...

Thanks,
//richard

[Bug ada/48621] Can't install gcc because Ada doctool installation process uses wrong gcc, thus producing incompatible ALI file

[bauhaus at futureapps dot de]

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

--- Comment #2 from Georg Bauhaus  2011-04-15 
14:16:38 UTC ---
I did first run

$ make boostrap

which I should have stated less implicitly, sorry.
And then, as the report says,

$ make check # with -k, actually. ACATS results were good

and only then

# make install

(I also noticed that I'm not the first to run into
the issue, according to Google search results for
gnatmake error:
gnatmake: "xgnatugn.ali" incompatible ALI file, please recompile.
First thing that turns up is msg26991 on the GCC help list.)

The part with the incorrect ALI file was easily
reproduced in isolation:

- After the failed install, the output of $(which gnatmake) was
/usr/local/bin/gnatmake

- There was no /usr/local/bin/gcc yet (because the
install had stopped at the above issue).

- I changed dicteory to the one with xgnatugn.* in it.
Removed the ALI file and ran
$ gnatmake xgnatugn  # this would be the new /usr/local/bin/gnatmake
to get
gnatmake: "xgnatugn.ali" incompatible ALI file, please recompile
gnatmake: "xgnatugn.adb" compilation error

This is one reason why I was guessing that
gnatmake would invoke /usr/bin/gcc, not
any of the newly created gccs, because these
had not yet been installed successfully.
The new gnatmake would invoke the gcc that
is finds in the path, which is not among any of the
new gccs.

I have started again using a absolute path to configure,
as you have suggested.
After removing everything from the /usr/local hierarchy,
and $ hash -r.

$ ls -l /opt/src/MAINTAINERS 
-rw-r--r-- 1 bauhaus bauhaus 21058 Apr 11 19:52 /opt/src/MAINTAINERS

$ pwd
/opt/build
$ ls -a
.  ..
$ which gcc
/usr/bin/gcc
$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

$ gcc -v  # compiler to be used for make bootstrap
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-8'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.4 --enable-shared --enable-multiarch
--enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--enable-targets=all --with-arch-32=i586 --with-tune=generic
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.4.5 (Debian 4.4.5-8) 

$ /opt/src/configure --enable-languages=c,ada --disable-nls
...
$
 I'll report what happens.

[Bug c/48623] gcc 4.6.0 generates no code for a function with __attribute__((always_inline))

[richard at nod dot at]

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

--- Comment #1 from Richard Weinberger  2011-04-15 
14:16:22 UTC ---
Created attachment 23995
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23995
Testcase for gcc 4.6.0

[Bug tree-optimization/48290] FAIL: gcc.dg/vect/pr38529.c, ICE in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1072

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Guenther  2011-04-15 
14:02:50 UTC ---
Author: rguenth
Date: Fri Apr 15 14:02:41 2011
New Revision: 172494

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172494
Log:
2011-04-15  Richard Guenther  

PR tree-optimization/48290
* tree-ssa-copy.c (copy_prop_visit_phi_node): Propagate constants.
Properly decide inhibiting propagation based on the valueized
operand.  Do loop-closed SSA form preserving here ...
(init_copy_prop): ... not here.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-copy.c

[Bug fortran/48286] gfortran.dg/cray_pointers_8.f90 FAILs

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2011-04-15 
14:06:51 UTC ---
Author: rguenth
Date: Fri Apr 15 14:06:44 2011
New Revision: 172495

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172495
Log:
2011-04-15  Richard Guenther  

PR testsuite/48286
* gfortran.dg/cray_pointers_8.f90: Use -ffloat-store.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/cray_pointers_8.f90

[Bug tree-optimization/48290] FAIL: gcc.dg/vect/pr38529.c, ICE in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1072

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #10 from Richard Guenther  2011-04-15 
14:03:26 UTC ---
And fixed.

[Bug fortran/48286] gfortran.dg/cray_pointers_8.f90 FAILs

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #4 from Richard Guenther  2011-04-15 
14:08:58 UTC ---
Fixed.

[Bug tree-optimization/48616] -ftree-vectorize -mxop miscompiles right shift

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  2011-04-15 
13:39:08 UTC ---
I should mention it is the only vpsrad insn in the testcase.

In *.cunroll we have:

  [pr48616.C : 113:76] D.52396_86 = MEM[(const AliasingEntryType *
{ref-all})&shifts];
...
  [pr48616.C : 113:76] D.52395_89 = MEM[(const AliasingEntryType *
{ref-all})&shifts + 4B];
...
  [pr48616.C : 113:76] D.52394_92 = MEM[(const AliasingEntryType *
{ref-all})&shifts + 8B];
...
  [pr48616.C : 113:76] D.52393_95 = MEM[(const AliasingEntryType *
{ref-all})&shifts + 12B];
...

:
  [pr48616.C : 1721:5] [pr48616.C : 1721] [pr48616.C : 1721] MEM[(struct Vector
*)&a].data = { 68719476752, 68719476752 };
  [pr48616.C : 1288:172] D.52507_129 = MEM[(AliasingEntryType & {ref-all})&a];
  [pr48616.C : 1288:172] D.52506_131 = D.52507_129 >> D.52396_86;
  [pr48616.C : 1288:172] MEM[(AliasingEntryType & {ref-all})&a] = D.52506_131;
  [pr48616.C : 1288:258] D.52504_132 = MEM[(AliasingEntryType & {ref-all})&a +
4];
  [pr48616.C : 1288:258] D.52503_134 = D.52504_132 >> D.52395_89;
  [pr48616.C : 1288:258] MEM[(AliasingEntryType & {ref-all})&a + 4] =
D.52503_134;
  [pr48616.C : 1288:344] D.52501_135 = MEM[(AliasingEntryType & {ref-all})&a +
8];
  [pr48616.C : 1288:344] D.52500_137 = D.52501_135 >> D.52394_92;
  [pr48616.C : 1288:344] MEM[(AliasingEntryType & {ref-all})&a + 8] =
D.52500_137;
  [pr48616.C : 1288:430] D.52498_138 = MEM[(AliasingEntryType & {ref-all})&a +
12];
  [pr48616.C : 1288:430] D.52497_140 = D.52498_138 >> D.52393_95;
  [pr48616.C : 1288:430] MEM[(AliasingEntryType & {ref-all})&a + 12] =
D.52497_140;

*.slp has:
:
  [pr48616.C : 1721:5] # .MEMD.52319_50 = VDEF <.MEMD.52319_1126>
  [pr48616.C : 1721] [pr48616.C : 1721] MEM[(struct VectorD.34523
*)&aD.38703].dataD.34590 = { 68719476752, 68719476752 };
  # PT = anything 
  # ALIGN = 16, MISALIGN = 0
  vect_p.1912D.63297_1085 = &MEM[(AliasingEntryTypeD.34571 &
{ref-all})&aD.38703];
  [pr48616.C : 1288:172] # VUSE <.MEMD.52319_50>
  vect_var_.1913D.63298_534 = MEM[(AliasingEntryTypeD.34571 &
{ref-all})vect_p.1912D.63297_1085];
  [pr48616.C : 1288:172] # VUSE <.MEMD.52319_50>
  D.52507_129 = MEM[(AliasingEntryTypeD.34571 & {ref-all})&aD.38703];
  [pr48616.C : 1288:172] vect_var_.1914D.63299_575 = vect_var_.1913D.63298_534
>> D.52396_86;
  [pr48616.C : 1288:172] D.52506_131 = D.52507_129 >> D.52396_86;
  # PT = anything 
  # ALIGN = 16, MISALIGN = 0
  vect_p.1918D.63303_576 = &MEM[(AliasingEntryTypeD.34571 &
{ref-all})&aD.38703];
  [pr48616.C : 1288:258] # VUSE <.MEMD.52319_50>
  D.52504_132 = MEM[(AliasingEntryTypeD.34571 & {ref-all})&aD.38703 + 4];
  [pr48616.C : 1288:258] D.52503_134 = D.52504_132 >> D.52395_89;
  [pr48616.C : 1288:344] # VUSE <.MEMD.52319_50>
  D.52501_135 = MEM[(AliasingEntryTypeD.34571 & {ref-all})&aD.38703 + 8];
  [pr48616.C : 1288:344] D.52500_137 = D.52501_135 >> D.52394_92;
  [pr48616.C : 1288:430] # VUSE <.MEMD.52319_50>
  D.52498_138 = MEM[(AliasingEntryTypeD.34571 & {ref-all})&aD.38703 + 12];
  [pr48616.C : 1288:430] D.52497_140 = D.52498_138 >> D.52393_95; 
  [pr48616.C : 1288:430] # .MEMD.52319_580 = VDEF <.MEMD.52319_50>
  MEM[(AliasingEntryTypeD.34571 & {ref-all})vect_p.1918D.63303_576] =
vect_var_.1914D.63299_575;

[Bug tree-optimization/48622] New: [4.7 Regression] ICE: in estimate_size_after_inlining, at ipa-inline-analysis.c:425 with -flto -finline-small-functions -fno-early-inlining

[zsojka at seznam dot cz]

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

   Summary: [4.7 Regression] ICE: in estimate_size_after_inlining,
at ipa-inline-analysis.c:425 with -flto
-finline-small-functions -fno-early-inlining
   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 23994
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23994
auto-reduced testcase (from gcc.c-torture/execute/20020108-1.c)

Compiler output:
$ gcc -O -flto -finline-small-functions -fno-early-inlining testcase.c
lto1: internal compiler error: in estimate_size_after_inlining, at
ipa-inline-analysis.c:425
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: /mnt/svn/gcc-trunk/binary-latest/bin/gcc returned 1 exit status
collect2: lto-wrapper returned 1 exit status

Tested revisions:
r172480 - crash
4.6 r172337 - OK

[Bug ada/48621] Can't install gcc because Ada doctool installation process uses wrong gcc, thus producing incompatible ALI file

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME

--- Comment #1 from Eric Botcazou  2011-04-15 
13:34:09 UTC ---
Probably something on your side, I've never seen this.

> When running
> # make install
> after running
> $ make check (successfully),

Run "make" before "make install".

> After installation as per the workaround above,
> 
> $  /usr/local/bin/gcc -v
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i686-pc-linux-gnu/4.7.0/lto-wrapper
> Target: i686-pc-linux-gnu
> Configured with: ../src/configure --enable-languages=c,ada --disable-nls
> Thread model: posix
> gcc version 4.7.0 20110411 (experimental) (GCC)

We recommend using an absolute path to configure.

[Bug tree-optimization/48616] -ftree-vectorize -mxop miscompiles right shift

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  2011-04-15 
13:07:56 UTC ---
The shift corresponding to
a = Vec(16);
a >>= shifts;
is actually there, but a wrong one, V4SImode = V4SImode >> SImode
rather than V4SImode = V4SImode >> V4SImode which needs to be done.  As the
first int in shifts is 0, this means %xmm0 containing {16,16,16,16} initially
is shifted down by {0,0,0,0} rather than {0,1,2,3}.

[Bug middle-end/48601] [4.7 Regression] ICE in lower_emutls_function_body, at tree-emutls.c:623

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.04.15 13:07:15
 CC||danglin at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #4 from John David Anglin  2011-04-15 
13:07:15 UTC ---
Also seen with hppa64-hp-hpux11.11.

[Bug middle-end/48584] [4.7 Regression] AVX testcase failures

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #3 from H.J. Lu  2011-04-15 12:54:48 
UTC ---
Fixed.

[Bug tree-optimization/48620] many libstdc++ tests FAIL with -m32 -fno-early-inlining -fipa-pta

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.04.15 12:52:48
 Depends on||47896
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-04-15 
12:52:48 UTC ---
I suspect this might be the same as PR47896, so don't spend too much time
here until that is fixed.

[Bug ada/48621] New: Can't install gcc because Ada doctool installation process uses wrong gcc, thus producing incompatible ALI file

[bauhaus at futureapps dot de]

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

   Summary: Can't install gcc because Ada doctool installation
process uses wrong gcc, thus producing incompatible
ALI file
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: ada
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bauh...@futureapps.de


When running
# make install
after running
$ make check (successfully),

the installation process stops, and importantly,
before having installed /usr/local/bin/gcc,
at:

make[3]: Entering directory `/opt/build/gcc'
mkdir -p ada/doctools
cp -p ../../src/gcc/ada/xgnatugn.adb ada/doctools
cd ada/doctools && gnatmake -q xgnatugn
gnatmake: "xgnatugn.ali" incompatible ALI file, please recompile
gnatmake: "xgnatugn.adb" compilation error

Indeed,
$ head -1 xgnatugn.ali 
will show GNAT Lib v4.4, not v4.6.

My guess is that the above step is effectively assuming that
a compatible (new) gcc is called, in effect the one /usr/bin---but
the new gcc isn't installed until the installation of gcc has succeeded
(into /usr/local). The gcc/xgcc does not seem to be used, either.
Catch 22.

A workaround seems to be to

# make -k install   # after which -e /usr/local/bin/gcc
# rm gcc/ada/doctools/xgnatugn.ali
# make install

Hints:

# make -n gcc/ada/doctools/xgnatugn
gcc   gcc/ada/doctools/xgnatugn.o   -o gcc/ada/doctools/xgnatugn

# CC=gcc/xgcc make -e -n gcc/ada/doctools/xgnatugn
gcc/xgcc   gcc/ada/doctools/xgnatugn.o   -o gcc/ada/doctools/xgnatugn

# cd gcc
# CC=./xgcc make -e -n ada/doctools/xgnatugn
mkdir -p ada/doctools
cp -p ../../src/gcc/ada/xgnatugn.adb ada/doctools
cd ada/doctools && gnatmake -q xgnatugn

I saw CC = cc ; COMPILER = $(CC) in ada/Makefile.
Is GNAT's make process such that is assumes a
compatible GNAT already installed when compiling
ada/doctools/xgnatugn?

After installation as per the workaround above,

$  /usr/local/bin/gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i686-pc-linux-gnu/4.7.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../src/configure --enable-languages=c,ada --disable-nls
Thread model: posix
gcc version 4.7.0 20110411 (experimental) (GCC)