[Bug fortran/39352] gfortran.dg/vect/pr39318.f90 doesn't work on ia64

[burnus at gcc dot gnu dot org]

--- Comment #6 from burnus at gcc dot gnu dot org  2009-05-15 06:57 ---
Fixed on the trunk (4.5). Thanks for reporting  HJ and thanks to Steve E. for
providing an initial patch, which pointed into the right direction.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug fortran/39352] gfortran.dg/vect/pr39318.f90 doesn't work on ia64

[burnus at gcc dot gnu dot org]

--- Comment #5 from burnus at gcc dot gnu dot org  2009-05-15 06:53 ---
Subject: Bug 39352

Author: burnus
Date: Fri May 15 06:52:41 2009
New Revision: 147559

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147559
Log:
2009-05-15  Tobias Burnus  

PR fortran/39352
* f95-lang.c: Add gfc_maybe_initialize_eh.
* gfortran.h: Add gfc_maybe_initialize_eh prototype.
* Make-lang.in: Add new .h dendencies for f95-lang.c
* openmp.c (resolve_omp_do): Call gfc_maybe_initialize_eh.
* misc.c (gfc_free): Avoid #define trickery for free.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/Make-lang.in
trunk/gcc/fortran/f95-lang.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/misc.c
trunk/gcc/fortran/openmp.c


-- 


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

[Bug target/38643] Doesn't hide (visibility-wise) vtables and VTTs on ARM EABI

[ramana at gcc dot gnu dot org]

--- Comment #4 from ramana at gcc dot gnu dot org  2009-05-15 06:28 ---
Doesn't work on 4.3 branch rev. 147478 .Works fine on trunk.


-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-05-15 06:28:38
   date||


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

[Bug other/26601] --whole-program --combine with gcc4.1 fails to link cpu2000 benchmarks

[bje at gcc dot gnu dot org]

--- Comment #2 from bje at gcc dot gnu dot org  2009-05-15 05:55 ---
There is no problem with current GCC that I can see.  The integer benchmarks
that fail to compile can be attributed to various C bugs such as mismatched
types between compilation units (eg. extern int foo in one file and char *foo
in another) that would not detected by separate compilation.


-- 

bje at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug c/40148] gcc 4.4.0 fails to build on Sparc Solaris 10

[peter dot kruse at lbbw dot de]

--- Comment #5 from peter dot kruse at lbbw dot de  2009-05-15 05:36 ---
(In reply to comment #4)
> > Thanks for the speed-of-light response.  I'm just thinking, could it be 
> > related
> > to the "-fPIC" argument (I found that in my CFLAGS)?
> 
> Yes, please don't set CFLAGS when building GCC.  I cannot reproduce.
> 

Alright, without -fPIC it compiles, I didn't have this problem with other
versions of gcc.  But ok, you're never too old to learn.


-- 


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

[Bug other/26601] --whole-program --combine with gcc4.1 fails to link cpu2000 benchmarks

[bje at gcc dot gnu dot org]

--- Comment #1 from bje at gcc dot gnu dot org  2009-05-15 05:35 ---
177.mesa and 188.ammp work with mainline.  The remaining FP benchmarks do not
compile because -fwhole-program -combine is not supported for FORTRAN programs.


-- 


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

[Bug target/39942] Nonoptimal code - leaveq; xchg %ax,%ax; retq

[hjl dot tools at gmail dot com]

--- Comment #36 from hjl dot tools at gmail dot com  2009-05-15 04:32 
---
Created an attachment (id=17871)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17871&action=view)
An updated patch

A few comments:

1. 3 branch limit is per 16byte page, not 16byte window.
2. We should allow 3 branches in a 16byte page.
3. When we have 4 branches in a 16byte page, we only need to
pad to the 16byte page boundary before the 4th branch, which
will start at the next 16byte page.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

  Attachment #17870|0   |1
is obsolete||


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

[Bug c++/40155] [c++1x] variadic template pack problem

[bangerth at gmail dot com]

--- Comment #1 from bangerth at gmail dot com  2009-05-15 02:56 ---
Oh, should've said:

g/x> /home/bangerth/bin/x86/gcc-mainline/bin/c++ -std=c++0x -c x.cc
x.cc:9: error: invalid conversion from 'int (*)(double)' to 'int (*)()'
x.cc:5: error: too many arguments to function 'int forward_call(RT (*)(A ...),
typename identity::type ...) [with RT = int, A = , typename
identity::type = A]'
x.cc:9: error: at this point in file


-- 


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

[Bug c++/40155] New: [c++1x] variadic template pack problem

[bangerth at gmail dot com]

I'm fairly sure this should compile but it doesn't:
-
template  struct identity
{  typedef T type;  };

template 
int forward_call(RT (*) (A...), typename identity::type...);

int g (double);

int i = forward_call(&g, 0);
-

The problem is the expansion
  typename identity::type...
which should wrap identity::type around each element An of the
template pack A. I'm not entirely familiar with all the rules for
template packs yet, but I think that this should work, taking
the examples in
  http://www.jot.fm/issues/issue_2008_02/article2/
into account.

Best
 W.


-- 
   Summary: [c++1x] variadic template pack problem
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at gmail dot com


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

[Bug target/39942] Nonoptimal code - leaveq; xchg %ax,%ax; retq

[hjl dot tools at gmail dot com]

--- Comment #35 from hjl dot tools at gmail dot com  2009-05-15 02:23 
---
Created an attachment (id=17870)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17870&action=view)
A patch

This patch limits 3 branches per 16byte page.


-- 


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

[Bug middle-end/40154] New: internal compiler error: in do_SUBST, at combine.c:681

[rmansfield at qnx dot com]

r...@ryan:~/gcc/trunk/gcc/build/gcc$ ./xgcc -v
Using built-in specs.
Target: sh4-unknown-linux-gnu
Configured with: ../configure --build=i486-build_pc-linux-gnu
--host=i486-build_pc-linux-gnu --target=sh4-unknown-linux-gnu
--prefix=/home/ryan/crosstool-ng-1.3.1/targets/sh4-unknown-linux-gnu/build/gcc-core-static
--with-local-prefix=/home/ryan/x-tools/sh4-unknown-linux-gnu/sh4-unknown-linux-gnu/sys-root
--disable-multilib
--with-sysroot=/home/ryan/x-tools/sh4-unknown-linux-gnu/sh4-unknown-linux-gnu/sys-root
--with-newlib --enable-threads=no --disable-shared --enable-__cxa_atexit
--disable-nls --enable-symvers=gnu --enable-languages=c
--enable-target-optspace
Thread model: single
gcc version 4.5.0 20090515 (experimental) [trunk revision 147550] (GCC)


$ cat ~/ice.i
char buf[20];

int main() {
long long int t = 50;
strcpy(buf, "hello world");
t *= 10;
for(;;)
foo(&t);
}
r...@ryan:~/gcc/trunk/gcc/build/gcc$ ./xgcc -B. -O ~/ice.i
/home/ryan/ice.i: In function 'main':
/home/ryan/ice.i:5: warning: incompatible implicit declaration of built-in
function 'strcpy'
/home/ryan/ice.i:9: internal compiler error: in do_SUBST, at combine.c:681
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Works in gcc 4.3.3. Fails in gcc 4.4.0 and trunk (4.5.0 20090515)


-- 
   Summary: internal compiler error: in do_SUBST, at combine.c:681
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rmansfield at qnx dot com
 GCC build triplet: i486-build_pc-linux-gnu
  GCC host triplet: i486-build_pc-linux-gnu
GCC target triplet: sh4-unknown-linux-gnu


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

[Bug middle-end/39976] [4.5 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817

[luisgpm at linux dot vnet dot ibm dot com]

--- Comment #18 from luisgpm at linux dot vnet dot ibm dot com  2009-05-15 
02:19 ---
64-bit with -mcpu=power6

.L93:
fmul 20,11,13
fmul 19,11,0
addis 12,11,0xffe5
lfd 3,0(11)
addi 5,11,8
lfd 2,9472(12)
addis 14,5,0xffe5
fmadd 1,12,0,20
fmsub 12,12,13,19
lfd 20,9472(14)
lfd 19,8(11)
addi 11,5,8
fmul 11,1,13
fmul 21,1,2
fmul 22,1,3
fmul 8,1,0
fmadd 11,12,0,11
fmadd 5,12,3,21
fmsub 4,12,2,22
fmsub 12,12,13,8
fmul 1,11,19
fmul 22,11,20
fadd 9,9,5
fadd 10,10,4
fmsub 21,12,20,1
fmadd 2,12,19,22
fadd 10,10,21
fadd 9,9,2
bdnz .L93
.L265:
stfd 12,736(1) ---
mr 11,3   |
ld 5,736(1) --


-- 


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

[Bug middle-end/39976] [4.5 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817

[luisgpm at linux dot vnet dot ibm dot com]

--- Comment #17 from luisgpm at linux dot vnet dot ibm dot com  2009-05-15 
02:16 ---
Actually, 64-bit is affected too, but not with the "power6x" tuning i was
using. With "-mcpu=power6" i can reproduce the problem.

The problem seems to be a couple load instructions that are being pushed up
from a different basic block, and this results in a Load-hit-store hazard,
since we've pushed the load too close to a store to the same address.

I'm not sure this is a direct consequence of changes in the gimple code. Would
you know Matz?

I'll continue digging...

Luis


-- 


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

[Bug c++/40092] -std=gnu++0x expansion pattern fails with error about derived template instead of actual template

[cppljevans at suddenlink dot net]

--- Comment #4 from cppljevans at suddenlink dot net  2009-05-15 01:19 
---
Created an attachment (id=17869)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17869&action=view)
Much simpler code showing problem

Code has #defines which can be enabled or disabled to 
show or hide bug.


-- 


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

[Bug tree-optimization/40087] [4.3/4.4/4.5 Regression] Number of iterations analysis wrong

[rakdver at gcc dot gnu dot org]

--- Comment #6 from rakdver at gcc dot gnu dot org  2009-05-15 00:34 ---
(In reply to comment #5)
> It is number of iteration analysis that gets it wrong (I suppose it might get
> confused by the two exits of the loop?).

Sort of; # of iterations analysis assumes that pointers never wrap, and uses
this assumption to derive a wrong number of iterations for the first exit
(which is not taken).  We had a similar problem before (PR 25985), but I
somehow persuaded myself that this cannot happen with pointers.


-- 


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

[Bug testsuite/40130] using RUNTESTFLAGS="--target_board 'foo{-mxyz,-mjkl,}'" screws up ieee.exp (and possibly others?)

[bonzini at gnu dot org]

--- Comment #8 from bonzini at gnu dot org  2009-05-14 22:01 ---
Subject: Re:  using RUNTESTFLAGS="--target_board 
'foo{-mxyz,-mjkl,}'" screws up ieee.exp (and possibly others?)

> Paolo, is it possible that you're using a target triplet that doesn't match 
> the
> checks in ieee.exp for using -ffloat-store?  Those are
>
>    [istarget "i\[34567\]86-*-*"]
>    { [istarget "x86_64-*-*"] && [check_effective_target_ilp32] }

No, it's just i686-pc-linux-gnu.  Without --target_board "etc." it
works; with I got this spurious failure.

But it's not a wrong code, so I think we can close as invalid.


-- 


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

[Bug rtl-optimization/40153] New: Long long comparison optimized away incorrectly in Thumb code.

[dougkwan at google dot com]

Several versions of gcc (trunk, 4.4.0, 4.3.1 and 4.3.3) mis-compiled this test
case.

bug.c
/* compile with -Os -mthumb */
extern void abort (void);

static int llcmp(long long a, long long b);

struct info {
  long unsigned ll;
};

int __attribute__((noinline))
cmp(const void *a, const void *b)
{
  struct info *pa = *((struct info **)a);
  struct info *pb = *((struct info **)b);
  return llcmp(pa->ll, pb->ll);
}

static int
llcmp(long long a, long long b)
{
  if (a < b)
return -1;
  if (a > b)
return 1;
  return 0;
}

int
main ()
{
  struct info pa, pb;
  struct info *unsorted[2];

  unsorted[0] = &pa;
  unsorted[1] = &pb;

  pa.ll = 1;
  pb.ll = 2;
  if (cmp (&unsorted[0], &unsorted[1]) != -1)
abort();

  pa.ll = 2;
  pb.ll = 1;
  if (cmp (&unsorted[0], &unsorted[1]) != 1)
abort();

  pa.ll = 1;
  pb.ll = 1;
  if (cmp (&unsorted[0], &unsorted[1]) != 0)
abort();

  return 0;
}
--

sh-3.2$ arm-unknown-linux-gnueabi-gcc -Os -mthumb bug.c
sh-3.2$ /disk2/dougkwan/qemu/install/bin/qemu-arm -L
~/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root a.out
qemu: uncaught target signal 6 (Aborted) - exiting
sh-3.2$ arm-unknown-linux-gnueabi-gcc  -mthumb bug.csh-3.2$
/disk2/dougkwan/qemu/install/bin/qemu-arm -L
~/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root a.out
sh-3.2$ 

Below is code generate for the function cmp:

.align  1
.global cmp
.code   16
.thumb_func
.type   cmp, %function
cmp:
push{lr}
ldr r3, [r0]
ldr r2, [r1]
ldr r3, [r3]
ldr r2, [r2]
cmp r2, r3
bhi .L6
mov r0, #0
b   .L2
.L6:
mov r0, #1
neg r0, r0
.L2:
@ sp needed for prologue
pop {pc}
.size   cmp, .-cmp
.align  1

Note that the compiled function only returns 0 and 1 where as the same function
in the source code return values -1, 0 and 1.


-- 
   Summary: Long long comparison optimized away incorrectly in Thumb
code.
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dougkwan at google dot com
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: arm-unknown-linux-gnueabi


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

[Bug libstdc++/36211] __iconv_adaptor chooses char** where const char** is required

[billingd at gcc dot gnu dot org]

--- Comment #10 from billingd at gcc dot gnu dot org  2009-05-14 21:51 
---
Patch is approved - http://gcc.gnu.org/ml/libstdc++/2009-05/msg00098.html


-- 

billingd at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |billingd at gcc dot gnu dot
   |dot org |org
 Status|WAITING |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-05-14 21:51:26
   date||


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

[Bug testsuite/40130] using RUNTESTFLAGS="--target_board 'foo{-mxyz,-mjkl,}'" screws up ieee.exp (and possibly others?)

[janis at gcc dot gnu dot org]

--- Comment #7 from janis at gcc dot gnu dot org  2009-05-14 21:23 ---
I can't reproduce this on my x86 laptop.  When I use the "make check" line
shown in comment #6, each compile for the ieee.exp tests uses -ffloat-store.

Paolo, is it possible that you're using a target triplet that doesn't match the
checks in ieee.exp for using -ffloat-store?  Those are

[istarget "i\[34567\]86-*-*"]
{ [istarget "x86_64-*-*"] && [check_effective_target_ilp32] }


-- 


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

[Bug c/40065] spurious format string warnings

[bje at gcc dot gnu dot org]

--- Comment #6 from bje at gcc dot gnu dot org  2009-05-14 21:12 ---
Not a bug.


-- 

bje at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug driver/40144] [4.5 Regression] ice in common_handle_option

[steven at gcc dot gnu dot org]

--- Comment #5 from steven at gcc dot gnu dot org  2009-05-14 20:57 ---
http://gcc.gnu.org/viewcvs?view=rev&revision=147543


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug driver/40144] [4.5 Regression] ice in common_handle_option

[steven at gcc dot gnu dot org]

--- Comment #4 from steven at gcc dot gnu dot org  2009-05-14 20:57 ---
Subject: Bug 40144

Author: steven
Date: Thu May 14 20:56:54 2009
New Revision: 147543

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147543
Log:
PR driver/40144
* opts.c (common_handle_option): Add OPT_fcse_skip_blocks as a no-op.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/opts.c


-- 


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

[Bug fortran/39971] kinds.h fails at building libgfortran

[gustcr at yahoo dot com dot ar]

--- Comment #17 from gustcr at yahoo dot com dot ar  2009-05-14 20:25 
---
Unfortunately I failed to apply the patch to both version 4.4.0 and 4.3.0 so I
am stuck here. It was probably written for some specific version, but I don't
know which one

dirac:~/local/src/gcc-4.3.0/fixincludes$ patch -p0 -i patch
patching file `fixincl.x'
Hunk #1 FAILED at 2.
Hunk #2 FAILED at 26.
Hunk #3 FAILED at 35.
Hunk #4 FAILED at 2195.
Hunk #5 FAILED at 2230.
Hunk #6 FAILED at 2275.
Hunk #7 FAILED at 2311.
7 out of 7 hunks FAILED -- saving rejects to fixincl.x.rej
patching file `inclhack.def'
Hunk #1 FAILED at 1291.
Hunk #2 FAILED at 1322.
Hunk #3 FAILED at 1346.
Hunk #4 FAILED at 1365.
4 out of 4 hunks FAILED -- saving rejects to inclhack.def.rej
patching file `fixincl.c'
Hunk #1 succeeded at 38 (offset 1 line).
Hunk #2 FAILED at 1108.
1 out of 2 hunks FAILED -- saving rejects to fixincl.c.rej


-- 


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

[Bug driver/40144] [4.5 Regression] ice in common_handle_option

[steven at gcc dot gnu dot org]

--- Comment #3 from steven at gcc dot gnu dot org  2009-05-14 20:24 ---
FWIW:
-fstrength-reduce is a no-op
-fcse-follow-jumps is a no-op
-fcse-skip-blocks -is a no-op (the crash will be fixed before the day is over)
-fforce-addr isa  no-op

The gnuboy maintainers should probably look into updating their Makefile, if
they want to hand-tune the optimizations.


-- 


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

[Bug inline-asm/40152] Illegal instruction in bits/mathinline.h:613

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|major   |normal
  Component|c++ |inline-asm


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

[Bug driver/40144] [4.5 Regression] ice in common_handle_option

[steven at gcc dot gnu dot org]

-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 CC|steven at gcc dot gnu dot   |
   |org |
 AssignedTo|unassigned at gcc dot gnu   |steven at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-05-14 11:20:31 |2009-05-14 20:14:57
   date||


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

[Bug c++/40152] New: Illegal instruction in bits/mathinline.h:613

[vaspoupkine2 at gmail dot com]

Compiler error message:

/usr/include/bits/mathinline.h: In function ‘double acosh(double)’:
/usr/include/bits/mathinline.h:613: internal compiler error: Illegal
instruction


-- 
   Summary: Illegal instruction in bits/mathinline.h:613
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vaspoupkine2 at gmail dot com


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

[Bug fortran/40045] ICE with type extension and -fdump-parse-tree

[domob at gcc dot gnu dot org]

--- Comment #6 from domob at gcc dot gnu dot org  2009-05-14 20:05 ---
Fixed (not addressing the "related" part in comment #2, but Janus promised to
work on it).


-- 

domob at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/40045] ICE with type extension and -fdump-parse-tree

[domob at gcc dot gnu dot org]

--- Comment #5 from domob at gcc dot gnu dot org  2009-05-14 20:03 ---
Subject: Bug 40045

Author: domob
Date: Thu May 14 20:02:46 2009
New Revision: 147540

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147540
Log:
2009-05-14  Daniel Kraft  

PR fortran/40045
* dump-parse-tree.c (show_typebound): Fix missing adaption to new
type-bound procedure storage structure.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/dump-parse-tree.c


-- 


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

[Bug target/39942] Nonoptimal code - leaveq; xchg %ax,%ax; retq

[vvv at ru dot ru]

--- Comment #34 from vvv at ru dot ru  2009-05-14 19:43 ---
(In reply to comment #32)
> Please make sure that you only test nop paddings for branch insns,
> not nop paddings for branch targets, which prefer 16byte alignment.

Additional tests (for Core2) results:
1. Execution time don't depend on paddings for branch target.
2. Execution time don't depend on position of NOP within 16-byte chunk with 4
branch. Even if NOP inserted between CMP and conditional jump.


-- 


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

[Bug target/39942] Nonoptimal code - leaveq; xchg %ax,%ax; retq

[hjl dot tools at gmail dot com]

--- Comment #33 from hjl dot tools at gmail dot com  2009-05-14 18:37 
---
(In reply to comment #20)
> Instruction decoders generally operate on whole cache-lines, so 16-byte chunk
> very very likely refers to a cache-line.
> 

That is true. For Intel CPUs, "16-bytes chunk" means memory range XXX0 - XXXF.


-- 


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

[Bug middle-end/40151] Possible memory leaks in ggc

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2009-05-14 18:26 ---
Likewise for tree-ssa-phiopt.c and reg-stack.c ones.

I think you need to look at the source instead of just doing a grep.

In fact these are all safe because they don't cross ggc_collect calls.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug middle-end/40151] Possible memory leaks in ggc

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-05-14 18:23 ---
I think the tree-ssa-sccvn.c and tree-ssa-pre.c ones are ok because they are
only used locally in that source and will not be used after the pass has run.


-- 


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

[Bug middle-end/40151] New: Possible memory leaks in ggc

[hjl dot tools at gmail dot com]

There may be memory leaks in ggc:

tree-tailcall.c: static tree m_acc, a_acc;
tree-ssa-sccvn.c: tree VN_TOP;
c-typeck.c: static tree constructor_max_index;
tree-ssa-phiopt.c: static tree condstoretemp;
tree-ssa-pre.c:

static tree pretemp;
static tree storetemp;
static tree prephitemp;

combine.c:

static rtx i2mod_old_rhs;
static rtx i2mod_new_rhs;

reg-stack.c:

static rtx not_a_num;
static rtx ix86_flags_rtx;

tree-ssa-structalias.c:

static tree anything_tree;
static tree nothing_tree;
static tree readonly_tree;
static tree escaped_tree;
static tree nonlocal_tree;
static tree callused_tree;
static tree storedanything_tree;


-- 
   Summary: Possible memory leaks in ggc
   Product: gcc
   Version: 4.5.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=40151

[Bug c/40150] internal compiler error: in cgraph_estimate_size_after_inlining, at ipa-inline.c:188

[josh at freedesktop dot org]

--- Comment #1 from josh at freedesktop dot org  2009-05-14 18:00 ---
Created an attachment (id=17868)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17868&action=view)
Tarball of preprocessed source files to reproduce ICE.


-- 


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

[Bug c/40150] New: internal compiler error: in cgraph_estimate_size_after_inlining, at ipa-inline.c:188

[josh at freedesktop dot org]

$ cc -std=gnu99 -O3 -fwhole-program -combine lv2log.i sim-common.i
flight-computer.i physics.i pressure_sensor.i sensors.i resample-optimal.i
coord.i mat.i vec.i isaac.i random.i normal.i normal_tab.i polynomial.i
polynomial_tab.i -lm -o lv2log
ziggurat/polynomial_tab.c: In function ‘main_chute’:
ziggurat/polynomial_tab.c:776: internal compiler error: in
cgraph_estimate_size_after_inlining, at ipa-inline.c:188
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

$ cc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.3-8'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.3.3 (Debian 4.3.3-8)

Tarball of preprocessed source attached.  (Since the bug involves
--combine -fwhole-program, it requires multiple source files, but I used
-save-temps to turn them all into corresponding .i files.)

- Josh Triplett


-- 
   Summary: internal compiler error: in
cgraph_estimate_size_after_inlining, at ipa-inline.c:188
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: josh at freedesktop dot org
 GCC build triplet: x86_64-linux-gnu
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu


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

[Bug libstdc++/40123] [4.5 Regression] Revision 147395 failed libstc++ tests

[paolo dot carlini at oracle dot com]

--- Comment #6 from paolo dot carlini at oracle dot com  2009-05-14 17:59 
---
Fixed.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug libstdc++/40123] [4.5 Regression] Revision 147395 failed libstc++ tests

[paolo at gcc dot gnu dot org]

--- Comment #5 from paolo at gcc dot gnu dot org  2009-05-14 17:56 ---
Subject: Bug 40123

Author: paolo
Date: Thu May 14 17:56:17 2009
New Revision: 147538

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147538
Log:
2009-05-14  Paolo Carlini  

PR libstdc++/40123
* random.tcc (independent_bits_engine<>::operator()()): Use
result_type(1), not 1UL.

* random.tcc (independent_bits_engine<>::operator()()): Use _M_b.max()
and _M_b.min(), instead of this->max() and this->min().

* random.h (_ShiftMin1): Remove, adjust everywhere.

* random.tcc: Minor cosmetic changes.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/random.h
trunk/libstdc++-v3/include/bits/random.tcc


-- 


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

[Bug fortran/40149] variable length still 6 ???

[kargl at gcc dot gnu dot org]

--- Comment #1 from kargl at gcc dot gnu dot org  2009-05-14 17:46 ---
Fortran bug reports are never given a Severity of Blocker.
That value is reserved for problems with C/C++.

Please attach the smallest compilable example that
exhibits the problem and provide the exact command line
used.  Your small code snippet and your interpretation of
the problem is insufficient.

I just noticed that you reported the problem against 
4.1.2.  Updating to 4.4.0 and 4.3.x is  advised.

Finally, no 6 characters is no longer the limit and
it has never been the limit in gfortran.


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|blocker |normal
 Status|UNCONFIRMED |WAITING
   Priority|P3  |P4


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

[Bug libstdc++/40123] [4.5 Regression] Revision 147395 failed libstc++ tests

[paolo dot carlini at oracle dot com]

-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-05-14 17:12:11
   date||


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

[Bug libstdc++/40123] [4.5 Regression] Revision 147395 failed libstc++ tests

[paolo dot carlini at oracle dot com]

--- Comment #4 from paolo dot carlini at oracle dot com  2009-05-14 17:12 
---
Indeed, very fishy: 1UL << 48. Patch forthcoming.


-- 


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

[Bug fortran/40149] New: variable length still 6 ???

[plivings at arb dot ca dot gov]

Failed on assigning values to an array in a simple loop with the following
structure:

" IARRAY2   = 0
  DO I = 2, 341
 IARRAY2 = IARRAY2 + 1
 PBLJARRAYPT(I,I,NCSP0)   = IARRAY2
  ENDDO
"  

Is the length of variables still 6 nowadays?


-- 
   Summary: variable length still 6 ???
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: plivings at arb dot ca dot gov


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

[Bug target/34526] no-altivec ABI should be fixed or no longer be the default

[janis at gcc dot gnu dot org]

--- Comment #15 from janis at gcc dot gnu dot org  2009-05-14 16:50 ---
Fixed by the patches shown in comments 12 and 13.


-- 

janis at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/40139] [4.4/4.5 Regression] ICE on invalid use of destructor

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2009-05-14 16:45 ---
Regressed with r145508 (PR39608).


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-05-14 16:45:48
   date||


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

[Bug target/39942] Nonoptimal code - leaveq; xchg %ax,%ax; retq

[hjl dot tools at gmail dot com]

--- Comment #32 from hjl dot tools at gmail dot com  2009-05-14 15:58 
---
(In reply to comment #30)
> Created an attachment (id=17863)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17863&action=view) [edit]
> Testing tool.
> 

Please make sure that you only test nop paddings for branch insns,
not nop paddings for branch targets, which prefer 16byte alignment.


-- 


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

[Bug middle-end/40147] [4.5 Regression] Memory leak in revision 147436

[hjl dot tools at gmail dot com]

--- Comment #6 from hjl dot tools at gmail dot com  2009-05-14 15:55 ---
Fixed.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/40147] [4.5 Regression] Memory leak in revision 147436

[hjl at gcc dot gnu dot org]

--- Comment #5 from hjl at gcc dot gnu dot org  2009-05-14 15:54 ---
Subject: Bug 40147

Author: hjl
Date: Thu May 14 15:54:19 2009
New Revision: 147537

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147537
Log:
2009-05-14  H.J. Lu  

Backport from mainline:
2009-05-14  H.J. Lu  

PR middle-end/40147
* ipa-utils.h (memory_identifier_string): Moved to ...
* tree.h (memory_identifier_string): Here.  Add GTY(()).

Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/ipa-utils.h
branches/gcc-4_3-branch/gcc/tree.h


-- 


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

[Bug middle-end/40147] [4.5 Regression] Memory leak in revision 147436

[hjl at gcc dot gnu dot org]

--- Comment #4 from hjl at gcc dot gnu dot org  2009-05-14 15:53 ---
Subject: Bug 40147

Author: hjl
Date: Thu May 14 15:52:58 2009
New Revision: 147536

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147536
Log:
2009-05-14  H.J. Lu  

Backport from mainline:
2009-05-14  H.J. Lu  

PR middle-end/40147
* ipa-utils.h (memory_identifier_string): Moved to ...
* tree.h (memory_identifier_string): Here.  Add GTY(()).

Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/ipa-utils.h
branches/gcc-4_4-branch/gcc/tree.h


-- 


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

[Bug middle-end/40147] [4.5 Regression] Memory leak in revision 147436

[hjl at gcc dot gnu dot org]

--- Comment #3 from hjl at gcc dot gnu dot org  2009-05-14 15:45 ---
Subject: Bug 40147

Author: hjl
Date: Thu May 14 15:45:32 2009
New Revision: 147535

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147535
Log:
2009-05-14  H.J. Lu  

PR middle-end/40147
* ipa-utils.h (memory_identifier_string): Moved to ...
* tree.h (memory_identifier_string): Here.  Add GTY(()).

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-utils.h
trunk/gcc/tree.h


-- 


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

[Bug debug/40126] [4.5 Regression] -O2 -g results in: can't resolve `.LFE95' {*UND* section} - `.Ltext0' {.text section}

[hubicka at gcc dot gnu dot org]

--- Comment #4 from hubicka at gcc dot gnu dot org  2009-05-14 15:29 ---
This looks like latent bug in dwarf2out.  There is location list:
.LLST2: 
.long   .LVL0-.Ltext0   # Location list begin address (*.LLST2)
.long   .LVL1-.Ltext0   # Location list end address (*.LLST2)
.value  0x2 # Location expression size
.byte   0x91# DW_OP_fbreg
.sleb128 0
.long   .LVL1-.Ltext0   # Location list begin address (*.LLST2)
.long   .LFE6-.Ltext0   # Location list end address (*.LLST2)
.value  0x2 # Location expression size
.byte   0x75# DW_OP_breg5
.sleb128 8
.long   0x0 # Location list terminator begin (*.LLST2)
.long   0x0 # Location list terminator end (*.LLST2)

and LFE6 is not defined.  It is used from from foo as:

.uleb128 0xb# (DIE (0x297) DW_TAG_lexical_block)
.uleb128 0x10   # (DIE (0x298) DW_TAG_formal_parameter)
.long   0x20d   # DW_AT_abstract_origin
.long   .LLST2  # DW_AT_location

   .uleb128 0x10   # (DIE (0x20d) DW_TAG_formal_parameter)
.long   0xd5# DW_AT_abstract_origin
.long   .LLST1  # DW_AT_location

.uleb128 0x8# (DIE (0xd5) DW_TAG_formal_parameter)
.ascii "t\0"# DW_AT_name
.byte   0x1 # DW_AT_decl_file (b.c)
.byte   0x22# DW_AT_decl_line
.long   0x78# DW_AT_type


-- 


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

[Bug c/40148] gcc 4.4.0 fails to build on Sparc Solaris 10

[ebotcazou at gcc dot gnu dot org]

--- Comment #4 from ebotcazou at gcc dot gnu dot org  2009-05-14 15:16 
---
> Thanks for the speed-of-light response.  I'm just thinking, could it be 
> related
> to the "-fPIC" argument (I found that in my CFLAGS)?

Yes, please don't set CFLAGS when building GCC.  I cannot reproduce.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org
   Severity|normal  |major
 Status|UNCONFIRMED |RESOLVED
  Component|target  |c
 Resolution||INVALID


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

[Bug target/39942] Nonoptimal code - leaveq; xchg %ax,%ax; retq

[jakub at gcc dot gnu dot org]

--- Comment #31 from jakub at gcc dot gnu dot org  2009-05-14 15:15 ---
Some -O2 code size data from today's trunk bootstraps.  The first .text line
is always vanilla bootstrap, the second one with
http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00702.html
only, the third one with that patch and
http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00703.html
and the last with additional:
--- i386.c.jj3  2009-05-14 12:41:24.0 +0200
+++ i386.c  2009-05-14 14:48:24.0 +0200
@@ -27202,7 +27202,7 @@ x86_function_profiler (FILE *file, int l
 static int
 min_insn_size (rtx insn)
 {
-  int l = 0;
+  int l = 0, len;

   if (!INSN_P (insn) || !active_insn_p (insn))
 return 0;
@@ -27222,7 +27222,8 @@ min_insn_size (rtx insn)
   && symbolic_reference_mentioned_p (PATTERN (insn))
   && !SIBLING_CALL_P (insn))
 return 5;
-  if (get_attr_length (insn) <= 1)
+  len = get_attr_length (insn);
+  if (len <= 1)
 return 1;

   /* For normal instructions we may rely on the sizes of addresses
@@ -27230,6 +27231,9 @@ min_insn_size (rtx insn)
  This is not the case for jumps where references are PC relative.  */
   if (!JUMP_P (insn))
 {
+  if (get_attr_type (insn) != TYPE_MULTI)
+   return len;
+
   l = get_attr_length_address (insn);
   if (l < 4 && symbolic_reference_mentioned_p (PATTERN (insn)))
l = 4;
to see how the code size changes with much more accurate (though sometimes not
minimum but maximum bound) insn sizing for the algorithm.
64-bit cc1plus
  [12] .text PROGBITS0047f990 07f990 8c3ba8 00  AX 
0   0 16
  [12] .text PROGBITS0047f990 07f990 89b1e8 00  AX 
0   0 16
  [12] .text PROGBITS0047f9c0 07f9c0 899f78 00  AX 
0   0 16
  [12] .text PROGBITS0047f9c0 07f9c0 88eaf8 00  AX 
0   0 16
32-bit cc1plus
  [12] .text PROGBITS080b24e0 06a4e0 8f8cac 00  AX  0   0
16
  [12] .text PROGBITS080b24e0 06a4e0 8d516c 00  AX  0   0
16
  [12] .text PROGBITS080b2510 06a510 8d507c 00  AX  0   0
16
  [12] .text PROGBITS080b2510 06a510 8cbd7c 00  AX  0   0
16
For 64-bit cc1plus that's 1.8%, 1.86%, 2.36% smaller binary with the 1, 2 resp.
3 patches, for 32-bit cc1plus 1.55%, 1.56%, 1.96% smaller binary.
So the first patch is the most important and something like the third one,
perhaps with more exceptions, also makes a difference.  I'll now try to update
my awk script to check for the AMD rules, namely that the last byte of the
branch insn counts rather than the first.


-- 


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

[Bug fortran/40142] integer constants not promoted with -fdefault-integer-8

[kargl at gcc dot gnu dot org]

--- Comment #1 from kargl at gcc dot gnu dot org  2009-05-14 14:56 ---
Looks like a false positive.

REMOVE:kargl[230] cat kj.f90
  program test
  implicit none
  integer i,j
  i = 1234567899876
  print *, i
  end
REMOVE:kargl[231] gfc4x -o z kj.f90
kj.f90:4.23:

  i = 1234567899876
   1
Error: Integer too big for its kind at (1). This check can be disabled
with the option -fno-range-check
REMOVE:kargl[232] gfc4x -o z -fdefault-integer-8 kj.f90
REMOVE:kargl[233] ./z
1234567899876


-- 


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

[Bug tree-optimization/40071] ICE assert aliasing in vectorizable_store, at tree-vect-stmts.c:3108 on mipsel abi=n32 and 64, works at 32

[ebotcazou at gcc dot gnu dot org]

--- Comment #3 from ebotcazou at gcc dot gnu dot org  2009-05-14 14:54 
---
Richard, the subtype bounds removal patch will expose this on x86-64 as well.

Vectorization is not a priority in Ada for the time being so I'll go ahead, but
do you have an idea about the nature of the problem?


-- 


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

[Bug testsuite/40130] using RUNTESTFLAGS="--target_board 'foo{-mxyz,-mjkl,}" screws up ieee.exp (and possibly others?)

[bonzini at gnu dot org]

--- Comment #6 from bonzini at gnu dot org  2009-05-14 14:54 ---
Yes, indeed ieee.exp adds -ffloat-store so I was wrong yesterday in my first
report.  However I can reproduce the problem with

  make -k check RUNTESTFLAGS="--target_board
'unix{-march=i486,-march=pentium2,}'"

where testsuite/gcc/gcc.log does not show -ffloat-store anymore.  So it's
probably a bug either in the harness or in dejagnu itself.

Changing component and CCing Janis.


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 CC||janis at gcc dot gnu dot org
  Component|target  |testsuite
   Keywords|wrong-code  |
Summary|rint from gcc.c-|using RUNTESTFLAGS="--
   |torture/execute miscompiled |target_board 'foo{-mxyz,-
   |with -march=i486|mjkl,}" screws up ieee.exp
   ||(and possibly others?)


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

[Bug fortran/40142] integer constants not promoted with -fdefault-integer-8

[kargl at gcc dot gnu dot org]

-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Priority|P3  |P5


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

[Bug middle-end/40141] [4.3 Regression] accessing aliased __m128 miscompiles

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-05-14 14:50 ---
For 4.4 this was fixed by

2008-04-29  Richard Guenther  

* tree-ssa-alias.c (finalize_ref_all_pointers): Remove.
(compute_may_aliases): Do not call finalize_ref_all_pointers.
(compute_flow_insensitive_aliasing): Do not treat
PTR_IS_REF_ALL pointers special.
(get_smt_for): Likewise.
(may_alias_p): Re-structure.
(is_escape_site): A ref-all pointer conversion is not an escape site.
* tree-ssa-structalias.c (find_what_p_points_to): Do not treat
PTR_IS_REF_ALL pointers special.
* tree-ssa-structalias.h (struct alias_info): Remove
ref_all_symbol_mem_tag field.
(PTR_IS_REF_ALL): Remove.

eventually exposing PRs 38151 and 38246.  Which were fixed by

2008-11-25  Richard Guenther  

PR middle-end/38151
PR middle-end/38236
* tree-ssa-alias.c (struct alias_info): Remove written_vars.
Remove dereferenced_ptrs_store and dereferenced_ptrs_load
in favor of dereferenced_ptrs.
(init_alias_info): Adjust.
(delete_alias_info): Likewise.
(compute_flow_insensitive_aliasing): Properly
include all aliased variables.
(update_alias_info_1): Use dereferenced_ptrs.
(setup_pointers_and_addressables): Likewise.
(get_smt_for): Honor ref-all pointers and pointers with known alias
set properly.
* config/i386/i386.c (ix86_gimplify_va_arg): Use ref-all pointers.


-- 


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

[Bug middle-end/40147] [4.5 Regression] Memory leak in revision 147436

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2009-05-14 14:34 ---
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00819.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2009-
   ||05/msg00819.html


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

[Bug c++/40146] Unexplained "'' is used uninitialized in this function" warning

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2009-05-14 14:31 ---
Well with -DTEST1, the functions which were in the anonymous namespace are now
in the normal namespace which means they are going to be exported from the TU
which changes the inlining decisions.


-- 


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

[Bug middle-end/40147] [4.5 Regression] Memory leak in revision 147436

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0


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

[Bug target/40148] gcc 4.4.0 fails to build on Sparc Solaris 10

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|major   |normal
  Component|c   |target
   Keywords||build


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

[Bug c/40148] gcc 4.4.0 fails to build on Sparc Solaris 10

[peter dot kruse at lbbw dot de]

--- Comment #3 from peter dot kruse at lbbw dot de  2009-05-14 14:14 ---
(In reply to comment #2)
> This sounds really like a bug in solaris's as and you should be reporting it 
> to
> Sun.
> 

Thanks for the speed-of-light response.  I'm just thinking, could it be related
to the "-fPIC" argument (I found that in my CFLAGS)?


-- 

peter dot kruse at lbbw dot de changed:

   What|Removed |Added

   Severity|normal  |major
  Component|target  |c


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

[Bug rtl-optimization/40101] [4.5 Regression] 200.sixtrack ICEs in get_seqno_by_preds, at sel-sched-ir.c:3752

[abel at gcc dot gnu dot org]

--- Comment #1 from abel at gcc dot gnu dot org  2009-05-14 14:12 ---
Confirmed, I'll take a look.  (Somehow my ispras.ru account didn't get any
mails about this bug.)


-- 

abel at gcc dot gnu dot org changed:

   What|Removed |Added

 CC|abel at ispras dot ru   |abel at gcc dot gnu dot org
 AssignedTo|unassigned at gcc dot gnu   |abel at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-05-14 14:12:49
   date||


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

[Bug target/40148] gcc 4.4.0 fails to build on Sparc Solaris 10

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2009-05-14 14:12 ---
This sounds really like a bug in solaris's as and you should be reporting it to
Sun.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|major   |normal
  Component|c   |target
 GCC target triplet||sparc-sun-solaris2.10


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

[Bug c/40148] gcc 4.4.0 fails to build on Sparc Solaris 10

[peter dot kruse at lbbw dot de]

--- Comment #1 from peter dot kruse at lbbw dot de  2009-05-14 14:03 ---
Created an attachment (id=17867)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17867&action=view)
sol2-c1.s

resulting .s file causing the failure


-- 


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

[Bug c/40148] New: gcc 4.4.0 fails to build on Sparc Solaris 10

[peter dot kruse at lbbw dot de]

Hello,

trying to compile gcc 4.4.0 results in the following error:

---8<
/ae/data/work/extern/ex00712/build/gcc/gcc-4.4.0-objdir/./gcc/xgcc
-B/ae/data/work/extern/ex00712/build/gcc/gcc-4.4.0-objdir/./gcc/
-B/apps/local/gcc/4.4.0/sparc-sun-solaris2.10/bin/
-B/apps/local/gcc/4.4.0/sparc-sun-solaris2.10/lib/ -isystem
/apps/local/gcc/4.4.0/sparc-sun-solaris2.10/include -isystem
/apps/local/gcc/4.4.0/sparc-sun-solaris2.10/sys-include -g
-I/apps/local/gcc/4.3.2/include -I/apps/prod/gcc/4.3.2/include -fPIC -m64 -c -o
/ae/data/work/extern/ex00712/build/gcc/gcc-4.4.0-objdir/sparc-sun-solaris2.10/sparcv9/libgcc/crt1.o
-x assembler-with-cpp ../../gcc-4.4.0/gcc/config/sparc/sol2-c1.asm
/usr/ccs/bin/as: "/var/tmp//ccLZqEDx.s": , approx line 92: internal error:
pic_relocs(): hh reltype?
make[6]: ***
[/ae/data/work/extern/ex00712/build/gcc/gcc-4.4.0-objdir/sparc-sun-solaris2.10/sparcv9/libgcc/crt1.o]
Error 1
make[6]: Leaving directory
`/ae/data/work/extern/ex00712/build/gcc/gcc-4.4.0-objdir/gcc'
make[5]: *** [gcc-extra-parts] Error 2
make[5]: Leaving directory
`/ae/data/work/extern/ex00712/build/gcc/gcc-4.4.0-objdir/sparc-sun-solaris2.10/sparcv9/libgcc'
make[4]: *** [multi-do] Error 1
make[4]: Leaving directory
`/ae/data/work/extern/ex00712/build/gcc/gcc-4.4.0-objdir/sparc-sun-solaris2.10/libgcc'
make[3]: *** [all-multi] Error 2
make[3]: Leaving directory
`/ae/data/work/extern/ex00712/build/gcc/gcc-4.4.0-objdir/sparc-sun-solaris2.10/libgcc'
make[2]: *** [all-stage1-target-libgcc] Error 2
make[2]: Leaving directory
`/ae/data/work/extern/ex00712/build/gcc/gcc-4.4.0-objdir'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory
`/ae/data/work/extern/ex00712/build/gcc/gcc-4.4.0-objdir'
make: *** [bootstrap-lean] Error 2
---8<

I have run the above "xgcc" command with "-save-temps" and will attach
the resulting sol2-c1.s file.

gcc has been configured with:

../gcc-4.4.0/configure --prefix=/apps/local/gcc/4.4.0 --enable-languages=c,c++
--with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld

and make's argument was "bootstrap-lean"

If I run the above "xgcc" command without the "-m64" argument the build of
crt1.o succeeds.

Thanks,

  Peter


-- 
   Summary: gcc 4.4.0 fails to build on Sparc Solaris 10
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: peter dot kruse at lbbw dot de


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

[Bug middle-end/40147] [4.5 Regression] Memory leak in revision 147436

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2009-05-14 13:59 ---
Somehow, memory_identifier_string got garbage collected. 


-- 


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

[Bug fortran/22552] Would like warning when an undeclared function is called

[domob at gcc dot gnu dot org]

--- Comment #6 from domob at gcc dot gnu dot org  2009-05-14 13:49 ---
Created an attachment (id=17866)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17866&action=view)
ChangeLog for patch posted


-- 


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

[Bug fortran/22552] Would like warning when an undeclared function is called

[domob at gcc dot gnu dot org]

--- Comment #5 from domob at gcc dot gnu dot org  2009-05-14 13:48 ---
Created an attachment (id=17865)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17865&action=view)
Latest patch


-- 


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

[Bug middle-end/40147] New: [4.5 Regression] Memory leak in revision 147436

[hjl dot tools at gmail dot com]

On Linux/ia32, revision 147436 failed to compile 483.xalancbmk in SPEC
CPU 2006:

gnu-33:pts/4[38]> /export/gnu/import/rrs/147454/usr/bin/gcc -m32 -c -o
DocumentImpl.o -DSPEC_CPU -DNDEBUG  -DAPP_NO_THREADS -DXALAN_INMEM_MSG_LOADER
-I. -Ixercesc -Ixercesc/dom -Ixercesc/dom/impl -Ixercesc/sax
-Ixercesc/util/MsgLoaders/InMemory -Ixercesc/util/Transcoders/Iconv
-Ixalanc/include -DPROJ_XMLPARSER -DPROJ_XMLUTIL -DPROJ_PARSERS -DPROJ_SAX4C
-DPROJ_SAX2 -DPROJ_DOM -DPROJ_VALIDATORS -DXML_USE_NATIVE_TRANSCODER
-DXML_USE_INMEM_MESSAGELOADER  -O3 -msse2 -mfpmath=sse -ffast-math
-funroll-loops -DSPEC_CPU_LINUX DocumentImpl.cpp 
In file included from ./xercesc/util/RefHashTableOf.hpp:373,
 from xercesc/dom/DocumentImpl.hpp:78,
 from DocumentImpl.cpp:65:
./xercesc/util/RefHashTableOf.c: In member function ‘void
xercesc_2_5::RefHashTableOf::put(void*, TVal*) [with TVal = void]’:
DocumentImpl.cpp:833:   instantiated from here
./xercesc/util/RefHashTableOf.c:460: warning: deleting ‘void*’ is undefined
./xercesc/util/RefHashTableOf.c: In member function ‘void
xercesc_2_5::RefHashTableOf::removeAll() [with TVal = void]’:
./xercesc/util/RefHashTableOf.c:226:   instantiated from
‘xercesc_2_5::RefHashTableOf::~RefHashTableOf() [with TVal = void]’
DocumentImpl.cpp:186:   instantiated from here
./xercesc/util/RefHashTableOf.c:281: warning: deleting ‘void*’ is undefined
./xercesc/util/RefHashTableOf.c: In member function ‘void
xercesc_2_5::RefHashTableOf::removeBucketElem(const void*, unsigned int&)
[with TVal = void]’:
./xercesc/util/RefHashTableOf.c:260:   instantiated from ‘void
xercesc_2_5::RefHashTableOf::removeKey(const void*) [with TVal = void]’
DocumentImpl.cpp:831:   instantiated from here
./xercesc/util/RefHashTableOf.c:596: warning: deleting ‘void*’ is undefined
DocumentImpl.cpp: In static member function ‘static
xercesc_2_5::TreeWalkerImpl*
xercesc_2_5::DocumentImpl::createTreeWalker(xercesc_2_5::DOM_Node, long
unsigned int, xercesc_2_5::DOM_NodeFilter*, bool,
xercesc_2_5::MemoryManager*)’:
DocumentImpl.cpp:389: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
gnu-33:pts/4[39]> 

It doesn't happen with preprocessed file. Valgrind reports:

In file included from ./xercesc/util/RefHashTableOf.hpp:373,
 from xercesc/dom/DocumentImpl.hpp:78,
 from DocumentImpl.cpp:65:
./xercesc/util/RefHashTableOf.c: In member function ‘void
xercesc_2_5::RefHashTableOf::put(void*, TVal*) [with TVal = void]’:
DocumentImpl.cpp:833:   instantiated from here
./xercesc/util/RefHashTableOf.c:460: warning: deleting ‘void*’ is undefined
./xercesc/util/RefHashTableOf.c: In member function ‘void
xercesc_2_5::RefHashTableOf::removeAll() [with TVal = void]’:
./xercesc/util/RefHashTableOf.c:226:   instantiated from
‘xercesc_2_5::RefHashTableOf::~RefHashTableOf() [with TVal = void]’
DocumentImpl.cpp:186:   instantiated from here
./xercesc/util/RefHashTableOf.c:281: warning: deleting ‘void*’ is undefined
./xercesc/util/RefHashTableOf.c: In member function ‘void
xercesc_2_5::RefHashTableOf::removeBucketElem(const void*, unsigned int&)
[with TVal = void]’:
./xercesc/util/RefHashTableOf.c:260:   instantiated from ‘void
xercesc_2_5::RefHashTableOf::removeKey(const void*) [with TVal = void]’
DocumentImpl.cpp:831:   instantiated from here
./xercesc/util/RefHashTableOf.c:596: warning: deleting ‘void*’ is undefined
==23451== Invalid read of size 2
==23451==at 0xD94DF4: simple_cst_equal (tree.c:5079)
==23451==by 0xE3A33A: check_stmt (ipa-pure-const.c:445)
==23451==by 0xE3A737: analyze_function (ipa-pure-const.c:512)
==23451==by 0xE3BD22: local_pure_const (ipa-pure-const.c:925)
==23451==by 0xA93F9E: execute_one_pass (passes.c:1283)
==23451==by 0xA941E5: execute_pass_list (passes.c:1332)
==23451==by 0xA94203: execute_pass_list (passes.c:1333)
==23451==by 0xC0743C: tree_rest_of_compilation (tree-optimize.c:394)
==23451==by 0xE2AFC3: cgraph_expand_function (cgraphunit.c:1095)
==23451==by 0xE2B173: cgraph_expand_all_functions (cgraphunit.c:1154)
==23451==by 0xE2B71D: cgraph_optimize (cgraphunit.c:1377)
==23451==by 0x5C430D: cp_write_global_declarations (decl2.c:3635)
==23451==  Address 0xb5fc300 is not stack'd, malloc'd or (recently) free'd
DocumentImpl.cpp: In static member function ‘static
xercesc_2_5::TreeWalkerImpl*
xercesc_2_5::DocumentImpl::createTreeWalker(xercesc_2_5::DOM_Node, long
unsigned int, xercesc_2_5::DOM_NodeFilter*, bool,
xercesc_2_5::MemoryManager*)’:
DocumentImpl.cpp:389: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: [4.5 Regression]  Memory leak in revision 147436
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity

[Bug c++/40146] Unexplained "'' is used uninitialized in this function" warning

[caolanm at redhat dot com]

--- Comment #1 from caolanm at redhat dot com  2009-05-14 13:09 ---
Created an attachment (id=17864)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17864&action=view)
test-case


-- 


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

[Bug c++/40146] New: Unexplained "'' is used uninitialized in this function" warning

[caolanm at redhat dot com]

With some code (attached) using an anonymous namespace I get an unexplained
"‘’ is used uninitialized in this function" with -Wall, with no
indication of what is seen to be used uninitialized. Changing the namespace to
a named one removes the error, as does removing part of the body of a used
method. 

g++ (GCC) 4.4.0 20090506 (Red Hat 4.4.0-4)

-DTEST1 names the namespace
-DTEST2 comments out the body of the offending method
"wiggling" the code makes it disappear/reappear, but difficult to know what the
problem is so as to make the test-case a more reasonable size

$ g++ -O2 -c -Wall foo.cxx
foo.cxx: In function ‘bool demo()’:
foo.cxx:4033: warning: ‘’ is used uninitialized in this function
foo.cxx:4033: note: ‘’ was declared here
$ g++ -DTEST1 -O2 -c -Wall foo.cxx
$ g++ -DTEST2 -O2 -c -Wall foo.cxx

Looks similar to bug #38908 but that one compiles without warnings here


-- 
   Summary: Unexplained "'' is used uninitialized in this
function" warning
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: caolanm at redhat dot com


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

[Bug c++/40145] New: structure inside a static function is exported, producing warning

[thiago at kde dot org]

Given the following code:

===
struct EditorInternalCommand { };

static void createCommandMap()
{
struct CommandEntry { EditorInternalCommand command; };
}
===

The structure createCommandMap()::CommandEntry is exported from a local-scope
(static) function. When compiling the code above with -fvisibility=hidden, g++
4.3 or 4.4 outputs the following warning:

visibility.cpp:5: warning: 'createCommandMap()::CommandEntry' declared with
greater visibility than the type of its field
'createCommandMap()::CommandEntry::command'

If I add constructors to both structures so that there are symbols emitted, the
ELF symbol table looks like this:
6:  22 FUNCLOCAL  DEFAULT2
_ZZL16createCommandMapvEN12CommandEntryC1Ev
7: 0016 16 FUNCLOCAL  DEFAULT2 _ZL16createCommandMapv
   12:   5 FUNCWEAK   HIDDEN 6
_ZN21EditorInternalCommandC1Ev

My understanding of the problem is that a "static" function has LOCAL scope but
DEFAULT visibility. The inner structure inherits these properties. However, the
outer structure (EditorInternalCommand) has HIDDEN visibility, which triggers
the warning.

However, since the binding scope is LOCAL, those symbols will not be exported
by the linker in the final ELF object anyways, thereby making them effectively
have hidden visibility.


Workarounds:

Any of the following three actions make the warning disappear:
1) remove the "static" keyword
2) move the inner structure outside the static function
3) place the outer structure in an anonymous namespace

Actions #2 and #3 above change those propeties making both constructors match
either LOCAL/DEFAULT or WEAK/HIDDEN. Action #1 causes the function to become
GLOBAL/HIDDEN, but leaves the inner structure unchanged -- however, the warning
is gone too.


-- 
   Summary: structure inside a static function is exported,
producing warning
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: thiago at kde dot org
 GCC build triplet: i586-manbo-linux-gnu
  GCC host triplet: i586-manbo-linux-gnu
GCC target triplet: i586-manbo-linux-gnu


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

[Bug c/40065] spurious format string warnings

[joseph at codesourcery dot com]

--- Comment #5 from joseph at codesourcery dot com  2009-05-14 12:01 ---
Subject: Re:  spurious format string warnings

On Thu, 14 May 2009, bje at gcc dot gnu dot org wrote:

> Andrew wrote:
> 
>   "GCC can assume %qE means anything from just printing E in quotes"
> 
> Can you explain this?  Is it really the case that the format specifier can 
> have
> an optional argument?

This is not a meaningful question.  There are no limits on the possible 
semantics of a format string; a variadic function can apply arbitrary 
Turing-complete computations to its fixed arguments to determine the types 
of the variable arguments, and to the first N variable arguments to 
determine the type of argument N+1.  GCC can only warn about strings not 
following the rules for a particular type of format that were built into 
GCC; if you compile code with a string intended for different, newer 
rules, as here, it cannot have any idea what the newer rules are and thus 
whether %E takes no arguments (like %%), one, two or more.


-- 


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

[Bug driver/40144] [4.5 Regression] ice in common_handle_option

[reichelt at gcc dot gnu dot org]

--- Comment #2 from reichelt at gcc dot gnu dot org  2009-05-14 11:26 
---
Steven, that is probably fallout from your patch:

2009-04-27  Steven Bosscher  

* dbgcnt.def (cprop1, cprop2, gcse, jump_bypass): Remove
(cprop, hoist, pre, store_motion): New debug counters.
* tree-pass.h (pass_tracer): Move to list of gimple passes, it
is not an RTL pass anymore.
(pass_profiling): Remove extern decl for pass removed in 2005.
(pass_gcse, pass_jump_bypass): Remove.
[...]
* common.opt: Remove flag_cse_skip_blocks, adjust documentation to
make it clear that -fcse-skip-blocks is a no-op for backward compat.
[...]

A crash doesn't look like a no-op to me ;-)


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||steven at gcc dot gnu dot
   ||org


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

[Bug driver/40144] [4.5 Regression] ice in common_handle_option

[reichelt at gcc dot gnu dot org]

--- Comment #1 from reichelt at gcc dot gnu dot org  2009-05-14 11:20 
---
Confirmed. The option -fcse-skip-blocks is the culprit.


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||reichelt at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-05-14 11:20:31
   date||


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

[Bug rtl-optimization/40086] [4.5 Regression]: cris-elf gfortran.dg/forall_1.f90 -O1 execution

[hp at gcc dot gnu dot org]

--- Comment #15 from hp at gcc dot gnu dot org  2009-05-14 11:17 ---
patch posted after testing


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2009-
   ||05/msg00811.html
   Keywords||patch, wrong-code


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

[Bug middle-end/40141] [4.3 Regression] accessing aliased __m128 miscompiles

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-05-14 11:04 ---
Confirmed.  That's the SMTs do not include ref-all stuff bug so DCE removes
the initialization.

extern void abort (void);
typedef int __m128 __attribute__((vector_size(16), may_alias));
typedef float floatA __attribute__((may_alias));

int main()
{
  __m128 x = { 0, 0, 0, 0 };
  int i;
  for (i = 0; i < 4; ++i) {
  const float xx = ((floatA*)&x)[i];
  if (xx != 0.f)
abort ();
  }
  return 0;
}

works without may_alias on __m128 for a strange reason.

I'll find the patch that fixed this.


-- 

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|UNCONFIRMED |ASSIGNED
  Component|c   |middle-end
 Ever Confirmed|0   |1
   Keywords||alias, wrong-code
   Last reconfirmed|-00-00 00:00:00 |2009-05-14 11:04:20
   date||
Summary|accessing aliased __m128|[4.3 Regression] accessing
   |miscompiles |aliased __m128 miscompiles
   Target Milestone|--- |4.3.4


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

[Bug middle-end/35412] Correctness with -ftrapv depended on libcall notes

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2009-05-14 10:55 ---
*** Bug 40143 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dickinsm at gmail dot com


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

[Bug c/40143] -ftrapv fails to generate signal for overflows in int multiplication on x86-64

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-05-14 10:55 ---


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


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug driver/40144] [4.5 Regression] ice in common_handle_option

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|ice in common_handle_option |[4.5 Regression] ice in
   ||common_handle_option
   Target Milestone|--- |4.5.0


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

[Bug driver/40144] New: ice in common_handle_option

[dcb314 at hotmail dot com]

I just tried to compile the Suse Linux package gnuboy-1.0.3-1060.55
with the GNU g++ version 4.5 snapshot 20090507.

The compiler said

gcc -O2 -g -m64 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector
-funwind-tables -fasynchronous-unwind-tables -pedantic -Wall -Wno-implicit
-Wno-long-long -O3 -fstrength-reduce -fthread-jumps  -fcse-follow-jumps
-fcse-skip-blocks -frerun-cse-after-loop  -fexpensive-optimizations
-fforce-addr -fomit-frame-pointer -I. -I/usr/local/include  -I./sys/nix
-DHAVE_CONFIG_H -DIS_LITTLE_ENDIAN  -DIS_LINUX -c lcd.c -o lcd.o
cc1: internal compiler error: in common_handle_option, at opts.c:2079
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

I'd like to be able to show the C code that causes this problem, but the
problem appears to be in the handling of options to the compiler.

valgrind doesn't seem to help.

The code at line 2079 of opts.c is

default:
  /* If the flag was handled in a standard way, assume the lack of
 processing here is intentional.  */
  gcc_assert (cl_options[scode].flag_var);
  break;

which doesn't help me much. It would be better code if it gave us a clue
about the unexpected value of scode or perhaps a sanity check on
the value of scode before using it as an index into cl_options
might help.


-- 
   Summary: ice in common_handle_option
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
  GCC host triplet: x86_64-suse-linux


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

[Bug c/40143] New: -ftrapv fails to generate signal for overflows in int multiplication on x86-64

[dickinsm at gmail dot com]

The -ftrapv option doesn't appear to work as documented for GCC 4.4.0 on Debian
Linux 5.0/amd64.  In the code below, the multiplication overflows an int, and
so I was expecting the program to be aborted.  Instead, the program returned
normally with exit code 1.

Looking at the generated assembly, it seems that the multiplication
generates a call to __mulvdi3 instead of __mulvsi3.


/* begin test.c */
int mul(int x, int y) {
  return x*y;
}

int main(void) {
  int x = 6, y = 65432, z;
  z = mul(x, y);
  return z < 0 ? 1 : 0;
}
/* end test.c */


Here's the output from gcc-4.4 -v -save-temps -ftrapv test.c:

Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.4.0/configure --program-suffix=-4.4
Thread model: posix
gcc version 4.4.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-ftrapv' '-mtune=generic'
 /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/cc1 -E -quiet -v test.c
-mtune=generic -ftrapv -fpch-preprocess -o test.i
ignoring nonexistent directory
"/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/include
 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-ftrapv' '-mtune=generic'
 /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/cc1 -fpreprocessed
test.i -quiet -dumpbase test.c -mtune=generic -auxbase test -version -ftrapv -o
test.s
GNU C (GCC) version 4.4.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.4.0, GMP version 4.2.2, MPFR version 2.3.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 4d22b9ce88170f4e051ca32157922a46
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-ftrapv' '-mtune=generic'
 as -V -Qy -o test.o test.s
GNU assembler version 2.18.0 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Debian) 2.18.0.20080103
COMPILER_PATH=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/:/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/:/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/:/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/:/usr/local/lib/gcc/x86_64-unknown-linux-gnu/
LIBRARY_PATH=/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/:/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-ftrapv' '-mtune=generic'
 /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/collect2 --eh-frame-hdr
-m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2
/usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/crtbegin.o
-L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0
-L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../.. test.o -lgcc
--as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/crtend.o
/usr/lib/../lib64/crtn.o


-- 
   Summary: -ftrapv fails to generate signal for overflows in int
multiplication on x86-64
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dickinsm at gmail dot com
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug fortran/39996] Double typing of function results not detected

[janus at gcc dot gnu dot org]

--- Comment #3 from janus at gcc dot gnu dot org  2009-05-14 09:46 ---
Fixed with r147528. Closing.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/39996] Double typing of function results not detected

[janus at gcc dot gnu dot org]

--- Comment #2 from janus at gcc dot gnu dot org  2009-05-14 09:42 ---
Subject: Bug 39996

Author: janus
Date: Thu May 14 09:41:41 2009
New Revision: 147528

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147528
Log:
2009-05-14  Janus Weil  

PR fortran/39996
* decl.c (gfc_match_function_decl): Use gfc_add_type.
* symbol.c (gfc_add_type): Better checking for duplicate types in
function declarations. And: Always give an error for duplicte types,
not just a warning with -std=gnu.


2009-05-14  Janus Weil  

PR fortran/39996
* gfortran.dg/func_decl_2.f90: Modified (replacing warnings by errors).
* gfortran.dg/duplicate_type_2.f90: Ditto.
* gfortran.dg/duplicate_type_3.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/duplicate_type_3.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/symbol.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/duplicate_type_2.f90
trunk/gcc/testsuite/gfortran.dg/func_decl_2.f90


-- 


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

[Bug fortran/40142] New: integer constants not promoted with -fdefault-integer-8

[ajmay81 at googlemail dot com]

Fortran code:

  program test
  implicit none
  character*2 a(1)
  character*24 trop
  integer i,j
  i=1
  j=2

  trop='b'//a(1)(i:j) ! fine
  trop='b'//a(1)(1:2) ! warning
  trop=a(1)(1:2)//'b' ! warning
  trop=a(1)(1:2) ! fine
  end

Compiled with:

gfortran -Wconversion test.f

produces no warnings, but with 8-byte integers:

gfortran -Wconversion -fdefault-integer-8 test.f
test.f:10.23:

  trop='b'//a(1)(1:2) ! warning
  1
Warning: Conversion from INTEGER(4) to INTEGER(8) at (1)
test.f:11.18:

  trop=a(1)(1:2)//'b' ! warning
 1
Warning: Conversion from INTEGER(4) to INTEGER(8) at (1)

Using gfortran build that ships with openSuSE 11.1:

Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3
--enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/
--with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap
--with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --program-suffix=-4.3
--enable-linux-futex --without-system-libunwind --with-cpu=generic
--build=x86_64-suse-linux
Thread model: posix
gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux)


-- 
   Summary: integer constants not promoted with -fdefault-integer-8
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ajmay81 at googlemail dot com


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

[Bug c/40141] New: accessing aliased __m128 miscompiles

[kretz at kde dot org]

Testcase:

#include 
#include 

typedef float floatA __attribute__((__may_alias__));

int main()
{
__m128 x = _mm_setzero_ps();
int i;
for (i = 0; i < 4; ++i) {
const float xx = ((floatA*)&x)[i];
if (xx != 0.f) {
printf("%d: %f\n", i, xx);
return -1;
}
}
return 0;
}

This fails with -O2, as well as with -O2 -fno-strict-aliasing. It works with
-O1 and -O0.

The generated assembly shows that the stack is created but not initialized and
then read from and checked whether it's 0.

If instead of
const float xx = ((floatA*)&x)[i];
you write
const float xx = ((floatA*)&x)[0];
(or any other constant between 0 and 3) then the testcase doesn't fail.

Tested versions:
4.2.4: doesn't fail
4.3.2: fails
4.3.3: fails
4.4.0: doesn't fail


-- 
   Summary: accessing aliased __m128 miscompiles
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kretz at kde dot org
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug c++/40139] [4.4/4.5 Regression] ICE on invalid use of destructor

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug libstdc++/40123] [4.5 Regression] Revision 147395 failed libstc++ tests

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2009-05-14 09:07 
---
Before dealing with this a middle-end, let me double check the implementation,
because I'm seeing something fishy...


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 AssignedTo|hubicka at gcc dot gnu dot  |paolo dot carlini at oracle
   |org |dot com
  Component|middle-end  |libstdc++


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

[Bug target/39942] Nonoptimal code - leaveq; xchg %ax,%ax; retq

[vvv at ru dot ru]

--- Comment #30 from vvv at ru dot ru  2009-05-14 09:01 ---
Created an attachment (id=17863)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17863&action=view)
Testing tool.

Here is results of my testing.
Code:
align   128
test_cikl:
rept 14 ; 14 if SH=0, 15 if SH=1, 16 if SH=2
{
nop
}
 cmp  al,0   ; 2 bytes

 jz   $+10h+NOPS ; 2 bytes offset=0
 cmp  al,1   ; 2 bytes offset=2
 jz   $+0Ch+NOPS ; 2 bytes offset=4
 cmp  al,2   ; 2 bytes offset=6
 jz   $+08h+NOPS ; 2 bytes offset=8
 cmp  al,3   ; 2 bytes offset=A
match =1, NOPS
{
   nop
}
match =2, NOPS
{
   xchg eax,eax ; 2-bytes NOP
}
 jz   $+04h  ; 2 bytes offset=C
 ja   $+02h  ; 2 bytes offset=E

 mov  eax,ecx
 and  eax,7h
 loop test_cikl

This code tested on Core2,Xeon and P4 CPU. Results in RDTSC ticks.

; Core 2 Duo
;NOPS/tick/Max  NOPS/tick/MaxNOPS/tick/Max
; SH=0  0/571/729  1/306/594   2/315/630
; SH=1  0/338/612  1/338/648   2/339/648
; SH=2  0/339/666  1/339/675   2/333/693

; Xeon 3110
;NOPS/tick/Max  NOPS/tick/MaxNOPS/tick/Max
; SH=0  0/586/693  1/310/675   2/310/675
; SH=1  0/333/657  1/330/648   2/464/630
; SH=2  0/333/657  1/470/594   2/474/603

; P4
;NOPS/tick/Max  NOPS/tick/MaxNOPS/tick/Max
; SH=0 0/1027/1317 1/1094/1258 2/1028/1207
; SH=1 0/1151/1377 1/1068/1352 2/902/1275
; SH=2 0/1124/1275 1/1148/1335 2/979/1139

Conclusion:
1. Core2 and Xeon - similar results. P4 - something strange.
For Core2 & Xeon padding very effective. Code with padding almoust 2 times
faster. No sence for P4?
2. My previous sentence

VVV> 1. AMD limitation for 16-bytes page (memory range XXX0 - XXXF),but
VVV> Intel limitation for 16-bytes chunk  (memory range  - +10h)

is wrong. At leat for Core2 & Xeon. For this CPU "16-bytes chunk" means
memory range XXX0 - XXXF.

Unfortunately, I can't test AMD.

PS. My testing tool in attachmen. It start under MSDOS, switch to 32-bit mode,
switch to 64-bit mode and measure rdtsc ticks for test code.


-- 


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

[Bug middle-end/40123] [4.5 Regression] Revision 147395 failed libstc++ tests

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2009-05-14 08:54 
---
I tried to reproduce the equal.cc fail, for example, and it happens only at -O1
or above, as a "Floating point exception"...


-- 


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

[Bug target/37179] gcc emits bad opcode 'ffreep'

[ubizjak at gmail dot com]

--- Comment #18 from ubizjak at gmail dot com  2009-05-14 08:25 ---
Fixed.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug target/37179] gcc emits bad opcode 'ffreep'

[uros at gcc dot gnu dot org]

--- Comment #17 from uros at gcc dot gnu dot org  2009-05-14 08:23 ---
Subject: Bug 37179

Author: uros
Date: Thu May 14 08:23:31 2009
New Revision: 147522

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147522
Log:
PR target/37179
* config/i386/driver-i386.c (vendor_signatures): New enum.
(processor_signatures): Ditto.
(host_detect_local_cpu): Use vendor_signatures and
processor_signatures enums.  For SIG_AMD vendor, check for
SIG_GEODE processor signature to detect geode processor.


Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/config/i386/driver-i386.c


-- 


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

[Bug middle-end/40123] [4.5 Regression] Revision 147395 failed libstc++ tests

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2009-05-14 08:21 
---
Assigning to Honza basing on a comment on the mailing list...


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||paolo dot carlini at oracle
   ||dot com
 AssignedTo|unassigned at gcc dot gnu   |hubicka at gcc dot gnu dot
   |dot org |org


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

[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3

[ubizjak at gmail dot com]

--- Comment #55 from ubizjak at gmail dot com  2009-05-14 07:51 ---
(In reply to comment #54)
> I've started work on the binutils support for this.  Work-in-progress patch at
> http://sourceware.org/ml/binutils/2009-05/msg00228.html
> 
> Once that's complete, I could deal with the GCC end too.
> 
> What should we do about backward-compatibility?  If we attempt to use the new
> features with the old toolchain, it won't work, and the linker will issue a
> bunch of noisy warnings about the .drectve statements it doesn't understand.
> 
> Should use of the new feature depend on a -m flag, or an assembler/linker
> version check of some sort?  Or should we just go ahead and let users of old
> toolchains get a bunch of warnings?  On the same lines, should we still
> continue to pad all COMMON symbols to a round multiple of BIGGEST_ALIGNMENT, 
> or
> should we get rid of that when we're using the new feature?

Perhaps you could activate -mno-common if the new feature you are implementing
in your binutils patch is not detected by configure?


-- 


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

[Bug tree-optimization/40140] [4.5 Regression] ICE with -ftree-parallelize-loops

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0


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

[Bug tree-optimization/40140] [4.5 Regression] ICE with -ftree-parallelize-loops

[reichelt at gcc dot gnu dot org]

--- Comment #1 from reichelt at gcc dot gnu dot org  2009-05-14 07:17 
---
Created an attachment (id=17862)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17862&action=view)
Testcase (about 90 lines)


-- 


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

[Bug tree-optimization/40140] New: [4.5 Regression] ICE with -ftree-parallelize-loops

[reichelt at gcc dot gnu dot org]

The attached valid code snippet triggers an ICE on the trunk when compiled with
"-O2 -ftree-parallelize-loops=2":

g++: Internal error: Segmentation fault (program cc1plus)
Please submit a full bug report. [etc.]


-- 
   Summary: [4.5 Regression] ICE with -ftree-parallelize-loops
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, monitored
  Severity: normal
  Priority: P3
 Component: tree-optimization
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=40140

[Bug c++/40139] [4.4/4.5 Regression] ICE on inavlid use of destructor

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.4.1


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

[Bug c++/40139] New: [4.4/4.5 Regression] ICE on inavlid use of destructor

[reichelt at gcc dot gnu dot org]

The following invalid code snippet triggers an ICE since GCC 4.4.0:

===
template struct A
{
  static int i;
};

template int A::i = { A::~A };

template class A<0>;
===

bug.cc: In instantiation of 'int A<0>::i':
bug.cc:8:   instantiated from here
bug.cc:6: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]


-- 
   Summary: [4.4/4.5 Regression] ICE on inavlid use of destructor
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, monitored
  Severity: normal
  Priority: P3
 Component: c++
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=40139