date:20110121

[Bug tree-optimization/47391] read from const volatile incorrectly eliminated

2011-01-21 Thread jakub at gcc dot gnu.org

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.01.21 08:24:13
 CC||jakub at gcc dot gnu.org
  Component|c   |tree-optimization
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.6.0
 Ever Confirmed|0   |1

--- Comment #1 from Jakub Jelinek  2011-01-21 
08:24:13 UTC ---
Buggy const_value_known_p.

[Bug tree-optimization/47391] [4.5/4.6 Regression] read from const volatile incorrectly eliminated

2011-01-21 Thread jakub at gcc dot gnu.org

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
  Known to work||4.4.5
Summary|read from const volatile|[4.5/4.6 Regression] read
   |incorrectly eliminated  |from const volatile
   ||incorrectly eliminated
  Known to fail||4.5.2, 4.6.0

--- Comment #2 from Jakub Jelinek  2011-01-21 
08:28:20 UTC ---
4.5 actually miscompiles this too, 4.4 works.

[Bug tree-optimization/47391] [4.5/4.6 Regression] read from const volatile incorrectly eliminated

2011-01-21 Thread jakub at gcc dot gnu.org

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

--- Comment #3 from Jakub Jelinek  2011-01-21 
08:36:08 UTC ---
Created attachment 23058
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23058
gcc46-pr47391.patch

Untested fix.

[Bug c++/46831] [4.6 Regression][C++0x] Crash when it tries to do an invalid ICS with a conversion function template

2011-01-21 Thread jakub at gcc dot gnu.org

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug bootstrap/47215] [4.6 Regression] Failed to bootstrap

2011-01-21 Thread ktietz at gcc dot gnu.org

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

--- Comment #18 from Kai Tietz  2011-01-21 09:05:18 
UTC ---
Author: ktietz
Date: Fri Jan 21 09:05:14 2011
New Revision: 169080

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169080
Log:
2011-01-21  Kai Tietz  

PR bootstrap/47215
* decl.c (java_init_decl_processing): Remove
va_list_type_node related type initializations.

2011-01-21  Kai Tietz  

PR bootstrap/47215
* config/i386/i386.c (ix86_local_alignment): Handle
case for va_list_type_node is nil.
(ix86_canonical_va_list_type): Likewise.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/java/ChangeLog
trunk/gcc/java/decl.c

[Bug bootstrap/47215] [4.6 Regression] Failed to bootstrap

2011-01-21 Thread ktietz at gcc dot gnu.org

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

Kai Tietz  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED

--- Comment #19 from Kai Tietz  2011-01-21 09:08:06 
UTC ---
Reverted at revision 169080.

[Bug tree-optimization/47391] [4.5/4.6 Regression] read from const volatile incorrectly eliminated

2011-01-21 Thread ebotcazou at gcc dot gnu.org

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #4 from Eric Botcazou  2011-01-21 
09:19:42 UTC ---
> Untested fix.

tree_invariant_p_1 uses

  if (TREE_CONSTANT (t)
  || (TREE_READONLY (t) && !TREE_SIDE_EFFECTS (t)))
return true;

rather than TREE_THIS_VOLATILE.

[Bug tree-optimization/47391] [4.5/4.6 Regression] read from const volatile incorrectly eliminated

2011-01-21 Thread jakub at gcc dot gnu.org

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

--- Comment #5 from Jakub Jelinek  2011-01-21 
09:29:46 UTC ---
setup_one_parameter too, on the other side
tree_add_const_value_attribute_for_decl, set_mem_attributes_minus_bitpos and
get_callee_fndecl test TREE_READONLY && !TREE_THIS_VOLATILE.

[Bug middle-end/45422] [4.6 Regression] compile time increases 3x.

2011-01-21 Thread jakub at gcc dot gnu.org

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #28 from Jakub Jelinek  2011-01-21 
09:50:25 UTC ---
David, any progress with this?

[Bug debug/46102] [4.3/4.4/4.5/4.6 Regression] ICE: SIGSEGV in dwarf2out_finish (dwarf2out.c:8490) with -feliminate-dwarf2-dups when using precompiled headers

2011-01-21 Thread jakub at gcc dot gnu.org

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||jakub at gcc dot gnu.org

[Bug tree-optimization/47392] New: [4.6 Regression] PRE opportunity no longer found

2011-01-21 Thread rguenth at gcc dot gnu.org

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

   Summary: [4.6 Regression] PRE opportunity no longer found
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org


struct A
{
  int i;
};

struct B
{
  struct A a[2];
};

int i = 1;
struct B b = { 0, 3 };

static void
test ()
{
  if (b.a[0].i != i)// <- with this
{
  int t = b.a[0].i;
  b.a[0] = b.a[1];
  b.a[1].i = t;
}

  if (b.a[1].i == i)
__builtin_abort ();

  if (b.a[0].i == 0)// <- partially redundant
__builtin_abort ();
}

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

no longer finds the PRE b.a[0].i

[Bug debug/47308] Dwarf Error: Cannot find signatured DIE referenced from DIE at 0x2581 [in module D:\main64.exe]

2011-01-21 Thread ktietz at gcc dot gnu.org

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

Kai Tietz  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011.01.21 10:22:13
 Ever Confirmed|0   |1

--- Comment #4 from Kai Tietz  2011-01-21 10:22:13 
UTC ---
Hmm, can't reproduce issue with current 4.6.0 gcc. Could you please retest with
current version. It seems issue was already solved.

[Bug tree-optimization/47382] [4.6 Regression] g++.dg/ipa/devirt-d-1.C FAILs with -finline-functions

2011-01-21 Thread jamborm at gcc dot gnu.org

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

Martin Jambor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.01.21 10:30:47
 AssignedTo|unassigned at gcc dot   |jamborm at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Martin Jambor  2011-01-21 
10:30:47 UTC ---
Something goes wrong in gimple_fold_obj_type_ref_call.  So its mine.

[Bug tree-optimization/47392] [4.6 Regression] PRE opportunity no longer found

2011-01-21 Thread rguenth at gcc dot gnu.org

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||xfail
   Last reconfirmed||2011.01.21 11:00:07
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1
   Target Milestone|--- |4.6.0

--- Comment #1 from Richard Guenther  2011-01-21 
11:00:07 UTC ---
Mine, of course.  Soon to be with an XFAILed testcase.

[Bug driver/47390] [4.6 Regression] Linking with -export-dynamic broken

2011-01-21 Thread rguenth at gcc dot gnu.org

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.01.21 11:07:28
 CC||jsm28 at gcc dot gnu.org
   Target Milestone|--- |4.6.0
Summary|Linking with|[4.6 Regression] Linking
   |-export-dynamic broken  |with -export-dynamic broken
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-01-21 
11:07:28 UTC ---
-export-dynamic is a linker option, you have to use -Wl,-export-dynamic to
pass it to the linker via the gcc driver.

Joseph - 4.5 handled -export-dynamic by passing it through to the linker
(not exactly sure why).  Can we restore this behavior to avoid regressions?
If not, can we diagnose this invalid option then?  It seems to be passed
as -e xport-dynamic to the linker now, resulting in an undefined symbol
for me with a trivial hello-world.

Currently neither behavior seems to be documented btw.

[Bug rtl-optimization/47389] ICE: in calc_dfs_tree, at dominance.c:395 with -fno-combine-stack-adjustments -fno-dse -fno-tree-forwprop

2011-01-21 Thread rguenth at gcc dot gnu.org

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.01.21 11:09:02
  Component|tree-optimization   |rtl-optimization
 Ever Confirmed|0   |1

--- Comment #3 from Richard Guenther  2011-01-21 
11:09:02 UTC ---
Confirmed.

[Bug c++/47388] [4.6 Regression] ICE: in begin_for_stmt, at cp/semantics.c:863 with -fno-for-scope and for(;;) inside a template

2011-01-21 Thread rguenth at gcc dot gnu.org

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |4.6.0

[Bug middle-end/47386] Wrong warning: ‘w.dim[2].stride’ may be used uninitialized in this function [-Wuninitialized]

2011-01-21 Thread rguenth at gcc dot gnu.org

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.01.21 11:12:28
 Ever Confirmed|0   |1

--- Comment #2 from Richard Guenther  2011-01-21 
11:12:28 UTC ---
Confirmed.

[Bug middle-end/47383] ivopts miscompiles Pmode != ptr_mode

2011-01-21 Thread pinskia at gmail dot com

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

--- Comment #6 from pinskia at gmail dot com  
2011-01-21 11:43:45 UTC ---
Sent from my Palm Pre on AT&T
On Jan 20, 2011 21:34, hjl.tools at gmail dot com
 wrote: 

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



--- Comment #4 from H.J. Lu  2011-01-21
05:33:53 UTC ---

(In reply to comment #3)

> The ivopts pass transforms

> 

> 

>   unsigned int D.2715;

>   unsigned int D.2716;

> ...

>   D.2715_43 = (unsigned int) elems_3(D);

>   D.2716_42 = D.2715_43 + 4294967295;

>   n_49 = (int) D.2716_42;

> 

> leads o the wrong result when Pmode != unsigned int. Adding

> -fno-ivopts fixes the bug.

> 



This is OK due to cast to int. But



  long unsigned int D.2757;

  long unsigned int D.2749;

  long unsigned int D.2750;

  unsigned int ivtmp.20;

  int D.2748;

  unsigned int ivtmp.17;

...

  D.2749_6 = (long unsigned int) prephitmp.8_18;

  D.2750_34 = ivtmp.17_28 - D.2749_6;

  MEM[symbol: heap, index: D.2750_34, step: 8, offset: 2296B] = n_11;



Mem here should have been rejected.


looks wrong since it assumes D.2750_34 can be negative. But

D.2750_34 is unsigned. It won't work when ptr_mode == unsigned

and Pmode is unsigned long long.

[Bug debug/47393] New: g++.dg/debug/dwarf2/icf.C FAILs on IRIX

2011-01-21 Thread ro at gcc dot gnu.org

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

   Summary: g++.dg/debug/dwarf2/icf.C FAILs on IRIX
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: ccout...@google.com
  Host: mips-sgi-irix6.5, mips-sgi-irix5.3
Target: mips-sgi-irix6.5, mips-sgi-irix5.3
 Build: mips-sgi-irix6.5, mips-sgi-irix5.3


On both IRIX 5.3 and 6.5, the g++.dg/debug/dwarf2/icf.C test partially fails:

FAIL: g++.dg/debug/dwarf2/icf.C scan-assembler .section.*.debug_dcall
FAIL: g++.dg/debug/dwarf2/icf.C scan-assembler New caller
FAIL: g++.dg/debug/dwarf2/icf.C scan-assembler Caller DIE offset
FAIL: g++.dg/debug/dwarf2/icf.C scan-assembler Callee DIE offset

In icf.s (attached), one can see that the .debug_call section is missing
completely.

[Bug debug/47393] g++.dg/debug/dwarf2/icf.C FAILs on IRIX

2011-01-21 Thread ro at gcc dot gnu.org

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

--- Comment #1 from Rainer Orth  2011-01-21 11:48:44 UTC 
---
Created attachment 23059
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23059
assembler output (IRIX 6.5, N32)

[Bug debug/47393] g++.dg/debug/dwarf2/icf.C FAILs on IRIX

2011-01-21 Thread ro at gcc dot gnu.org

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0
  Known to fail||4.5.3, 4.6.0

[Bug c++/44641] Generated constructors and destructors get wrong debug location when a typedef uses a forward declaration of the type before the definition

2011-01-21 Thread ro at gcc dot gnu.org

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #23 from Rainer Orth  2011-01-21 11:53:44 
UTC ---
g++.dg/debug/dwarf2/lineno-simple1.C also FAILs on IRIX 6.5, as does
g++.dg/debug/dwarf2/pr46527.C for what seems to be the same reason:

FAIL: g++.dg/debug/dwarf2/lineno-simple1.C scan-assembler
main:[^t]*(t.(fnstart|frame|mask|file)[^t]*)*t[^:]+:12n

The code around main looks like this:

 #
/vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/debug/dwarf2/lineno-
simple1.C:12
.loc 1 12 0
.setnomips16
.entmain
.type   main, @function
main:
.frame  $fp,16,$31  # vars= 0, regs= 1/0, args= 0, gp= 0
.mask   0x4000,-8
.fmask  0x,0

I'm attaching the complete assembler output.

[Bug c++/44641] Generated constructors and destructors get wrong debug location when a typedef uses a forward declaration of the type before the definition

2011-01-21 Thread ro at gcc dot gnu.org

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

--- Comment #24 from Rainer Orth  2011-01-21 11:54:34 
UTC ---
Created attachment 23060
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23060
IRIX 6.5 (N32) assembler output

[Bug debug/47308] Dwarf Error: Cannot find signatured DIE referenced from DIE at 0x2581 [in module D:\main64.exe]

2011-01-21 Thread pluto at agmk dot net

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

--- Comment #5 from Pawel Sikora  2011-01-21 12:23:04 
UTC ---
(In reply to comment #4)
> Hmm, can't reproduce issue with current 4.6.0 gcc. Could you please retest 
> with
> current version. It seems issue was already solved.

i'm still see the problem. probably it's some configuration detail to expose
it.

my gcc mingw64 crosscompiler runs on linux.

$ /local/devel/toolchain46/x86_64-pc-mingw32/bin/x86_64-pc-mingw32-g++ -v
Using built-in specs.
COLLECT_GCC=/local/devel/toolchain46/x86_64-pc-mingw32/bin/x86_64-pc-mingw32-g++
COLLECT_LTO_WRAPPER=/local/devel/toolchain46/x86_64-pc-mingw32.host64/lib/gcc/x86_64-pc-mingw32/4.6.0/lto-wrapper
Target: x86_64-pc-mingw32
Configured with: ../configure --target=x86_64-pc-mingw32 --with-arch=core2
--prefix=/local/devel/toolchain46/x86_64-pc-mingw32.host64
--with-sysroot=/local/devel/toolchain46/x86_64-pc-mingw32.host64
--libdir=/local/devel/toolchain46/x86_64-pc-mingw32.host64/lib
--libexecdir=/local/devel/toolchain46/x86_64-pc-mingw32.host64/lib
--with-slibdir=/local/devel/toolchain46/x86_64-pc-mingw32.host64/lib
--with-gmp-include=/home/users/pluto/alatek/toolchain/trunk/gcc-math-runtime/include
--with-gmp-lib=/home/users/pluto/alatek/toolchain/trunk/gcc-math-runtime/lib
--with-mpfr-include=/home/users/pluto/alatek/toolchain/trunk/gcc-math-runtime/include
--with-mpfr-lib=/home/users/pluto/alatek/toolchain/trunk/gcc-math-runtime/lib
--with-mpc-include=/home/users/pluto/alatek/toolchain/trunk/gcc-math-runtime/include
--with-mpc-lib=/home/users/pluto/alatek/toolchain/trunk/gcc-math-runtime/lib
--disable-multilib --disable-nls --disable-libgomp --disable-libmudflap
--disable-libquadmath --disable-libssp --enable-tls
--enable-libstdcxx-allocator=mt --enable-cxx-flags='-O2 -mcld -gdwarf-4 -g2'
--disable-libstdcxx-pch --disable-lto --disable-plugin --enable-c99
--enable-long-long --disable-win32-registry --enable-threads=win32
--enable-sjlj-exceptions --enable-shared --enable-fully-dynamic-string
--enable-__cxa_atexit --enable-languages=c,c++
--enable-checking=yes,df,rtl,tree --disable-symvers --with-long-double-128
--disable-cld --disable-bootstrap
Thread model: win32
gcc version 4.6.0 20110121 (experimental) (GCC)

$ /local/devel/toolchain46/x86_64-pc-mingw32/bin/x86_64-pc-mingw32-as --version
GNU assembler (Linux/GNU Binutils) 2.21.51.0.6.20110118


interesting 'bad register' info in .debug_frame section:

$ /local/devel/toolchain46/x86_64-pc-mingw32/bin/x86_64-pc-mingw32-objdump
--dwarf=frames main.o 

main.o: file format pe-x86-64

Contents of the .debug_frame section:

 0014  CIE
  Version:   1
  Augmentation:  ""
  Code alignment factor: 1
  Data alignment factor: -8
  Return address column: 16

  DW_CFA_def_cfa: r7 (rsp) ofs 8
  DW_CFA_offset: r16 (rip) at cfa-8
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop

0018 0024  FDE cie= pc=..002e
  DW_CFA_advance_loc: 1 to 0001
  DW_CFA_def_cfa_offset: 16
  DW_CFA_offset: r6 (rbp) at cfa-16
  DW_CFA_advance_loc: 3 to 0004
  DW_CFA_def_cfa_register: r6 (rbp)
  DW_CFA_advance_loc: 41 to 002d
  DW_CFA_def_cfa: r7 (rsp) ofs 8
  DW_CFA_restore: r6 (rbp)
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop

0040 0024  FDE cie= pc=002e..005c
  DW_CFA_advance_loc: 1 to 002f
  DW_CFA_def_cfa_offset: 16
  DW_CFA_offset: r6 (rbp) at cfa-16
  DW_CFA_advance_loc: 3 to 0032
  DW_CFA_def_cfa_register: r6 (rbp)
  DW_CFA_advance_loc: 41 to 005b
  DW_CFA_def_cfa: r7 (rsp) ofs 8
  DW_CFA_restore: r6 (rbp)
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop

0068 007c  FDE cie= pc=005c..0270
  DW_CFA_advance_loc: 1 to 005d
  DW_CFA_def_cfa_offset: 16
  DW_CFA_offset: r6 (rbp) at cfa-16
  DW_CFA_advance_loc: 2 to 005f
  DW_CFA_def_cfa_offset: 24
  DW_CFA_offset: r15 (r15) at cfa-24
  DW_CFA_advance_loc: 2 to 0061
  DW_CFA_def_cfa_offset: 32
  DW_CFA_offset: r14 (r14) at cfa-32
  DW_CFA_advance_loc: 2 to 0063
  DW_CFA_def_cfa_offset: 40
  DW_CFA_offset: r13 (r13) at cfa-40
  DW_CFA_advance_loc: 2 to 0065
  DW_CFA_def_cfa_offset: 48
  DW_CFA_offset: r12 (r12) at cfa-48
  DW_CFA_advance_loc: 1 to 0066
  DW_CFA_def_cfa_offset: 56
  DW_CFA_offset: r5 (rdi) at cfa-56
  DW_CFA_advance_loc: 1 to 0067
  DW_CFA_def_cfa_offset: 64
  DW_CFA_offset: r4 (rsi) at cfa-64
  DW_CFA_advance_loc: 1 to 0068
  DW_CFA_def_cfa_offset: 72
  DW_CFA_offset: r3 (rbx) at cfa-72
  DW_CFA_advance_loc: 7 to 006f
  DW_CFA_def_cfa_offset: 416
  DW_CFA_advance_loc: 8 to 0077
  DW_CFA_def_cfa: r6 (rbp) ofs 288
  DW_CFA_advance_loc1: 118 to 00ed
  DW_CFA_offset: r32 (xmm15) at cfa-96
  DW_CFA_offset: r31 (xmm14) at cfa-112
  DW_CFA_offset: r30 (xmm13) at cfa-128
  DW_CFA_offset: r29 (xmm12) at cfa-144
  DW_CFA_offset: r28 (xmm11) at cfa-160
  DW_CFA_offset:

[Bug fortran/47394] New: Internal compiler error when error count limit is reached

2011-01-21 Thread thenlich at users dot sourceforge.net

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

   Summary: Internal compiler error when error count limit is
reached
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: thenl...@users.sourceforge.net


When compiling a program with -fmax-errors=n and the n-th error is encountered,
an internal compiler error occurs and the gfortran command exits with status 4.

Expected result is: the compiler should report the abortion and exit with the
status code according to the error encountered, like the C compiler does.

Example:
$ echo x > test.f
$ gfortran -fmax-errors=1 test.f
test.f:1.1:

x
 1
Error: Non-numeric character in statement label at (1)
Fatal Error: Error count reached limit of 1.
gfortran.exe: internal compiler error: Aborted (program f951)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

$ echo $?
4

[Bug tree-optimization/47392] [4.6 Regression] PRE opportunity no longer found

2011-01-21 Thread rguenth at gcc dot gnu.org

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

Richard Guenther  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #2 from Richard Guenther  2011-01-21 
12:35:52 UTC ---
We don't do insertion because the redundancy is not along an edge that
is supposed to be optimize_edge_for_speed_p ().  But frequencies and
counts are the same as on the 4.5 branch!?  So it's probably the
optimize_function_for_size_p (main) issue again...  I wonder how many
wrong-code tortures no longer test what they used to test because of
this ...

Marking main () with attribute((hot)) makes PRE functional again.

Honza, I think the testing issue is a real problem for existing testcases.

[Bug middle-end/47383] ivopts miscompiles Pmode != ptr_mode

2011-01-21 Thread rguenth at gcc dot gnu.org

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

--- Comment #7 from Richard Guenther  2011-01-21 
12:38:22 UTC ---
(In reply to comment #6)
> Sent from my Palm Pre on AT&T
> On Jan 20, 2011 21:34, hjl.tools at gmail dot com
>  wrote: 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47383
> 
> 
> 
> --- Comment #4 from H.J. Lu  2011-01-21
> 05:33:53 UTC ---
> 
> (In reply to comment #3)
> 
> > The ivopts pass transforms
> 
> > 
> 
> > 
> 
> >   unsigned int D.2715;
> 
> >   unsigned int D.2716;
> 
> > ...
> 
> >   D.2715_43 = (unsigned int) elems_3(D);
> 
> >   D.2716_42 = D.2715_43 + 4294967295;
> 
> >   n_49 = (int) D.2716_42;
> 
> > 
> 
> > leads o the wrong result when Pmode != unsigned int. Adding
> 
> > -fno-ivopts fixes the bug.
> 
> > 
> 
> 
> 
> This is OK due to cast to int. But
> 
> 
> 
>   long unsigned int D.2757;
> 
>   long unsigned int D.2749;
> 
>   long unsigned int D.2750;
> 
>   unsigned int ivtmp.20;
> 
>   int D.2748;
> 
>   unsigned int ivtmp.17;
> 
> ...
> 
>   D.2749_6 = (long unsigned int) prephitmp.8_18;
> 
>   D.2750_34 = ivtmp.17_28 - D.2749_6;
> 
>   MEM[symbol: heap, index: D.2750_34, step: 8, offset: 2296B] = n_11;
> 
> 
> 
> Mem here should have been rejected.
> 
> 
> looks wrong since it assumes D.2750_34 can be negative. But

sizetype values are sign-extended.

> D.2750_34 is unsigned. It won't work when ptr_mode == unsigned
> 
> and Pmode is unsigned long long.

[Bug debug/47308] Dwarf Error: Cannot find signatured DIE referenced from DIE at 0x2581 [in module D:\main64.exe]

2011-01-21 Thread ktietz at gcc dot gnu.org

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

--- Comment #6 from Kai Tietz  2011-01-21 12:39:13 
UTC ---
I don't see an obvious difference to my toolchain (beside I use a cygwin
cross-compiler). But such issues could be related also to used binutils
version. I am using:
$x86_64-pc-mingw32-ld.exe -v
 GNU ld (GNU Binutils) 2.21.51.20110114

[Bug tree-optimization/47392] [4.6 Regression] PRE opportunity no longer found

2011-01-21 Thread rguenth at gcc dot gnu.org

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

--- Comment #3 from Richard Guenther  2011-01-21 
12:45:56 UTC ---
We could also always perform PRE when there is one insertion and one
elimination, assuming the size cost cancels.

[Bug c/47362] genconstants.c:68: undefined reference to `_ __chkstk_ms' on 01/15/2011 snapshot

2011-01-21 Thread michael.a.richmond at nasa dot gov

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

Michael Richmond  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Michael Richmond  
2011-01-21 12:48:37 UTC ---
I inadvertently used the MinGW g++ compiler. The problem went away when I
installed the Cygwin g++ compiler.

[Bug tree-optimization/47391] [4.5/4.6 Regression] read from const volatile incorrectly eliminated

2011-01-21 Thread jakub at gcc dot gnu.org

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

--- Comment #6 from Jakub Jelinek  2011-01-21 
12:57:55 UTC ---
Author: jakub
Date: Fri Jan 21 12:57:52 2011
New Revision: 169084

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169084
Log:
PR tree-optimization/47391
* varpool.c (const_value_known_p): Return false if
decl is volatile.

* gcc.dg/pr47391.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr47391.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/varpool.c

[Bug middle-end/45566] [4.5/4.6 Regression] ICE: in convert_to_eh_region_ranges, at except.c:2446 with -freorder-blocks-and-partition -fnon-call-exceptions -fprofile-use

2011-01-21 Thread jakub at gcc dot gnu.org

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  2011-01-21 
12:58:48 UTC ---
Created attachment 23061
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23061
gcc46-pr45566.patch

Untested fix.

[Bug tree-optimization/47391] [4.5 Regression] read from const volatile incorrectly eliminated

2011-01-21 Thread jakub at gcc dot gnu.org

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

Jakub Jelinek  changed:

   What|Removed |Added

  Known to work||4.6.0
   Target Milestone|4.6.0   |4.5.3
Summary|[4.5/4.6 Regression] read   |[4.5 Regression] read from
   |from const volatile |const volatile incorrectly
   |incorrectly eliminated  |eliminated
  Known to fail|4.6.0   |

--- Comment #7 from Jakub Jelinek  2011-01-21 
13:02:29 UTC ---
Fixed on the trunk so far.

[Bug tree-optimization/47392] [4.6 Regression] PRE opportunity no longer found

2011-01-21 Thread jakub at gcc dot gnu.org

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  2011-01-21 
13:04:41 UTC ---
I agree that for testing this is an issue, but for real-world code probably
not.
If you remove static for test, does it work properly?

[Bug tree-optimization/47355] [4.6 Regression] ICE: verify_ssa failed with -O2 -fipa-cp-clone

2011-01-21 Thread jakub at gcc dot gnu.org

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug other/47395] New: the tree code WIDEN_MULT_MINUS_EXPR has a mismatching name

2011-01-21 Thread adam.rak at streamnovation dot com

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

   Summary: the tree code WIDEN_MULT_MINUS_EXPR has a mismatching
name
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: adam@streamnovation.com


the lowercase name has a "plus" where it should be "minus". At least I think,
because it breaks my code quite well. 

DEFTREECODE (WIDEN_MULT_MINUS_EXPR, "widen_mult_plus_expr", tcc_expression, 3)

fortunately it is trivial to correct, and doesn't cause real problems in GCC
itself.

[Bug fortran/47394] Internal compiler error when error count limit is reached

2011-01-21 Thread burnus at gcc dot gnu.org

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #1 from Tobias Burnus  2011-01-21 
13:17:55 UTC ---
This seems to be a Windows / MinGW specific problem caused by the way gfortran
returns when a fatal error occurs.

gfortran just calls
   exit(3);

which according to Kai matches Windows' abort status code.

The proper way seems to use the system.h's exit codes: FATAL_EXIT_CODE,
EXIT_SUCCESS and EXIT_FAILURE instead of hard-coded error codes.


The error message itself is printed by the driver (gcc.c, gfortran.exe) and not
by the proper compiler (f951.exe).


Draft patch:

diff --git a/gcc/fortran/error.c b/gcc/fortran/error.c
index 3092828..8520e2a 100644
--- a/gcc/fortran/error.c
+++ b/gcc/fortran/error.c
@@ -941,3 +941,3 @@ gfc_error_now (const char *gmsgid, ...)
   if (flag_fatal_errors)
-exit (1);
+exit (EXIT_FAILURE);
 }
@@ -958,3 +958,3 @@ gfc_fatal_error (const char *gmsgid, ...)

-  exit (3);
+  exit (FATAL_EXIT_CODE);
 }
@@ -1021,3 +1021,3 @@ gfc_error_check (void)
   if (flag_fatal_errors)
-   exit (1);
+   exit (EXIT_FAILURE);
 }
diff --git a/gcc/fortran/scanner.c b/gcc/fortran/scanner.c
index c226bae..d4388e0 100644
--- a/gcc/fortran/scanner.c
+++ b/gcc/fortran/scanner.c
@@ -1870,3 +1870,3 @@ include_line (gfc_char_t *line)
   if (load_file (filename, NULL, false) == FAILURE)
-exit (1);
+exit (EXIT_FAILURE);

@@ -2074,3 +2074,3 @@ gfc_new_file (void)

-  exit (0);
+  exit (EXIT_SUCCESS);
 #endif

[Bug c++/47396] New: Link error when declare a constant reference to a class or struct static const member!

2011-01-21 Thread aishen944 at 163 dot com

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

   Summary: Link error when declare a constant reference to a
class or struct static const member!
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: aishen...@163.com


if code like this:
struct test
{
 static const int uri = 10;
};

int main(void)
{
 const int &ref = test::uri;
}

errors:
[qiang@chenyq-fedora ~]$ g++ test.cc  
/tmp/ccwzRULi.o: In function `main':
test.cc:(.text+0x8): undefined reference to `test::uri'
collect2: ld returned 1 exit status

[Bug debug/47308] Dwarf Error: Cannot find signatured DIE referenced from DIE at 0x2581 [in module D:\main64.exe]

2011-01-21 Thread pluto at agmk dot net

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

--- Comment #7 from Pawel Sikora  2011-01-21 13:37:21 
UTC ---
(In reply to comment #6)
> I don't see an obvious difference to my toolchain (beside I use a cygwin
> cross-compiler). But such issues could be related also to used binutils
> version. I am using:
> $x86_64-pc-mingw32-ld.exe -v
>  GNU ld (GNU Binutils) 2.21.51.20110114

could you compile on cygwin the assembly source from testcase
and check compiled object with objdump against dwarf corruption?
('DW_CFA_restore: bad register')

[Bug c++/47396] Link error when declare a constant reference to a class or struct static const member!

2011-01-21 Thread jakub at gcc dot gnu.org

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  2011-01-21 
13:38:28 UTC ---
That's a user error.  In C++ you need to provide a definition for static const
data members, even when it is initialized in its declaration.
Just add:
const int test::uri;
somewhere.

[Bug debug/47308] Dwarf Error: Cannot find signatured DIE referenced from DIE at 0x2581 [in module D:\main64.exe]

2011-01-21 Thread ktietz at gcc dot gnu.org

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

--- Comment #8 from Kai Tietz  2011-01-21 13:41:57 
UTC ---
Well, I would, if I could extract .xz attachments. Could you re-attach it as
bz2?

[Bug libfortran/47375] GETLOG not threadsafe, causes warnings/wrong-code with static linking

2011-01-21 Thread jb at gcc dot gnu.org

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

Janne Blomqvist  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.01.21 13:44:37
 CC||jb at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #5 from Janne Blomqvist  2011-01-21 13:44:37 
UTC ---
Assigning to myself. The linking issues is probably not solvable, but at least
we should use the _r() functions if available.

[Bug c++/47396] Link error when declare a constant reference to a class or struct static const member!

2011-01-21 Thread aishen944 at 163 dot com

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

ChenYongqiang  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |

--- Comment #2 from ChenYongqiang  2011-01-21 
13:45:37 UTC ---
but like this:

struct test
{
static const int i = 0;
};

int main(void)
{
const unsigned int &m = test::i;
}


no link errors why???

[Bug c++/47396] Link error when declare a constant reference to a class or struct static const member!

2011-01-21 Thread redi at gcc dot gnu.org

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #3 from Jakub Jelinek  2011-01-21 
13:49:32 UTC ---
GCC bugzilla is not a place to learn C++, just read the standard, in particular
[class.static.data]/4:
"If a static data member is of const integral or const enumeration type, its
declaration in the class definition can specify a constant-initializer which
shall be an integral constant expression (5.19). In that case, the member can
appear in integral constant expressions within its scope. The member shall
still be defined in a namespace scope if it is used in the program and the
namespace scope definition shall not contain an initializer."

--- Comment #4 from Jonathan Wakely  2011-01-21 
13:49:32 UTC ---
(In reply to comment #2)
> but like this:
> 
> struct test
> {
> static const int i = 0;
> };
> 
> int main(void)
> {
> const unsigned int &m = test::i;
> }
> 
> 
> no link errors why???

a temporary (of type unsigned) has to be created, and the reference binds to
the temporary, not to test::i

This is invalid, please don't reopen it

[Bug c++/47396] Link error when declare a constant reference to a class or struct static const member!

2011-01-21 Thread jakub at gcc dot gnu.org

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #3 from Jakub Jelinek  2011-01-21 
13:49:32 UTC ---
GCC bugzilla is not a place to learn C++, just read the standard, in particular
[class.static.data]/4:
"If a static data member is of const integral or const enumeration type, its
declaration in the class definition can specify a constant-initializer which
shall be an integral constant expression (5.19). In that case, the member can
appear in integral constant expressions within its scope. The member shall
still be defined in a namespace scope if it is used in the program and the
namespace scope definition shall not contain an initializer."

[Bug debug/47308] Dwarf Error: Cannot find signatured DIE referenced from DIE at 0x2581 [in module D:\main64.exe]

2011-01-21 Thread pluto at agmk dot net

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

Pawel Sikora  changed:

   What|Removed |Added

  Attachment #22975|0   |1
is obsolete||

--- Comment #9 from Pawel Sikora  2011-01-21 13:51:37 
UTC ---
Created attachment 23062
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23062
testcase

testcase repacked.

[Bug middle-end/47397] New: GCC not correctly define alignment of memory in AVX mode

2011-01-21 Thread hjl.tools at gmail dot com

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

   Summary: GCC not correctly define alignment of memory in AVX
mode
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


In

---
double a[NUM], b[NUM];

void foo()
{
   for (i = 0; i < N; i++)
   {
  b[i] = a[i+2] * 10.0;
   }
}
---

both "a" and "b" are aligned at 32byte/256bits. However, RTL dump from
"-O3 -mavx" shows that alignment of a[i+2] is 64bits instead of 128bits
as expected:

(insn 39 38 40 4 (set (mem:V4DF (plus:DI (reg/f:DI 95)
(reg:DI 80 [ ivtmp.21 ])) [2 MEM[symbol: b, index: ivtmp.21_20,
offset: 16B]+0 S32 A64])
(unspec:V4DF [
(reg:V4DF 93)
] UNSPEC_MOVU)) align.c:64 -1
 (nil))

[Bug tree-optimization/47365] [4.5/4.6 Regression] wrong code with -O -ftree-pre

2011-01-21 Thread rguenth at gcc dot gnu.org

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

--- Comment #4 from Richard Guenther  2011-01-21 
14:02:45 UTC ---
Author: rguenth
Date: Fri Jan 21 14:02:41 2011
New Revision: 169089

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169089
Log:
2011-01-21  Richard Guenther  

PR tree-optimization/47365
* tree-ssa-sccvn.h (vn_lookup_kind): Declare.
(vn_reference_lookup_pieces): Adjust.
(vn_reference_lookup): Likewise.
* tree-ssa-sccvn.c (vn_walk_kind): New static global.
(vn_reference_lookup_3): Only look through kills if in
VN_WALKREWRITE mode.
(vn_reference_lookup_pieces): Adjust.
(vn_reference_lookup): Likewise.
(visit_reference_op_load): Likewise.
(visit_reference_op_store): Likewise.
* tree-ssa-pre.c (phi_translate_1): Use VN_WALK mode.
(compute_avail): Likewise.
(eliminate): Likewise.

* gcc.dg/torture/pr47365.c: New testcase.
* gcc.dg/tree-ssa/pr47392.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr47365.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr47392.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-pre.c
trunk/gcc/tree-ssa-sccvn.c
trunk/gcc/tree-ssa-sccvn.h

[Bug c++/14404] static const integral member cannot be passed as const reference

2011-01-21 Thread redi at gcc dot gnu.org

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||aishen944 at 163 dot com

--- Comment #9 from Jonathan Wakely  2011-01-21 
14:04:20 UTC ---
*** Bug 47396 has been marked as a duplicate of this bug. ***

[Bug middle-end/47397] Alignment of array element is incorrect in AVX mode

2011-01-21 Thread hjl.tools at gmail dot com

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

--- Comment #1 from H.J. Lu  2011-01-21 14:05:21 
UTC ---
The bug seems in get_object_alignment.

[Bug tree-optimization/47392] [4.6 Regression] PRE opportunity no longer found

2011-01-21 Thread rguenth at gcc dot gnu.org

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

Richard Guenther  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID

--- Comment #5 from Richard Guenther  2011-01-21 
14:06:30 UTC ---
Yes, without static it works.

Not a bug.

[Bug debug/47308] Dwarf Error: Cannot find signatured DIE referenced from DIE at 0x2581 [in module D:\main64.exe]

2011-01-21 Thread ktietz at gcc dot gnu.org

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

Kai Tietz  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #10 from Kai Tietz  2011-01-21 14:05:31 
UTC ---
(In reply to comment #9)
> Created attachment 23062 [details]
> testcase
> 
> testcase repacked.

Thanks, I can confirm this issue.
Interesting is that my old gdb is able to read it. It has something to do with
used register tables.

[Bug c++/47396] Link error when declare a constant reference to a class or struct static const member!

2011-01-21 Thread redi at gcc dot gnu.org

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|INVALID |DUPLICATE

--- Comment #5 from Jonathan Wakely  2011-01-21 
14:04:20 UTC ---
actually just for completeness I'm going to mark this as a duplicate of PR
14404

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

[Bug tree-optimization/47365] [4.5/4.6 Regression] wrong code with -O -ftree-pre

2011-01-21 Thread rguenth at gcc dot gnu.org

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

--- Comment #5 from Richard Guenther  2011-01-21 
14:05:03 UTC ---
Author: rguenth
Date: Fri Jan 21 14:05:00 2011
New Revision: 169090

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169090
Log:
2011-01-21  Richard Guenther  

PR tree-optimization/47365
* tree-ssa-sccvn.h (vn_lookup_kind): Declare.
(vn_reference_lookup_pieces): Adjust.
(vn_reference_lookup): Likewise.
* tree-ssa-sccvn.c (vn_walk_kind): New static global.
(vn_reference_lookup_3): Only look through kills if in
VN_WALKREWRITE mode.
(vn_reference_lookup_pieces): Adjust.
(vn_reference_lookup): Likewise.
(visit_reference_op_load): Likewise.
(visit_reference_op_store): Likewise.
* tree-ssa-pre.c (phi_translate_1): Use VN_WALK mode.
(compute_avail): Likewise.
(eliminate): Likewise.

* gcc.dg/torture/pr47365.c: New testcase.
* gcc.dg/tree-ssa/pr47392.c: Likewise.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/torture/pr47365.c
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/tree-ssa/pr47392.c
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
branches/gcc-4_5-branch/gcc/tree-ssa-pre.c
branches/gcc-4_5-branch/gcc/tree-ssa-sccvn.c
branches/gcc-4_5-branch/gcc/tree-ssa-sccvn.h

[Bug other/47395] the tree code WIDEN_MULT_MINUS_EXPR has a mismatching name

2011-01-21 Thread rguenth at gcc dot gnu.org

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.01.21 14:09:55
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-01-21 
14:09:55 UTC ---
Mine.

[Bug tree-optimization/47365] [4.5/4.6 Regression] wrong code with -O -ftree-pre

2011-01-21 Thread rguenth at gcc dot gnu.org

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #6 from Richard Guenther  2011-01-21 
14:06:55 UTC ---
Fixed.

[Bug middle-end/47397] Alignment of array element is incorrect in AVX mode

2011-01-21 Thread hjl.tools at gmail dot com

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

--- Comment #2 from H.J. Lu  2011-01-21 14:11:59 
UTC ---
This testcase can compile

---
double a[1024], b[1024];

void foo()
{
  int i;
   for (i = 0; i < sizeof (a)/sizeof (a[0]) ; i++)
   {
  b[i] = a[i+2] * 10.0;
   }
}
---

[Bug other/47395] the tree code WIDEN_MULT_MINUS_EXPR has a mismatching name

2011-01-21 Thread rguenth at gcc dot gnu.org

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

--- Comment #2 from Richard Guenther  2011-01-21 
14:14:16 UTC ---
Author: rguenth
Date: Fri Jan 21 14:14:12 2011
New Revision: 169092

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169092
Log:
2011-01-21  Richard Guenther  

PR middle-end/47395
* tree.def (WIDEN_MULT_MINUS_EXPR): Fix printed name.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree.def

[Bug middle-end/47397] Alignment of array element is incorrect in AVX mode

2011-01-21 Thread rguenth at gcc dot gnu.org

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

--- Comment #3 from Richard Guenther  2011-01-21 
14:15:49 UTC ---
Investigating.

[Bug middle-end/47397] Alignment of array element is not optimal in AVX mode due to use of TARGET_MEM_REFs

2011-01-21 Thread rguenth at gcc dot gnu.org

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.01.21 14:21:20
Summary|Alignment of array element  |Alignment of array element
   |is incorrect in AVX mode|is not optimal in AVX mode
   ||due to use of
   ||TARGET_MEM_REFs
 Ever Confirmed|0   |1

--- Comment #4 from Richard Guenther  2011-01-21 
14:21:20 UTC ---
This is because index is unknown in both

  vect_var_.13_20 = MEM[symbol: a, index: ivtmp.24_12, offset: 16B];

and

  MEM[symbol: b, index: ivtmp.24_12, offset: 0B] = vect_var_.14_22;

we don't have a way to record that ivtmp.24_12 is {0, +, 32} for
RTL expansion.  Which means that IVOPTs is responsible for the
loss of information.  Before IVOPTs we have

  # ALIGN = 32, MISALIGN = 16
  # vect_pa.9_18 = PHI 
  # ALIGN = 32, MISALIGN = 0
  # vect_pb.16_24 = PHI 
  vect_var_.13_20 = MEM[(double[1024] *)vect_pa.9_18];
  MEM[(double[1024] *)vect_pb.16_24] = vect_var_.14_22;

so we know that the pointers we dereference are properly aligned.

[Bug other/47395] the tree code WIDEN_MULT_MINUS_EXPR has a mismatching name

2011-01-21 Thread rguenth at gcc dot gnu.org

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #3 from Richard Guenther  2011-01-21 
14:21:24 UTC ---
Fixed.

[Bug middle-end/47397] Alignment of array element is not optimal in AVX mode due to use of TARGET_MEM_REFs

2011-01-21 Thread rguenth at gcc dot gnu.org

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

--- Comment #5 from Richard Guenther  2011-01-21 
14:22:40 UTC ---
Thus, the real reason is that we lack alignment information on
MEM_REFs/TARGET_MEM_REFs but only have pointer alignment information for now.

[Bug c++/47398] [4.5/4.6 Regression] tree check: accessed elt 10 of tree_vec with 9 elts in tsubst, at cp/pt.c:10500

2011-01-21 Thread jakub at gcc dot gnu.org

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |4.5.3

[Bug c++/47398] New: [4.5/4.6 Regression] tree check: accessed elt 10 of tree_vec with 9 elts in tsubst, at cp/pt.c:10500

2011-01-21 Thread jakub at gcc dot gnu.org

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

   Summary: [4.5/4.6 Regression] tree check: accessed elt 10 of
tree_vec with 9 elts in tsubst, at cp/pt.c:10500
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org


Created attachment 23063
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23063
rh670984.C

On the attached testcase g++ 4.5 and 4.6 ICE with:
rh670984.C:168:5: internal compiler error: tree check: accessed elt 10 of
tree_vec with 9 elts in tsubst, at cp/pt.c:10500
(different line number in 4.5 of course).
4.4 compiles it without errors.

[Bug middle-end/47397] Alignment of array element is not optimal in AVX mode due to use of TARGET_MEM_REFs

2011-01-21 Thread hjl.tools at gmail dot com

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

--- Comment #6 from H.J. Lu  2011-01-21 14:45:31 
UTC ---
(In reply to comment #5)
> Thus, the real reason is that we lack alignment information on
> MEM_REFs/TARGET_MEM_REFs but only have pointer alignment information for now.

I know it won't solve this bug.  But shouldn't we at least use alignment
of array element instead of pointer alignment?

[Bug c++/47398] [4.5/4.6 Regression] tree check: accessed elt 10 of tree_vec with 9 elts in tsubst, at cp/pt.c:10500

2011-01-21 Thread jakub at gcc dot gnu.org

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||dodji at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  2011-01-21 
14:46:43 UTC ---
Caused by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145440

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

2011-01-21 Thread aoliva at gcc dot gnu.org

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

--- Comment #3 from Alexandre Oliva  2011-01-21 
14:57:36 UTC ---
Author: aoliva
Date: Fri Jan 21 14:57:33 2011
New Revision: 169093

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169093
Log:
PR debug/47106
* cfgexpand.c (account_used_vars_for_block): Only account vars
that are annotated as used.
(estimated_stack_frame_size): Don't set TREE_USED.
* tree-dfa.c (create_var_ann): Mark variable as used.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgexpand.c
trunk/gcc/tree-dfa.c

[Bug c++/47398] [4.5/4.6 Regression] tree check: accessed elt 10 of tree_vec with 9 elts in tsubst, at cp/pt.c:10500

2011-01-21 Thread pluto at agmk dot net

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

Pawel Sikora  changed:

   What|Removed |Added

 CC||pluto at agmk dot net

--- Comment #2 from Pawel Sikora  2011-01-21 15:07:56 
UTC ---
(In reply to comment #1)
> Caused by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145440

the candidate fix http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01381.html
doesn't solve this testcase.

[Bug fortran/47399] New: ICE with TBP of a PARAMETER

2011-01-21 Thread burnus at gcc dot gnu.org

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

   Summary: ICE with TBP of a PARAMETER
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: ja...@gcc.gnu.org


Found by Wolfgang Kilian, cf
http://groups.google.com/group/comp.lang.fortran/msg/e6a865eda59e86db (Whole
c.l.f thread:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/69220fdd4c2715c0
)

The following program ICEs for variant #3, where one uses a TBP of a PARAMETER.

The variants #1 and #2 compile with -std=f2003/f2008/gnu and print "13".
Variant #1 with the TBP comment out compiles also with -std=f95.


The ICE is by definition wrong. I have not checked whether the program is valid
or not. My feeling is that variant #1 (with TBP comment) is at least invalid in
-std=f95, but I might be wrong.

Ifort fails with: "An automatic object is invalid in a main program." If this
is not changed and applies here, one should check for it using a subroutine and
not a main program. -- If one does so, ifort compiles #1 and #3 but rejects #2.
NAG v5.1 does the same for the subroutine version.
gfortran behaves identical for program and subroutine.


TODO:
a) Fix ICE
b) Check whether the code is valid Fortran 2008
c) Check whether some diagnostic is needed for Fortran 95/2003/2008
d) Do (b) and (c) for program replaced by subroutine.


The ICE is:

test.f90:19:0: internal compiler error: in gfc_match_varspec, at
fortran/primary.c:1846



module mytypes
   implicit none
   private
   public :: mytype, get_i

   integer, save :: i_priv = 13

   type :: mytype
  integer :: dummy
contains
  procedure, nopass :: i => get_i
   end type mytype

 contains

   pure function get_i () result (i)
 integer :: i
 i = i_priv
   end function get_i

end module mytypes

program test
   use mytypes
   implicit none

   type(mytype) :: a
   type(mytype), parameter :: a_const = mytype (0)

!   integer, dimension (get_i()) :: x! #1
!   integer, dimension (a%i()) :: x  ! #2
   integer, dimension (a_const%i()) :: x! #3

   print *, size (x)
end program test

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

2011-01-21 Thread ro at gcc dot gnu.org

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

   Summary: Several UCN tests FAIL on Tru64 UNIX V5.1B and IRIX
6.5
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
  Host: alpha-dec-osf5.1b, mips-sgi-irix6.5
Target: alpha-dec-osf5.1b, mips-sgi-irix6.5
 Build: alpha-dec-osf5.1b, mips-sgi-irix6.5


Several UCN tests partially fail on Tru64 UNIX V5.1B and IRIX 6.5. One common
example is

FAIL: gcc.dg/ucnid-10.c  (test for warnings, line 7)
FAIL: gcc.dg/ucnid-10.c  (test for warnings, line 8)
FAIL: gcc.dg/ucnid-10.c (test for excess errors)
Excess errors:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/ucnid-10.c:7:9: warning:
#pragma pack(pop, ó) encountered without matching #pragma pack(push, ó)
[-Wpragmas]
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/ucnid-10.c:8:9: warning:
unknown action 'ç' for '#pragma pack' - ignored [-Wpragmas]

Instead of being printed in \u... notation, the characters are printed
literally.

The set of failures isn't identical on both platforms (maybe due to char being
unsigned on IRIX, but signed on Tru64 UNIX?), but the symptom is always the
same.

[Bug tree-optimization/47355] [4.6 Regression] ICE: verify_ssa failed with -O2 -fipa-cp-clone

2011-01-21 Thread jakub at gcc dot gnu.org

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

--- Comment #6 from Jakub Jelinek  2011-01-21 
15:15:42 UTC ---
Author: jakub
Date: Fri Jan 21 15:15:40 2011
New Revision: 169094

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169094
Log:
PR tree-optimization/47355
* tree-eh.c (cleanup_empty_eh_merge_phis): Give up if
NOP has non-debug uses beyond PHIs in new_bb.

* g++.dg/opt/pr47355.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/opt/pr47355.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-eh.c

[Bug target/44606] Wrong SPE floating point during computation

2011-01-21 Thread dvdkhlng at gmx dot de

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

--- Comment #12 from David Kühling  2011-01-21 15:17:34 
UTC ---
Ok, looks like the change to reload1.c introduced by GCC revision 168347
(author froydnj):

http://gcc.gnu.org/viewcvs/trunk/gcc/reload1.c?r1=168347&r2=168346&pathrev=168347

fixes the problem for me.  I just took that patch and applied it to a checkout
of the GCC 4.4 branch, now my test-case for this floating point bug passes!

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

2011-01-21 Thread aoliva at gcc dot gnu.org

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

Alexandre Oliva  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Alexandre Oliva  2011-01-21 
15:17:13 UTC ---
Fixed

[Bug debug/47308] Dwarf Error: Cannot find signatured DIE referenced from DIE at 0x2581 [in module D:\main64.exe]

2011-01-21 Thread ktietz at gcc dot gnu.org

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

Kai Tietz  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID

--- Comment #11 from Kai Tietz  2011-01-21 15:32:20 
UTC ---
Found the issue. It is binutils related. For x64 windows target the
x86_dwarf2_return_column get initialized with wrong value. I will file a patch
for binutils for this.
It is no gcc bug, so I close it as invalid. Thanks again for finding this
issue.

[Bug middle-end/47397] Alignment of array element is not optimal in AVX mode due to use of TARGET_MEM_REFs

2011-01-21 Thread rguenth at gcc dot gnu.org

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

--- Comment #7 from Richard Guenther  2011-01-21 
15:35:29 UTC ---
(In reply to comment #6)
> (In reply to comment #5)
> > Thus, the real reason is that we lack alignment information on
> > MEM_REFs/TARGET_MEM_REFs but only have pointer alignment information for 
> > now.
> 
> I know it won't solve this bug.  But shouldn't we at least use alignment
> of array element instead of pointer alignment?

Well, part of it is half-way re-introducing type-alignment stuff,
deviating from the intial conservative-correctness.


Thus, we run into

align = MAX (TYPE_ALIGN (TREE_TYPE (exp)),
 get_object_alignment (exp, BIGGEST_ALIGNMENT));

for deciding whether to use movmisalign_optab but in set_mem_attrs_minus_bitpos
we do not fall back to TYPE_ALIGNment at all (which is conservative and
by initial design).

You might argue we want consistency here.

Note that this shouldn't be an issue for AVX/SSE as unaligned moves are
as fast as aligned ones if they are really aligned (at least I hope
this is true for AVX, it definitely is for SSE on recent archs - if not
the vectorizer cost model would need adjustment).

[Bug middle-end/47397] Alignment of array element is not optimal in AVX mode due to use of TARGET_MEM_REFs

2011-01-21 Thread rguenth at gcc dot gnu.org

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

--- Comment #8 from Richard Guenther  2011-01-21 
15:37:33 UTC ---
And before you start fiddling with set_mem_attributes_minus_bitpos, most
alignment related pieces in it should simply re-use get_object_alignment
(a cleanup I didn't finish in time for 4.6).

[Bug tree-optimization/47355] [4.6 Regression] ICE: verify_ssa failed with -O2 -fipa-cp-clone

2011-01-21 Thread jakub at gcc dot gnu.org

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from Jakub Jelinek  2011-01-21 
15:39:49 UTC ---
Fixed.

[Bug middle-end/47397] Alignment of array element is not optimal in AVX mode due to use of TARGET_MEM_REFs

2011-01-21 Thread hjl.tools at gmail dot com

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

--- Comment #9 from H.J. Lu  2011-01-21 16:03:41 
UTC ---
(In reply to comment #7)
> 
> Note that this shouldn't be an issue for AVX/SSE as unaligned moves are
> as fast as aligned ones if they are really aligned (at least I hope
> this is true for AVX, it definitely is for SSE on recent archs - if not
> the vectorizer cost model would need adjustment).

On SNB, we want to split 32byte unaligned load/store.

[Bug middle-end/47397] Alignment of array element is not optimal in AVX mode due to use of TARGET_MEM_REFs

2011-01-21 Thread rguenth at gcc dot gnu.org

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

--- Comment #10 from Richard Guenther  2011-01-21 
16:21:55 UTC ---
You can play with a cleanup patch I have lying around, queued for 4.7:

Index: emit-rtl.c
===
*** emit-rtl.c  (revision 169088)
--- emit-rtl.c  (working copy)
*** set_mem_attributes_minus_bitpos (rtx ref
*** 1611,1654 

/* We can set the alignment from the type if we are making an object,
   this is an INDIRECT_REF, or if TYPE_ALIGN_OK.  */
!   if (objectp || TREE_CODE (t) == INDIRECT_REF || TYPE_ALIGN_OK (type))
! align = MAX (align, TYPE_ALIGN (type));
! 
!   else if (TREE_CODE (t) == MEM_REF)
  {
!   tree op0 = TREE_OPERAND (t, 0);
!   if (TREE_CODE (op0) == ADDR_EXPR
! && (DECL_P (TREE_OPERAND (op0, 0))
! || CONSTANT_CLASS_P (TREE_OPERAND (op0, 0
!   {
! if (DECL_P (TREE_OPERAND (op0, 0)))
!   align = DECL_ALIGN (TREE_OPERAND (op0, 0));
! else if (CONSTANT_CLASS_P (TREE_OPERAND (op0, 0)))
!   {
! align = TYPE_ALIGN (TREE_TYPE (TREE_OPERAND (op0, 0)));
! #ifdef CONSTANT_ALIGNMENT
! align = CONSTANT_ALIGNMENT (TREE_OPERAND (op0, 0), align);
! #endif
!   }
! if (TREE_INT_CST_LOW (TREE_OPERAND (t, 1)) != 0)
!   {
! unsigned HOST_WIDE_INT ioff
!   = TREE_INT_CST_LOW (TREE_OPERAND (t, 1));
! unsigned HOST_WIDE_INT aoff = (ioff & -ioff) * BITS_PER_UNIT;
! align = MIN (aoff, align);
!   }
!   }
!   else
/* ??? This isn't fully correct, we can't set the alignment from the
   type in all cases.  */
align = MAX (align, TYPE_ALIGN (type));
  }

-   else if (TREE_CODE (t) == TARGET_MEM_REF)
- /* ??? This isn't fully correct, we can't set the alignment from the
-type in all cases.  */
- align = MAX (align, TYPE_ALIGN (type));
- 
/* If the size is known, we can set that.  */
if (TYPE_SIZE_UNIT (type) && host_integerp (TYPE_SIZE_UNIT (type), 1))
  size = GEN_INT (tree_low_cst (TYPE_SIZE_UNIT (type), 1));
--- 1611,1628 

/* We can set the alignment from the type if we are making an object,
   this is an INDIRECT_REF, or if TYPE_ALIGN_OK.  */
!   if (!TYPE_P (t))
  {
!   align = MAX (align, get_object_alignment (t, BIGGEST_ALIGNMENT));
!   if (objectp || TYPE_ALIGN_OK (type))
!   align = MAX (align, TYPE_ALIGN (type));
!   else if (TREE_CODE (t) == TARGET_MEM_REF
!  || TREE_CODE (t) == MEM_REF)
/* ??? This isn't fully correct, we can't set the alignment from the
   type in all cases.  */
align = MAX (align, TYPE_ALIGN (type));
  }

/* If the size is known, we can set that.  */
if (TYPE_SIZE_UNIT (type) && host_integerp (TYPE_SIZE_UNIT (type), 1))
  size = GEN_INT (tree_low_cst (TYPE_SIZE_UNIT (type), 1));


but I wonder why we are not falling into the

-   else if (TREE_CODE (t) == TARGET_MEM_REF)
- /* ??? This isn't fully correct, we can't set the alignment from the
-type in all cases.  */
- align = MAX (align, TYPE_ALIGN (type));

case right now, or what I am missing.

Ah, for the offsetted load the vectorizer uses a 64bit aligned type.
So it either cannot compute the alignment or fails to use an aligned type.

[Bug c++/47388] [4.6 Regression] ICE: in begin_for_stmt, at cp/semantics.c:863 with -fno-for-scope and for(;;) inside a template

2011-01-21 Thread jakub at gcc dot gnu.org

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.01.21 16:22:26
 CC||jason at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #2 from Jakub Jelinek  2011-01-21 
16:22:26 UTC ---
Caused by r168731.

[Bug middle-end/45422] [4.6 Regression] compile time increases 3x.

2011-01-21 Thread xinliangli at gmail dot com

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

--- Comment #29 from davidxl  2011-01-21 16:27:43 
UTC ---
(In reply to comment #28)
> David, any progress with this?

The cost function fix to make sure solution set does not become too big will be
probably very involved and won't be availlable in 4.6 time frame. I will get a
workaround using Richard's suggestion -- terminate the iterating loop when slow
convergence is detected and some limit is reached.

David

[Bug middle-end/47401] New: Support for must-not-throw regions with SJLJ exceptions broken

2011-01-21 Thread uweigand at gcc dot gnu.org

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

   Summary: Support for must-not-throw regions with SJLJ
exceptions broken
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: uweig...@gcc.gnu.org
Target: spu-elf


A couple of exception related tests are failing on SPU:
FAIL: g++.dg/cpp0x/noexcept04.C execution test
FAIL: g++.dg/cpp0x/noexcept05.C scan-assembler LSDA
FAIL: g++.dg/eh/spec10.C execution test
FAIL: g++.dg/eh/spec11.C scan-assembler LSDA

These are related to must-not-throw regions.  To implement those,
we may have to register a personality function with empty LSDA.
This has been implemented for DWARF CFI exception handling, but
apparently not (fully?) for SJLJ exception handling.

For example, the test case for noexcept05.C:
struct A { ~A(); };
void g();
void f() noexcept
{
  A var;
  g();
}

compiles on the SPU to:
.global _Z1fv
.type   _Z1fv, @function
_Z1fv:
stqd$lr,16($sp)
stqd$sp,-48($sp)
ai  $sp,$sp,-48
brsl$lr,_Z1gv
ai  $2,$sp,32
ori $3,$2,0
brsl$lr,_ZN1AD1Ev
ai  $sp,$sp,48
lqd $lr,16($sp)
bi  $lr
.size   _Z1fv, .-_Z1fv

Note the absence of any call to _Unwind_SJLJ_Register.

[Bug middle-end/47401] Support for must-not-throw regions with SJLJ exceptions broken

2011-01-21 Thread uweigand at gcc dot gnu.org

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

--- Comment #1 from Ulrich Weigand  2011-01-21 
16:33:43 UTC ---
Created attachment 23064
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23064
Proposed fix

Patch from http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01406.html

[Bug bootstrap/47402] New: [4.6 Regression] Bootstrap comparison failure

2011-01-21 Thread hjl.tools at gmail dot com

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

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


On Linux/ia32, revision 169093 gave

make[6]: Leaving directory `/export/gnu/import/svn/gcc-test-ia32/bld'
Comparing stages 2 and 3 
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
gcc/fortran/module.o differs
make[5]: *** [compare] Error 1

Revision 169088 seems OK.

[Bug rtl-optimization/41619] [4.4/4.5/4.6 regression] ICE in insert_save (caller-save.c) for SPEC CPU2000's 252.eon

2011-01-21 Thread law at redhat dot com

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

--- Comment #9 from Jeffrey A. Law  2011-01-21 16:45:36 
UTC ---
http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01424.html

After some brief discussion with rth (concerns about global_regs) in IRC, rth
approved the patch.

[Bug rtl-optimization/41619] [4.4/4.5/4.6 regression] ICE in insert_save (caller-save.c) for SPEC CPU2000's 252.eon

2011-01-21 Thread law at gcc dot gnu.org

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

--- Comment #10 from Jeffrey A. Law  2011-01-21 
16:49:34 UTC ---
Author: law
Date: Fri Jan 21 16:49:31 2011
New Revision: 169095

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169095
Log:

PR rtl-optimization/41619
* caller-save.c (setup_save_areas): Break out code to determine
which hard regs are live across calls by examining the reload chains
so that it is always used.
Eliminate code which checked REG_N_CALLS_CROSSED.

PR rtl-optimization/41619
* gcc.dg/pr41619.c: New.


Added:
trunk/gcc/testsuite/gcc.dg/pr41619.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/caller-save.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/41619] [4.4/4.5/4.6 regression] ICE in insert_save (caller-save.c) for SPEC CPU2000's 252.eon

2011-01-21 Thread law at redhat dot com

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|4.4.6   |4.6.0

--- Comment #11 from Jeffrey A. Law  2011-01-21 16:50:09 
UTC ---
Fixed

[Bug rtl-optimization/37273] [4.4/4.5/4.6 Regression] IRA does not re-materializes addresses (loads from the TOC)

2011-01-21 Thread law at redhat dot com

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

--- Comment #7 from Jeffrey A. Law  2011-01-21 17:13:35 
UTC ---
SPEC 2k6 testing on x86-64 is a wash for integer codes.  Small improvement for
403.gcc 462.libquantum and small regressions for 456.hmmr and 471.omnetpp are
evident.  There's a couple other tests which seem to have a tiny bias for
improvement, but without many more runs it'd be impossible to know if the
improvements are in the noise or not.  The net specint change is a 14.5 ->
14.6, but I wouldn't put a lot of stock into that.

FP shows a big improvement for 454.calculix and a small improvement for
459.gemsfdtd.  Small regressions are seen for 410.bwaves, 433.milc and
434.zeusmp, and 437.leslie3d.  The improvement for calculix dwarfs the minor
regressions and is probably responsible for the 13.6->13.7 improvement in the
FP base.

I've also verified that the patch consistently improves code density on x86 and
gives us the desired code on PPC for the testcase in the PR.

And, at least in my mind, the patch makes sense and I'll be posting it shortly.

[Bug c++/47388] [4.6 Regression] ICE: in begin_for_stmt, at cp/semantics.c:863 with -fno-for-scope and for(;;) inside a template

2011-01-21 Thread jakub at gcc dot gnu.org

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

--- Comment #3 from Jakub Jelinek  2011-01-21 
17:15:52 UTC ---
Created attachment 23065
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23065
gcc46-pr47388.patch

Untested fix.

[Bug middle-end/47401] Support for must-not-throw regions with SJLJ exceptions broken

2011-01-21 Thread uweigand at gcc dot gnu.org

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

Ulrich Weigand  changed:

   What|Removed |Added

  Attachment #23064|0   |1
is obsolete||

--- Comment #2 from Ulrich Weigand  2011-01-21 
17:18:59 UTC ---
Created attachment 23066
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23066
Updated fix

Updated patch from http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01483.html

[Bug target/47403] New: [x32] TLS doesn't work

2011-01-21 Thread hjl.tools at gmail dot com

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

   Summary: [x32] TLS doesn't work
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


[hjl@gnu-6 ilp32-15]$ cat x.c
extern __thread int __libc_errno __attribute__ ((tls_model ("initial-exec")));
;
int *
__errno_location (void)
{
  return &__libc_errno;
}
[hjl@gnu-6 ilp32-15]$ make
/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -S -o x.s -mx32 -O2 -dp 
x.c
x.c: In function ‘__errno_location’:
x.c:7:1: error: unrecognizable insn:
(insn 8 7 9 3 (set (reg:SI 59 [  ])
(reg:DI 63)) x.c:5 -1
 (expr_list:REG_EQUAL (symbol_ref:SI ("__libc_errno") [flags 0x60]
)
(nil)))
x.c:7:1: internal compiler error: in extract_insn, at recog.c:2109
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make: *** [x.s] Error 1
[hjl@gnu-6 ilp32-15]$

[Bug libfortran/46267] strerror() is not necessarily thread-safe

2011-01-21 Thread jb at gcc dot gnu.org

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

Janne Blomqvist  changed:

   What|Removed |Added

URL|http://gcc.gnu.org/ml/gcc-p |http://gcc.gnu.org/ml/gcc-p
   |atches/2011-01/msg01400.htm |atches/2011-01/msg01486.htm
   |l   |l
 AssignedTo|unassigned at gcc dot   |jb at gcc dot gnu.org
   |gnu.org |

--- Comment #7 from Janne Blomqvist  2011-01-21 17:26:08 
UTC ---
Updated patch: http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01486.html

[Bug middle-end/47401] Support for must-not-throw regions with SJLJ exceptions broken

2011-01-21 Thread uweigand at gcc dot gnu.org

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

Ulrich Weigand  changed:

   What|Removed |Added

  Attachment #23066|0   |1
is obsolete||

--- Comment #3 from Ulrich Weigand  2011-01-21 
17:29:40 UTC ---
Created attachment 23067
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23067
Updated fix

Minor update as requested

[Bug tree-optimization/47404] New: gcc.dg/pr46909.c FAILs on IRIX 6.5

2011-01-21 Thread ro at gcc dot gnu.org

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

   Summary: gcc.dg/pr46909.c FAILs on IRIX 6.5
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: ja...@redhat.com
  Host: mips-sgi-irix6.5
Target: mips-sgi-irix6.5
 Build: mips-sgi-irix6.5


gcc.dg/pr46909.c FAILS on IRIX 6.5 (both ABIs):

FAIL: gcc.dg/pr46909.c scan-tree-dump ifcombine "optimizing two comparisons to
x_[0-9]+\(D\) != 4"

The dump file (attached) contains

optimizing two comparisons to x_2(D) != 6

instead.

[Bug tree-optimization/47404] gcc.dg/pr46909.c FAILs on IRIX 6.5

2011-01-21 Thread ro at gcc dot gnu.org

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

--- Comment #1 from Rainer Orth  2011-01-21 17:30:55 UTC 
---
Created attachment 23068
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23068
ifcombine dump

[Bug middle-end/47405] New: gcc.dg/torture/20090618-1.c FAILs on IRIX 6.5

2011-01-21 Thread ro at gcc dot gnu.org

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

   Summary: gcc.dg/torture/20090618-1.c FAILs on IRIX 6.5
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: rguent...@suse.de
  Host: mips-sgi-irix6.5
Target: mips-sgi-irix6.5
 Build: mips-sgi-irix6.5


gcc.dg/torture/20090618-1.c FAILs on IRIX 6.5 at -O1 and up:

FAIL: gcc.dg/torture/20090618-1.c  -O1  (test for excess errors)
Excess errors:
ld32: ERROR   33 : Unresolved data symbol "mempcpy" -- 1st referenced by
/var/tmp//ccfiGZ5r.o.
Use linker option -v to see when and which objects, archives and dsos are
loaded.  
ld32: INFO152: Output file removed because of error.

WARNING: gcc.dg/torture/20090618-1.c  -O1  compilation failed to produce
executable

[Bug c++/46977] [4.6 Regression] [C++0x] ICE: SIGSEGV in htab_find_slot_with_hash (hashtab.c:650)

2011-01-21 Thread jason at gcc dot gnu.org

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

--- Comment #5 from Jason Merrill  2011-01-21 
17:38:06 UTC ---
Author: jason
Date: Fri Jan 21 17:38:02 2011
New Revision: 169096

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169096
Log:
PR c++/46977
* semantics.c (potential_constant_expression_1): Split out from
potential_constant_expression.  Add want_rval parm.  Handle
template expression forms.  Don't enforce restriction on address
of automatic variable here.  Add a couple of diagnostics that
had been missing.
(require_potential_constant_expression): New entry point.
(build_data_member_initialization, register_constexpr_fundef): Adjust.
(maybe_constant_value): Check potential_constant_expression.
* pt.c (fold_non_dependent_expr_sfinae): Likewise.
* tree.c (build_vec_init_expr): Adjust.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-stmtexpr.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/pt.c
trunk/gcc/cp/semantics.c
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/47406] New: gcc.dg/torture/builtin-modf-1.c FAILs on IRIX 6.5

2011-01-21 Thread ro at gcc dot gnu.org

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

   Summary: gcc.dg/torture/builtin-modf-1.c FAILs on IRIX 6.5
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
  Host: mips-sgi-irix6.5
Target: mips-sgi-irix6.5
 Build: mips-sgi-irix6.5


gcc.dg/torture/builtin-modf-1.c FAILs on IRIX 6.5 at all optimization levels:

FAIL: gcc.dg/torture/builtin-modf-1.c  -O0  (test for excess errors)
Excess errors:
ld32: ERROR   33 : Unresolved data symbol "link_error" -- 1st referenced by
/var/tmp//ccw6kU6D.o.
Use linker option -v to see when and which objects, archives and dsos are
loaded.  
ld32: INFO152: Output file removed because of error.

I'm including the -save-temps output (i.e. .i and .s files).

[Bug middle-end/47406] gcc.dg/torture/builtin-modf-1.c FAILs on IRIX 6.5

2011-01-21 Thread ro at gcc dot gnu.org

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

--- Comment #1 from Rainer Orth  2011-01-21 17:44:45 UTC 
---
Created attachment 23069
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23069
preprocessed input

1 2 >

1 - 100 of 159 matches

Mail list logo