[Bug driver/47549] New: -save-temps and -finput-charset= causing 'cc1.exe: error: failure to convert gbk to UTF-8'

[silver24k at gmail dot com]

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

   Summary: -save-temps and -finput-charset= causing 'cc1.exe:
error: failure to convert gbk to UTF-8'
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: silver...@gmail.com


Created attachment 23172
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23172
simple source in GBK encoding

The source is in GBK encoding. 
arm-gcc -finput-charset=gbk -c -save-temps gbk.c
cc1: error: failure to convert gbk to UTF-8

If no '-save-temps' used, everything is OK.

[Bug driver/47549] -save-temps and -finput-charset= causing 'cc1.exe: error: failure to convert gbk to UTF-8'

[silver24k at gmail dot com]

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

--- Comment #1 from Yu Simin  2011-01-31 08:07:27 
UTC ---
$ arm-gcc -v -finput-charset=gbk -c -save-temps gbk.c
Using built-in specs.
COLLECT_GCC=arm-gcc
COLLECT_LTO_WRAPPER=/home/starlight/src/gnu-toolchain/platform/cross-on-linux/mingw/bin/../libexec/gcc/arm/4.6.0/lto-wrapper
Target: arm
Configured with: ../../../gcc_trunk/configure --target=arm
--prefix=/platform/cross-on-linux/mingw --disable-threads --disable-tls
--disable-win32-registry --enable-version-specific-runtime-libs
--with-pkgversion='General ARM GCC' --enable-multilib --with-newlib
--with-headers=/home/starlight/src/gnu-toolchain/newlib/newlib/libc/include
--disable-nls --enable-languages=c,c++ --with-mpc=/usr/local
--with-ppl=/usr/local --with-cloog=/usr/local --with-libelf=/usr/local
--disable-plugin --disable-libstdcxx-pch --enable-cloog-backend=isl
--disable-cloog-version-check
Thread model: single
gcc version 4.6.0 20110129 (experimental) mingw-20090616 (General ARM GCC)
COLLECT_GCC_OPTIONS='-v' '-finput-charset=gbk' '-c' '-save-temps'

/home/starlight/src/gnu-toolchain/platform/cross-on-linux/mingw/bin/../libexec/gcc/arm/4.6.0/cc1
-E -quiet -v -iprefix
/home/starlight/src/gnu-toolchain/platform/cross-on-linux/mingw/bin/../lib/gcc/arm/4.6.0/
-D__USES_INITFINI__ gbk.c -finput-charset=gbk -fpch-preprocess -o gbk.i
ignoring duplicate directory
"/home/starlight/src/gnu-toolchain/platform/cross-on-linux/mingw/bin/../lib/gcc/../../lib/gcc/arm/4.6.0/include"
ignoring duplicate directory
"/home/starlight/src/gnu-toolchain/platform/cross-on-linux/mingw/bin/../lib/gcc/../../lib/gcc/arm/4.6.0/include-fixed"
ignoring duplicate directory
"/home/starlight/src/gnu-toolchain/platform/cross-on-linux/mingw/bin/../lib/gcc/../../lib/gcc/arm/4.6.0/../../../../arm/sys-include"
ignoring duplicate directory
"/home/starlight/src/gnu-toolchain/platform/cross-on-linux/mingw/bin/../lib/gcc/../../lib/gcc/arm/4.6.0/../../../../arm/include"
#include "..." search starts here:
#include <...> search starts here:

/home/starlight/src/gnu-toolchain/platform/cross-on-linux/mingw/bin/../lib/gcc/arm/4.6.0/include

/home/starlight/src/gnu-toolchain/platform/cross-on-linux/mingw/bin/../lib/gcc/arm/4.6.0/include-fixed

/home/starlight/src/gnu-toolchain/platform/cross-on-linux/mingw/bin/../lib/gcc/arm/4.6.0/../../../../arm/sys-include

/home/starlight/src/gnu-toolchain/platform/cross-on-linux/mingw/bin/../lib/gcc/arm/4.6.0/../../../../arm/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-finput-charset=gbk' '-c' '-save-temps'

/home/starlight/src/gnu-toolchain/platform/cross-on-linux/mingw/bin/../libexec/gcc/arm/4.6.0/cc1
-fpreprocessed gbk.i -quiet -dumpbase gbk.c -auxbase gbk -version
-finput-charset=gbk -o gbk.s
GNU C (General ARM GCC) version 4.6.0 20110129 (experimental) mingw-20090616
(arm)
compiled by GNU C version 4.4.3, GMP version 5.0.1, MPFR version
3.0.0-p3, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
cc1: error: failure to convert gbk to UTF-8
GNU C (General ARM GCC) version 4.6.0 20110129 (experimental) mingw-20090616
(arm)
compiled by GNU C version 4.4.3, GMP version 5.0.1, MPFR version
3.0.0-p3, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

[Bug c++/47416] [4.6 Regression] ICE in build_data_member_initialization, at cp/semantics.c:5509

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  2011-01-31 
08:20:29 UTC ---
Created attachment 23173
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23173
pr47416.ii

Somewhat reduced testcase which preserves the property that after diagnosing
one error it ICEs in build_data_member_initialization.

[Bug fortran/47550] New: PURE with VALUE and w/o INTENT: add gfc_notify_std (GFC_STD_F2008 ?

[burnus at gcc dot gnu.org]

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

   Summary: PURE with VALUE and w/o INTENT: add gfc_notify_std
(GFC_STD_F2008 ?
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org


PURE procedures with VALUE and without INTENT are allowed since Fortran 2008

The support has been added via
http://gcc.gnu.org/ml/fortran/2011-01/msg00277.html

Should there be a gfc_notify_std with Error: "Fortran 2008: "?

Cf. http://j3-fortran.org/doc/year/11/11-139.txt

[Bug bootstrap/47279] Bootstrap fails in stage1 with GCC 4.6

[amodra at gmail dot com]

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

--- Comment #10 from Alan Modra  2011-01-31 08:47:16 
UTC ---
With enough fiddling around, I finally duplicated the error, in my case when
linking lto1.

libbackend.a(cse.o): In function `insert_const_anchors':
/src/gcc-current/gcc/cse.c:1293: sibling call optimization to `.opd' does not
allow automatic multiple TOCs; recompile with -mminimal-toc or
-fno-optimize-sibling-calls, or make `.opd' extern
/src/gcc-current/gcc/cse.c:1296: sibling call optimization to `.opd' does not
allow automatic multiple TOCs; recompile with -mminimal-toc or
-fno-optimize-sibling-calls, or make `.opd' extern
/home/alan/build/ppc/bin/ld/ld-new: final link failed: Bad value

It is a GNU ld bug.

[Bug java/47456] internal compiler error: Segmentation fault while using jna

[steve.reinke at iws dot fraunhofer.de]

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

--- Comment #6 from steve.reinke at iws dot fraunhofer.de 2011-01-31 08:47:55 
UTC ---
Created attachment 23174
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23174
the jar which trys to load the dll

[Bug rtl-optimization/47454] registers are not allocated according to its preferred order

[carrot at google dot com]

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

--- Comment #3 from Carrot  2011-01-31 08:48:40 UTC 
---
(In reply to comment #2)
> -frename-registers should help for this issue on the ARM.

All of r8 can be renamed to r2, in this case only two of them have been
renamed.

[Bug java/47456] internal compiler error: Segmentation fault while using jna

[steve.reinke at iws dot fraunhofer.de]

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

--- Comment #7 from steve.reinke at iws dot fraunhofer.de 2011-01-31 08:48:43 
UTC ---
Created attachment 23175
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23175
batch file for compiling

[Bug java/47456] internal compiler error: Segmentation fault while using jna

[steve.reinke at iws dot fraunhofer.de]

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

--- Comment #8 from steve.reinke at iws dot fraunhofer.de 2011-01-31 08:49:04 
UTC ---
Created attachment 23176
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23176
the dll i try to load

[Bug tree-optimization/47538] [4.6 Regression] GNU Scientific Library miscompiled by gcc 4.6

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
  Component|c   |tree-optimization

--- Comment #8 from Jakub Jelinek  2011-01-31 
09:30:30 UTC ---
Ugh.  The problem seems to be that the middle-end considers sizetype and size_t
to be compatible types, thus we have x = y + 1; and similar stmts where x and 1
has sizetype type, but y has size_t.  tree-ssa-ccp.c (but similarly other
places e.g. in tree.c) ignore TYPE_UNSIGNED on sizetype, assuming it is 0, so
my fix in tree-ssa-ccp.c results in different value of uns on such stmts.

--- gcc/tree-ssa.c.jj   2011-01-15 11:26:42.0 +0100
+++ gcc/tree-ssa.c  2011-01-31 10:16:30.319433380 +0100
@@ -1276,6 +1276,12 @@ useless_type_conversion_p (tree outer_ty
  || TYPE_PRECISION (inner_type) != TYPE_PRECISION (outer_type))
return false;

+  if ((TREE_CODE (inner_type) == INTEGER_TYPE
+  && TYPE_IS_SIZETYPE (inner_type))
+ != (TREE_CODE (outer_type) == INTEGER_TYPE
+ && TYPE_IS_SIZETYPE (outer_type)))
+   return false;
+
   /* We don't need to preserve changes in the types minimum or
 maximum value in general as these do not generate code
 unless the types precisions are different.  */

seems to fix the miscompilation, but I'm afraid could have pretty substantial
result on IL size.  Why do we need something so ill-designed as sizetype?  Just
for Ada?

[Bug c++/47536] gcc-4.5.2 fails to build on Solaris 10 i386

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ebotcazou at gcc dot
   ||gnu.org
 Resolution||INVALID

--- Comment #11 from Eric Botcazou  2011-01-31 
09:49:04 UTC ---
> So there are two issues with gcc-4.5.2 on Solaris:
> 1. Inability to detect GNU assembler in path (unwarranted requirement to pass
> --with-gnu-as). Broken build when either no GNU assembler in path or no option
> --with-gnu-as passed.

This works as designed.  If you don't specify --with-as=xxx at configure time,
the compiler is configured to pick whatever assembler it finds at run time.  On
Solaris, the default is the Sun assembler.

> 2. GNU assembler from path isn't used by g++, causing Sun assembler to fail on
> GNU-formatted assembler file.

Likewise.  --with-gnu-as doesn't mean "pick the GNU assembler", it means that
the default assembler GCC will find is the GNU assembler.

[Bug target/47522] [4.4/4.5/4.6 Regression] wrong code at -O3 -ffast-math

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||wrong-code
  Component|middle-end  |target
 Blocks||44183
   Target Milestone|--- |4.4.6

--- Comment #2 from Richard Guenther  2011-01-31 
10:03:25 UTC ---
Target piece, if there is one.  PR44183 for the vectorizer piece, if there is
one.

[Bug tree-optimization/44183] Vectorizer may generate invalid memory access

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Guenther  2011-01-31 
10:06:27 UTC ---
(In reply to comment #6)
> It depends on the specific values of (a) array end alignment and (b) the 
> number
> of bytes read. As long as the array end + number of bytes read can cross a 
> page
> boundary, you're potentially causing SEGV or other errors.

I don't think this can happen.  The access to the out-of-bounds area only
happens if there are pieces inluded in the last (aligned) vector move.
That vector move will be aligned so it can't cross page-boundary.  As
it contains at least one allocated element the access may not trap.

[Bug tree-optimization/47538] [4.6 Regression] GNU Scientific Library miscompiled by gcc 4.6

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #9 from Eric Botcazou  2011-01-31 
10:13:07 UTC ---
> Why do we need something so ill-designed as sizetype?  Just for Ada?

Yes, they are useful for Ada, but the _original_ design; the POINTER_PLUS_EXPR
mistake is orthogonal to it and shouldn't be an excuse to eliminate them.

[Bug debug/47501] [4.6 Regression] -fcompare-debug failure with -Os -fmodulo-sched

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #2 from Alexandre Oliva  2011-01-31 
10:15:49 UTC ---
Mine.  Patch reverted in revision 169429, testing revised patch at
http://gcc.gnu.org/ml/gcc-patches/2011-01/msg02260.html

[Bug debug/47498] [4.6 Regression] -fcompare-debug failure with -fsched2-use-superblocks

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #3 from Alexandre Oliva  2011-01-31 
10:16:10 UTC ---
Mine.  Patch reverted in revision 169429, testing revised patch at
http://gcc.gnu.org/ml/gcc-patches/2011-01/msg02260.html

[Bug target/47522] [4.4/4.5/4.6 Regression] wrong code at -O3 -ffast-math

[Joost.VandeVondele at pci dot uzh.ch]

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

--- Comment #3 from Joost VandeVondele  
2011-01-31 10:16:24 UTC ---
(In reply to comment #2)
> Target piece, if there is one.  PR44183 for the vectorizer piece, if there is
> one.

I'm almost certain that this is a dup of PR44183. As far as I can judge, the
result of the calculation is indeed correct.

The annoying thing is that this makes valgrind's 'out of bounds checking' kind
of useless.

[Bug tree-optimization/47538] [4.6 Regression] GNU Scientific Library miscompiled by gcc 4.6

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  2011-01-31 
10:27:58 UTC ---
Self-contained testcase:

/* PR tree-optimization/47538 */

struct S
{
  double a, b, *c;
  unsigned long d;
};

__attribute__((noinline, noclone)) void
foo (struct S *x, const struct S *y)
{
  const unsigned long n = y->d + 1;
  const double m = 0.25 * (y->b - y->a);
  x->a = y->a;
  x->b = y->b;
  if (n == 1)
{
  x->c[0] = 0.;
}
  else if (n == 2)
{
  x->c[1] = m * y->c[0];
  x->c[0] = 2.0 * x->c[1];
}
  else
{
  double o = 0.0, p = 1.0;
  unsigned long i;

  for (i = 1; i <= n - 2; i++)
{
  x->c[i] = m * (y->c[i - 1] - y->c[i + 1]) / (double) i;
  o += p * x->c[i];
  p = -p;
}
  x->c[n - 1] = m * y->c[n - 2] / (n - 1.0);
  o += p * x->c[n - 1];
  x->c[0] = 2.0 * o;
}
}

int
main (void)
{
  struct S x, y;
  double c[4] = { 10, 20, 30, 40 }, d[4], e[4] = { 118, 118, 118, 118 };

  y.a = 10;
  y.b = 6;
  y.c = c;
  x.c = d;
  y.d = 3;
  __builtin_memcpy (d, e, sizeof d);
  foo (&x, &y);
  if (d[0] != 0 || d[1] != 20 || d[2] != 10 || d[3] != -10)
__builtin_abort ();
  y.d = 2;
  __builtin_memcpy (d, e, sizeof d);
  foo (&x, &y);
  if (d[0] != 60 || d[1] != 20 || d[2] != -10 || d[3] != 118)
__builtin_abort ();
  y.d = 1;
  __builtin_memcpy (d, e, sizeof d);
  foo (&x, &y);
  if (d[0] != -20 || d[1] != -10 || d[2] != 118 || d[3] != 118)
__builtin_abort ();
  y.d = 0;
  __builtin_memcpy (d, e, sizeof d);
  foo (&x, &y);
  if (d[0] != 0 || d[1] != 118 || d[2] != 118 || d[3] != 118)
__builtin_abort ();
  return 0;
}

[Bug fortran/47463] [OOP] ICE in gfc_add_component_ref

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.01.31 10:29:20
 AssignedTo|unassigned at gcc dot   |janus at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #5 from janus at gcc dot gnu.org 2011-01-31 10:29:20 UTC ---
Alright, here is a draft patch:


Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c(revision 169407)
+++ gcc/fortran/resolve.c(working copy)
@@ -5877,14 +5877,12 @@ resolve_typebound_subroutine (gfc_code *code)

   /* Deal with typebound operators for CLASS objects.  */
   expr = code->expr1->value.compcall.base_object;
-  if (expr && expr->symtree->n.sym->ts.type == BT_CLASS
-&& code->expr1->value.compcall.name)
+  if (expr && expr->ts.type == BT_CLASS && code->expr1->value.compcall.name)
 {
   /* Since the typebound operators are generic, we have to ensure
  that any delays in resolution are corrected and that the vtab
  is present.  */
-  ts = expr->symtree->n.sym->ts;
-  declared = ts.u.derived;
+  declared = expr->ts.u.derived;
   c = gfc_find_component (declared, "_vptr", true, true);
   if (c->ts.u.derived == NULL)
 c->ts.u.derived = gfc_find_derived_vtab (declared);
@@ -5895,6 +5893,7 @@ resolve_typebound_subroutine (gfc_code *code)
   /* Use the generic name if it is there.  */
   name = name ? name : code->expr1->value.function.esym->name;
   code->expr1->symtree = expr->symtree;
+  code->expr1->ref = gfc_copy_ref (expr->ref);
   expr->symtree->n.sym->ts.u.derived = declared;
   gfc_add_vptr_component (code->expr1);
   gfc_add_component_ref (code->expr1, name);



This fixes comment #1 and comment #4. For the original test case I now get:

gfortran-4.6  -std=f2003   -c hydro_types.f90
gfortran-4.6  -std=f2003   -c hydro_state.f90
gfortran-4.6  -std=f2003   -c hydro_speeds.f90
gfortran-4.6  -std=f2003   -c hydro_grid.f90
gfortran-4.6  -std=f2003   -c hydro_flow.f90
hydro_flow.f90:55.13:

call this%init(st, gr)
 1
Error: Found no matching specific binding for the call to the GENERIC 'init' at
(1)



Changing this generic call to the corresponding specific type-bound procedure,
I get:

gfortran-4.6  -std=f2003   -c hydro_flow.f90
hydro_flow.f90:55.13:

call this%init_comps(st, gr)
 1
Error: Type mismatch in argument 'this' at (1); passed CLASS(flow_t) to
CLASS(grid_t)



And the same without type-binding:

gfortran-4.6  -std=f2003   -c hydro_flow.f90
hydro_flow.f90:55.20:

call init_comps(this, st, gr)
1
Error: Type mismatch in argument 'this' at (1); passed CLASS(flow_t) to
CLASS(grid_t)



The code does look valid to me (unless I'm missing something), so this seems to
be another gfortran bug.

[Bug target/47540] ARM THUMB crash with complex numbers

[mikpe at it dot uu.se]

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

--- Comment #4 from Mikael Pettersson  2011-01-31 
10:34:56 UTC ---
I can reproduce the ICE with a 4.5.2 cross to arm-elf.  Only occurs for Thumb1.

[Bug debug/47508] [4.6 Regression] -fcompare-debug failure with -ftracer for pr42918.c

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2011-01-31 
10:40:20 UTC ---
Alex (temporarily) reverted the patch on the trunk, can you verify this is gone
again?

[Bug tree-optimization/47538] [4.6 Regression] GNU Scientific Library miscompiled by gcc 4.6

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Guenther  2011-01-31 
10:44:08 UTC ---
(In reply to comment #9)
> > Why do we need something so ill-designed as sizetype?  Just for Ada?
> 
> Yes, they are useful for Ada, but the _original_ design; the POINTER_PLUS_EXPR
> mistake is orthogonal to it and shouldn't be an excuse to eliminate them.

I agree with that POINTER_PLUS_EXPR shouldn't have used sizetype.

But - the problem with sizetype is not that they exist (and have that
special overflow behavior), but - that sizetypes are considered
always sign-extended despite TYPE_UNSIGNED saying "yes!".  That's a
very very very bad design mistake.  I tried to "fix" that mistake
at least two times IIRC but failed.

At the end -> no-undefined-overflow branch (no more sizetype).

[Bug rtl-optimization/44031] [4.4/4.5 Regression] ice in subst_reloads, at reload.c:6327

[ebotcazou at gcc dot gnu.org]

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

--- Comment #13 from Eric Botcazou  2011-01-31 
10:45:23 UTC ---
Author: ebotcazou
Date: Mon Jan 31 10:45:20 2011
New Revision: 169433

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169433
Log:
PR rtl-optimization/44031
* gcc.c-torture/compile/20110131-1.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/20110131-1.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug target/47522] [4.4/4.5/4.6 Regression] wrong code at -O3 -ffast-math

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de  
2011-01-31 10:47:53 UTC ---
On Mon, 31 Jan 2011, Joost.VandeVondele at pci dot uzh.ch wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47522
> 
> --- Comment #3 from Joost VandeVondele  
> 2011-01-31 10:16:24 UTC ---
> (In reply to comment #2)
> > Target piece, if there is one.  PR44183 for the vectorizer piece, if there 
> > is
> > one.
> 
> I'm almost certain that this is a dup of PR44183. As far as I can judge, the
> result of the calculation is indeed correct.
> 
> The annoying thing is that this makes valgrind's 'out of bounds checking' kind
> of useless.

I think valgrind should simply special-case these kind of out of bounds
checks based on the instruction that was used.  This is an optimization
that is useful (even glibc memcpy routines do that, but they have
exception rules in valgrind ...)

Richard.

[Bug target/47522] [4.4/4.5/4.6 Regression] wrong code at -O3 -ffast-math

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX

--- Comment #5 from Richard Guenther  2011-01-31 
10:49:53 UTC ---
WONTFIX.  The transformation is legal.  valgrind sucks (maybe report this
to them).

[Bug tree-optimization/44183] Vectorizer may generate invalid memory access

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #8 from Richard Guenther  2011-01-31 
10:51:32 UTC ---
This is a non-bug.  The transformation is ok and will never cause a pagefault.

[Bug target/47543] ICE: in extract_insn, at recog.c:2109 when building zlib

[ibolton at gcc dot gnu.org]

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

Ian Bolton  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.01.31 10:53:30
 CC||ibolton at gcc dot gnu.org
 Ever Confirmed|0   |1
  Known to fail||4.6.0

[Bug debug/47106] -fcompare-debug failure (length) with -fpartial-inlining -flto -fconserve-stack

[aoliva at gcc dot gnu.org]

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

--- Comment #7 from Alexandre Oliva  2011-01-31 
11:03:11 UTC ---
Revised patch under testing, posted at
http://gcc.gnu.org/ml/gcc-patches/2011-01/msg02264.html

[Bug fortran/47463] [OOP] ICE in gfc_add_component_ref

[burnus at gcc dot gnu.org]

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

--- Comment #6 from Tobias Burnus  2011-01-31 
11:03:31 UTC ---
(In reply to comment #5)
> hydro_flow.f90:55.13:
> call this%init(st, gr)
>  1
> Error: Found no matching specific binding for the call to the GENERIC
> 'init' at (1)

That matches Cray's ftn (cf. comment 1):
call this%init(st, gr)
 ^ 
ftn-389 crayftn: ERROR INIT_PARAMS, File = hydro_flow.f90, Line = 55, Column =
14 
  No specific match can be found for the generic subprogram call "INIT".



> Changing this generic call to the corresponding specific type-bound procedure,

I assume s/this%init/this%init_comps/ in that line. With Crayftn I then get the
following, which looks at a glance like a bug in crayftn, though I have not
checked it:

 procedure :: init_comps
  ^
ftn-1130 crayftn: ERROR HYDRO_FLOW, File = hydro_flow.f90, Line = 21, Column =
19
  "INIT_COMPS" is specified as a procedure-name in a type bound procedure
statement.  It must be a module procedure or an external procedure with an
explicit interface.

  subroutine init_comps (this, st, gr)
 ^
ftn-575 crayftn: ERROR HYDRO_FLOW, File = hydro_flow.f90, Line = 66, Column =
14
  "INIT_COMPS" has been used as a subroutine, therefore it must not be declared
as a module procedure subroutine.


> I get:
[ Some gfortran error message, completely different from Crays]


> And the same without type-binding:
> call init_comps(this, st, gr)
> Error: Type mismatch in argument 'this' at (1); passed CLASS(flow_t) to
> CLASS(grid_t)

That version works with Crayftn. It then compiles hydro_flow.f90 - and stops in
hydro_recon.f90 (line 31) for "fl%n" as '"N" is not a component of derived type
"FLOW_T"'

[Bug target/47522] [4.4/4.5/4.6 Regression] wrong code at -O3 -ffast-math

[Joost.VandeVondele at pci dot uzh.ch]

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

--- Comment #6 from Joost VandeVondele  
2011-01-31 11:17:46 UTC ---
(In reply to comment #5)
> valgrind sucks (maybe report this to them).

I think this is an unnecessary comment (all useful tools have bugs, or features
we don't like). The issue has been reported as

https://bugs.kde.org/show_bug.cgi?id=264936

[Bug tree-optimization/47538] [4.6 Regression] GNU Scientific Library miscompiled by gcc 4.6

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  2011-01-31 
11:36:24 UTC ---
Created attachment 23177
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23177
gcc46-pr47538.patch

The #c8 patch doesn't bootstrap, agree with Richard this is not stage4ish.

Another alternative patch, which just reverts the patch that caused it and
limits it to comparisons (where lhs type is always unrelated to the comparison
type).

[Bug target/47551] New: ICE when reloading neon registers from out-of-range offsets

[richard.sandiford at linaro dot org]

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

   Summary: ICE when reloading neon registers from out-of-range
offsets
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: richard.sandif...@linaro.org


The ref_vldX.c test from:

http://gitorious.org/arm-neon-tests/arm-neon-tests

fails when compiled with -O0 -marm:

(insn 1817 1816 1818 2
/home/export/usr/gcc-linaro/H-x86_64-unknown-linux-gnu/bin/../lib/gcc/arm-linux-gnueabi/4.5.2/include/arm_neon.h:921
5 (parallel [
(set (reg:CI 303 [ D.14795 ])
(unspec:CI [
(mem:CI (reg:SI 3 r3 [1023]) [0 S48 A64])
(reg:CI 303 [ D.14795 ])
(unspec:V8HI [
(const_int 0 [0x0])
] 191)
] 106))
(set (reg:SI 3 r3 [1023])
(plus:SI (reg:SI 3 r3 [1023])
(const_int 24 [0x18])))
]) 1614 {neon_vld3qav8hi} (nil))
ref_vldX.c:157: confused by earlier errors, bailing out

This is due to a bug in the ARM secondary_reload code.

[Bug tree-optimization/47538] [4.6 Regression] GNU Scientific Library miscompiled by gcc 4.6

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Guenther  2011-01-31 
11:55:03 UTC ---
Can we use sth like

Index: tree-ssa-ccp.c
===
--- tree-ssa-ccp.c  (revision 169434)
+++ tree-ssa-ccp.c  (working copy)
@@ -1770,9 +1770,38 @@ bit_value_binop_1 (enum tree_code code,
 {
   bool uns = (TREE_CODE (r1type) == INTEGER_TYPE
  && TYPE_IS_SIZETYPE (r1type) ? 0 : TYPE_UNSIGNED (r1type));
+
   /* Assume we'll get a constant result.  Use an initial varying value,
  we fall back to varying in the end if necessary.  */
   *mask = double_int_minus_one;
+
+  /* We have some sizetype issues, drop to varying in case there are
+ mismatches.  */
+  switch (code)
+{
+case LSHIFT_EXPR:
+case RSHIFT_EXPR:
+case LROTATE_EXPR:
+case RROTATE_EXPR:
+  if ((TREE_CODE (type) == INTEGER_TYPE
+  && TYPE_IS_SIZETYPE (type) ? 0 : TYPE_UNSIGNED (type)) != uns)
+   return;
+  break;
+
+case EQ_EXPR:
+case NE_EXPR:
+case LT_EXPR:
+case LE_EXPR:
+case GE_EXPR:
+case GT_EXPR:
+  if ((TREE_CODE (r2type) == INTEGER_TYPE
+  && TYPE_IS_SIZETYPE (r2type) ? 0 : TYPE_UNSIGNED (r2type)) != uns)
+   return;
+  break;
+
+default:;
+}
+

instead?  It makes it more obvious what happens (IMHO).

[Bug tree-optimization/47538] [4.6 Regression] GNU Scientific Library miscompiled by gcc 4.6

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Guenther  2011-01-31 
12:07:52 UTC ---
Created attachment 23178
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23178
patch

[Bug tree-optimization/47538] [4.6 Regression] GNU Scientific Library miscompiled by gcc 4.6

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

  Attachment #23178|0   |1
is obsolete||

--- Comment #15 from Richard Guenther  2011-01-31 
12:30:17 UTC ---
Created attachment 23179
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23179
another update

[Bug fortran/47552] New: CTIME: Valgrind warning "depends on uninitialised value"

[burnus at gcc dot gnu.org]

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

   Summary: CTIME: Valgrind warning "depends on uninitialised
value"
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: j...@gcc.gnu.org


The following does not seem to be a regression and it only occurs with the
function version and not with the subroutine version.

character(len=20) :: str
! OK:
!call ctime(time8(),str)

! Valgrind issue (2x line 7):
! Conditional jump or move depends on uninitialised value
str = ctime(time8()) ! << this line
print *, str
end

[Bug fortran/47552] CTIME: Valgrind warning "depends on uninitialised value"

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.01.31 12:57:07
 Ever Confirmed|0   |1

--- Comment #1 from Janne Blomqvist  2011-01-31 12:57:07 
UTC ---
FWIW, I see the same problem with gfortran 4.4 @work, so probably not something
due to my recent ctime_r() patch.

[Bug target/47553] New: ARM neon vld1q_lane_u8 & co. don't accept lanes >= 8

[richard.sandiford at linaro dot org]

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

   Summary: ARM neon vld1q_lane_u8 & co. don't accept lanes >= 8
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: richard.sandif...@linaro.org


The testcase:

#include 

uint8x16_t
foo (uint8_t *a, uint8x16_t b)
{
  vst1q_lane_u8 (a, b, 14);
  return vld1q_lane_u8 (a + 0x100, b, 15);
}

fails with:

error: argument must be a constant

The v{ld,st}1q_lane_{u,s,p}8 intrinsic functions are supposed to take a range
between 0 and 15.  The function is then converted to a vld1 or vst1 of one half
of the quad value.  The problem is that the lane predicate doesn't account for
this, and only accepts the 0..7 range that are supported by vld1 and vst1.

The error could be a bit friendlier too; maybe "argument out of range" or
something.  That's a problem in a separate piece of code though, so I'm not
treating it as part of this bug.

[Bug fortran/47519] Deferred-length string wrong results with character intrinsic functions

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  2011-01-31 
13:24:19 UTC ---
> That does indeed regtest OK.

It passes all my tests too;-)

Thanks for the patch.

[Bug driver/47547] WHOPR, can't use /dev/null as an output file

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.01.31 13:29:28
 CC||hjl at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-01-31 
13:29:28 UTC ---
We end up with -dumpdir /dev/ -dumpbase null.wpa.  The failure occurs in

(gdb) up
#1  0x00936029 in init_asm_output (name=0x1780640 "t.o")
at /space/rguenther/src/svn/trunk/gcc/toplev.c:928
928 fatal_error ("can%'t open %s for writing: %m", asm_file_name);
(gdb) l
923   if (!strcmp (asm_file_name, "-"))
924 asm_out_file = stdout;
925   else
926 asm_out_file = fopen (asm_file_name, "w+b");
927   if (asm_out_file == 0)
928 fatal_error ("can%'t open %s for writing: %m", asm_file_name);
929 }
930
931   if (!flag_syntax_only)
932 {

and

(gdb) p global_options->x_dump_base_name 
$2 = 0x179ce30 "/dev/null.wpa"

I think HJ caused this (the -dumpdir / -dumpbase flags are bogus), non-LTO
does not use -dumpdir, lto-wrapper.c is what sets that flag (I don't
remember why -dumpdir is used at all - HJ?).

Same problem with

gcc -S t.c -o /dev/null -fdump-tree-optimized

btw, so not really LTO specific (but more annoying).

[Bug lto/47528] liblto_plugin.so not found should not to be an fatal error

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Target||mingw64-*-*

--- Comment #1 from Richard Guenther  2011-01-31 
13:37:21 UTC ---
I think you use an old GCC snapshot (if you didn't pass -fuse-linker-plugin
manually).  That said, your target should not use the flag unconditionally,
the fatal-error is on purpose and it will not be changed.

[Bug lto/47527] [4.6 regression] -flto -flto-partition=none broken for arm-linux-gnueabi

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0

--- Comment #1 from Richard Guenther  2011-01-31 
13:39:51 UTC ---
As this is a linker error maybe it's a linker bug?

[Bug rtl-optimization/47521] [4.4/4.5/4.6 Regression] Unnecessary usage of edx register

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.4.6

[Bug c++/47541] [4.5/4.6 Regression] For integer pointers, the value of ++*p is not written back to memory

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  2011-01-31 
14:26:39 UTC ---
It is tree dse1 that removes the needed increment (the only dse_optimize_stmt
optimized store in the whole testcase).

[Bug target/45325] [4.6 Regression] target attribute doesn't work with -march=i586

[ro at gcc dot gnu.org]

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

--- Comment #17 from Rainer Orth  2011-01-31 14:27:45 
UTC ---
That works.  Patch submitted:

http://gcc.gnu.org/ml/gcc-patches/2011-01/msg02297.html

[Bug driver/47547] WHOPR, can't use /dev/null as an output file

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  2011-01-31 14:32:34 
UTC ---
(In reply to comment #1)
> 
> I think HJ caused this (the -dumpdir / -dumpbase flags are bogus), non-LTO
> does not use -dumpdir, lto-wrapper.c is what sets that flag (I don't
> remember why -dumpdir is used at all - HJ?).

It is for PR 41564.

[Bug lto/47528] liblto_plugin.so not found should not to be an fatal error

[dongsheng.song at gmail dot com]

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

--- Comment #2 from Dongsheng Song  2011-01-31 
14:34:07 UTC ---
(In reply to comment #1)
> I think you use an old GCC snapshot (if you didn't pass -fuse-linker-plugin
> manually).  That said, your target should not use the flag unconditionally,
> the fatal-error is on purpose and it will not be changed.

Which version is OK ?

I can confirm my working copy is not older than 2011-01-27.

In any case, I'll try again at tomorrow.

[Bug fortran/47463] [OOP] ICE in gfc_add_component_ref

[janus at gcc dot gnu.org]

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

--- Comment #7 from janus at gcc dot gnu.org 2011-01-31 14:49:00 UTC ---
(In reply to comment #5)
> Alright, here is a draft patch:

The patch in comment #5 regtests cleanly. I will commit as obvious soon ...

[Bug target/45325] [4.6 Regression] target attribute doesn't work with -march=i586

[ro at gcc dot gnu.org]

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

--- Comment #18 from Rainer Orth  2011-01-31 14:56:35 
UTC ---
Author: ro
Date: Mon Jan 31 14:56:31 2011
New Revision: 169440

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169440
Log:
PR target/45325
* gcc.target/i386/pr38240.c: Add dg-options "-msse".

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/pr38240.c

[Bug tree-optimization/47538] [4.6 Regression] GNU Scientific Library miscompiled by gcc 4.6

[howarth at nitro dot med.uc.edu]

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

--- Comment #16 from Jack Howarth  2011-01-31 
14:59:43 UTC ---
(In reply to comment #15)
> Created attachment 23179 [details]
> another update

This patch eliminates the testsuite failures in gsl-1.14 built at either -O2 or
-O3 under current gcc trunk on x86_64-apple-darwin10.

[Bug testsuite/47400] Several UCN tests FAIL on Tru64 UNIX V5.1B and IRIX 6.5

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2011-01/msg02305.htm
   ||l
   Last reconfirmed||2011.01.31 15:06:17
  Component|c   |testsuite
 AssignedTo|unassigned at gcc dot   |ro at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.6.0
 Ever Confirmed|0   |1

--- Comment #4 from Rainer Orth  2011-01-31 15:06:17 UTC 
---
Mine, initial patch posted.

[Bug go/47515] Issues porting libgo to IRIX 6.5

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-01-31 15:11:15 UTC ---
> --- Comment #1 from Ralf Wildenhues  2011-01-28 
> 18:53:54 UTC ---
> (In reply to comment #0)
>> * Building libgo still depends on a linker supporting --whole-archive, but 
>> SGI
>>   ld doesn't and GNU ld doesn't work due to PR target/43533.
>
> libtool abstracts --whole-archive when libtool convenience archives are used,
> and it can create relocatable objects.  As a cheap way to exploit that you
> could amend BUILDGOX to create a little convenience archive .la file.  Or let
> BUILDARCHIVE build an actual .la convenience archive, that's even easier.  
> Hmm,
> there is even a rule to create %.la from %.a, why all this going backwards
> trying to hack around libtool when it can do the job?

No idea, although there have been many times where I've been swearing at
libtool when it gets in my way and thinks it's smarter than me ;-(

But thanks alot for the tip: this proved to be remarkably simple and
I've posted an initial patch:

http://gcc.gnu.org/ml/gcc-patches/2011-01/msg02304.html

> libtool also has a pending patch abstracting -Bstatic/-Bdynamic by the way.

... which won't help since gcc needs to be usable without libtool.

Thanks.
Rainer

[Bug c++/47541] [4.5/4.6 Regression] For integer pointers, the value of ++*p is not written back to memory

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Guenther  2011-01-31 
15:10:34 UTC ---
Mine.

[Bug target/47543] ICE: in extract_insn, at recog.c:2109 when building zlib

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #4 from Jeffrey A. Law  2011-01-31 15:38:02 
UTC ---
Investigating

[Bug c++/47541] [4.5/4.6 Regression] For integer pointers, the value of ++*p is not written back to memory

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  2011-01-31 
15:57:28 UTC ---
Created attachment 23180
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23180
pr47541.ii

For Richard:
x86_64-linux, trunk from today, ./cc1plus -O2 -fdump-tree-alias
-fdump-tree-dse-all pr47541.ii
;; Function virtual void B::Push(Wrapper) (_ZN1B4PushE7Wrapper)
...
Deleted dead store '*D.10321_19 = D.10324_22;
'
and the delete is invalid.
*.alias has:
ptr = &PARM_NOALIAS.204.64+64
D.10321_19 = *ptr + 128
...
D.10321_19 = { }
...
D.10321_19, points-to vars: { }

[Bug target/47543] [4.6 Regression] ICE: in extract_insn, at recog.c:2109 when building zlib

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |4.6.0
Summary|ICE: in extract_insn, at|[4.6 Regression] ICE: in
   |recog.c:2109 when building  |extract_insn, at
   |zlib|recog.c:2109 when building
   ||zlib

[Bug c++/47416] [4.6 Regression] ICE in build_data_member_initialization, at cp/semantics.c:5509

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  2011-01-31 
16:18:33 UTC ---
Created attachment 23181
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23181
gcc46-pr47416.patch

Untested fix.

[Bug c++/47541] [4.5/4.6 Regression] For integer pointers, the value of ++*p is not written back to memory

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Guenther  2011-01-31 
16:28:19 UTC ---
Hmm.  We have

  D.10321_19 = MEM[(const struct RefCount &)ptr_3(D) + 8].count_;
  MEM[(struct RefCount *)D.9717_8 + 8B].count_ = D.10321_19;
  D.10322_20 = MEM[(struct RefCount *)D.9717_8 + 8B].count_;
...
  MEM[(int *)D.10322_20] = D.10324_22;

so _19 isn't used at this point (as in, dereferenced) directly.

Constraints:

PARM_NOALIAS.204.64+64 = NONLOCAL
PARM_NOALIAS.204.128+64 = NONLOCAL
ptr = &PARM_NOALIAS.204.64+64
D.10321_19 = *ptr + 128
*D.9717_8 + 128 = D.10321_19
D.10322_20 = *D.9717_8 + 128
D.10323_21 = *D.10322_20

Note the funny fact that no constraint is there for
the subvar starting at 0.  And we end up with

  # PT = nonlocal escaped
  D.10320_18 = MEM[(const struct RefCount &)ptr_3(D) + 8].ptr_;
  MEM[(struct RefCount *)D.9717_8 + 8B].ptr_ = D.10320_18;
  # PT =
  D.10321_19 = MEM[(const struct RefCount &)ptr_3(D) + 8].count_;
  MEM[(struct RefCount *)D.9717_8 + 8B].count_ = D.10321_19;
  # PT = nonlocal escaped
  D.10322_20 = MEM[(struct RefCount *)D.9717_8 + 8B].count_;

which means that we think we access PARM_NOALIAS.204.196+64 when
loading from count_.  This looks like a type issue to me, related to
pass-by-reference + restrict handling.  Eventually related to
how inheritance is represented.

[Bug target/47543] [4.6 Regression] ICE: in extract_insn, at recog.c:2109 when building zlib

[law at redhat dot com]

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

--- Comment #5 from Jeffrey A. Law  2011-01-31 16:33:29 
UTC ---
I'm far from an ARM expert, but this looks like a problem in the ARM backend. 
Anyway, I'm still investigating.

[Bug c++/47541] [4.5/4.6 Regression] For integer pointers, the value of ++*p is not written back to memory

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Guenther  2011-01-31 
16:40:11 UTC ---
Testcase:

struct Dummy {};
struct RefCount : public Dummy {
~RefCount(); /* Has to be non-pod.  */
int *a;
int *b;
};
RefCount::~RefCount(){}
struct Wrapper : public Dummy { RefCount ref; };
void __attribute__((noinline,noclone))
Push(Wrapper ptr)
{
  *ptr.ref.b = 0;
}
extern "C" void abort (void);
int main()
{
  int a = 1, b = 1;
  Wrapper x;
  x.ref.a = &a;
  x.ref.b = &b;
  Push(x);
  if (b != 0)
abort ();
  return 0;
}

[Bug tree-optimization/47538] [4.6 Regression] GNU Scientific Library miscompiled by gcc 4.6

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek  2011-01-31 
16:52:27 UTC ---
Author: jakub
Date: Mon Jan 31 16:52:22 2011
New Revision: 169441

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169441
Log:
PR tree-optimization/47538
* tree-ssa-ccp.c (bit_value_binop_1): For uns computation use
type instead of r1type, except for comparisons.  For right
shifts and comparisons punt if there are mismatches in
sizetype vs. non-sizetype types.

* gcc.c-torture/execute/pr47538.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr47538.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-ccp.c

[Bug tree-optimization/47538] [4.6 Regression] GNU Scientific Library miscompiled by gcc 4.6

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #18 from Jakub Jelinek  2011-01-31 
16:56:33 UTC ---
Fixed.

[Bug driver/47547] WHOPR, can't use /dev/null as an output file

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot   |hjl.tools at gmail dot com
   |gnu.org |

--- Comment #3 from H.J. Lu  2011-01-31 17:00:38 
UTC ---
Created attachment 23182
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23182
A patch

How about this patch?

[Bug driver/47547] WHOPR, can't use /dev/null as an output file

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0

[Bug c++/47541] [4.5/4.6 Regression] For integer pointers, the value of ++*p is not written back to memory

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Guenther  2011-01-31 
17:07:19 UTC ---
So, type Wrapper as seen by PTA has

Wrapper
  offset 64:  RefCount

RefCount
  offset 0: a
  offset 64: b

and the issue is that the ptr parameter gets the address of a as initial
value by PTA.  Oops.  It really needs to get offset zero as initial address!
We should always keep a subvar for offset zero.

I have a patch.

[Bug lto/47274] [4.6 regression] ICE in lto_varpool_replace_node, at lto-symtab.c:306

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||dave.korn.cygwin at gmail
   ||dot com

--- Comment #21 from Jan Hubicka  2011-01-31 
17:07:35 UTC ---
Thanks.  Looking at compilation time callgraphs, they are all as expected.
At link time however, the resolution info seems however all wrong.
That results in wrong merging. Not only for vars, but also for functions:

main_test/7(-1) @0x4045f5b0 (asm: main_test) prevailing_def_ironly
  called by: main/6 (1.00 per call) 
  calls: 
  References: 
  Refering this function:

main_test/0(-1) @0x4045f000 (asm: main_test) analyzed 19 time, 12 benefit 13
size, 4 benefit externally_visible finalized inlinable
  called by: 
  calls: abort/1 abort/1 abs/2 (1.00 per call) 
  References:  var:abs_called (read)
  Refering this function: 

The first node is main_test comming from main.c, the second is one comming from
abd-1.c defining the function.

The problem is that first one is defined as prevailing_def_ironly while it is
not an definition, just use of the symbol. Correct would be to have
PREVAILING_DEF_IRONLY on the second and PREEMTED_IR on the first. 
We probably should add sanity check that functions with PREVAILING_DEFs are
always analyzed and vars finalized.

As observer by Richard, it comes from resolution file already:
abs-1.o 3
70 262910e5 PREEMPTED_IR main_test
main.o 3
76 e5772d37 PREVAILING_DEF_IRONLY main_test
should be the other way around

I am quite convinced that we are seeing GNU LD bug and adding Dave Korn to CC
thus. 

The other alternative would be that lto symbol table is output incorrectly at
compilation time. You might try to experiment with NM's plugin support to try
to dump LTO symbol table of main.o. I never tried it myself as I never really
needed to dump LTO symbol table, but it should be supported now.

But given that the code in write_symbol is quite straighforward:
  if (DECL_EXTERNAL (t))
{ 
  if (DECL_WEAK (t))
kind = GCCPK_WEAKUNDEF;
  else
kind = GCCPK_UNDEF;
}
  else
{ 
  if (DECL_WEAK (t))
kind = GCCPK_WEAKDEF;
  else if (DECL_COMMON (t))
kind = GCCPK_COMMON;
  else
kind = GCCPK_DEF;

  /* When something is defined, it should have node attached.  */
  gcc_assert (alias || TREE_CODE (t) != VAR_DECL
  || varpool_get_node (t)->finalized);
  gcc_assert (alias || TREE_CODE (t) != FUNCTION_DECL
  || (cgraph_get_node (t)
  && cgraph_get_node (t)->analyzed));
}
(kind should be GCCPK_UNDEF for main_test in main.o)
I would not expect bug to be on symbol streaming side.

[Bug lto/47274] [4.6 regression] ICE in lto_varpool_replace_node, at lto-symtab.c:306

[davek at gcc dot gnu.org]

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

Dave Korn  changed:

   What|Removed |Added

 CC||davek at gcc dot gnu.org

--- Comment #22 from Dave Korn  2011-01-31 17:22:55 
UTC ---
(In reply to comment #21)

> The problem is that first one is defined as prevailing_def_ironly while it is
> not an definition, just use of the symbol. Correct would be to have
> PREVAILING_DEF_IRONLY on the second and PREEMTED_IR on the first. 
> We probably should add sanity check that functions with PREVAILING_DEFs are
> always analyzed and vars finalized.
> 
> As observer by Richard, it comes from resolution file already:
> abs-1.o 3
> 70 262910e5 PREEMPTED_IR main_test
> main.o 3
> 76 e5772d37 PREVAILING_DEF_IRONLY main_test
> should be the other way around
> 
> I am quite convinced that we are seeing GNU LD bug and adding Dave Korn to CC
> thus. 

  Looking into it.

[Bug c/47520] [trans-mem] ICE Segmentation fault at 01

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #1 from Aldy Hernandez  2011-01-31 
17:34:36 UTC ---
fixed on branch

[Bug other/47554] New: [trans-mem] expand_expr_addr_expr_1 ICE

[aldyh at gcc dot gnu.org]

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

   Summary: [trans-mem] expand_expr_addr_expr_1 ICE
   Product: gcc
   Version: trans-mem
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: al...@gcc.gnu.org


ICE ICE baby

[Bug other/47554] [trans-mem] expand_expr_addr_expr_1 ICE

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.01.31 17:42:35
 AssignedTo|unassigned at gcc dot   |aldyh at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Aldy Hernandez  2011-01-31 
17:42:35 UTC ---
Created attachment 23183
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23183
testcase

[Bug other/47554] [trans-mem] expand_expr_addr_expr_1 ICE

[aldyh at gcc dot gnu.org]

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

--- Comment #2 from Aldy Hernandez  2011-01-31 
17:43:11 UTC ---
./cc1plus b.C -O0 -fgnu-tm -fdump-tree-all -fdump-ipa-all -quiet 
b.C: In member function 'list list::_M_get_Tp_allocator() const':
b.C:14:38: internal compiler error: in expand_expr_addr_expr_1, at expr.c:6905
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug target/47543] [4.6 Regression] ICE: in extract_insn, at recog.c:2109 when building zlib

[law at redhat dot com]

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

--- Comment #6 from Jeffrey A. Law  2011-01-31 17:57:45 
UTC ---
Created attachment 23184
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23184
potential fix

[Bug target/47543] [4.6 Regression] ICE: in extract_insn, at recog.c:2109 when building zlib

[law at redhat dot com]

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

--- Comment #7 from Jeffrey A. Law  2011-01-31 17:58:37 
UTC ---
When I first started looking at this problem I was ready to point the finger at
the ARM backend.  A missing secondary reload or something along those lines.. 
However, after further investigation, this may be a latent reload bug.


So basically what happens is we determine that a particular pseudo is better
left in memory and the equivalent address is ip + 32.  So we've got this memory
address:

(plus:SI (reg/v/f:SI 12 ip [orig:161 state ] [161]) (const_int 32 [0x20]))

There's two problems.  The first is (reg:SI 12) is not a valid base address for
the thumb.  Second (const_int 32) is an invalid offset for QImode on thumb.

Reload reloads the base register generating:

(plus:SI (reg:SI 5 r5) (const_int 32 [0x20])) 

That's an improvement (we've got a valid base register), but the memory address
is still invalid for QImode due to the out-of-range offset.

As I've sat here tracking find_reloads_address, I'm really starting to wonder
if this really is a latent reload bug.

The best chance I see to fix this problem is the reloading code guarded by this
conditional (it will reload the displacement into a reg or reload the entire
address into a reg).  The code doesn't trigger because the base register is not
valid.

  /* If we have address of a stack slot but it's not valid because the
 displacement is too large, compute the sum in a register.
 Handle all base registers here, not just fp/ap/sp, because on some
 targets (namely SH) we can also get too large displacements from
 big-endian corrections.  */
  else if (GET_CODE (ad) == PLUS
   && REG_P (XEXP (ad, 0))
   && REGNO (XEXP (ad, 0)) < FIRST_PSEUDO_REGISTER
   && CONST_INT_P (XEXP (ad, 1))
   && regno_ok_for_base_p (REGNO (XEXP (ad, 0)), mode, PLUS,
   CONST_INT))


There's no other clauses that apply so we eventually call:

  return find_reloads_address_1 (mode, ad, 0, MEM, SCRATCH, loc, opnum, type,
 ind_levels, insn);

Which recurses via the code:
   else if (code1 == CONST_INT || code1 == CONST
 || code1 == SYMBOL_REF || code1 == LABEL_REF)
  find_reloads_address_1 (mode, orig_op0, 0, PLUS, code1,
  &XEXP (x, 0), opnum, type, ind_levels,
  insn);

Which ultimately reloads the base register leaving the out-of-range constant.

Presumably this hasn't caused us many problems in the past because we only
rarely decide to leave pseudos in memory and even rarer do we address them via
an invalid base register and an out-of-range offset.  

The fix is relatively simple, given an address of the form
(plus (reg) (const_int))

If reloading the reg doesn't make a valid address, then the problem is the
constant and we should reload the entire address.

That's a 1-line change.  Which looks something like that attached patch.

[Bug fortran/47463] [OOP] ICE in gfc_add_component_ref

[janus at gcc dot gnu.org]

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

--- Comment #8 from janus at gcc dot gnu.org 2011-01-31 18:11:36 UTC ---
Author: janus
Date: Mon Jan 31 18:11:32 2011
New Revision: 169443

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169443
Log:
2011-01-31  Janus Weil  

PR fortran/47463
* resolve.c (resolve_typebound_subroutine): Bug fix for the case of
an argument of a typebound assignment being a component.


2011-01-31  Janus Weil  

PR fortran/47463
* gfortran.dg/typebound_assignment_1.f03: New.

Added:
trunk/gcc/testsuite/gfortran.dg/typebound_assignment_1.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/40979] induct benchmark 60% slower when compiled with -fgraphite-identity

[spop at gcc dot gnu.org]

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

--- Comment #11 from Sebastian Pop  2011-01-31 
18:12:38 UTC ---
Here is a reduced testcase from induct.f90 for the first loop
not vectorized with -fgraphite-identity:

module mqc_m
integer, parameter, private :: longreal = selected_real_kind(15,90)
contains
  subroutine mutual_ind_quad_cir_coil (m, l12)
  real (kind = longreal), dimension(9), save :: w2gauss, w1gauss
  real (kind = longreal) :: l12_lower, numerator
  real (kind = longreal), dimension(3) :: current_vector, coil_current_vec
  w2gauss(1) = 16.0_longreal/81.0_longreal
  w1gauss(5) = 0.3302393550_longreal
  do i = 1, 2*m
  do j = 1, 9
  do k = 1, 9
  numerator = w1gauss(j) * w2gauss(k) *
&

dot_product(coil_current_vec,current_vector)
  l12_lower = l12_lower + numerator
  end do
  end do
  end do
  l12 = l12_lower
  end subroutine mutual_ind_quad_cir_coil
end module mqc_m

The problem seems to be that graphite introduces a
Commutative_Associative_Reduction array that confuses the vectorizer.

I looked at how to improve translate_scalar_reduction_to_array in
order to avoid the creation of the temporary array, but it seems to be
difficult as the result is written to memory under a different type
than the reduction itself: l12_lower is a real whereas l12 is an
integer:

l12_lower_200 = some_computation;
# l12_lower_9 = PHI 
D.1585_43 = (integer(kind=4)) l12_lower_9;
# .MEM_48 = VDEF <.MEM_47>
*l12_44(D) = D.1585_43;

so we cannot use *l12_44(D) as a data reference in the loop to perform
the reduction as it does not have the same precision as l12_lower: it
seems to me that we cannot avoid creating the temporary array.

The solution could be to clean up the temporary arrays after graphite.

[Bug c/47492] [trans-mem] Problem with memset() inside transaction_safe function

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011.01.31 18:21:35
 CC||aldyh at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #2 from Aldy Hernandez  2011-01-31 
18:21:35 UTC ---
Fixed here:
http://gcc.gnu.org/ml/gcc-patches/2011-01/msg02325.html

Awaiting approval.

[Bug target/47540] ARM THUMB crash with complex numbers

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.01.31 18:24:35
 Ever Confirmed|0   |1

--- Comment #5 from Ian Lance Taylor  2011-01-31 18:24:35 
UTC ---
Marking as confirmed.

[Bug target/40183] g++.dg/tls/static-1.C, execution abort

[greed at pobox dot com]

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

Graham Reed  changed:

   What|Removed |Added

 CC||greed at pobox dot com

--- Comment #3 from Graham Reed  2011-01-31 18:44:57 
UTC ---
(In reply to comment #2)
> On SPARC, I only see this when configuring with gas and gld, which isn't
> apparent in your g++ -v output.

It looks like this is resolved with binutils-2.21.  I used the gld from
binutils-2.21 with the .o files produced by gas in binutils-2.20.1 and the
gcc-4.5.2 compiler, and the tls/static-1.C test now passes.  (Using gcc's -v
feature to find out what the actual link command was; replacing collect2 with a
direct call to ld seems to work well enough for this test.)

I haven't tried x86-64 yet; I'm a bit short of CPU power on that one.

[Bug middle-end/40979] induct benchmark 60% slower when compiled with -fgraphite-identity

[dominiq at lps dot ens.fr]

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

--- Comment #12 from Dominique d'Humieres  
2011-01-31 18:46:23 UTC ---
> I looked at how to improve translate_scalar_reduction_to_array in
> order to avoid the creation of the temporary array, but it seems to be
> difficult as the result is written to memory under a different type
> than the reduction itself: l12_lower is a real whereas l12 is an
> integer:

In the original code l12 is real (kind = longreal) as l12_lower, but making the
change does not help the vectorization.

[Bug lto/47274] [4.6 regression] ICE in lto_varpool_replace_node, at lto-symtab.c:306

[davek at gcc dot gnu.org]

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

--- Comment #23 from Dave Korn  2011-01-31 18:53:30 
UTC ---
(In reply to comment #21)

> The problem is that first one is defined as prevailing_def_ironly while it is
> not an definition, just use of the symbol. Correct would be to have
> PREVAILING_DEF_IRONLY on the second and PREEMTED_IR on the first. 
> We probably should add sanity check that functions with PREVAILING_DEFs are
> always analyzed and vars finalized.
> 
> As observer by Richard, it comes from resolution file already:
> abs-1.o 3
> 70 262910e5 PREEMPTED_IR main_test
> main.o 3
> 76 e5772d37 PREVAILING_DEF_IRONLY main_test
> should be the other way around

  Why would you expect to see PREEMPTED_IR?  There is only one definition of
main_test; I would expect RESOLVED_IR.  Rather than swapped, aren't they just
plain wrong?

> I am quite convinced that we are seeing GNU LD bug and adding Dave Korn to CC
> thus. 

  I also think you must be seeing a bug in LD, but haven't reproduced it yet;
on both x86_64-linux and i686-cygwin I get the same correct resolution file:

davek@gcc10:~/binutils/obj-gcc/gcc/pr47274$ cat *.res
3
abs-1.o 2
79 7d1d28a3 PREVAILING_DEF_IRONLY main_test
93 7d1d28a3 PREVAILING_DEF_IRONLY abs_called
abs-1-lib.o 2
110 4db0e4c5 RESOLVED_IR inside_main
112 4db0e4c5 RESOLVED_IR abs_called
main.o 4
79 8cf841f3 PREVAILING_DEF main
85 8cf841f3 PREVAILING_DEF_IRONLY link_error
89 8cf841f3 RESOLVED_IR main_test
99 8cf841f3 PREVAILING_DEF_IRONLY inside_main

  What endian-ness are the ppc and hppa targets?

[Bug tree-optimization/45122] [4.6 Regression] -funsafe-loop-optimizations causes FAIL: gcc.c-torture/execute/pr27285.c execution

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  2011-01-31 
18:56:33 UTC ---
Created attachment 23185
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23185
gcc46-pr45122.patch

Here is a patch I've bootstrapped/regtested today on x86_64-linux and
i686-linux.  The only regressions on both of those targets are:
+FAIL: gcc.dg/tree-ssa/pr19210-1.c  (test for warnings, line 9)
+FAIL: gcc.dg/tree-ssa/pr19210-1.c  (test for warnings, line 12)
+FAIL: gcc.dg/tree-ssa/pr19210-1.c  (test for warnings, line 24)
+FAIL: gcc.dg/tree-ssa/pr19210-1.c  (test for warnings, line 27)
+FAIL: gcc.dg/tree-ssa/pr19210-2.c  (test for warnings, line 9)
+FAIL: gcc.dg/tree-ssa/pr19210-2.c  (test for warnings, line 12)
+FAIL: gcc.dg/tree-ssa/pr19210-2.c  (test for warnings, line 23)
+FAIL: gcc.dg/tree-ssa/pr19210-2.c  (test for warnings, line 26)
(none of the expected warnings have been emitted in those).

[Bug driver/47547] [4.5/4.6 Regression] WHOPR, can't use /dev/null as an output file

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2011-01/msg02329.htm
   ||l
Summary|WHOPR, can't use /dev/null  |[4.5/4.6 Regression] WHOPR,
   |as an output file   |can't use /dev/null as an
   ||output file

--- Comment #4 from H.J. Lu  2011-01-31 19:04:12 
UTC ---
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2011-01/msg02329.html

[Bug fortran/47519] Deferred-length string wrong results with character intrinsic functions

[pault at gcc dot gnu.org]

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

--- Comment #7 from Paul Thomas  2011-01-31 19:13:17 
UTC ---
Author: pault
Date: Mon Jan 31 19:13:13 2011
New Revision: 169444

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169444
Log:
2011-01-31  Paul Thomas  

PR fortran/47519
* trans-stmt.c (gfc_trans_allocate): Improve handling of
deferred character lengths with SOURCE.
* iresolve.c (gfc_resolve_repeat): Calculate character
length from source length and ncopies.
* dump-parse-tree.c (show_code_node): Show MOLD and SOURCE
expressions for ALLOCATE.


2011-01-31  Paul Thomas  

PR fortran/47519
* gfortran.dg/allocate_deferred_char_scalar_2.f03: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/allocate_deferred_char_scalar_2.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/dump-parse-tree.c
trunk/gcc/fortran/iresolve.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/testsuite/ChangeLog

[Bug lto/47274] [4.6 regression] ICE in lto_varpool_replace_node, at lto-symtab.c:306

[dave at hiauly1 dot hia.nrc.ca]

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

--- Comment #24 from dave at hiauly1 dot hia.nrc.ca 2011-01-31 19:35:15 UTC ---
>   What endian-ness are the ppc and hppa targets?

hppa is big.  I believe ppc is also big.

Dave

[Bug lto/47274] [4.6 regression] ICE in lto_varpool_replace_node, at lto-symtab.c:306

[davek at gcc dot gnu.org]

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

--- Comment #25 from Dave Korn  2011-01-31 19:40:52 
UTC ---
(In reply to comment #24)
> >   What endian-ness are the ppc and hppa targets?
> 
> hppa is big.  I believe ppc is also big.
> 
> Dave

  Probably the first time this code has been tested on a big endian machine. 
Maybe some field's being read wrong out of the symbols or something.

  If one of you could try the whole thing with "--save-temps -v -Wl,-v
-Wl,--verbose", and attach the various .o and @ arg files (some of which still
get left in /tmp) and the log of the build output, I may be able to run far
enough through the link with just a cross binutils to get to the symbol
resolution stage and debug it.

[Bug tree-optimization/47555] New: Huge memory usage when optimizing

[matthijs.douze at inria dot fr]

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

   Summary: Huge memory usage when optimizing
   Product: gcc
   Version: 4.4.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: matthijs.do...@inria.fr


Created attachment 23186
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23186
code that triggers the bug

Hello,

The attached code contains manually unrolled loops. When compiling it with 

cc -c bug2.c -O2

the memory usage of the cc1 process grows above 3.5 GB (before killing it). 

cc -v gives: 

Using built-in specs.
Target: x86_64-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
--with-arch-32=i586 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.5 (Debian 4.4.5-8) 

The bug does appear with cc -O2, cc -O3, not with cc -O1. gcc 4.3.2 also uses a
lot of memory but manages to compile it in the end.

Thanks

[Bug preprocessor/47549] -save-temps and -finput-charset= causing 'cc1.exe: error: failure to convert gbk to UTF-8'

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|driver  |preprocessor

--- Comment #2 from Andrew Pinski  2011-01-31 
20:08:24 UTC ---
>cc1: error: failure to convert gbk to UTF-8

The preprocessor is only really know how to convert UTF-8 to/from UTF16/32
LE/BE without the help from the host's iconv.

Your host's iconv is what is failing to do the conversion.  I doubt this is a
GCC bug.

[Bug c++/47416] [4.6 Regression] ICE in build_data_member_initialization, at cp/semantics.c:5509

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  2011-01-31 
20:19:31 UTC ---
Author: jakub
Date: Mon Jan 31 20:19:25 2011
New Revision: 169447

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169447
Log:
PR c++/47416
* semantics.c (build_data_member_initialization): Handle
STATEMENT_LIST always instead of just for CLEANUP_BODY.

* g++.dg/cpp0x/pr47416.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr47416.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

[Bug preprocessor/47549] -save-temps and -finput-charset= causing 'cc1.exe: error: failure to convert gbk to UTF-8'

[silver24k at gmail dot com]

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

--- Comment #3 from Yu Simin  2011-01-31 20:22:11 
UTC ---
(In reply to comment #2)
> >cc1: error: failure to convert gbk to UTF-8
> 
> The preprocessor is only really know how to convert UTF-8 to/from UTF16/32
> LE/BE without the help from the host's iconv.
> 
> Your host's iconv is what is failing to do the conversion.  I doubt this is a
> GCC bug.


But there is no such error when '-save-temps' is not used and the output object
file seems correct.

[Bug fortran/47455] [4.6 Regression][OOP] internal compiler error: in fold_convert_loc, at fold-const.c:2028

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.01.31 20:28:40
 Ever Confirmed|0   |1

--- Comment #6 from janus at gcc dot gnu.org 2011-01-31 20:28:40 UTC ---
(In reply to comment #3)
> RFC patch. Janus, what do you think?

I think I'd prefer the following version:

Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c(revision 169442)
+++ gcc/fortran/trans-expr.c(working copy)
@@ -3606,10 +3606,9 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol *
 x = f()
  where f is pointer valued, we have to dereference the result.  */
   if (!se->want_pointer && !byref
-  && (sym->attr.pointer || sym->attr.allocatable)
-  && !gfc_is_proc_ptr_comp (expr, NULL))
-se->expr = build_fold_indirect_ref_loc (input_location,
-se->expr);
+  && ((!comp && (sym->attr.pointer || sym->attr.allocatable))
+  || (comp && (comp->attr.pointer || comp->attr.allocatable
+se->expr = build_fold_indirect_ref_loc (input_location, se->expr);

   /* f2c calling conventions require a scalar default real function to
  return a double precision result.  Convert this back to default



This fixes all of the following variant of the test case, which was (partially)
miscompiled by both previous patches:


module class_t
  type :: tx
integer :: i
  end type
  type :: t
type(tx), pointer :: x
procedure(find_x), pointer :: ppc
  contains
procedure :: find_x
  end type
contains
  function find_x(this)
class(t), intent(in) :: this
type(tx), pointer :: find_x
find_x => null()
  end function find_x
end module

program test
  use class_t
  class(t),allocatable :: this
  procedure(find_x), pointer :: pp
  allocate(this)
  pp => find_x
  this%ppc => find_x
  this%x = find_x(this)! (1) ordinary function
  this%x = pp(this)! (2) procedure pointer
  this%x = this%ppc()  ! (3) PPC
  this%x = this%find_x()   ! (4) TBP
end

[Bug c++/29571] [4.3/4.4/4.5/4.6 regression] ICE with invalid static const member

[andreasmeier80 at gmx dot de]

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

andreasmeier80 at gmx dot de changed:

   What|Removed |Added

 CC||andreasmeier80 at gmx dot
   ||de

--- Comment #12 from andreasmeier80 at gmx dot de 2011-01-31 20:36:48 UTC ---
(In reply to comment #11)
> The ICE does not exist anymore at least in 4.6.

So a test should be added to the testsuite and here should be closed

[Bug c++/29571] [4.3/4.4/4.5/4.6 regression] ICE with invalid static const member

[paolo.carlini at oracle dot com]

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

--- Comment #13 from Paolo Carlini  2011-01-31 
20:50:16 UTC ---
Still, apparently it's a regression, thus, if we could identify which specific
patch fixed it and it turned out to be small enough, we could consider applying
it to 4_5-branch too, at least (if you ask me, I think it could also be closed
right away, after all it's just an ICE on invalid).

[Bug preprocessor/47549] -save-temps and -finput-charset= causing 'cc1.exe: error: failure to convert gbk to UTF-8'

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com  2011-01-31 20:51:56 UTC ---
The involvement of -save-temps makes me suspect the same underlying issue 
as bug 21521.

[Bug other/47029] fixincludes: the fix for c99 inlines in the glibc header files fixes function declarations as well as function definitions

[hkodungallur at gmail dot com]

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

--- Comment #2 from Hari Kodungallur  2011-01-31 
20:54:57 UTC ---
Created attachment 23187
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23187
/usr/include/sys/stat.h from a CentOS 5.5 server.

[Bug other/47029] fixincludes: the fix for c99 inlines in the glibc header files fixes function declarations as well as function definitions

[hkodungallur at gmail dot com]

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

--- Comment #3 from Hari Kodungallur  2011-01-31 
20:55:37 UTC ---
Sorry for the delay. I was on vacation. I've attached the stat.h header file.

[Bug c++/47416] [4.6 Regression] ICE in build_data_member_initialization, at cp/semantics.c:5509

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from Jakub Jelinek  2011-01-31 
20:58:28 UTC ---
Fixed.

[Bug rtl-optimization/38644] [4.3/4.4/4.5/4.6 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code

[joel at gcc dot gnu.org]

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

Joel Sherrill  changed:

   What|Removed |Added

  Known to fail||

--- Comment #33 from Joel Sherrill  2011-01-31 
21:26:08 UTC ---
Any chance this can get some attention before 4.6 branches?  Please.

[Bug fortran/47463] [OOP] ICE in gfc_add_component_ref

[burnus at gcc dot gnu.org]

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

--- Comment #9 from Tobias Burnus  2011-01-31 
21:42:29 UTC ---
(In reply to comment #6)
> > And the same without type-binding:
> > call init_comps(this, st, gr)
> > Error: Type mismatch in argument 'this' at (1); passed CLASS(flow_t) to
> > CLASS(grid_t)

I looked closer at that version.

a)  It works if one reverses the order of subroutines (all versions)

Rich: That's a work around, which is sufficient to compile the whole program.
Note: You need a gfortran, which includes Janus' patch from comment 8.


b) For the failing version. The formal argument in compare_actual_formal alias
compare_parameter is odd:

(gdb) p a->expr->ts.u.derived->name
$17 = 0x2cf0eae0 "__class_hydro_flow_Flow_t"
(gdb) p f->sym->ts.u.derived->name
$18 = 0x2cf0eac0 "__class_hydro_grid_Grid_t_a"
(gdb) p f->sym->name
$19 = 0x2ce40fb0 "this"

Namely, the formal argument has the right name, but it is associated with the
wrong typespec!

 * * *

Reduced test case:

module hydro_grid
  type :: grid_t
   contains
 procedure :: assign
 generic   :: assignment(=) => assign
  end type grid_t
  public :: grid_t
contains
  subroutine assign (this, that)
class(grid_t), intent(inout) :: this
class(grid_t), intent(in):: that
  end subroutine assign
end module hydro_grid

module hydro_flow
  use hydro_grid
  type :: flow_t
 class(grid_t), allocatable  :: gr ! Computation grid
  end type flow_t
contains
  subroutine init_params (this)
class(flow_t), intent(out) :: this
type(grid_t)   :: gr
   call init_comps(this, gr)
  end subroutine init_params
  subroutine init_comps (this, gr)
class(flow_t), intent(out) :: this
class(grid_t), intent(in)  :: gr
this%gr = gr
  end subroutine init_comps
end module hydro_flow

[Bug c/47556] New: x86: fails to take advantage of high-byte addressing mode

[jeremy at goop dot org]

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

   Summary: x86: fails to take advantage of high-byte addressing
mode
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jer...@goop.org


Created attachment 23188
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23188
Preprocessed file

When comparing two bytes in a 16-bit value, gcc introduces an unnecessary temp
register rather than just directly comparing the two byte halves.

In the attached source, the code generated for

  if (inc.head == inc.tail)
   goto out;

is
movzbl  %ah, %edx
cmpb%al, %dl

rather than simply
cmpb %ah, %al

If it did, then the code would be identical to the hand-written asm it is
intended to replace.

I'm compiling with "gcc -S -O2 -Wall halfreg-codegen.i"

The gcc version is the standard Fedora 14 package:
$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.5.1/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,lto --enable-plugin
--enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.5.1 20100924 (Red Hat 4.5.1-4) (GCC) 

$ rpm -q gcc
gcc-4.5.1-4.fc14.x86_64

[Bug target/40454] [4.4 regression] zlib is about 20% slower when compiled with GCC 4.4.1

[t.artem at mailcity dot com]

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

--- Comment #17 from Artem S. Tashkinov  
2011-01-31 21:46:29 UTC ---
At least on i686 platform the difference is marginal (GCC flags: -O2
-march=pentium-m -fomit-frame-pointer, Intel Core Gen 2 CPU):

GCC 3.4.6
real0m15.859s
user0m15.662s
sys 0m0.177s

GCC 4.5.2
real0m16.147s
user0m15.939s
sys 0m0.187s

I'm compressing a 400MB TAR archive containing miscellaneous binaries and
documentation. So the issue is m68060 specific.