[Bug target/44202] Missing compare after add

[hp at gcc dot gnu dot org]

--- Comment #9 from hp at gcc dot gnu dot org  2010-05-20 06:53 ---
Subject: Bug 44202

Author: hp
Date: Thu May 20 06:53:34 2010
New Revision: 159618

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159618
Log:
PR target/44202
* config/cris/cris.md ("*addsi3_v32"): Correct "cc"
settings for 16-bit-constant "addo" alternative.

Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/config/cris/cris.md


-- 


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

[Bug target/44202] Missing compare after add

[hp at gcc dot gnu dot org]

--- Comment #8 from hp at gcc dot gnu dot org  2010-05-20 06:52 ---
Subject: Bug 44202

Author: hp
Date: Thu May 20 06:52:25 2010
New Revision: 159617

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159617
Log:
PR target/44202
* gcc.c-torture/execute/pr44202-1.c: New test.

Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/execute/pr44202-1.c
Modified:
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug target/44202] Missing compare after add

[hp at gcc dot gnu dot org]

--- Comment #7 from hp at gcc dot gnu dot org  2010-05-20 06:51 ---
Subject: Bug 44202

Author: hp
Date: Thu May 20 06:51:05 2010
New Revision: 159616

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159616
Log:
PR target/44202
* config/cris/cris.md ("*addsi3_v32"): Correct "cc"
settings for 16-bit-constant "addo" alternative.

Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/config/cris/cris.md


-- 


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

[Bug target/44202] Missing compare after add

[hp at gcc dot gnu dot org]

--- Comment #6 from hp at gcc dot gnu dot org  2010-05-20 06:50 ---
Subject: Bug 44202

Author: hp
Date: Thu May 20 06:50:15 2010
New Revision: 159615

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159615
Log:
PR target/44202
* gcc.c-torture/execute/pr44202-1.c: New test.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr44202-1.c
Modified:
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug target/44202] Missing compare after add

[hp at gcc dot gnu dot org]

--- Comment #5 from hp at gcc dot gnu dot org  2010-05-20 06:48 ---
Subject: Bug 44202

Author: hp
Date: Thu May 20 06:48:37 2010
New Revision: 159614

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159614
Log:
PR target/44202
* config/cris/cris.md ("*addsi3_v32"): Correct "cc"
settings for 16-bit-constant "addo" alternative.

Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/config/cris/cris.md


-- 


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

[Bug target/44202] Missing compare after add

[hp at gcc dot gnu dot org]

--- Comment #4 from hp at gcc dot gnu dot org  2010-05-20 06:47 ---
Subject: Bug 44202

Author: hp
Date: Thu May 20 06:47:41 2010
New Revision: 159613

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159613
Log:
PR target/44202
* gcc.c-torture/execute/pr44202-1.c: New test.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.c-torture/execute/pr44202-1.c
Modified:
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug target/44202] Missing compare after add

[hp at gcc dot gnu dot org]

--- Comment #3 from hp at gcc dot gnu dot org  2010-05-20 06:46 ---
Subject: Bug 44202

Author: hp
Date: Thu May 20 06:45:38 2010
New Revision: 159612

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159612
Log:
PR target/44202
* config/cris/cris.md ("*addsi3_v32"): Correct "cc"
settings for 16-bit-constant "addo" alternative.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/cris/cris.md


-- 


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

[Bug target/44202] Missing compare after add

[hp at gcc dot gnu dot org]

--- Comment #2 from hp at gcc dot gnu dot org  2010-05-20 06:45 ---
Subject: Bug 44202

Author: hp
Date: Thu May 20 06:44:45 2010
New Revision: 159611

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159611
Log:
PR target/44202
* gcc.c-torture/execute/pr44202-1.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr44202-1.c
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug target/43764] -mrelax-pic-calls fails with complex types

[wilson at gcc dot gnu dot org]

--- Comment #2 from wilson at gcc dot gnu dot org  2010-05-20 06:27 ---
Mine.


-- 

wilson at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |wilson at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-05-20 06:27:28
   date||


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

[Bug target/43764] -mrelax-pic-calls fails with complex types

[wilson at gcc dot gnu dot org]

--- Comment #1 from wilson at gcc dot gnu dot org  2010-05-20 06:27 ---
Subject: Bug 43764

Author: wilson
Date: Thu May 20 06:26:52 2010
New Revision: 159610

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159610
Log:
PR target/43764
* mips.c (mips_call_expr_from_insn): New arg second_call.  Set it.
(mips_annotate_pic_calls): Pass new arg to mips_call_expr_from_insn.
Use it.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/mips/mips.c


-- 


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

[Bug middle-end/44121] [4.6 Regression] multiple char-related fails.

[reichelt at gcc dot gnu dot org]

--- Comment #12 from reichelt at gcc dot gnu dot org  2010-05-20 06:25 
---
The failure in comment #1 might be related to PR 44206.


-- 


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

[Bug middle-end/44206] [4.6 Regression] ICE: Inline clone with address taken

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0


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

[Bug middle-end/44206] New: [4.6 Regression] ICE: Inline clone with address taken

[reichelt at gcc dot gnu dot org]

The following valid code snippet triggers an ICE on trunk when compiled with
"-O3" on i686-pc-linux-gnu and x86_64-unknown-linux-gnu:

===
template struct A
{
  void foo(void(*)(A));
  void bar(void(*f)(A)) { foo(f); foo(f); }
};

template inline void FOO(A a)
{
  a.foo(0);
}

extern template void FOO(A<0>);

void BAR()
{
  A<0> a;
  FOO(a);
  a.bar(FOO);
}
===

bug.cc:19:1: error: Inline clone with address taken
void FOO(A) [with int N = 0]/5(-1) @0x40228780 (asm: _Z3FOOILi0EEv1AIXT_EE)
(inline copy in void BAR()/0) availability:local analyzed 12 time, 11 benefit 3
size, 2 benefit address_taken body local finalized inlinable
  called by: void BAR()/0 (1.00 per call) (inlined) (can throw external) 
  calls: void A< >::foo(void (*)(A< >)) [with int
 = 0, A< > = A<0>]/3 (1.00 per call) (can throw external) 
  References: 
  Refering this function:  fn:void A< >::bar(void (*)(A<
>)) [with int  = 0, A< > = A<0>]/4 (addr) fn:void
A< >::bar(void (*)(A< >)) [with int  = 0,
A< > = A<0>]/4 (addr)
bug.cc:19:1: internal compiler error: verify_cgraph_node failed
Please submit a full bug report, [etc.]

This is probably related to PR 44121.


-- 
   Summary: [4.6 Regression] ICE: Inline clone with address taken
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, monitored
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug lto/44195] [4.6 regression] gcc.dg/lto/20100518 c_lto_20100518_0.o

[steven at gcc dot gnu dot org]

-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |steven at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-05-20 05:42:33
   date||
   Target Milestone|4.6.0   |---


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

[Bug c++/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

[jason at gcc dot gnu dot org]

--- Comment #15 from jason at gcc dot gnu dot org  2010-05-20 05:35 ---
Giving all unions alias set 0 doesn't fix the testcase.  This surprises me,
since I thought that the problem was with the union assignment

  this->functor = f.functor;

in assign_to_own.  Giving alias set 0 to all classes with a member or base of
alias set 0 also doesn't fix the testcase.  Giving alias set 0 to all classes
does fix the testcase.


-- 


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

[Bug rtl-optimization/44169] Wrong code while generating TLS offsets

[Kyle dot D dot Moffett at boeing dot com]

--- Comment #5 from Kyle dot D dot Moffett at boeing dot com  2010-05-20 
04:53 ---
I am not able to reproduce this with a cross-compiling GCC 4.4.3 or 4.4.4 built
from Debian sources.  Configuration parameters for GCC 4.4.4 were:

-v
--with-pkgversion='Debian 4.4.4-2'
--with-bugurl='file:///usr/share/doc/gcc-4.4/README.Bugs'
--prefix=/usr
--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/powerpc-linux-gnuspe/include/c++/4.4.4
--program-suffix=-4.4
--enable-nls
--enable-clocale=gnu
--enable-libstdcxx-debug
--enable-objc-gc
--with-cpu=8548
--enable-e500_double
--with-long-double-128
--disable-multilib
--enable-checking=release
--program-prefix=powerpc-linux-gnuspe-
--includedir=/usr/powerpc-linux-gnuspe/include
--with-headers=/usr/powerpc-linux-gnuspe/include
--with-libs=/usr/powerpc-linux-gnuspe/lib
--build=x86_64-linux-gnu
--host=x86_64-linux-gnu
--target=powerpc-linux-gnuspe
CC=gcc
build_alias=x86_64-linux-gnu
host_alias=x86_64-linux-gnu
target_alias=powerpc-linux-gnuspe
--enable-languages=c,c++,fortran,objc,obj-c++

Versions are:
  powerpc-linux-gnuspe-gcc-4.3 (Debian 4.3.4-10 with a patch to debian/rules)
4.3.4
  powerpc-linux-gnuspe-gcc-4.4 (Debian 4.4.4-2 with a patch to debian/rules)
4.4.4

The C file was compiled as follows in both cases:
  powerpc-linux-gnuspe-gcc -Werror -pthread -ftls-model=initial-exec -O2
-pthread -fPIC -DPIC tc.c -o tc.S -S -mcpu=8540 -O1 -fdump-rtl-all -c

I'm not very familiar with the RTL passes, but if somebody can tell me what
else to look for or test I'll go scrounge around to see if I can find what's
hiding the problem for me.

Cheers,
Kyle Moffett


-- 

Kyle dot D dot Moffett at boeing dot com changed:

   What|Removed |Added

 CC||Kyle dot D dot Moffett at
   ||boeing dot com


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

[Bug fortran/43851] Add _gfortran_error_stop_numeric

[jvdelisle at gcc dot gnu dot org]

--- Comment #4 from jvdelisle at gcc dot gnu dot org  2010-05-20 04:44 
---
Subject: Bug 43851

Author: jvdelisle
Date: Thu May 20 04:44:11 2010
New Revision: 159609

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159609
Log:
2010-05-19 Jerry DeLisle 

PR fortran/43851
* runtime/stop.c (error_stop_numeric): New function and updated
comment.
Add declaration for stop_numeric and remove declaration for
stop_string.
(stop_string): Use for blank STOP.
(stop_numeric): Remove use of special -1 stop code.
* runtime/pause.c (do_pause): Use stop_string for blank stop.
(pause_numeric): Remove use of special -1 pause code.
* gfortran.map: Add new symbol to run-time library.
* libgfortran.h: Move declaration for stop_string to here to make
function visible for do_pause. Remove declaration for stop_numeric.

2010-05-19 Jerry DeLisle 

PR fortran/43851
* trans-stmt.c (gfc_trans_stop): Add generation of call to
gfortran_error_stop_numeric. Fix up some whitespace. Use stop_string
for
blank STOP, handling a null expression. (gfc_trans_pause): Use
pause_string for blank PAUSE.
* trans.h: Add external function declaration for error_stop_numeric.
* trans-decl.c (gfc_build_builtin_function_decls): Add the building of
the declaration for the library call. Adjust whitespaces.
* match.c (gfc_match_stopcode): Remove use of the actual stop code to
signal no stop code. Match the expression following the stop and pass
that to the translators. Remove the old use of digit matching.  Add
checks that the stop_code expression is INTEGER or CHARACTER, constant,
and if CHARACTER, default character KIND.

2010-05-19 Jerry DeLisle 

PR fortran/43851
* gfortran.dg/label_1.f90: Update test.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/match.c
trunk/gcc/fortran/trans-decl.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/fortran/trans.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/label_1.f90
trunk/libgfortran/ChangeLog
trunk/libgfortran/gfortran.map
trunk/libgfortran/libgfortran.h
trunk/libgfortran/runtime/pause.c
trunk/libgfortran/runtime/stop.c


-- 


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

[Bug target/44199] ppc64 glibc miscompilation

[amodra at gmail dot com]

--- Comment #8 from amodra at gmail dot com  2010-05-20 04:31 ---
FWIW, Jakub's patch looks a reasonable fix to me.


-- 


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

[Bug target/44202] Missing compare after add

[hp at gcc dot gnu dot org]

-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-05-20 00:24:47
   date||


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

[Bug objc/44125] [4.6 Regression] const-str-9 fails.

[iains at gcc dot gnu dot org]

--- Comment #3 from iains at gcc dot gnu dot org  2010-05-19 23:17 ---
static const NSConstantString *appKey = @"MyApp";

is not being emitted because it's unused - this seems correct behavior to me.

solutions:
(a) make it
const NSConstantString *appKey = @"MyApp";
(b) 
add :

void *foo (void)
{
   return (void *) appKey ;
}

either proves that the correct assembler pattern is emitted for the
initializer.

Any preference Mike? (or I'll apply b after a few days...).


-- 


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

[Bug middle-end/44204] [4.6 regression] ICE in gimple_op_ptr, at gimple.h:167

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2010-05-19 23:14 ---
The new failures are caused by revision 159585:

http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00638.html

FAIL: g++.dg/opt/mmx2.C (internal compiler error)
FAIL: g++.dg/opt/mmx2.C (test for excess errors)
FAIL: gcc.target/i386/avx-1.c (internal compiler error)
FAIL: gcc.target/i386/avx-1.c (test for excess errors)
FAIL: gcc.target/i386/avx-2.c (internal compiler error)
FAIL: gcc.target/i386/avx-2.c (test for excess errors)
FAIL: gcc.target/i386/avx-vzeroall-1.c (internal compiler error)
FAIL: gcc.target/i386/avx-vzeroall-1.c (test for excess errors)
FAIL: gcc.target/i386/avx-vzeroall-2.c (internal compiler error)
FAIL: gcc.target/i386/avx-vzeroall-2.c (test for excess errors)
FAIL: gcc.target/i386/avx-vzeroupper-1.c (internal compiler error)
FAIL: gcc.target/i386/avx-vzeroupper-1.c (test for excess errors)
FAIL: gcc.target/i386/avx-vzeroupper-2.c (internal compiler error)
FAIL: gcc.target/i386/avx-vzeroupper-2.c (test for excess errors)
FAIL: gcc.target/i386/mmx-1.c (internal compiler error)
FAIL: gcc.target/i386/mmx-1.c (test for excess errors)
FAIL: gcc.target/i386/mmx-2.c (internal compiler error)
FAIL: gcc.target/i386/mmx-2.c (test for excess errors)
FAIL: gcc.target/i386/mmx-7.c (internal compiler error)
FAIL: gcc.target/i386/mmx-7.c (test for excess errors)
FAIL: gcc.target/i386/pr36438.c (internal compiler error)
FAIL: gcc.target/i386/pr36438.c (test for excess errors)
FAIL: gcc.target/i386/sse-13.c (internal compiler error)
FAIL: gcc.target/i386/sse-13.c (test for excess errors)
FAIL: gcc.target/i386/sse-14.c (internal compiler error)
FAIL: gcc.target/i386/sse-14.c (test for excess errors)
FAIL: gcc.target/i386/sse-22.c (internal compiler error)
FAIL: gcc.target/i386/sse-22.c (test for excess errors)
FAIL: gcc.target/i386/sse-23.c (internal compiler error)
FAIL: gcc.target/i386/sse-23.c (test for excess errors)
FAIL: gcc.target/i386/sse2-mmx.c (internal compiler error)
FAIL: gcc.target/i386/sse2-mmx.c (test for excess errors)
FAIL: gcc.target/i386/ssse3-pabsb.c (internal compiler error)
FAIL: gcc.target/i386/ssse3-pabsb.c (test for excess errors)
FAIL: gcc.target/i386/ssse3-pabsd.c (internal compiler error)
FAIL: gcc.target/i386/ssse3-pabsd.c (test for excess errors)
FAIL: gcc.target/i386/ssse3-pabsw.c (internal compiler error)
FAIL: gcc.target/i386/ssse3-pabsw.c (test for excess errors)
FAIL: gcc.target/i386/ssse3-palignr.c (internal compiler error)
FAIL: gcc.target/i386/ssse3-palignr.c (test for excess errors)
FAIL: gcc.target/i386/ssse3-phaddd.c (internal compiler error)
FAIL: gcc.target/i386/ssse3-phaddd.c (test for excess errors)
FAIL: gcc.target/i386/ssse3-phaddsw.c (internal compiler error)
FAIL: gcc.target/i386/ssse3-phaddsw.c (test for excess errors)
FAIL: gcc.target/i386/ssse3-phaddw.c (internal compiler error)
FAIL: gcc.target/i386/ssse3-phaddw.c (test for excess errors)
FAIL: gcc.target/i386/ssse3-phsubd.c (internal compiler error)
FAIL: gcc.target/i386/ssse3-phsubd.c (test for excess errors)
FAIL: gcc.target/i386/ssse3-phsubsw.c (internal compiler error)
FAIL: gcc.target/i386/ssse3-phsubsw.c (test for excess errors)
FAIL: gcc.target/i386/ssse3-phsubw.c (internal compiler error)
FAIL: gcc.target/i386/ssse3-phsubw.c (test for excess errors)
FAIL: gcc.target/i386/ssse3-pmaddubsw.c (internal compiler error)
FAIL: gcc.target/i386/ssse3-pmaddubsw.c (test for excess errors)
FAIL: gcc.target/i386/ssse3-pmulhrsw.c (internal compiler error)
FAIL: gcc.target/i386/ssse3-pmulhrsw.c (test for excess errors)
FAIL: gcc.target/i386/ssse3-pshufb.c (internal compiler error)
FAIL: gcc.target/i386/ssse3-pshufb.c (test for excess errors)
FAIL: gcc.target/i386/ssse3-psignb.c (internal compiler error)
FAIL: gcc.target/i386/ssse3-psignb.c (test for excess errors)
FAIL: gcc.target/i386/ssse3-psignd.c (internal compiler error)
FAIL: gcc.target/i386/ssse3-psignd.c (test for excess errors)
FAIL: gcc.target/i386/ssse3-psignw.c (internal compiler error)
FAIL: gcc.target/i386/ssse3-psignw.c (test for excess errors)


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||froydnj at gcc dot gnu dot
   ||org


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

[Bug target/43810] [4.5 Regression] linking results in undefined references to _savegpr_* _restgpr_*_x

[patrick at motec dot com dot au]

--- Comment #12 from patrick at motec dot com dot au  2010-05-19 22:58 
---
(In reply to comment #10)
> See comment #4.  I believe this is a pilot error.
> 

Richard,

Are you referring to my original bug report or to Khem's link problem.

I don't think (unless I've messed up my gcc build) that my original report is
misuse.


-- 


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

[Bug c++/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

[jason at gcc dot gnu dot org]

--- Comment #14 from jason at gcc dot gnu dot org  2010-05-19 22:53 ---
In C++, an assignment of a union is defined to be equivalent to a byte copy:

12.8/32 "The implicitly-defined copy assignment operator for a union X copies
the object representation (3.9) of X."

3.9/4 "The object representation of an object of type T is the sequence of N
unsigned char objects taken up by the object of type T, where N equals
sizeof(T)."


-- 


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

[Bug debug/44205] New: Wrong .debug_line for -O0 -g

[jan dot kratochvil at redhat dot com]

extern int i;
void
f (void)
{
  if (i)
{
  if (i)
i = 0;
  else
i = 1;
}
  else
i = 2;
}

gcc -c -g
objdump -dS

i = 0;
  18:   c7 05 00 00 00 00 00movl   $0x0,0x0(%rip)# 22 
  1f:   00 00 00
  else
i = 1;
  22:   eb 16   jmp3a 
  24:   c7 05 00 00 00 00 01movl   $0x1,0x0(%rip)# 2e 
  2b:   00 00 00
  2e:   eb 0a   jmp3a 

jmp at offset 22 should belong to the "i = 0;" line.

Problem reproduced on:
gcc (GCC) 4.4.5 20100519 (prerelease)
gcc (GCC) 4.5.1 20100519 (prerelease)
gcc (GCC) 4.6.0 20100519 (experimental)
gcc-4.4.3-4.fc12.x86_64

Correct output on:
gcc-4.1.2-48.el5.x86_64

This will cause GDB to skip the line on `step' (which is a workaround in GDB
for missing is_stmt info).

Can GCC use its own new gdb guality framework to test it on its own?
There was before: PR debug/29609, PR debug/36690, PR debug/37616


-- 
   Summary: Wrong .debug_line for -O0 -g
   Product: gcc
   Version: 4.4.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug middle-end/44204] New: [4.6 regression] ICE in gimple_op_ptr, at gimple.h:167

[hjl dot tools at gmail dot com]

On Linux/x86, revision 159586 gave

Executing on host: /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/
/export/gnu/import/git/gcc/gcc/testsuite/gcc.target/i386/avx-1.c   -O2
-Werror-implicit-function-declaration -march=k8 -m3dnow -mavx  -maes -mpclmul
-S  -o avx-1.s(timeout = 300)
/export/gnu/import/git/gcc/gcc/testsuite/gcc.target/i386/avx-1.c: In function
'_m_empty':^M 
/export/gnu/import/git/gcc/gcc/testsuite/gcc.target/i386/avx-1.c:131:0:
internal compiler error: in gimple_op_ptr, at gimple.h:1672^M
Please submit a full bug report,^M
with preprocessed source if appropriate.^M 
See  for instructions.^M
compiler exited with status 1

Revision 159573 is OK.


-- 
   Summary: [4.6 regression] ICE in gimple_op_ptr, at gimple.h:167
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug middle-end/44203] New: [4.6 regression] New prefetch test failures

[hjl dot tools at gmail dot com]

On Linux/x86, revision 159557:

http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00609.html

caused:

FAIL: gcc.dg/tree-ssa/prefetch-3.c scan-tree-dump-times aprefetch "unroll
factor 4" 1
FAIL: gcc.dg/tree-ssa/prefetch-5.c scan-tree-dump-times aprefetch "Issued
prefetch" 2
FAIL: gcc.dg/tree-ssa/prefetch-6.c scan-assembler-times prefetchnta 3
FAIL: gcc.dg/tree-ssa/prefetch-6.c scan-tree-dump-times aprefetch "Issued
nontemporal prefetch" 3
FAIL: gcc.dg/tree-ssa/update-unroll-1.c scan-tree-dump-not aprefetch "SUCC: 7
.100.0%"


-- 
   Summary: [4.6 regression] New prefetch test failures
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug c++/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2010-05-17 15:50:41 |2010-05-19 22:15:45
   date||


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

[Bug target/42159] [4.4/4.5/4.6] app SIGABRTs after a trivial nested throw/stack unwinding

[simon at pushface dot org]

--- Comment #17 from simon at pushface dot org  2010-05-19 22:05 ---
(In reply to comment #16)
> Confirmed on gcc version 4.5.1 20100506 (prerelease).
Confirmed fixed or confirmed present?

The Ada version of this test executes correctly for 4.5.0:

$ gnatgcc -v
Using built-in specs.
COLLECT_GCC=/opt/gcc-4.5.0-x86_64/bin/gcc
COLLECT_LTO_WRAPPER=/opt/gcc-4.5.0-x86_64/libexec/gcc/x86_64-apple-darwin10/4.5.0/lto-wrapper
Target: x86_64-apple-darwin10
Configured with: ../gcc-4.5.0/configure --prefix=/opt/gcc-4.5.0-x86_64
--disable-multilib --enable-languages=c,ada --with-gmp=/opt/gnu
--with-mpfr=/opt/gnu --with-mpc=/opt/gnu --build=x86_64-apple-darwin10
Thread model: posix
gcc version 4.5.0 (GCC) 

$ cat raiser.adb 
with Ada.Text_IO; use Ada.Text_IO;
procedure Raiser is
begin
   begin
  raise Constraint_Error;
   exception
  when Constraint_Error =>
 Put_Line ("CE raised.");
   end;
end Raiser;

$ ./raiser 
CE raised.


-- 


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

[Bug middle-end/44197] [4.6 Regresssion] varpool SEGV

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2010-05-19 21:57 ---
It is caused by revision 159321:

http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00373.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu dot
   ||org
Summary|varpool SEGV|[4.6 Regresssion] varpool
   ||SEGV
   Target Milestone|--- |4.6.0


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

[Bug fortran/26227] accepts invalid fortran, different dummy types/number

[tkoenig at gcc dot gnu dot org]

--- Comment #13 from tkoenig at gcc dot gnu dot org  2010-05-19 21:53 
---
This is now

real, dimension(2) :: test
integer:: n
test = n
! print *, test
return
end function test
program arr
real, dimension(2) :: res
res = test(2)
print *, res
end program
i...@linux-fd1f:/tmp> gfortran -fwhole-file gurgl.f90
gurgl.f90:10.6:

res = test(2)
  1
Fehler: The reference to function 'test' at (1) either needs an explicit
INTERFACE or the rank is incorrect

Should we close this?


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu dot
   ||org


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

[Bug target/44199] ppc64 glibc miscompilation

[bergner at gcc dot gnu dot org]

--- Comment #7 from bergner at gcc dot gnu dot org  2010-05-19 21:52 ---
Pat is going to SPEC test the patch and will report back here with his results.


-- 

bergner at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pthaugen at gcc dot gnu dot
   ||org


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

[Bug middle-end/44101] [4.6 regression] ICE compiling 25_algorithms/fill/4.cc on Tru64 UNIX V5.1B

[ebotcazou at gcc dot gnu dot org]

--- Comment #6 from ebotcazou at gcc dot gnu dot org  2010-05-19 21:13 
---
Thanks, can reproduce now.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
   Last reconfirmed|2010-05-12 21:36:59 |2010-05-19 21:13:53
   date||


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

[Bug c++/44193] [4.3/4.4/4.5/4.6 Regression] function types, cv-quals and typename

[jason at gcc dot gnu dot org]

--- Comment #4 from jason at gcc dot gnu dot org  2010-05-19 21:02 ---
Subject: Bug 44193

Author: jason
Date: Wed May 19 21:01:50 2010
New Revision: 159596

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159596
Log:
PR c++/44193
* typeck.c (type_memfn_quals): New fn.
(apply_memfn_quals): New fn.
(cp_type_quals): Return TYPE_UNQUALIFIED for FUNCTION_TYPE.
(cp_type_readonly): Use cp_type_quals.
* cp-tree.h: Add declarations.
* tree.c (cp_build_qualified_type_real): Don't set, but do
preserve, quals on FUNCTION_TYPE.
(strip_typedefs): Use apply_memfn_quals and type_memfn_quals.
* decl.c (build_ptrmem_type): Likewise.
(grokdeclarator): Likewise.
(static_fn_type): Likewise.
* decl2.c (change_return_type): Likewise.
(cp_reconstruct_complex_type): Likewise.
* pt.c (tsubst_function_type): Likewise.
(unify): Likewise.
(tsubst): Likewise.  Drop special FUNCTION_TYPE substitution code.

Added:
trunk/gcc/testsuite/g++.dg/template/fntype1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl.c
trunk/gcc/cp/decl2.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/tree.c
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug target/44199] ppc64 glibc miscompilation

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2010-05-19 20:31 ---
Created an attachment (id=20705)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20705&action=view)
gcc46-pr44199.patch

Untested patch.  Unfortunately, rs6000_emit_stack_tie isn't good enough.
1) it uses frame alias set, but the stack block can have arbitrary alias sets
in
   it and we need to avoid moving all of them over
2) for the frame_pointer_needed case using sp based BLK mem isn't sufficient,
   as then fp based mem can still be scheduled over it.  Using stack_tie insn
   just with hard frame pointer based BLK mem doesn't work either, then the sp
   restore insn can be moved over it.

Could anyone please test this on SPEC to see if it causes meassurable
differences?


-- 


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

[Bug target/44199] ppc64 glibc miscompilation

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2010-05-19 19:27 ---
rs6000.c already has rs6000_emit_stack_tie and calls it in several places in
the epilogue generation, I guess we just should add another call to this.


-- 


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

[Bug target/44202] Missing compare after add

[hp at gcc dot gnu dot org]

--- Comment #1 from hp at gcc dot gnu dot org  2010-05-19 19:24 ---
Created an attachment (id=20704)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20704&action=view)
test-case

Compile with -O2 -march=v32.  Observe "addo 513,$r10,$acr" and "addo
512,$r10,$acr" directly followed by a branch insn (on the 4.3 branch).
The test-case is intended for gcc/testsuite/gcc.c-torture/execute.


-- 


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

[Bug target/44199] ppc64 glibc miscompilation

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2010-05-19 19:23 ---
Yes, it is related, but solving it in the scheduler in generic way isn't going
to be trivial.

E.g. x86_64 emits memory_blockage early in ix86_expand_epilogue:
  /* See the comment about red zone and frame
 pointer usage in ix86_expand_prologue.  */
  if (frame_pointer_needed && frame.red_zone_size)
emit_insn (gen_memory_blockage ());

Another testcase:

extern void *alloca (__SIZE_TYPE__);
__attribute__((noinline, noclone))
long *bar (long *p)
{
  asm volatile ("" : : "r" (p) : "memory");
  return p;
}

long
foo (long x)
{
  long *p = (long *) alloca (x * sizeof (long));
  long *q = bar (p);
  return q[0];
}

which shows that some blockage or preventing scheduling over the stack release
is needed even when the frame size is smaller than the red zone size and that
the memory address doesn't need to be obviously based on stack pointer (it
would be just safe to allow moving over stack accesses that are provably in the
red zone or above.


-- 


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

[Bug target/44202] New: Missing compare after add

[hp at gcc dot gnu dot org]

In the attached test-case, a compare is missing, due to a misoptimization
regarding removing redundant compare-insns; when using "addo" the compare is
needed. Code generation for the test-case is different on 4.4, 4.5 and head;
somewhat suboptimally using "adds", except that a compare-insn *would* be
redundant and there is none).


-- 
   Summary: Missing compare after add
   Product: gcc
   Version: 4.3.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: hp at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
GCC target triplet: crisv32-*-*


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

[Bug target/44201] ppc64 glibc miscompilation

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2010-05-19 19:09 ---
Sorry.

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


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/44199] ppc64 glibc miscompilation

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2010-05-19 19:09 ---
*** Bug 44201 has been marked as a duplicate of this bug. ***


-- 


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

[Bug target/44199] ppc64 glibc miscompilation

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2010-05-19 19:09 ---
*** Bug 44200 has been marked as a duplicate of this bug. ***


-- 


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

[Bug target/44200] ppc64 glibc miscompilation

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2010-05-19 19:09 ---
Sorry.

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


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/44201] New: ppc64 glibc miscompilation

[jakub at gcc dot gnu dot org]

vfscanf is miscompiled by gcc 4.4, here is a shorter testcase that is
miscompiled also by 4.6:

extern void *alloca (__SIZE_TYPE__);
extern void bar (long *, char *);

long
foo (long x)
{
  long buf[400];
  char *p = alloca (x);
  bar (buf, p);
  return buf[0];
}

at -O2 -m64 results in:
...
bl .bar
nop
addi 1,31,3328
ld 3,112(31)
ld 0,16(1)
ld 31,-8(1)
mtlr 0
blr
Note that sched2 swapped incorrectly the stack frame release and ld 3,112(31),
so the ld insn reads from memory location 3216 below the stack (which is much
lower than 288 bytes of ppc64 red zone).
If a signal comes in in between addi and ld and something clobbers the stack,
this function (or, with 4.4 vfscanf) will return incorrect value.
There is nothing in the epilogue stack release insn that would make it a memory
barrier.


-- 
   Summary: ppc64 glibc miscompilation
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: powerpc64-linux


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

[Bug target/44200] New: ppc64 glibc miscompilation

[jakub at gcc dot gnu dot org]

vfscanf is miscompiled by gcc 4.4, here is a shorter testcase that is
miscompiled also by 4.6:

extern void *alloca (__SIZE_TYPE__);
extern void bar (long *, char *);

long
foo (long x)
{
  long buf[400];
  char *p = alloca (x);
  bar (buf, p);
  return buf[0];
}

at -O2 -m64 results in:
...
bl .bar
nop
addi 1,31,3328
ld 3,112(31)
ld 0,16(1)
ld 31,-8(1)
mtlr 0
blr
Note that sched2 swapped incorrectly the stack frame release and ld 3,112(31),
so the ld insn reads from memory location 3216 below the stack (which is much
lower than 288 bytes of ppc64 red zone).
If a signal comes in in between addi and ld and something clobbers the stack,
this function (or, with 4.4 vfscanf) will return incorrect value.
There is nothing in the epilogue stack release insn that would make it a memory
barrier.


-- 
   Summary: ppc64 glibc miscompilation
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: powerpc64-linux


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

[Bug target/44199] ppc64 glibc miscompilation

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-05-19 18:30 ---
Looks related to PR 30282.


-- 


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

[Bug target/44199] New: ppc64 glibc miscompilation

[jakub at gcc dot gnu dot org]

vfscanf is miscompiled by gcc 4.4, here is a shorter testcase that is
miscompiled also by 4.6:

extern void *alloca (__SIZE_TYPE__);
extern void bar (long *, char *);

long
foo (long x)
{
  long buf[400];
  char *p = alloca (x);
  bar (buf, p);
  return buf[0];
}

at -O2 -m64 results in:
...
bl .bar
nop
addi 1,31,3328
ld 3,112(31)
ld 0,16(1)
ld 31,-8(1)
mtlr 0
blr
Note that sched2 swapped incorrectly the stack frame release and ld 3,112(31),
so the ld insn reads from memory location 3216 below the stack (which is much
lower than 288 bytes of ppc64 red zone).
If a signal comes in in between addi and ld and something clobbers the stack,
this function (or, with 4.4 vfscanf) will return incorrect value.
There is nothing in the epilogue stack release insn that would make it a memory
barrier.


-- 
   Summary: ppc64 glibc miscompilation
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: powerpc64-linux


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

[Bug debug/44113] bad debugging information for unrolled loops

[drow at gcc dot gnu dot org]

--- Comment #8 from drow at gcc dot gnu dot org  2010-05-19 18:08 ---
It seems to me that a series of line notes for each copy of line 5 are the
right debug output, and if GCC can generate that, someone should hack up GDB
until it recognizes that and treats it sensibly.


-- 


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

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

--- Comment #136 from pinskia at gcc dot gnu dot org  2010-05-19 18:05 
---
*** Bug 44198 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||AlekM at hotmail dot com


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

[Bug c/44198] Constant floating point values are mutable (with '-O1')

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2010-05-19 18:05 ---
And it is as it works correctly with -std=c99 in 4.5.0 and above and it works
correctly on x86_64 or with -mfpmath=sse.

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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c/44198] Constant floating point values are mutable (with '-O1')

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-05-19 18:01 ---
I think this is a dup of bug 323.


-- 


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

[Bug c/44198] New: Constant floating point values are mutable (with '-O1')

[AlekM at hotmail dot com]

The example code below, compiled on x86 with gcc versions 4.1.2 through 4.4.0,
aborts when executed.

#include 
#include 

int main(void)__attribute__ ((optimize("O1")));  // Also with '-O2'
int main(void)
{
   const float a = rand(); // Any function call that returns 1804289383 will do
   volatile float tmp=a;

   assert(tmp==a); // This one aborts
   assert(tmp==a); // This one passes (if line above is replaced with printf)
}

If you replace assert() with two consecutive printf("%f ", a), two different
values are displayed for the constant variable a.


-- 
   Summary: Constant floating point values are mutable (with '-O1')
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: AlekM at hotmail dot com
 GCC build triplet: gcc version 4.4.0 20090514 (Red Hat 4.4.0-6) (GCC)
  GCC host triplet: Linux hld-lx 2.6.18-128.7.1.el5 #1 SMP Mon Aug 24
08:20:55 EDT 2
GCC target triplet: same as above


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

[Bug fortran/27989] -fbounds-check should check for too small arrays on subroutine calls

[dfranke at gcc dot gnu dot org]

--- Comment #3 from dfranke at gcc dot gnu dot org  2010-05-19 17:53 ---
*** Bug 30939 has been marked as a duplicate of this bug. ***


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu dot
   ||org


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

[Bug fortran/30939] Run-time check if dummy array sizes is larger than actual array size

[dfranke at gcc dot gnu dot org]

--- Comment #3 from dfranke at gcc dot gnu dot org  2010-05-19 17:53 ---
(In reply to comment #2)
> I dedicate it to the run time test.
> Test: Place program and subroutine in different files, compile and run them.
> NAG f95 -C=all shows then:

Same as PR27989.


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


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/44074] Solaris 2.9 x86 Sun assembler doesn't like rep/lock prefixes on same line

[ro at gcc dot gnu dot org]

--- Comment #11 from ro at gcc dot gnu dot org  2010-05-19 17:44 ---
Fixed for 4.4.5, 4.5.1, 4.6.0.


-- 

ro at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||4.4.5 4.5.1 4.6.0
 Resolution||FIXED
   Target Milestone|--- |4.5.1


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

[Bug target/44074] Solaris 2.9 x86 Sun assembler doesn't like rep/lock prefixes on same line

[ro at gcc dot gnu dot org]

--- Comment #10 from ro at gcc dot gnu dot org  2010-05-19 17:42 ---
Subject: Bug 44074

Author: ro
Date: Wed May 19 17:42:00 2010
New Revision: 159591

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159591
Log:
Backport from mainline:
2010-05-17  Rainer Orth  

PR target/44074
* configure.ac (HAVE_AS_IX86_REP_LOCK_PREFIX): New test.
* configure: Regenerate.
* config.in: Regenerate.
* config/i386/i386.c (print_operand) : Also print ; if
!HAVE_AS_IX86_REP_LOCK_PREFIX.
Don't emit whitespace.
* config/i386/i386.md (*rep_movdi_rex64): Use {%;} after rep.
(*rep_movsi): Likewise.
(*rep_movsi_rex64): Likewise.
(*rep_movqi): Likewise.
(*rep_movqi_rex64): Likewise.
(*rep_stosdi_rex64): Likewise.
(*rep_stossi): Likewise.
(*rep_stossi_rex64): Likewise.
(*rep_stosqi): Likewise.
(*rep_stosqi_rex64): Likewise.
(*cmpstrnqi_nz_1): Use {%;} after repz.
(*cmpstrnqi_nz_rex_1): Likewise.
(*cmpstrnqi_1): Likewise.
(*cmpstrnqi_rex_1): Likewise.
(*strlenqi_1): Use {%;} after repnz.
(*strlenqi_rex_1): Likewise.
* config/i386/sync.md (memory_barrier_nosse): Replace {%;| } by {%;} .
(*sync_compare_and_swap): Likewise.
(sync_double_compare_and_swap): Likewise.
(*sync_double_compare_and_swapdi_pic): Likewise.
(sync_old_add): Likewise.
(sync_add): Likewise.
(sync_sub): Likewise.
(sync_): Likewise.

Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/config.in
branches/gcc-4_4-branch/gcc/config/i386/i386.c
branches/gcc-4_4-branch/gcc/config/i386/i386.md
branches/gcc-4_4-branch/gcc/config/i386/sync.md
branches/gcc-4_4-branch/gcc/configure
branches/gcc-4_4-branch/gcc/configure.ac


-- 


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

[Bug fortran/44055] Warn (-Wconversion*) when converting single to double precision

[dfranke at gcc dot gnu dot org]

--- Comment #5 from dfranke at gcc dot gnu dot org  2010-05-19 17:34 ---
Fixed in trunk. Closing.


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug target/44074] Solaris 2.9 x86 Sun assembler doesn't like rep/lock prefixes on same line

[ro at gcc dot gnu dot org]

--- Comment #9 from ro at gcc dot gnu dot org  2010-05-19 17:33 ---
Subject: Bug 44074

Author: ro
Date: Wed May 19 17:32:43 2010
New Revision: 159590

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159590
Log:
Backport from mainline:
2010-05-17  Rainer Orth  

PR target/44074
* configure.ac (HAVE_AS_IX86_REP_LOCK_PREFIX): New test.
* configure: Regenerate.
* config.in: Regenerate.
* config/i386/i386.c (print_operand) : Also print ; if
!HAVE_AS_IX86_REP_LOCK_PREFIX.
Don't emit whitespace.
* config/i386/i386.md (*rep_movdi_rex64): Use {%;} after rep.
(*rep_movsi): Likewise.
(*rep_movsi_rex64): Likewise.
(*rep_movqi): Likewise.
(*rep_movqi_rex64): Likewise.
(*rep_stosdi_rex64): Likewise.
(*rep_stossi): Likewise.
(*rep_stossi_rex64): Likewise.
(*rep_stosqi): Likewise.
(*rep_stosqi_rex64): Likewise.
(*cmpstrnqi_nz_1): Use {%;} after repz.
(*cmpstrnqi_nz_rex_1): Likewise.
(*cmpstrnqi_1): Likewise.
(*cmpstrnqi_rex_1): Likewise.
(*strlenqi_1): Use {%;} after repnz.
(*strlenqi_rex_1): Likewise.
* config/i386/sync.md (memory_barrier_nosse): Replace {%;| } by {%;} .
(*sync_compare_and_swap): Likewise.
(sync_double_compare_and_swap): Likewise.
(*sync_double_compare_and_swapdi_pic): Likewise.
(sync_old_add): Likewise.
(sync_add): Likewise.
(sync_sub): Likewise.
(sync_): Likewise.

Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/config.in
branches/gcc-4_5-branch/gcc/config/i386/i386.c
branches/gcc-4_5-branch/gcc/config/i386/i386.md
branches/gcc-4_5-branch/gcc/config/i386/sync.md
branches/gcc-4_5-branch/gcc/configure
branches/gcc-4_5-branch/gcc/configure.ac


-- 


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

[Bug fortran/38849] ICE in fold_convert with C_F_POINTER and C binding

[dfranke at gcc dot gnu dot org]

--- Comment #4 from dfranke at gcc dot gnu dot org  2010-05-19 16:57 ---
$ gfortran-4.5  pr38849.f90 
pr38849.f90: In function 'MAIN__':
pr38849.f90:9:0: internal compiler error: in gimplify_expr, at gimplify.c:7346

$ gfortran-svn  pr38849.f90 
gimplification failed:
chararr 
QI
size 
unit size 
align 8 symtab 0 alias set -1 canonical type 0xb77a3ba0
arg-types 
chain 
chain >>>
pointer_to_this >
unsigned SI
size 
unit size 
align 32 symtab 0 alias set -1 canonical type 0xb77a3c00>
constant
arg 0 
public external QI file pr38849.f90 line 5 col 0 align 8
chain 
used static QI file pr38849.f90 line 2 col 0 align 8 initial  result 
(mem:QI (symbol_ref:SI ("MAIN__") [flags 0x3] ) [0 S1 A8])
struct-function 0xb772239c chain >>>
pr38849.f90: In function 'MAIN__':
pr38849.f90:9:0: internal compiler error: gimplification failed

$ gfortran-svn -v
gcc version 4.6.0 20100518 (experimental) (GCC)


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dfranke at gcc dot gnu dot
   ||org
  Known to fail|4.3.2 4.4.0 |4.3.2 4.4.0 4.5.1 4.6.0


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

[Bug middle-end/44197] varpool SEGV

[ams at gcc dot gnu dot org]

--- Comment #2 from ams at gcc dot gnu dot org  2010-05-19 16:46 ---
Jeff, it was recommended that I add you as CC. Apologies if that was not
appropriate.


-- 


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

[Bug middle-end/44197] varpool SEGV

[ams at gcc dot gnu dot org]

--- Comment #1 from ams at gcc dot gnu dot org  2010-05-19 16:46 ---
Created an attachment (id=20703)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20703&action=view)
test case

This test case is reduced from uClibc sources.

To reproduce the bug:

cc1 -fpreprocessed __C_ctype_b_10.i -O1


-- 


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

[Bug middle-end/44197] New: varpool SEGV

[ams at gcc dot gnu dot org]

assemble_alias in varasm.c sets varpool->alias to 1, but fails to set
varpool->extra_name to anything.

This leads to trouble further down the line. In my case, varpool_remove_node
fails with a NULL-pointer exception.

This appears to be target/host independent. So far, the only work around I have
is to disable optimization.

Test case to follow ...


-- 
   Summary: varpool SEGV
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: critical
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ams at gcc dot gnu dot org


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

[Bug fortran/44055] Warn (-Wconversion*) when converting single to double precision

[dfranke at gcc dot gnu dot org]

--- Comment #4 from dfranke at gcc dot gnu dot org  2010-05-19 16:36 ---
Subject: Bug 44055

Author: dfranke
Date: Wed May 19 16:35:34 2010
New Revision: 159586

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159586
Log:
gcc/fortran/:
2010-05-19  Daniel Franke  

PR fortran/44055
* lang.opt (Wconversion-extra): New option.
* gfortran.h (gfc_option_t): Add warn_conversion_extra.
* options.c (gfc_init_options): Disable -Wconversion-extra by default.
(set_Wall): Enable -Wconversion.
(gfc_handle_option): Set warn_conversion_extra.
* intrinsic.c (gfc_convert_type_warn): Ignore kind conditions
introduced for -Wconversion if -Wconversion-extra is present.
* invoke.texi: Add -Wconversion to -Wall; document new behaviour of
-Wconversion; document -Wconversion-extra.

gcc/testsuite/:
2010-05-19  Daniel Franke  

PR fortran/44055
* gfortran.dg/c_sizeof_2.f90: Add -Wno-conversion to dg-options;
Fixed scope of C_SIZEOF.
* gfortran.dg/warn_conversion_2.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/warn_conversion_2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/intrinsic.c
trunk/gcc/fortran/invoke.texi
trunk/gcc/fortran/lang.opt
trunk/gcc/fortran/options.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/c_sizeof_2.f90


-- 


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

[Bug fortran/37744] ICE-on-invalid with ISO_C_BINDING

[dfranke at gcc dot gnu dot org]

--- Comment #7 from dfranke at gcc dot gnu dot org  2010-05-19 16:29 ---
Not related to types - this is more about namespace cleanup. Reduced testcase:

PROGRAM Main
  USE, INTRINSIC :: iso_c_binding
  CALL C_F_POINTER(rws, xrws)
  XXX ! any error will do
END PROGRAM Main

SUBROUTINE F()
END SUBROUTINE F

valgrind:
==24940== Invalid read of size 4
==24940==at 0x8173957: gfc_delete_symtree (symbol.c:2374)
==24940==by 0x4131BD5: (below main) (libc-start.c:226)
==24940==  Address 0x4308fc8 is 0 bytes inside a block of size 1,692 free'd
==24940==at 0x4024B3A: free (vg_replace_malloc.c:366)
==24940==by 0x812A3F5: gfc_free (misc.c:51)
==24940==by 0x4131BD5: (below main) (libc-start.c:226)

gdb:
Program received signal SIGSEGV, Segmentation fault.
0x081739b2 in gfc_find_symtree (st=0x2e1, name=0xb7eece00 "shape") at
/home/daniel/svn/gcc-svn/gcc/fortran/symbol.c:2393
2393  c = strcmp (name, st->name);
(gdb) bt
#0  0x081739b2 in gfc_find_symtree (st=0x2e1, name=0xb7eece00 "shape") at
/home/daniel/svn/gcc-svn/gcc/fortran/symbol.c:2393
#1  0x08173969 in gfc_delete_symtree (root=0x8c54760, name=0xb7eece00 "shape")
at /home/daniel/svn/gcc-svn/gcc/fortran/symbol.c:2374
#2  0x08174473 in gfc_undo_symbols () at
/home/daniel/svn/gcc-svn/gcc/fortran/symbol.c:2845
#3  0x081385ff in decode_statement () at
/home/daniel/svn/gcc-svn/gcc/fortran/parse.c:271
#4  0x0813a0e9 in next_free () at
/home/daniel/svn/gcc-svn/gcc/fortran/parse.c:722
#5  0x0813a4d2 in next_statement () at
/home/daniel/svn/gcc-svn/gcc/fortran/parse.c:907
#6  0x0813e6a6 in gfc_parse_file () at
/home/daniel/svn/gcc-svn/gcc/fortran/parse.c:4220
#7  0x0817cbba in gfc_be_parse_file (set_yydebug=0) at
/home/daniel/svn/gcc-svn/gcc/fortran/f95-lang.c:239
#8  0x084cfe1b in compile_file () at /home/daniel/svn/gcc-svn/gcc/toplev.c:1049
#9  0x084d1ed8 in do_compile () at /home/daniel/svn/gcc-svn/gcc/toplev.c:2393
#10 0x084d1f9e in toplev_main (argc=2, argv=0xb3c4) at
/home/daniel/svn/gcc-svn/gcc/toplev.c:2435
#11 0x0820961b in main (argc=2, argv=0xb3c4) at
/home/daniel/svn/gcc-svn/gcc/main.c:35


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail|4.3.2 4.3.3 4.3.4 4.4.0 |4.3.4 4.4.0 4.5.1 4.6.0
Summary|ICE-on-invalid with |ICE-on-invalid with
   |ISO_C_BINDING and TYPEs |ISO_C_BINDING


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

[Bug target/43810] [4.5 Regression] linking results in undefined references to _savegpr_* _restgpr_*_x

[raj dot khem at gmail dot com]

--- Comment #11 from raj dot khem at gmail dot com  2010-05-19 16:25 ---
(In reply to comment #10)
> See comment #4.  I believe this is a pilot error.
> 

yeah on 4.5.0 libgcc.so is a linker script but 4.4 is still broken with this
issues

I guess http://gcc.gnu.org/ml/gcc-cvs/2009-09/msg00315.html needs backported to
4.4 branch as well.


-- 


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

[Bug target/44139] Exporting emutls symbols from a DLL broken on w32 targets

[ktietz at gcc dot gnu dot org]

--- Comment #20 from ktietz at gcc dot gnu dot org  2010-05-19 16:18 ---
(In reply to comment #19)
> What is the relationship between this bug and PR 44132?  Richi and Honza seem
> to prefer the DECL_PRESERVE_P hack.  We will see if Iain's lowering works.  I
> don't think both the decl attribute merging patch and DECL_PRESERVE_P patch 
> are
> needed.
> 

I don't see here any relations AFAICS (beside both patches are touching
emutls).  This declaration preserve flag is fine, but AFAICS don't address this
issue.
The point here is that w32 targets dependent on original decl-attributes for
name-decoration. So Richi asked me, that I ask you, if you could test this
patch for AIX to avoid side-effects.


-- 


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

[Bug c++/44158] [C++0x] wrong overload resolution for copy-initialization from an rvalue

[jason at gcc dot gnu dot org]

--- Comment #9 from jason at gcc dot gnu dot org  2010-05-19 16:10 ---
Fixed for 4.5.1.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug c++/44157] [C++0x] GCC wrongly takes a std::initializer_list argument as non-deduced context

[jason at gcc dot gnu dot org]

--- Comment #3 from jason at gcc dot gnu dot org  2010-05-19 16:10 ---
Fixed for 4.5.1.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug lto/44196] lto1: ICE: tree check: expected field_decl, have type_decl in gimple_types_compatible_p, at gimple.c:3597

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2010-05-19 15:58 
---
Fixed for 4.6.  Leaving open for eventual backport for 4.5.1.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.5.0
  Known to work||4.6.0


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

[Bug lto/44196] lto1: ICE: tree check: expected field_decl, have type_decl in gimple_types_compatible_p, at gimple.c:3597

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2010-05-19 15:57 ---
Subject: Bug 44196

Author: rguenth
Date: Wed May 19 15:57:17 2010
New Revision: 159582

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159582
Log:
2010-05-19  Richard Guenther  

PR lto/44196
* tree.c (find_decls_types_r): Walk BLOCKs and its vars.

* g++.dg/lto/20100519-1_0.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/lto/20100519-1_0.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c


-- 


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

[Bug c++/44193] [4.3/4.4/4.5/4.6 Regression] function types, cv-quals and typename

[jason at gcc dot gnu dot org]

--- Comment #3 from jason at gcc dot gnu dot org  2010-05-19 15:50 ---
Subject: Bug 44193

Author: jason
Date: Wed May 19 15:49:39 2010
New Revision: 159580

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159580
Log:
PR c++/44193
* pt.c (tsubst) [TYPENAME_TYPE]: Discard cv-quals on
function/reference type.

Added:
branches/gcc-4_5-branch/gcc/testsuite/g++.dg/template/fntype1.C
Modified:
branches/gcc-4_5-branch/gcc/cp/ChangeLog
branches/gcc-4_5-branch/gcc/cp/pt.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/44157] [C++0x] GCC wrongly takes a std::initializer_list argument as non-deduced context

[jason at gcc dot gnu dot org]

--- Comment #2 from jason at gcc dot gnu dot org  2010-05-19 15:49 ---
Subject: Bug 44157

Author: jason
Date: Wed May 19 15:49:12 2010
New Revision: 159578

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159578
Log:
PR c++/44157
* call.c (build_over_call): Limit init-list deduction warning to
cases where the argument is actually an init-list.

Added:
branches/gcc-4_5-branch/gcc/testsuite/g++.dg/cpp0x/initlist34.C
Modified:
branches/gcc-4_5-branch/gcc/cp/ChangeLog
branches/gcc-4_5-branch/gcc/cp/call.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/44158] [C++0x] wrong overload resolution for copy-initialization from an rvalue

[jason at gcc dot gnu dot org]

--- Comment #8 from jason at gcc dot gnu dot org  2010-05-19 15:49 ---
Subject: Bug 44158

Author: jason
Date: Wed May 19 15:49:01 2010
New Revision: 159577

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159577
Log:
PR c++/44158
* call.c (build_over_call): Don't do bitwise copy for move ctor.

Modified:
branches/gcc-4_5-branch/gcc/cp/ChangeLog
branches/gcc-4_5-branch/gcc/cp/call.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
branches/gcc-4_5-branch/gcc/testsuite/g++.dg/cpp0x/rv-trivial-bug.C


-- 


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

[Bug debug/44113] bad debugging information for unrolled loops

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2010-05-19 15:45 ---
I guess that needs discussion with the GDB folks...


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tromey at gcc dot gnu dot
   ||org, jan dot kratochvil at
   ||redhat dot com, drow at gcc
   ||dot gnu dot org


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

[Bug c++/44193] [4.3/4.4/4.5/4.6 Regression] function types, cv-quals and typename

[jason at gcc dot gnu dot org]

--- Comment #2 from jason at gcc dot gnu dot org  2010-05-19 15:45 ---
Subject: Bug 44193

Author: jason
Date: Wed May 19 15:44:33 2010
New Revision: 159576

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159576
Log:
PR c++/44193
* pt.c (tsubst) [TYPENAME_TYPE]: Discard cv-quals on
function/reference type.

Added:
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/fntype1.C
Modified:
branches/gcc-4_4-branch/gcc/cp/ChangeLog
branches/gcc-4_4-branch/gcc/cp/pt.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/44193] [4.3/4.4/4.5/4.6 Regression] function types, cv-quals and typename

[jason at gcc dot gnu dot org]

--- Comment #1 from jason at gcc dot gnu dot org  2010-05-19 15:44 ---
Subject: Bug 44193

Author: jason
Date: Wed May 19 15:44:08 2010
New Revision: 159575

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159575
Log:
PR c++/44193
* pt.c (tsubst) [TYPENAME_TYPE]: Discard cv-quals on
function/reference type.

Added:
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/template/fntype1.C
Modified:
branches/gcc-4_3-branch/gcc/cp/ChangeLog
branches/gcc-4_3-branch/gcc/cp/pt.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/template/qualttp20.C


-- 


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

[Bug debug/43521] java: "this" pointer not marked with DW_AT_artificial

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2010-05-19 15:42 ---
Created an attachment (id=20702)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20702&action=view)
gcc46-pr43521.patch

Untested fix that seems to work on this testcase.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug target/44139] Exporting emutls symbols from a DLL broken on w32 targets

[dje at gcc dot gnu dot org]

--- Comment #19 from dje at gcc dot gnu dot org  2010-05-19 15:40 ---
What is the relationship between this bug and PR 44132?  Richi and Honza seem
to prefer the DECL_PRESERVE_P hack.  We will see if Iain's lowering works.  I
don't think both the decl attribute merging patch and DECL_PRESERVE_P patch are
needed.


-- 


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

[Bug debug/44113] bad debugging information for unrolled loops

[andi-gcc at firstfloor dot org]

--- Comment #6 from andi-gcc at firstfloor dot org  2010-05-19 15:40 ---
Jakub, are you saying this should be fixed in gdb? 
How could gdb detect this case?

If gcc emitted another .loc like you said couldn't gdb check for this?


-- 


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

[Bug lto/44196] lto1: ICE: tree check: expected field_decl, have type_decl in gimple_types_compatible_p, at gimple.c:3597

[rguenther at suse dot de]

--- Comment #8 from rguenther at suse dot de  2010-05-19 15:13 ---
Subject: Re:  lto1: ICE: tree check: expected field_decl, have
 type_decl in gimple_types_compatible_p, at gimple.c:3597

On Wed, 19 May 2010, hubicka at ucw dot cz wrote:

> --- Comment #7 from hubicka at ucw dot cz  2010-05-19 15:11 ---
> Subject: Re:  lto1: ICE: tree check: expected field_decl,
> have type_decl in gimple_types_compatible_p, at gimple.c:3597
> 
> > I suppose this is an alias but we fail to clear its body/block tree.  We end
> > up refering to some TYPE_DECL in its BLOCK tree from somewhere else
> > (but we don't stream that function decl in the end).
> 
> For aliases we never clear their body/blocks because they are never finalized.
> If this is same_body_alias produced by C++ FE, I guess it should be 
> responsible
> for giving us a decl alone.  Overall C++ FE is leaking quite a few 
> bodies/trees
> in unfinalized decls.   I used to have aptch to clear them out but it was
> rejected
> for PCH reasons.

Ok, so my patch might be even correct as we are reaching the odd
TYPE_DECL via streaming block abstract origin from a different function.

Richard.


-- 


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

[Bug lto/44196] lto1: ICE: tree check: expected field_decl, have type_decl in gimple_types_compatible_p, at gimple.c:3597

[hubicka at ucw dot cz]

--- Comment #7 from hubicka at ucw dot cz  2010-05-19 15:11 ---
Subject: Re:  lto1: ICE: tree check: expected field_decl,
have type_decl in gimple_types_compatible_p, at gimple.c:3597

> I suppose this is an alias but we fail to clear its body/block tree.  We end
> up refering to some TYPE_DECL in its BLOCK tree from somewhere else
> (but we don't stream that function decl in the end).

For aliases we never clear their body/blocks because they are never finalized.
If this is same_body_alias produced by C++ FE, I guess it should be responsible
for giving us a decl alone.  Overall C++ FE is leaking quite a few bodies/trees
in unfinalized decls.   I used to have aptch to clear them out but it was
rejected
for PCH reasons.

Honza


-- 


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

[Bug middle-end/43987] [4.5 Regression] type-punning causes broken binaries unless -O0 is used

[rguenth at gcc dot gnu dot org]

--- Comment #23 from rguenth at gcc dot gnu dot org  2010-05-19 15:08 
---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug lto/44196] lto1: ICE: tree check: expected field_decl, have type_decl in gimple_types_compatible_p, at gimple.c:3597

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2010-05-19 15:08 ---
I suppose this is an alias but we fail to clear its body/block tree.  We end
up refering to some TYPE_DECL in its BLOCK tree from somewhere else
(but we don't stream that function decl in the end).


-- 


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

[Bug lto/44196] lto1: ICE: tree check: expected field_decl, have type_decl in gimple_types_compatible_p, at gimple.c:3597

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2010-05-19 15:01 ---
Hm, we have a cgraph node

ConstValueTypeSerializationBuffer::ConstValueTypeSerializationBuffer(Ordinal)
[with Ordinal = int]/2(1) @0x77edd930 (asm:
_ZN33ConstValueTypeSerializationBufferIiEC2Ei) analyzed 11 time, 12 benefit 2
size, 3 benefit reachable body finalized
  called by: int main()/0 (1.00 per call) (can throw external) 
  calls: static void
DirectSerializationTraits::fromCountToDirectBytes(Ordinal) [with
Ordinal = int]/4 (1.00 per call) 
  References: 
  Refering this function: 
  aliases & thunks:
ConstValueTypeSerializationBuffer::ConstValueTypeSerializationBuffer(Ordinal)
[with Ordinal = int]/3 (asm: _ZN33ConstValueTypeSerializationBufferIiEC1Ei)

where its function decl has DECL_SAVED_TREE, DECL_INITIAL and
gimple_has_body_p is false.  Huh.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu dot
   ||org


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

[Bug debug/43540] ICE: vector VEC(dw_cfi_ref,heap) grow domain error, in output_cfis at dwarf2out.c:3346 or OOM-killed

[jakub at gcc dot gnu dot org]

--- Comment #10 from jakub at gcc dot gnu dot org  2010-05-19 14:56 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug debug/43762] VLA artificial length var loclist is missing DW_OP_stack_value

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2010-05-19 14:55 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug debug/43950] fortran: Use DW_AT_identifier_case

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2010-05-19 14:54 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug middle-end/43602] ___emutls_v.__gcov_indirect_call_[counters|callee] undefined on *-*-darwin*

[iains at gcc dot gnu dot org]

--- Comment #22 from iains at gcc dot gnu dot org  2010-05-19 14:54 ---
I would imagine that this will ultimately affect all EMUTLS targets even tho
it's against darwin.

tree-profile.c is generating gimple directly  for the inserted statements -
AFAICT it's assuming that these don't need further expansion/gimplification...

We need to substitute a reference and call for each emutls var ref. so that
needs to be stuffed in and gimplified.. 

on my TODO if unless someone gets there first .. 


-- 

iains at gcc dot gnu dot org changed:

   What|Removed |Added

 CC|developer at sandoe-|iains at gcc dot gnu dot org
   |acoustics dot co dot uk |


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

[Bug debug/44113] bad debugging information for unrolled loops

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2010-05-19 14:52 ---
The problem is just that there are no instructions with locus on line 4 - with
unrolling no traces of the for loop in the assembly remains and all
instructions in the body have line 5 and immediately after it another unrolled
iteration has the same line.
Apparently gdb on next just puts a breakpoint on the first insn after it that
has different file or line number.  GCC could emit extra .loc 1 5 0 directives
which would just add another row in the line table, or .loc 1 5 0 is_stmt 0
right after the first insn and .loc 1 5 0 is_stmt 1 back before first insn of
the next iteration, but apparently this doesn't change anything in gdb.  Not
even lying and alternating .loc 1 5 0 and .loc 1 5 1 helps.  And, putting
extra .loc 1 4 0 covering no instructions doesn't change anything either.

So I'm afraid there is nothing to do here on the gcc side, except lying that
some insn comes from some other line (and for unrolling where the body is just
one insn there is nothing to do at all).


-- 


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

[Bug middle-end/43987] [4.5 Regression] type-punning causes broken binaries unless -O0 is used

[rguenth at gcc dot gnu dot org]

--- Comment #22 from rguenth at gcc dot gnu dot org  2010-05-19 14:48 
---
Subject: Bug 43987

Author: rguenth
Date: Wed May 19 14:48:24 2010
New Revision: 159567

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159567
Log:
2010-05-19  Richard Guenther  

PR tree-optimization/43987
* tree-ssa-structalias.c (could_have_pointers): For possibly
address-taken variables force pointers to be recorded.
(create_variable_info_for_1): Likewise.
(push_fields_onto_fieldstack): Pass in wheter all fields
must have pointers.
(find_func_aliases): Query types instead of vars whether
they contain pointers where appropriate.

* gcc.c-torture/execute/pr43987.c: New testcase.
* gcc.dg/torture/pta-escape-1.c: Adjust.
* gcc.dg/tree-ssa/pta-escape-1.c: Likewise.
* gcc.dg/tree-ssa/pta-escape-2.c: Likewise.
* gcc.dg/tree-ssa/pta-escape-3.c: Likewise.
* gcc.dg/torture/ipa-pta-1.c: Likewise.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.c-torture/execute/pr43987.c
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/torture/ipa-pta-1.c
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/torture/pta-escape-1.c
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/tree-ssa/pta-escape-1.c
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/tree-ssa/pta-escape-2.c
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/tree-ssa/pta-escape-3.c
branches/gcc-4_5-branch/gcc/tree-ssa-structalias.c


-- 


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[iains at gcc dot gnu dot org]

--- Comment #21 from iains at gcc dot gnu dot org  2010-05-19 14:48 ---
Created an attachment (id=20701)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20701&action=view)
latest.. 

this is mostly there ... might be worth trying on other platforms for feedback.

without the catch-net of expr.c (which covered up several things.. )

When stuff works here it seems to work across the board now (including lto,
whopr).

three issues:
1/ Finalization of emutls control vars.
2/ Failure to emit constructor for uninitialized control vars.
3/ Small buglet in emutls.

strategy for 
(1)
 a) finalization of the control vars is cascaded from finalization of the
user-land vars in varpool.c 
 b) a mop-up pass is carried out in emutls_final() - this is needed to pick up
vars introduced by late passes (in particular by OMP).

 c) The initializer for init vars is applied and decl-finalized as soon as it
is presented (we keep a mark to notice if the user tries to re-init).

 d) I've reorganized the code in varpool_finalize_decl () to ensure that
varpool_enqueue_needed_node () is not done until after all the checks have been
carried out for 'needed'.
 e) Removed some redundant calls to varpool_assemble_pending_decls () from
varpool_finalize_decl ().

2.  
 (a) some code re-organization in varasm.c to put all the emutls stuff
together. 
 (b) re-wrote the emutls structure to put the pointer at the start.
 (c) all tls control vars are static and they all need to be constructed -
(FWIW DECL_COMMON() was never set anyway)/

3. I put some comments into emutls.c since I had to figure it out ... and a
minor bug that would hit after you reached 32 emutls vars.


I'd welcome feedback on the approach(es) and whether it helps on other EMUTLS
platforms.


What is **NOT** fixed:
A>> there is still some leakage in OMP (some interaction with threadprivate)  I
will carry on looking at that ... 

B>> PR43602 -- the tree-profile pass generates gimple directly without
considering that it might need to be further gimplifed... 
C>> PR44140 -- although it shows up in a tls test is not realted to these
issues.


-- 

iains at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #20688|0   |1
is obsolete||
  Attachment #20693|0   |1
is obsolete||


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

[Bug fortran/38822] Compile-time simplification of x**(real)

[dfranke at gcc dot gnu dot org]

--- Comment #17 from dfranke at gcc dot gnu dot org  2010-05-19 14:43 
---
No more ICE, removed keyword.


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |


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

[Bug lto/44196] lto1: ICE: tree check: expected field_decl, have type_decl in gimple_types_compatible_p, at gimple.c:3597

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2010-05-19 14:40 ---
Hm, we still have TYPE_DECLs in TYPE_FIELDs somehow.  I have a patch.


-- 


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

[Bug lto/44196] lto1: ICE: tree check: expected field_decl, have type_decl in gimple_types_compatible_p, at gimple.c:3597

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-05-19 14:10 ---
template  
struct DirectSerializationTraits
{
  static void fromCountToDirectBytes(const Ordinal count) {}
};
template class SerializationTraits
  : public DirectSerializationTraits { };
template 
class ConstValueTypeSerializationBuffer
{
public:
ConstValueTypeSerializationBuffer(const Ordinal count)
  {
typedef SerializationTraits SerT;
SerT::fromCountToDirectBytes(count);
  }
};
int main ()
{
  ConstValueTypeSerializationBuffer charSendBuffer(1);
} 


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2010-05-19 13:59:35 |2010-05-19 14:10:32
   date||


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

[Bug bootstrap/43870] ICE in gcc/config/soft-fp/divtf3.c

[ro at CeBiTec dot Uni-Bielefeld dot DE]

--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld dot DE  2010-05-19 
14:07 ---
Subject: Re:  ICE in gcc/config/soft-fp/divtf3.c

> --- Comment #8 from zadeck at naturalbridge dot com  2010-05-19 14:06 
> ---
> df maintainers cannot approve their own patches.   you should get bonzini or
> any other back end maintainer to approve it.

Understood: all I meant was that the ChangeLog entry would name you as
the patch author.

> thanks for doing the testing.

Thanks for the blazingly fast response.

Rainer


-- 


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

[Bug bootstrap/43870] ICE in gcc/config/soft-fp/divtf3.c

[zadeck at naturalbridge dot com]

--- Comment #8 from zadeck at naturalbridge dot com  2010-05-19 14:06 
---
df maintainers cannot approve their own patches.   you should get bonzini or
any other back end maintainer to approve it.

thanks for doing the testing.

kenny


-- 


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

[Bug bootstrap/43870] ICE in gcc/config/soft-fp/divtf3.c

[ro at CeBiTec dot Uni-Bielefeld dot DE]

--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld dot DE  2010-05-19 
14:03 ---
Subject: Re:  ICE in gcc/config/soft-fp/divtf3.c

> --- Comment #6 from zadeck at naturalbridge dot com  2010-05-19 13:41 
> ---
> I have a deadline and do not have time to play with this.  The comparison
> function in df-scan.c, df_ref_compare, is not stable according to what has 
> been
> discussed in pr42157.   however, it does satisfy the definition of qsort in 
> the
> linux manuals.

I've no idea if the Solaris 8 (and IRIX 5) qsort violates ISO C90 here.

> if you need it to be that stable for those platforms, then change the last 
> line
> of df_ref_compare from "return 0;" to be 
>
> return (int)DF_REF_ORDER (ref1) - (int)DF_REF_ORDER (ref2);

Thanks, that's all I needed: bootstrap is past the ICE in the stage1
libgcc now, I'll let if finish and submit the patch, attributed to you,
once testing is complete.

Rainer


-- 


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

[Bug lto/44196] lto1: ICE: tree check: expected field_decl, have type_decl in gimple_types_compatible_p, at gimple.c:3597

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-05-19 13:59 ---
Confirmed.  Reducing.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||lto
   Last reconfirmed|-00-00 00:00:00 |2010-05-19 13:59:35
   date||
Summary|lto1: internal compiler |lto1: ICE: tree check:
   |error: Segmentation fault   |expected field_decl, have
   ||type_decl in
   ||gimple_types_compatible_p,
   ||at gimple.c:3597


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

[Bug debug/44178] -fcompare-debug failure with -O1 -fgcse -fsched-pressure -funroll-loops -fschedule-insns

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2010-05-19 13:53 ---
Created an attachment (id=20700)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20700&action=view)
gcc46-pr44178.patch

Untested fix.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED


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

[Bug bootstrap/43870] ICE in gcc/config/soft-fp/divtf3.c

[zadeck at naturalbridge dot com]

--- Comment #6 from zadeck at naturalbridge dot com  2010-05-19 13:41 
---
I have a deadline and do not have time to play with this.  The comparison
function in df-scan.c, df_ref_compare, is not stable according to what has been
discussed in pr42157.   however, it does satisfy the definition of qsort in the
linux manuals.

if you need it to be that stable for those platforms, then change the last line
of df_ref_compare from "return 0;" to be 

return (int)DF_REF_ORDER (ref1) - (int)DF_REF_ORDER (ref2);


-- 


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

[Bug lto/44196] lto1: internal compiler error: Segmentation fault

[martin dot kronbichler at it dot uu dot se]

--- Comment #1 from martin dot kronbichler at it dot uu dot se  2010-05-19 
13:35 ---
Created an attachment (id=20699)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20699&action=view)
File that triggers the problem when linking a shared library

A reduced testcase. Extracted from the Trilinos library Tpetra
(trilinos.sandia.gov).


-- 


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