[Bug fortran/37829] ICE in resolve_symbol

[dominiq at lps dot ens dot fr]

--- Comment #3 from dominiq at lps dot ens dot fr  2008-12-09 08:41 ---
The patch in comment #2 fixes the ICE without regression on i686-apple-darwin9.
Is not the "obvious rule" applying here?
Thanks


-- 


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

[Bug middle-end/38431] [graphite] several ICEs with CP2K

[jv244 at cam dot ac dot uk]

--- Comment #1 from jv244 at cam dot ac dot uk  2008-12-09 08:42 ---
Tobias, 

you might be interested to check if your recent patch also fixed these bugs.
Otherwise I should be able to give it a round of testing before the weekend.


-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

 CC||grosser at gcc dot gnu dot
   ||org


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

[Bug ada/38450] [4.4 Regression] ada bootstrap is broken

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2008-12-09 08:56 ---
Testing a 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
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-12-09 08:56:03
   date||


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

[Bug web/12821] dead link on onlinedocs/gccint/Top-Level.html

[steven at gcc dot gnu dot org]

--- Comment #9 from steven at gcc dot gnu dot org  2008-12-09 09:00 ---
Something as simple as this would already fix the broken link.

Index: gcc/doc/sourcebuild.texi
===
--- gcc/doc/sourcebuild.texi(revision 142582)
+++ gcc/doc/sourcebuild.texi(working copy)
@@ -93,8 +93,14 @@
 The build system in the top level directory, including how recursion
 into subdirectories works and how building runtime libraries for
 multilibs is handled, is documented in a separate manual, included
-with GNU Binutils.  @xref{Top, , GNU configure and build system,
+with GNU Binutils.
[EMAIL PROTECTED] ??? This manual is apparently not available online.  Keep the 
cross
[EMAIL PROTECTED] reference for 'info' but leave it out of HTML pages to avoid 
broken
[EMAIL PROTECTED] links on the web site.
[EMAIL PROTECTED]
[EMAIL PROTECTED], , GNU configure and build system,
 configure, The GNU configure and build system}, for details.
[EMAIL PROTECTED] ifinfo

 @node gcc Directory
 @section The @file{gcc} Subdirectory


-- 


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

[Bug fortran/38430] [4.4 Regression]: gfortran.dg/streamio_1.f90, 10, 14, 2, 6 now fails

[hp at gcc dot gnu dot org]

--- Comment #12 from hp at gcc dot gnu dot org  2008-12-09 09:17 ---
.


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug tree-optimization/38445] [4.4 Regression] ICE in tree-ssa-struct-alias when compiling grub-0.97

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-12-09 11:06 ---
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=38445

[Bug ada/38450] [4.4 Regression] ada bootstrap is broken

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2008-12-09 13:44 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/37829] ICE in resolve_symbol

[mikael at gcc dot gnu dot org]

--- Comment #4 from mikael at gcc dot gnu dot org  2008-12-09 13:53 ---
(In reply to comment #3)
> The patch in comment #2 fixes the ICE without regression on 
> i686-apple-darwin9.
I didn't expect any regression with that patch. 
However, I wonder whether we are not missing something. 

For example, I tried to adapt the testcase in PR 33295 to the c_funloc case. 
The resulting program is rejected with the following error:
Error: Can't convert TYPE(_gfortran_iso_c_binding_c_funptr) to TYPE(c_funptr)
at (1)
The question is: Is it valid/Do we want to support this?

module a
  use iso_c_binding, only:c_funptr
end module a

module b
  use iso_c_binding, only:c_funloc!,c_funptr
end module b

module f
  contains
  subroutine g() bind(c)
  end subroutine
end module f

program c
  use b
  use a
  use f
  implicit none
  type (c_funptr) :: d 
  d = c_funloc (g)
end


-- 


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

[Bug tree-optimization/38445] [4.4 Regression] ICE in tree-ssa-struct-alias when compiling grub-0.97

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-12-09 11:07 ---
Subject: Bug 38445

Author: rguenth
Date: Tue Dec  9 11:06:34 2008
New Revision: 142590

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142590
Log:
2008-12-09  Richard Guenther  <[EMAIL PROTECTED]>

PR tree-optimization/38445
* tree-ssa-structalias.c (emit_pointer_definition): Only visit
names once.
(emit_alias_warning): Adjust.

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


-- 


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

[Bug ada/38450] [4.4 Regression] ada bootstrap is broken

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2008-12-09 10:36 ---
Subject: Bug 38450

Author: jakub
Date: Tue Dec  9 10:35:15 2008
New Revision: 142588

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142588
Log:
PR ada/38450
* gcc-interface/utils.c (finish_record_type): Use SET_TYPE_MODE.
* gcc-interface/decl.c (gnat_to_gnu_entity, make_aligning_type):
Likewise.

Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gcc-interface/decl.c
trunk/gcc/ada/gcc-interface/utils.c


-- 


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

[Bug web/12821] dead link on onlinedocs/gccint/Top-Level.html

[joseph at codesourcery dot com]

--- Comment #10 from joseph at codesourcery dot com  2008-12-09 13:40 
---
Subject: Re:  dead link on onlinedocs/gccint/Top-Level.html

On Tue, 9 Dec 2008, steven at gcc dot gnu dot org wrote:

> [EMAIL PROTECTED] ??? This manual is apparently not available online.  Keep 
> the cross

But it is online - http://www.airs.com/ian/configure/ - and while that's 
not a makeinfo --html copy, when it's only linking to the manual as a 
whole that doesn't matter much (a single redirect in .htaccess should 
suffice - and the fix being such a redirect is why I say this is a web 
problem not a manual problem).

I believe the description of how multilibs are built is still relevant, 
although no-one has updated that manual to reflect toplevel 
autoconfiscation.  If the assignment issues were resolved (that manual has 
a Cygnus copyright notice) then it might make sense to move the multilib 
documentation into the GCC documentation and remove the reference to this 
old manual.


-- 


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

[Bug rtl-optimization/38452] New: delared branch scheduling doesn't fully take return into account

[amylaar at gcc dot gnu dot org]

Due to a backend bug, dbr had picked a delay slot insn for annul-true which was
not actually elegible for annul-true.  When I fixed the bug, I found that
instead an insn from the target path was chosen, the restore of the return
address, as the target is an epilogue.
The original instruction, mov r4,-1 , would have been suitable as a non-anulled
delay slot insn, since r4 is a call-used register, and the function does not
return a value that would require r4 to represent, and the epilogue did not
make use of the value in r4.

I've seen this for ARC compiling
cjpeg/jcmarker.c
using the options:
-mnorm -mswap -mmul64 -mARC600 -O3 -fomit-frame-pointer

in the function write_file_header.

For obvious reasons I can't provide preprocessed source for some eighty years.


-- 
   Summary: delared branch scheduling doesn't fully take return into
account
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: minor
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org


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

[Bug target/38344] [4.3 Regression] bootstrap failure in libjava/link.cc (ICE in invariant_for_use)

[ebotcazou at gcc dot gnu dot org]

--- Comment #11 from ebotcazou at gcc dot gnu dot org  2008-12-09 10:58 
---
> a current snapshot from the branch, exluding r142149 works for me. I'll try to
> reduce the applied patches until the builds succeeds again with r142149, but
> again, this may take a while.

The only possibility is some patch that defines EH_USES for ARM.


-- 


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

[Bug tree-optimization/35468] [4.2/4.3/4.4 Regression] LHS of assignment can be folded to a constant causing ICE

[jakub at gcc dot gnu dot org]

-- 

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 |
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2008-
   ||12/msg00535.html
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-03-06 10:35:49 |2008-12-09 14:09:32
   date||


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

[Bug c++/38410] [4.4 regression] g++.dg/eh/crossjump1.C (internal compiler error)

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2008-12-09 14:12 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c/38453] New: Output code optimisation excessive use of builtins

[vince at simtec dot co dot uk]

While compiling compression code for LZMA for use with an embedded ARM target I
have discovered a regression from previous editions of GCC.

I have pared this down to a trivial example (attached) which boils down to a
application specific modulus operation (please note this is the *minimal* test
case and obviously is a bit more complex buried in the middle of the
compression system. The behavior exhibited remains the same in both the large
and small systems.

The simple test case is compiled with  
arm-unknown-linux-gnu-gcc -Os -o foo test.c

and the resulting objdump is:

83fc :
83fc:   e92d4010push{r4, lr}
8400:   e5d11000ldrbr1, [r1]
8404:   e1a04000mov r4, r0
8408:   e1a02001mov r2, r1
840c:   ea02b   841c 
8410:   e5943004ldr r3, [r4, #4]
8414:   e2833001add r3, r3, #1  ; 0x1
8418:   e5843004str r3, [r4, #4]
841c:   e242302dsub r3, r2, #45 ; 0x2d
8420:   e352002ccmp r2, #44 ; 0x2c
8424:   e20320ffand r2, r3, #255; 0xff
8428:   8af8bhi 8410 
842c:   e1a1mov r0, r1
8430:   e3a0102dmov r1, #45 ; 0x2d
8434:   eb03bl  8448 <__umodsi3>
8438:   e2ffand r0, r0, #255; 0xff
843c:   e584str r0, [r4]
8440:   e8bd8010pop {r4, pc}

if a differing optimisation is used:

arm-unknown-linux-gnu-gcc -O2 -o foo test.c

83fc :
83fc:   e92d4070push{r4, r5, r6, lr}
8400:   e5d14000ldrbr4, [r1]
8404:   e354002ccmp r4, #44 ; 0x2c
8408:   e1a06000mov r6, r0
840c:   9a0ebls 844c 
8410:   e244402dsub r4, r4, #45 ; 0x2d
8414:   e20440ffand r4, r4, #255; 0xff
8418:   e5905004ldr r5, [r0, #4]
841c:   e3a0102dmov r1, #45 ; 0x2d
8420:   e1a4mov r0, r4
8424:   eb4fbl  8568 <__umodsi3>
8428:   e3a0102dmov r1, #45 ; 0x2d
842c:   e1a03000mov r3, r0
8430:   e1a4mov r0, r4
8434:   e20340ffand r4, r3, #255; 0xff
8438:   eb06bl  8458 <__aeabi_uidiv>
843c:   e2855001add r5, r5, #1  ; 0x1
8440:   e2ffand r0, r0, #255; 0xff
8444:   e0855000add r5, r5, r0
8448:   e5865004str r5, [r6, #4]
844c:   e5864000str r4, [r6]
8450:   e8bd8070pop {r4, r5, r6, pc}

Actually several optimization levels were tried and all produced similar output

GCC 4.2.2 and 4.2.4 (which are our current compliers) 
arm-unknown-linux-gnueabi-gcc -Os -o foo test.c
produce:

8328 :
8328:   e5d12000ldrbr2, [r1]
832c:   ea03b   8340 
8330:   e5903004ldr r3, [r0, #4]
8334:   e20120ffand r2, r1, #255; 0xff
8338:   e2833001add r3, r3, #1  ; 0x1
833c:   e5803004str r3, [r0, #4]
8340:   e352002ccmp r2, #44 ; 0x2c
8344:   e242102dsub r1, r2, #45 ; 0x2d
8348:   8af8bhi 8330 
834c:   e5802000str r2, [r0]
8350:   e12fff1ebx  lr



As can be seen the trivial loop is performed and the divisor and remainder
found but then the __umodsi3 builtin is called to do the operation *again* and
that used to assign the result which is already available from the loop!

This odd behavior is seen in cross built (and native) GCC 4.3.2 but not in
4.2.4 it seems to be present in current development builds however I have
issues building those reliably so cannot give definite results.

The behavior is especially obvious with large performance and code size
degradation in compression code on small embedded system. Also the additional
need to link in the __umodsi3 implementation causes more space to be lost. 

This has also been observed in some circumstances within ARM kernels when using
modulous on powers of two! the obvious optimisation using shifts is performed
and then the value recomputed using __modsi3

Just for completeness here is the GCC 4.3.2 compiler used for the tests (the
4.3.4 produces identical compiled output but has other undesirable behaviors
not relevant to this report)

arm-unknown-linux-gnu-gcc -v
Using built-in specs.
Target: arm-unknown-linux-gnu
Configured with: /opt/simtec/crosstool-ng/targets/src/gcc-4.3.2/configure
--build=x86_64-build_unknown-linux-gnu --host=x86_64-build_unknown-linux-gnu
--target=arm-unknown-linux-gnu --prefix=/opt/simtec/arm-unknown-linux-gnu
--with

[Bug c/38453] Output code optimisation excessive use of builtins

[vince at simtec dot co dot uk]

--- Comment #1 from vince at simtec dot co dot uk  2008-12-09 14:51 ---
Created an attachment (id=16854)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16854&action=view)
Trivial test code to show behaviour


-- 


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

[Bug target/38344] [4.3 Regression] bootstrap failure in libjava/link.cc (ICE in invariant_for_use)

[doko at ubuntu dot com]

--- Comment #12 from doko at ubuntu dot com  2008-12-09 15:28 ---
sorry for not noticing earlier; indeded, this is a patch by CodeSourcery to
enable to build libobjc.

see http://lists.debian.org/debian-gcc/2008/04/msg00240.html

I don't see this defined on the trunk. I suppose this report can be closed.


-- 


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

[Bug middle-end/38454] New: [4.4 Regression] memcpy folding breaks -D_FORTIFY_SOURCE=2 protection

[jakub at gcc dot gnu dot org]

/* { dg-do compile } */
/* { dg-options "-O2" } */

typedef __SIZE_TYPE__ size_t;

extern inline __attribute__((gnu_inline, always_inline, artificial)) void *
memcpy (void *__restrict dest, const void *__restrict src, size_t len)
{
  return __builtin___memcpy_chk (dest, /* { dg-warning "will always overflow
destination buffer" } */
 src, len, __builtin_object_size (dest, 0));
}

struct S { char buf[10]; } s;

void
foo (void)
{
  char buf[12];
  char *p = buf + 4;
  struct S *q = (struct S *) p;
  memcpy (q, &s, sizeof (s));
}

/* { dg-final { scan-assembler "__memcpy_chk" } } */

FAILs since I've added new memcpy folding.  The memcpy is folded before it is
inlined and so it isn't warned on, nor checked at runtime.  Testing a patch
that will help this as well as e.g. the memset swapped arguments warning.


-- 
   Summary: [4.4 Regression] memcpy folding breaks -
D_FORTIFY_SOURCE=2 protection
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: jakub at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org


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

[Bug middle-end/38454] [4.4 Regression] memcpy folding breaks -D_FORTIFY_SOURCE=2 protection

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-12-09 15:42:33
   date||
   Target Milestone|--- |4.4.0


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

[Bug target/38344] [4.3 Regression] bootstrap failure in libjava/link.cc (ICE in invariant_for_use)

[jakub at gcc dot gnu dot org]

--- Comment #13 from jakub at gcc dot gnu dot org  2008-12-09 16:06 ---
Works with upstream 4.3 and on the trunk.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


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

[Bug target/38344] [4.3 Regression] bootstrap failure in libjava/link.cc (ICE in invariant_for_use)

[ebotcazou at gcc dot gnu dot org]

--- Comment #14 from ebotcazou at gcc dot gnu dot org  2008-12-09 16:35 
---
> sorry for not noticing earlier; indeded, this is a patch by CodeSourcery to
> enable to build libobjc.
> 
> see http://lists.debian.org/debian-gcc/2008/04/msg00240.html

Thanks.  The definition of EH_USES looks suspicious given

/* Use r0 and r1 to pass exception handling information.  */
#define EH_RETURN_DATA_REGNO(N) (((N) < 2) ? N : INVALID_REGNUM)

This might have been a work around for the problem fixed by

2008-11-25  Eric Botcazou  <[EMAIL PROTECTED]>

* regrename.c (merge_overlapping_regs): Add registers artificially
defined at the top of the basic block to the set of live ones just
before the first insn.


-- 


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

[Bug tree-optimization/35468] [4.2/4.3/4.4 Regression] LHS of assignment can be folded to a constant causing ICE

[jakub at gcc dot gnu dot org]

--- Comment #9 from jakub at gcc dot gnu dot org  2008-12-09 16:57 ---
Subject: Bug 35468

Author: jakub
Date: Tue Dec  9 16:55:35 2008
New Revision: 142598

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142598
Log:
PR tree-optimization/35468
* tree-ssa-ccp.c (fold_stmt_r): Don't fold reads from constant
string on LHS.

* gcc.dg/pr35468.c: New test.
* gcc.c-torture/compile/pr35468.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr35468.c
trunk/gcc/testsuite/gcc.dg/pr35468.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-ccp.c


-- 


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

[Bug testsuite/37326] gcc.dg/tree-ssa/ssa-store-ccp-3.c scan-tree-dump-times optimized "conststaticvariable" 1

[sje at gcc dot gnu dot org]

--- Comment #8 from sje at gcc dot gnu dot org  2008-12-09 16:59 ---
Subject: Bug 37326

Author: sje
Date: Tue Dec  9 16:57:49 2008
New Revision: 142599

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142599
Log:
PR testsuite/37326
* gcc.dg/tree-ssa/ssa-store-ccp-3.c: Skip on hppa*64-*-*.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-store-ccp-3.c


-- 


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

[Bug c++/38455] New: aligned struct members in heap-allocated code

[tim at klingt dot org]

the following code works on x86_64 as 64-bit binary, but the alignment
constraints of heap-allocated structs are not matched, when compiling 32-bit
code:

#include 

template 
struct aligned_buffer
{
char padding;
float data[size] __attribute__((aligned((16;
};

struct my_struct
{
aligned_buffer<> buf1;
char padding;
aligned_buffer<> buf2;
};



int main()
{
{
aligned_buffer<> ab;
assert((long)&ab.data % 16 == 0);
}

{
my_struct m;
assert((long)&m.buf1.data % 16 == 0);
assert((long)&m.buf2.data % 16 == 0);
}

{
aligned_buffer<> * ab = new aligned_buffer<>();
assert((long)&ab->data % 16 == 0); /* fails */
}

{
my_struct * m = new my_struct();
assert((long)&m->buf1.data % 16 == 0); /* fails */
assert((long)&m->buf2.data % 16 == 0); /* fails */
delete m;
}
}

g++ -m32: int main(): Assertion `(long)&ab->data % 16 == 0' failed.
g++ -m64: works fine

when changing the alignment from 16 to 64, the alignment constraints for
heap-allocated structs fail with both -m32 and -m64.


-- 
   Summary: aligned struct members in heap-allocated code
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tim at klingt dot org


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

[Bug testsuite/37326] gcc.dg/tree-ssa/ssa-store-ccp-3.c scan-tree-dump-times optimized "conststaticvariable" 1

[sje at cup dot hp dot com]

--- Comment #9 from sje at cup dot hp dot com  2008-12-09 17:05 ---
Fixed by skipping the test on hppa64.


-- 

sje at cup dot hp dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/35468] [4.2/4.3 Regression] LHS of assignment can be folded to a constant causing ICE

[jakub at gcc dot gnu dot org]

--- Comment #10 from jakub at gcc dot gnu dot org  2008-12-09 17:09 ---
Fixed on the trunk.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail|4.2.0 4.3.0 4.4.0   |4.2.0 4.3.0
  Known to work|4.1.0 4.0.1 |4.1.0 4.0.1 4.4.0
Summary|[4.2/4.3/4.4 Regression] LHS|[4.2/4.3 Regression] LHS of
   |of assignment can be folded |assignment can be folded to
   |to a constant causing ICE   |a constant causing ICE


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

[Bug tree-optimization/37416] [4.4 Regression] Failure to return number of loop iterations

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2008-12-09 17:14 ---
> I have not yet tracked this down to the patch that produced this regression.

I have tracked this down to r138207 AKA tuples branch merge.
*.ifcvt dump looks the same (the only difference is:
-  # SMT.10D.1968_19 = PHI 
   # iD.1947_18 = PHI 
+  # SMT.10D.1968_19 = PHI 
), I'll try to debug this side by side where it differs.


-- 


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

[Bug c++/38455] aligned struct members in heap-allocated code

[brian at dessent dot net]

--- Comment #1 from brian at dessent dot net  2008-12-09 17:14 ---
Subject: Re:   New: aligned struct members in heap-allocated code

This is a dup of pr15795.  Basically, operator new is just a wrapper
around malloc from the libc, and malloc returns an allocation with a
fixed alignment (8 for x86 and 16 for x86_64 in the case of glibc.) 
There is no way to communicate any alignment requirement to malloc(), so
you'd have to override operator new to use posix_memalign() or something
in this case.


-- 


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

[Bug c++/38455] aligned struct members in heap-allocated code

[tim at klingt dot org]

--- Comment #2 from tim at klingt dot org  2008-12-09 17:23 ---
well, would be nice to read something like that in the attribute documentation
...


-- 


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

[Bug fortran/37829] ICE in resolve_symbol

[burnus at gcc dot gnu dot org]

--- Comment #5 from burnus at gcc dot gnu dot org  2008-12-09 17:28 ---
(In reply to comment #4)
> For example, I tried to adapt the testcase in PR 33295 to the c_funloc case. 
> The resulting program is rejected with the following error:
> Error: Can't convert TYPE(_gfortran_iso_c_binding_c_funptr) to TYPE(c_funptr)
> at (1)
> The question is: Is it valid/Do we want to support this?

I don't see why it should be invalid (though I have not spend too much time on
finding a reason). It also compiles just fine with ifort and g95.


-- 


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

[Bug testsuite/38420] gcc.target/i386/pr37248-2.c doesn't work on ia32

[hjl at gcc dot gnu dot org]

--- Comment #1 from hjl at gcc dot gnu dot org  2008-12-09 17:39 ---
Subject: Bug 38420

Author: hjl
Date: Tue Dec  9 17:38:09 2008
New Revision: 142601

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142601
Log:
2008-12-09  H.J. Lu  <[EMAIL PROTECTED]>

PR testsuite/38420
* gcc.target/i386/pr37248-2.c: Support hex dump on 32bit host.
* gcc.target/i386/pr37248-3.c: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/pr37248-2.c
trunk/gcc/testsuite/gcc.target/i386/pr37248-3.c


-- 


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

[Bug c++/15795] No way to teach operator new anything about alignment requirements

[rguenth at gcc dot gnu dot org]

--- Comment #42 from rguenth at gcc dot gnu dot org  2008-12-09 17:43 
---
*** Bug 38455 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tim at klingt dot org


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

[Bug c++/38455] aligned struct members in heap-allocated code

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-12-09 17:43 ---


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


-- 

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=38455

[Bug fortran/36355] matmul argument-check: wrong error messages

[dfranke at gcc dot gnu dot org]

-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dfranke at gcc dot gnu dot
   |dot org |org
URL||http://gcc.gnu.org/ml/fortra
   ||n/2008-12/msg00138.html
 Status|NEW |ASSIGNED
   Keywords||patch
   Last reconfirmed|2008-07-22 12:30:06 |2008-12-09 17:48:14
   date||


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

[Bug c/38456] New: Suggestion: slight improvement of scoping rules

[lc235951 at students dot mimuw dot edu dot pl]

I would like to make a suggestion regarding the problem I posed in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38443 (sorry I didn't check with
the trunk).

To repeat it: the scope of a variable begins in its initializer instead of
after it, making e.g. the following program output some random value instead of
1:

int main()
{
  int x = 0;
  { int x = x + 1;
printf("%d\n", x);
  }
  return 0;
}

As I've learned from the reply this behaviour is not only an artifact of GCC,
but it's mandated by the standard. Maybe it is correct in ISO C, but it's plain
stupid. At least I cannot see any use for such behaviour, and I can see why it
should be different.

I suggest to change the scoping rules so that variables become visible after
their initializers, maybe leaving the old behaviour with -pedantic or -ansi.
There could also be a warning generated that it might not work with other
compilers if somebody actually tries to use this feature.

Here are my reasons:

1) Consider the following code:
#define macro(a) \
{\
   int x = (a);  \
/* ... some code ... */
}
void f()
{
   int x = 0;
   macro(x);
   /* ... */
}
And we get a very subtle bug here. Obviously, after getting a warning one could
rename the variable, but it's just a vexation. And it's even more confusing if
the code is auto-generated, or the macro is provided by some library header.
One might remark here that I should use `_x' in the macro instead of `x'. OK,
that's fine, but if you've got a macro inside a macro, then it gets more
complicated. The truth is that with the current behaviour it's IMPOSSIBLE to
ensure in advance that ANY macro works correctly without checking ALL its uses,
and ALL variable names in ALL macros used by it, recursively.

2) The proposed scoping rules, besides being more coherent, are used in
languages like ML or Lisp, so many people may assume them by default.

3) The proposed improvement may be non-conforming, but it cannot break any
code, because anything which uses a variable in its own initializer is already
broken.

4) This shouldn't be difficult to change, though I may be wrong here. I'm not
familiar with GCC internals, but from what I know about compiler construction
it should amount to moving a store to a symbol table (or whatever you have
there) several statements forward.

5) Believe it or not, but it would make life easier for me. I'm used to write C
code in a peculiar functional-like fashion, passing whole blocks to macros as
if they were lambda-expression (possible with GCC). With this kind of style the
issue comes up much more often.

This improvement is not very important, but its introduction would just make
the language more coherent.

Forgive me if this issue was already discussed, or if you think it's not
appropriate as a bug report (I rarely file bug reports for GCC, so I don't know
what's appropriate ;)

Regards,
Łukasz Czajka


-- 
   Summary: Suggestion: slight improvement of scoping rules
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lc235951 at students dot mimuw dot edu dot pl
  GCC host triplet: irrelevant


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

[Bug debug/27574] [4.2/4.3 Regression] MIssing debug info at -O0 for a local variable in a C++ constructor

[amylaar at gcc dot gnu dot org]

--- Comment #30 from amylaar at gcc dot gnu dot org  2008-12-09 18:22 
---
I think the testcase pr27574.C should be added to the testsuite before
closing this bug.


-- 

amylaar at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug target/38326] [4.3/4.4 regression] libjava build failure on ia64-linux-gnu

[ebotcazou at gcc dot gnu dot org]

--- Comment #3 from ebotcazou at gcc dot gnu dot org  2008-12-09 18:32 
---
Now on to this one. :-)  Is 20081115 the date of the first failure? 08 was
fine?

There are test results for IA-64/Linux (suse-linux and unknown-linux) both
4.3.3
and 4.4.0 posted on the gcc-testresults on a daily basis.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |WAITING


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

[Bug debug/27574] [4.2/4.3 Regression] MIssing debug info at -O0 for a local variable in a C++ constructor

[amylaar at gcc dot gnu dot org]

--- Comment #31 from amylaar at gcc dot gnu dot org  2008-12-09 18:48 
---
Sorry, I only checked for the presence of the original testcase name in
the testsuite, and thus missed the fact that there is a new test called
local-var-in-contructor.C [sic] .


-- 

amylaar at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED


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

[Bug c/38456] Suggestion: slight improvement of scoping rules

[brian at dessent dot net]

--- Comment #1 from brian at dessent dot net  2008-12-09 18:53 ---
Subject: Re:   New: Suggestion: slight improvement of scoping rules

I seriously don't think you will ever convince anyone to change a facet
of gcc which is currently following the standard to something that is
non-standard.

Besides, you can solve the unique name problem like this:

#define UNIQUIFY2(a,b) a##b
#define UNIQUIFY1(a,b) UNIQUIFY2(a,b)
#define UNIQUIFY(x) UNIQUIFY1(x_,__COUNTER__)

#define macro(a) \
({   \
   __typeof(a) UNIQUIFY(a) = (a);  \
/* ... some code ... */ \
})

__COUNTER__ was new in 4.3.


-- 


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

[Bug target/38326] [4.3/4.4 regression] libjava build failure on ia64-linux-gnu

[steven at gcc dot gnu dot org]

--- Comment #4 from steven at gcc dot gnu dot org  2008-12-09 18:53 ---
I have had no trouble bootstrapping 4.4 on ia64-unknown-linux-gnu (Debian) in
the last two weeks.


-- 


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

[Bug c/38456] Suggestion: slight improvement of scoping rules

[steven at gcc dot gnu dot org]

--- Comment #2 from steven at gcc dot gnu dot org  2008-12-09 18:59 ---
This is what -Wshadow is for.  We can't invent a new C dialect or "fix" the
standard.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c/38456] Suggestion: slight improvement of scoping rules

[lc235951 at students dot mimuw dot edu dot pl]

--- Comment #3 from lc235951 at students dot mimuw dot edu dot pl  
2008-12-09 19:09 ---
I know I can turn on warnings or use some tricks like UNIQUIFY(), but it's just
cumbersome with large macros.

I also know that changing the standard is considered "not done", but in this
case it cannot have any undesirable consequences, because any code exploiting
this behaviour is by definition incorrect (except for the case that you want to
get a random value from the stack in a really strange way). The only drawback
is that users may get used to it and try it with other compilers, so I proposed
a warning.

Well, but if you insist on such strict compliance then let it be so. After all
it's not that very important.


-- 


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

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

[dfranke at gcc dot gnu dot org]

--- Comment #2 from dfranke at gcc dot gnu dot org  2008-12-09 19:12 ---
Confirmed. As is, the testcase hangs for me and does not ICE. However, valgrind
shows

==3159==
pr37744.f90:22.19:  

  foo%flags(trouble) = .FALSE.
  1   
Error: Symbol 'trouble' at (1) has no IMPLICIT type
==3159== Invalid read of size 4
==3159==at 0x80C88BB: gfc_delete_symtree (symbol.c:2269)
==3159==by 0x80C898C: gfc_undo_symbols (symbol.c:2723)  
==3159==by 0x80A35E4: decode_statement (parse.c:267)
==3159==by 0x80A46C4: next_statement (parse.c:661)  
==3159==by 0x80A6DFB: gfc_parse_file (parse.c:3781) 
==3159==by 0x80EC438: gfc_init_constants (trans-const.c:197)
==3159==by 0x80D6CDC: gfc_be_parse_file (f95-lang.c:236)
==3159==by 0x83B7FC2: toplev_main (toplev.c:968)
==3159==by 0x40D1004: (below main) (in /lib/libc-2.6.1.so)  
==3159==  Address 0x42893e8 is 0 bytes inside a block of size 1,676 free'd
==3159==at 0x4023F2A: free (vg_replace_malloc.c:323)  
==3159==by 0x80C81B5: gfc_free_namespace (symbol.c:3065)  
==3159==by 0x80EC438: gfc_init_constants (trans-const.c:197)  
==3159==by 0x80D6CDC: gfc_be_parse_file (f95-lang.c:236)  
==3159==by 0x83B7FC2: toplev_main (toplev.c:968)  
==3159==by 0x40D1004: (below main) (in /lib/libc-2.6.1.so)

[snipped many more invalid reads/writes]

==3159==
==3159== ERROR SUMMARY: 78 errors from 19 contexts (suppressed: 7 from 1)
==3159== malloc/free: in use at exit: 212,092 bytes in 976 blocks.
==3159== malloc/free: 2,238 allocs, 1,268 frees, 522,550 bytes allocated.
==3159== For counts of detected errors, rerun with: -v
==3159== searching for pointers to 976 not-freed blocks.
==3159== checked 2,261,148 bytes.


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dfranke at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   GCC host triplet|i686-pc-linux-gnu   |
 GCC target triplet|i686-pc-linux-gnu   |
  Known to fail||4.3.2 4.4.0
   Last reconfirmed|-00-00 00:00:00 |2008-12-09 19:12:15
   date||


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

[Bug fortran/35983] C_LOC in derived type constructor gives weird result

[mikael at gcc dot gnu dot org]

--- Comment #3 from mikael at gcc dot gnu dot org  2008-12-09 19:13 ---
Subject: Bug 35983

Author: mikael
Date: Tue Dec  9 19:12:27 2008
New Revision: 142605

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142605
Log:
2008-12-09  Mikael Morin  <[EMAIL PROTECTED]>

PR fortran/35983
* trans-expr.c (gfc_trans_subcomponent_assign):
Add se's pre and post blocks to current block.
(gfc_trans_structure_assign): Remove specific handling
of C_NULL_PTR and C_NULL_FUNPTR.

2008-12-09  Mikael Morin  <[EMAIL PROTECTED]>

PR fortran/35983
* gfortran.dg/pr35983.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/pr35983.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/36912] [4.2/4.3/4.4 regression] ICE with "-frounding-math -g"

[mmitchel at gcc dot gnu dot org]

--- Comment #8 from mmitchel at gcc dot gnu dot org  2008-12-09 19:20 
---
With respect to Comment #4: I see no reason for C++ to be different than C in
this respect, and thus I see no reason not to perform the computation at
compile-time.

In general, although some in the committees do not seem to care, users expect C
to be a subset of C++.  Certainly, wherever the standards permit us to do so,
we should make GNU C and GNU C++ behave identically; compiling C code as C++
with the same toolset and getting different results leads to user surprise.


-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug fortran/37469] invalid GMP usage on gfortran.dg/parameter_array_init_3.f90

[mikael at gcc dot gnu dot org]

--- Comment #6 from mikael at gcc dot gnu dot org  2008-12-09 19:22 ---
Subject: Bug 37469

Author: mikael
Date: Tue Dec  9 19:20:18 2008
New Revision: 142606

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142606
Log:
2008-12-09  Mikael Morin  <[EMAIL PROTECTED]>

PR fortran/37469
* expr.c (find_array_element): Simplify array bounds.
Assert that both bounds are constant expressions.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c


-- 


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

[Bug fortran/36457] preprocessing: option -idirafter undefined for fortran

[dfranke at gcc dot gnu dot org]

--- Comment #5 from dfranke at gcc dot gnu dot org  2008-12-09 19:27 ---
Subject: Bug 36457

Author: dfranke
Date: Tue Dec  9 19:25:55 2008
New Revision: 142607

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142607
Log:
2008-12-09  Daniel Franke  <[EMAIL PROTECTED]>

PR fortran/36457
* lang.opt: Added option idirafter.
* cpp.h (gfc_cpp_add_include_path_after): New prototype.
* cpp.c (gfc_cpp_handle_option): Recognize and handle OPT_dirafter.
(gfc_cpp_add_include_path_after): New, adds user-defined search path
after any other paths.
* invoke.texi (idirafter): New.
(no-range-check): Fixed entry in option-index.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/cpp.c
trunk/gcc/fortran/cpp.h
trunk/gcc/fortran/invoke.texi
trunk/gcc/fortran/lang.opt


-- 


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

[Bug rtl-optimization/38434] [4.4 Regression] speed regression with hand-unrolled matmul

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug middle-end/37843] [4.4 Regression] unaligned stack in main due to tail call optimization

[mmitchel at gcc dot gnu dot org]

--- Comment #20 from mmitchel at gcc dot gnu dot org  2008-12-09 19:34 
---
HJ --

As Richard says, you should not have checked in the new testcases without
XFAILs and without having fixed the bug.

Furthermore, your patch to the middle-end is without explanation.  What is the
problem?  How does your patch fix the problem?

-- Mark


-- 


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

[Bug middle-end/38271] [4.4 Regression] Spurious / missing "... used uninitialized in this function" warning

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug c++/38427] [4.4 Regression] crash for reference init code

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug middle-end/38454] [4.4 Regression] memcpy folding breaks -D_FORTIFY_SOURCE=2 protection

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug fortran/36457] preprocessing: option -idirafter undefined for fortran

[dfranke at gcc dot gnu dot org]

--- Comment #6 from dfranke at gcc dot gnu dot org  2008-12-09 19:29 ---
Fixed in trunk. Closing.


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug c/38457] New: -Wattributes gives warnings for portable code for default-packed architectures.

[hp at gcc dot gnu dot org]

c-common.c:handle_packed_attribute about line 5117 gives a warning for types
where __attribute__ ((__packed__)) is applied but has no effect.  That
particular warning should be removed or perhaps moved to a separate flag,
because it emits warnings for code such as:

struct x
{
  char c;
  int x  __attribute__ ((__packed__));
};

*depending on the target ABI*, i.e. it will always warn for a target where the
default layout corresponds to the packed layout (example cut down from generic
code in glibc-2.9).  Worse, this warning is on by default.

I know someone will jump up and tell me to remove the attribute in the code,
but it doesn't work that way: editing the code is not appropriate (example cut
down from generic code in glibc).  Neither is shutting off *all*
attribute-warnings using -Wno-attributes.  Observed with [trunk revision
142601] and [gcc-4_3-branch revision 135713].


-- 
   Summary: -Wattributes gives warnings for portable code for
default-packed architectures.
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
GCC target triplet: cris-*-* and crisv32-*-* and other default-packed arches


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

[Bug fortran/37469] invalid GMP usage on gfortran.dg/parameter_array_init_3.f90

[mikael at gcc dot gnu dot org]

-- 

mikael at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |mikael at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-11-30 09:04:20 |2008-12-09 19:31:30
   date||
   Target Milestone|--- |4.4.0


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

[Bug middle-end/38431] [graphite] several ICEs with CP2K

[jv244 at cam dot ac dot uk]

--- Comment #2 from jv244 at cam dot ac dot uk  2008-12-09 19:41 ---
This is a simple testcase for one of the first segfaults, observed with current
graphite branch:

gfortran -c -O2 -ffree-form -fgraphite -fgraphite-identity test.f90
test.f90: In function ‘matmov’:
test.f90:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

> cat test.f90
  SUBROUTINE matmov ( n, m, a, lda, b, ldb )
INTEGER, PARAMETER :: dbl=KIND(0.0D0)
INTEGER  :: n, m, lda
COMPLEX(dbl) :: a( lda, * )
INTEGER  :: ldb
COMPLEX(dbl) :: b( ldb, * )

b ( 1:n , 1:m ) = a ( 1:n, 1:m )
  END SUBROUTINE matmov


-- 


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

[Bug fortran/35983] C_LOC in derived type constructor gives weird result

[mikael at gcc dot gnu dot org]

-- 

mikael at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |mikael at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-04-20 11:40:52 |2008-12-09 19:32:41
   date||
   Target Milestone|--- |4.4.0


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

[Bug testsuite/38420] gcc.target/i386/pr37248-2.c doesn't work on ia32

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2008-12-09 19:33 ---
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=38420

[Bug target/38326] [4.3/4.4 regression] libjava build failure on ia64-linux-gnu

[doko at ubuntu dot com]

--- Comment #5 from doko at ubuntu dot com  2008-12-09 19:50 ---
which versions of binutils/glibc are used? for debian these are binutils-2.18.1
and glibc-2.7.


-- 


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

[Bug tree-optimization/38458] New: copy-propagation doesn't handle cycles

[rguenth at gcc dot gnu dot org]

For

# a_1 = PHI 
b_1 = a_1;

copy-propagation propagates a_1 into b_1 instead of c_1 into a_1 and b_1.

This is because handling of PHI and copy nodes is different.  Either

Index: tree-ssa-copy.c
===
--- tree-ssa-copy.c (revision 142591)
+++ tree-ssa-copy.c (working copy)
@@ -793,7 +793,7 @@ copy_prop_visit_phi_node (gimple phi)
 memory reference of all the other arguments.  */
   if (phi_val.value == NULL_TREE)
{
- phi_val.value = arg;
+ phi_val.value = arg_val->value;
  continue;
}


or

Index: tree-ssa-copy.c
===
--- tree-ssa-copy.c (revision 142591)
+++ tree-ssa-copy.c (working copy)
@@ -574,8 +574,7 @@ dump_copy_of (FILE *file, tree var)
 static enum ssa_prop_result
 copy_prop_visit_assignment (gimple stmt, tree *result_p)
 {
-  tree lhs, rhs;
-  prop_value_t *rhs_val;
+  tree lhs, rhs, rhs_val;

   lhs = gimple_assign_lhs (stmt);
   rhs = gimple_assign_rhs1 (stmt);
@@ -583,10 +582,12 @@ copy_prop_visit_assignment (gimple stmt,

   gcc_assert (gimple_assign_rhs_code (stmt) == SSA_NAME);

-  rhs_val = get_copy_of_val (rhs);
+  rhs_val = get_last_copy_of (rhs);

   if (TREE_CODE (lhs) == SSA_NAME)
 {
+  bool res;
+
   /* Straight copy between two SSA names.  First, make sure that
 we can propagate the RHS into uses of LHS.  */
   if (!may_propagate_copy (lhs, rhs))
@@ -599,10 +600,15 @@ copy_prop_visit_assignment (gimple stmt,
 This is different from what we do in copy_prop_visit_phi_node.
 In those cases, we are interested in the copy-of chains.  */
   *result_p = lhs;
-  if (set_copy_of_val (*result_p, rhs_val->value))
-   return SSA_PROP_INTERESTING;
-  else
-   return SSA_PROP_NOT_INTERESTING;
+  res = set_copy_of_val (*result_p, rhs_val);
+  if (dump_file && (dump_flags & TDF_DETAILS))
+   {
+ fprintf (dump_file, "\nASSIGN node ");
+ dump_copy_of (dump_file, lhs);
+ fprintf (dump_file, "\n");
+   }
+
+  return res ? SSA_PROP_INTERESTING : SSA_PROP_NOT_INTERESTING;
 }

   return SSA_PROP_VARYING;


fixes this particular case.  Note that phicprop from DOM handles the above
case fine.  I have a testcase only on the alias-improvements branch with
a local patch applied.

Still - is there any fundamental reason to not use last_copy_of for assignments
and not the copy-of the phi arg?

The testcase goes as

PHI  a is copy of c
CPY  b is copy of c
  ... make edge executable
PHI  a is copy of b which is copy of c
CPY  b is not a copy (whoops, because of b in the copy-of chain of a)
PHI  a is not a copy
CPY  b is a copy of a

I don't know if we in general can fixup cycles this way (in the end we
do not want cycles to survive if there are copy-of edges from it, otherwise
we want to have a single representative).  Maybe we need to do SCC
finding first?


-- 
   Summary: copy-propagation doesn't handle cycles
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org


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

[Bug fortran/37468] unknown option -i not recognized by gfortran driver

[dfranke at gcc dot gnu dot org]

--- Comment #9 from dfranke at gcc dot gnu dot org  2008-12-09 19:54 ---
Subject: Bug 37468

Author: dfranke
Date: Tue Dec  9 19:53:02 2008
New Revision: 142608

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142608
Log:
2008-12-09  Daniel Franke  <[EMAIL PROTECTED]>

PR fortran/36376
PR fortran/37468
* lang-specs.h: Pass on -i* options to f951 to (probably) report
them as unknown. Duplicate gcc.c (cpp_options), but omit
-fpch-preprocess on -save-temps.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/lang-specs.h


-- 


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

[Bug fortran/36376] -cpp -save-temps passes unknown options to f951

[dfranke at gcc dot gnu dot org]

--- Comment #2 from dfranke at gcc dot gnu dot org  2008-12-09 19:54 ---
Subject: Bug 36376

Author: dfranke
Date: Tue Dec  9 19:53:02 2008
New Revision: 142608

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142608
Log:
2008-12-09  Daniel Franke  <[EMAIL PROTECTED]>

PR fortran/36376
PR fortran/37468
* lang-specs.h: Pass on -i* options to f951 to (probably) report
them as unknown. Duplicate gcc.c (cpp_options), but omit
-fpch-preprocess on -save-temps.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/lang-specs.h


-- 


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

[Bug fortran/36376] -cpp -save-temps passes unknown options to f951

[dfranke at gcc dot gnu dot org]

--- Comment #3 from dfranke at gcc dot gnu dot org  2008-12-09 19:55 ---
Fixed in trunk. Closing.


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug fortran/37468] unknown option -i not recognized by gfortran driver

[dfranke at gcc dot gnu dot org]

--- Comment #10 from dfranke at gcc dot gnu dot org  2008-12-09 19:56 
---
Fixed in trunk. Closing.


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/36912] [4.2/4.3/4.4 regression] ICE with "-frounding-math -g"

[sylvain dot pion at sophia dot inria dot fr]

--- Comment #9 from sylvain dot pion at sophia dot inria dot fr  2008-12-09 
20:03 ---
Incidentally, I submitted to WG21 a few days ago a proposal which will appear
in the coming mid-term mailing as N2811, named "Directed Rounding Arithmetic
Operations".  In the meantime, you can find it here:
http://www-sop.inria.fr/members/Sylvain.Pion/cxx/rounded_operations_N2811.pdf

This document proposes the addition of functions like:

--
template < float_round_style r, FloatingPointLike T, FloatingPointLike U >
requires True<(r != round_indeterminate)>
constexpr auto add(T t, U u) -> decltype(t + u);

Returns: The addition of t and u rounded according to r.
--

(and similarly for sub, mul, div, sqrt, fma, and int<->float and float<->float
conversions).

With these, it would be possible to explictly attach a rounding mode to an
operation in the source code.  Moreover, their constexpr nature would mean that
they would work for compile-time constants as well.  This would require a bit
of help from the compiler.

That would mean that code which cares about rounding modes would have a way to
say so, and then, other codes can more easily be dealt with (that is: no need
to bother thinking about the effect of -frounding-math on compile-time
constants computations).

(comments on the proposal are welcome, BTW)


-- 


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

[Bug tree-optimization/37894] [graphite] Polyhedron is not compiling (Summary)

[grosser at gcc dot gnu dot org]

--- Comment #3 from grosser at gcc dot gnu dot org  2008-12-09 20:08 ---
The graphite branch should now be able to compile polyhedron. 


-- 

grosser at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2008-10-22 21:39:50 |2008-12-09 20:08:48
   date||


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

[Bug middle-end/38431] [graphite] several ICEs with CP2K (summery)

[grosser at gcc dot gnu dot org]

--- Comment #3 from grosser at gcc dot gnu dot org  2008-12-09 20:10 ---
Thanks for these test cases.

My commit fixed at least one failure, but there are more.

To help us it would be great to get a little bit structure in the failures.
Just get for every failing test a backtrace and create for every different bug
a new bugreport.

A little bit like Bub37894 for polyhedron.

It would be awesome, if you also could add one reduced test case and one
backtrace to every bugreport.


-- 

grosser at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-12-09 20:10:27
   date||
Summary|[graphite] several ICEs with|[graphite] several ICEs with
   |CP2K|CP2K (summery)


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

[Bug c/38387] psim miscompiled [regression]

[joel at gcc dot gnu dot org]

--- Comment #11 from joel at gcc dot gnu dot org  2008-12-09 20:11 ---
I wondered if I had a mistake in my testing since some of the later results
didn't make sense as I thought about them.  I am pretty convinced now this 
is NOT a strict aliasing problem in psim.  

Broken when configuring GDB with:

(CFLAGS="-Wstrict-aliasing=2 -O2 -Wno-error -fno-strict-aliasing"
~/old/test-gcc/gdb-6.8/configure --disable-werror --target=powerpc-rtems4.10
--enable-sim --enable-sim-hardware --enable-timebase --enable-sim-trace
--prefix=/n/12/joel/test-gcc/install/

$ gcc --version
gcc (GCC) 4.4.0 20081205 (experimental) [trunk revision 142492]


-- 


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

[Bug middle-end/38459] New: [graphite] SEGFAULT in cloog_clast_create

[grosser at gcc dot gnu dot org]

In the current graphite branch we fail with a SEGFAULT.

#0  0x28ed1fb1 in _malloc_prefork () from /lib/libc.so.7
#1  0x28ed6f45 in realloc () from /lib/libc.so.7
#2  0x28c9d019 in __gmp_default_reallocate () from /usr/local/lib/libgmp.so.7
#3  0x28cb0a4e in __gmpz_realloc () from /usr/local/lib/libgmp.so.7
#4  0x28cb14ce in __gmpz_set () from /usr/local/lib/libgmp.so.7
#5  0x28ce44ec in insert_loop (loop=0x291b56e0, level=4, scalar=0,
next=0xbfbfe7f0, infos=0x291b53c0)
at source/ppl/clast.c:1446
#6  0x28ce46fd in insert_loop (loop=0x291b5340, level=3, scalar=0,
next=0xbfbfe7f0, infos=0x291b53c0)
at source/ppl/clast.c:1480
#7  0x28ce46fd in insert_loop (loop=0x291b53e0, level=2, scalar=0,
next=0xbfbfe7f0, infos=0x291b53c0)
at source/ppl/clast.c:1480
#8  0x28ce46fd in insert_loop (loop=0x291b5360, level=1, scalar=0,
next=0xbfbfe7f0, infos=0x291b53c0)
at source/ppl/clast.c:1480
#9  0x28ce492f in cloog_clast_create (program=0x2910bfe0, options=0x2916f1c0)
at source/ppl/clast.c:1518
#10 0x08a15cf2 in find_transform (scop=0x29132310) at
../../../git/gcc/graphite.c:4238
#11 0x08a189a8 in graphite_transform_loops () at
../../../git/gcc/graphite.c:5386

It seems we do not initialize the cloog data structures correct or there is a
bug in cloog.


-- 
   Summary: [graphite] SEGFAULT in cloog_clast_create
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: grosser at gcc dot gnu dot org
ReportedBy: grosser at gcc dot gnu dot org
OtherBugsDependingO 37894
 nThis:


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

�dv

[Anita]

Szia

Pár napja kérdezted hogy nem e tudok egy jó letöltős oldalt. És én
most találtam egyet.

Tele van jobbnál jobb filmekkel, és olcsó! 1 db sms elküldése után 500
kb/sec-el töltöttem napokig a legújabb premier filmeket és meséket!



Küldj most SMS-t,és 5 nap helyet,25-öt adunk,ez jelenlegi akciónk!



http://href.hu/x/7k7e

http://href.hu/x/7k7e



__

E-mail címed a Country jóvoltából került bele hírlevél rendszerünkbe.

Ha nem szeretnél több ilyet kapni. Írj a [EMAIL PROTECTED] email címre!

A küldő Fiktív, kitalált személy, de az e-mail címen elérsz
bennünket. 

[Bug middle-end/38459] [graphite] SEGFAULT in cloog_clast_create

[grosser at gcc dot gnu dot org]

--- Comment #1 from grosser at gcc dot gnu dot org  2008-12-09 20:17 ---
Created an attachment (id=16855)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16855&action=view)
Add reduced testcase from mltfftsg.F CP2K


-- 


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

[Bug tree-optimization/38458] copy-propagation doesn't handle cycles

[dnovillo at google dot com]

--- Comment #1 from dnovillo at google dot com  2008-12-09 20:22 ---
Subject: Re:  New: copy-propagation doesn't 
handle cycles

On Tue, Dec 9, 2008 at 14:53, rguenth at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>{
> - phi_val.value = arg;
> + phi_val.value = arg_val->value;
>  continue;
>}

This looks OK.

> -  rhs_val = get_copy_of_val (rhs);
> +  rhs_val = get_last_copy_of (rhs);

We don't want to propagate using get_last_copy_of here.  The reason
now escapes me, but it should be documented in the code.  It was
related to phi-cycles, but it's been a long time.


Diego.


-- 


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

[Bug middle-end/38431] [graphite] several ICEs with CP2K (summery)

[grosser at gcc dot gnu dot org]

--- Comment #4 from grosser at gcc dot gnu dot org  2008-12-09 20:24 ---
mltfftsg.F fails on Bug38459


-- 


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

[Bug middle-end/38459] [graphite] SEGFAULT in cloog_clast_create

[grosser at gcc dot gnu dot org]

-- 

grosser at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-12-09 20:26:08
   date||


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

[Bug fortran/38220] C_LOC intrinsic non-pure and without explicit interface

[dfranke at gcc dot gnu dot org]

--- Comment #1 from dfranke at gcc dot gnu dot org  2008-12-09 20:30 ---
The same seems to hold for C_FUNLOC, but not C_F_POINTER?!


-- 


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

[Bug rtl-optimization/38426] Incorrect code produced with -momit-leaf-frame-pointer -fno-unit-at-a-time

[d dot g dot gorbachev at gmail dot com]

--- Comment #3 from d dot g dot gorbachev at gmail dot com  2008-12-09 
20:31 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00583.html


-- 

d dot g dot gorbachev at gmail dot com changed:

   What|Removed |Added

  Component|middle-end  |rtl-optimization


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

[Bug c/38460] New: fails to build unwinder

[aldot at gcc dot gnu dot org]

compiling gcc/unwind* with IMA fails to produce correct assembly with trunk:

/there/src/buildroot.git.pentium4/i686_build/staging/usr/bin/i686-linux-uclibc-gcc
 -Os -pipe -fno-builtin -O2  -Os -pipe -fno-builtin   -DIN_GCC   -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual
-Wold-style-definition  -isystem ./include  -fPIC -g -DHAVE_GTHR_DEFAULT
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   -I. -I. -I../.././gcc
-I/there/src/buildroot.git.pentium4/i686_toolchain/gcc-4.4.0/libgcc
-I/there/src/buildroot.git.pentium4/i686_toolchain/gcc-4.4.0/libgcc/.
-I/there/src/buildroot.git.pentium4/i686_toolchain/gcc-4.4.0/libgcc/../gcc
-I/there/src/buildroot.git.pentium4/i686_toolchain/gcc-4.4.0/libgcc/../include 
-DHAVE_CC_TLS -DUSE_TLS -o libgcc_eh_onestep.o -MT libgcc_eh_onestep.o -MD -MP
-MF libgcc_eh_onestep.dep -fexceptions
/there/src/buildroot.git.pentium4/i686_toolchain/gcc-4.4.0/libgcc/../gcc/emutls.c
/there/src/buildroot.git.pentium4/i686_toolchain/gcc-4.4.0/libgcc/../gcc/gthr-gnat.c
/there/src/buildroot.git.pentium4/i686_toolchain/gcc-4.4.0/libgcc/../gcc/unwind-c.c
/there/src/buildroot.git.pentium4/i686_toolchain/gcc-4.4.0/libgcc/../gcc/unwind-dw2-fde-glibc.c
/there/src/buildroot.git.pentium4/i686_toolchain/gcc-4.4.0/libgcc/../gcc/unwind-dw2.c
/there/src/buildroot.git.pentium4/i686_toolchain/gcc-4.4.0/libgcc/../gcc/unwind-sjlj.c
-fvisibility=hidden -DHIDE_EXPORTS -c -combine
In file included from
/there/src/buildroot.git.pentium4/i686_toolchain/gcc-4.4.0/libgcc/../gcc/unwind-dw2-fde-glibc.c:62:
/there/src/buildroot.git.pentium4/i686_toolchain/gcc-4.4.0/libgcc/../gcc/unwind-dw2-fde.c:
In function ‘fde_unencoded_compare’:
/there/src/buildroot.git.pentium4/i686_toolchain/gcc-4.4.0/libgcc/../gcc/unwind-dw2-fde.c:326:
warning: dereferencing type-punned pointer will break strict-aliasing rules
/there/src/buildroot.git.pentium4/i686_toolchain/gcc-4.4.0/libgcc/../gcc/unwind-dw2-fde.c:327:
warning: dereferencing type-punned pointer will break strict-aliasing rules
/there/src/buildroot.git.pentium4/i686_toolchain/gcc-4.4.0/libgcc/../gcc/unwind-dw2-fde.c:
In function ‘add_fdes’:
/there/src/buildroot.git.pentium4/i686_toolchain/gcc-4.4.0/libgcc/../gcc/unwind-dw2-fde.c:682:
warning: dereferencing type-punned pointer will break strict-aliasing rules
/there/src/buildroot.git.pentium4/i686_toolchain/gcc-4.4.0/libgcc/../gcc/unwind-dw2-fde.c:
In function ‘linear_search_fdes’:
/there/src/buildroot.git.pentium4/i686_toolchain/gcc-4.4.0/libgcc/../gcc/unwind-dw2-fde.c:800:
warning: dereferencing type-punned pointer will break strict-aliasing rules
/there/src/buildroot.git.pentium4/i686_toolchain/gcc-4.4.0/libgcc/../gcc/unwind-dw2-fde.c:
In function ‘binary_search_unencoded_fdes’:
/there/src/buildroot.git.pentium4/i686_toolchain/gcc-4.4.0/libgcc/../gcc/unwind-dw2-fde.c:848:
warning: dereferencing type-punned pointer will break strict-aliasing rules
{standard input}: Assembler messages:
{standard input}:4640: Error: symbol `read_encoded_value' is already defined
make[3]: *** [libgcc_eh_onestep.o] Error 1


-- 
   Summary: fails to build unwinder
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: assemble-failure
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aldot at gcc dot gnu dot org


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

[Bug tree-optimization/37416] [4.4 Regression] Failure to return number of loop iterations

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2008-12-09 20:37 ---
Indeed, tuplification bug.  The following makes the testcase vectorizable
again.
gcc 4.3 had:
Symbolic number of iterations is (short unsigned int) y_3(D) + 65534
and so does trunk with this patch:
--- gcc/tree-scalar-evolution.c.jj  2008-11-10 10:28:26.0 +0100
+++ gcc/tree-scalar-evolution.c 2008-12-09 21:17:10.0 +0100
@@ -1229,6 +1229,18 @@ follow_ssa_edge_in_rhs (struct loop *loo
 case GIMPLE_SINGLE_RHS:
   return follow_ssa_edge_expr (loop, stmt, gimple_assign_rhs1 (stmt),
   halting_phi, evolution_of_loop, limit);
+case GIMPLE_UNARY_RHS:
+  if (code == NOP_EXPR)
+   {
+ /* This assignment is under the form "a_1 = (cast) rhs.  */
+ t_bool res
+   = follow_ssa_edge_expr (loop, stmt, gimple_assign_rhs1 (stmt),
+   halting_phi, evolution_of_loop, limit);
+ *evolution_of_loop = chrec_convert (type, *evolution_of_loop, stmt);
+ return res;
+   }
+  /* FALLTHRU */
+
 default:
   return t_false;
 }


-- 

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
   Last reconfirmed|2008-11-22 15:47:53 |2008-12-09 20:37:03
   date||


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

[Bug c/38460] fails to build unwinder

[aldot at gcc dot gnu dot org]

--- Comment #1 from aldot at gcc dot gnu dot org  2008-12-09 20:37 ---
Created an attachment (id=16856)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16856&action=view)
unreduced file1


-- 


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

[Bug c/38460] fails to build unwinder

[aldot at gcc dot gnu dot org]

--- Comment #2 from aldot at gcc dot gnu dot org  2008-12-09 20:37 ---
Created an attachment (id=16857)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16857&action=view)
unreduced file2


-- 


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

[Bug c/38460] fails to build unwinder

[aldot at gcc dot gnu dot org]

--- Comment #3 from aldot at gcc dot gnu dot org  2008-12-09 20:38 ---
Created an attachment (id=16858)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16858&action=view)
unreduced file3


-- 


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

[Bug c/38460] fails to build unwinder

[aldot at gcc dot gnu dot org]

--- Comment #4 from aldot at gcc dot gnu dot org  2008-12-09 20:38 ---
Created an attachment (id=16859)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16859&action=view)
output of unreduced input

/there/src/buildroot.git.pentium4/i686_build/staging/usr/bin/i686-linux-uclibc-gcc
-Os emutls.i unwind-c.i unwind-dw2.i -S -o libgcc_eh-unreduced.S -combine


-- 


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

[Bug c/38460] fails to build unwinder

[aldot at gcc dot gnu dot org]

--- Comment #5 from aldot at gcc dot gnu dot org  2008-12-09 20:39 ---
Created an attachment (id=16860)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16860&action=view)
reduced file1


-- 


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

[Bug c/38460] fails to build unwinder

[aldot at gcc dot gnu dot org]

--- Comment #6 from aldot at gcc dot gnu dot org  2008-12-09 20:39 ---
Created an attachment (id=16861)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16861&action=view)
reduced file3


-- 


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

[Bug c/38460] fails to build unwinder

[aldot at gcc dot gnu dot org]

--- Comment #7 from aldot at gcc dot gnu dot org  2008-12-09 20:40 ---
Created an attachment (id=16862)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16862&action=view)
reduced file3


-- 


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

[Bug c/38460] fails to build unwinder

[aldot at gcc dot gnu dot org]

--- Comment #8 from aldot at gcc dot gnu dot org  2008-12-09 20:41 ---
Created an attachment (id=16863)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16863&action=view)
output of reduced input

/there/src/buildroot.git.pentium4/i686_build/staging/usr/bin/i686-linux-uclibc-gcc
-Os emutls.0.i unwind-c.0.i unwind-dw2.0.i -c -o libgcc_eh.o -combine -w
/tmp/ccBHYNVJ.s: Assembler messages:
/tmp/ccBHYNVJ.s:29: Error: symbol `read_encoded_value' is already defined


-- 


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

[Bug middle-end/38459] [graphite] SEGFAULT in cloog_clast_create

[jv244 at cam dot ac dot uk]

--- Comment #2 from jv244 at cam dot ac dot uk  2008-12-09 20:43 ---
(In reply to comment #0)

similar stack trace for the segfault in harris_force_types.F:

0  0x2b3cbe554066 in realloc () from /lib64/libc.so.6
#1  0x2b3cbd66098c in __gmp_default_reallocate () from
/usr/lib64/libgmp.so.3
#2  0x2b3cbd675a21 in __gmpz_realloc () from /usr/lib64/libgmp.so.3
#3  0x2b3cbd676554 in __gmpz_set () from /usr/lib64/libgmp.so.3
#4  0x2b3cbd8a4dfc in insert_loop (loop=0x128e0a0, level=2, scalar=0,
next=0x7fffed66c930, infos=0x12a0910)
at source/ppl/clast.c:1446
#5  0x2b3cbd8a5367 in insert_loop (loop=0x128dfa0, level=1, scalar=0,
next=0x7fffed66c930, infos=0x12a0910)
at source/ppl/clast.c:1480
#6  0x2b3cbd8a5a41 in cloog_clast_create (program=0x128a590, options=) at source/ppl/clast.c:1518
#7  0x00ae667d in find_transform (scop=0x1204710) at
/scratch/vondele/gcc/graphite/gcc/graphite.c:4238
#8  0x00aede4b in graphite_transform_loops () at
/scratch/vondele/gcc/graphite/gcc/graphite.c:5382
#9  0x007df337 in graphite_transforms () at
/scratch/vondele/gcc/graphite/gcc/tree-ssa-loop.c:298
#10 0x0066cb55 in execute_one_pass (pass=0x10827e0) at
/scratch/vondele/gcc/graphite/gcc/passes.c:1279
#11 0x0066cd41 in execute_pass_list (pass=0x10827e0) at
/scratch/vondele/gcc/graphite/gcc/passes.c:1328
#12 0x0066cd55 in execute_pass_list (pass=0x1082540) at
/scratch/vondele/gcc/graphite/gcc/passes.c:1329
#13 0x0066cd55 in execute_pass_list (pass=0x1081a00) at
/scratch/vondele/gcc/graphite/gcc/passes.c:1329
#14 0x0075dafc in tree_rest_of_compilation (fndecl=0x2b3cbefb3800) at
/scratch/vondele/gcc/graphite/gcc/tree-optimize.c:418
#15 0x008d7ac0 in cgraph_expand_function (node=0x2b3cbf058300) at
/scratch/vondele/gcc/graphite/gcc/cgraphunit.c:1038
#16 0x008d967d in cgraph_optimize () at
/scratch/vondele/gcc/graphite/gcc/cgraphunit.c:1097
#17 0x00485ffa in gfc_be_parse_file (set_yydebug=)
at /scratch/vondele/gcc/graphite/gcc/fortran/f95-lang.c:240
#18 0x0070e55d in toplev_main (argc=, argv=0x0) at
/scratch/vondele/gcc/graphite/gcc/toplev.c:968
#19 0x2b3cbe4ffb54 in __libc_start_main () from /lib64/libc.so.6


-- 


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

[Bug middle-end/38459] [graphite] SEGFAULT in cloog_clast_create

[jv244 at cam dot ac dot uk]

--- Comment #3 from jv244 at cam dot ac dot uk  2008-12-09 20:46 ---
(In reply to comment #0)

similar for fft_tools.F


0x2ad42b5a4507 in __gmpz_set () from /usr/lib64/libgmp.so.3
(gdb) bt
#0  0x2ad42b5a4507 in __gmpz_set () from /usr/lib64/libgmp.so.3
#1  0x2ad42b7d2dfc in insert_loop (loop=0x16d8650, level=4, scalar=0,
next=0x7fff7f73e888, infos=0x12a40b0)
at source/ppl/clast.c:1446
#2  0x2ad42b7d3367 in insert_loop (loop=0x16d8870, level=3, scalar=0,
next=0x7fff7f73e888, infos=0x12a40b0)
at source/ppl/clast.c:1480
#3  0x2ad42b7d3367 in insert_loop (loop=0x16bece0, level=2, scalar=0,
next=0x7fff7f73e888, infos=0x12a40b0)
at source/ppl/clast.c:1480
#4  0x2ad42b7d33fd in insert_loop (loop=0x127e720, level=2, scalar=0,
next=0x7fff7f73ea00, infos=0x12a40b0)
at source/ppl/clast.c:1489
#5  0x2ad42b7d3367 in insert_loop (loop=0x12a4cc0, level=1, scalar=0,
next=0x7fff7f73ea00, infos=0x12a40b0)
at source/ppl/clast.c:1480
#6  0x2ad42b7d3a41 in cloog_clast_create (program=0x1285140, options=) at source/ppl/clast.c:1518
#7  0x00ae667d in find_transform (scop=0x16bee50) at
/scratch/vondele/gcc/graphite/gcc/graphite.c:4238
#8  0x00aede4b in graphite_transform_loops () at
/scratch/vondele/gcc/graphite/gcc/graphite.c:5382
#9  0x007df337 in graphite_transforms () at
/scratch/vondele/gcc/graphite/gcc/tree-ssa-loop.c:298
#10 0x0066cb55 in execute_one_pass (pass=0x10827e0) at
/scratch/vondele/gcc/graphite/gcc/passes.c:1279
#11 0x0066cd41 in execute_pass_list (pass=0x10827e0) at
/scratch/vondele/gcc/graphite/gcc/passes.c:1328
#12 0x0066cd55 in execute_pass_list (pass=0x1082540) at
/scratch/vondele/gcc/graphite/gcc/passes.c:1329
#13 0x0066cd55 in execute_pass_list (pass=0x1081a00) at
/scratch/vondele/gcc/graphite/gcc/passes.c:1329
#14 0x0075dafc in tree_rest_of_compilation (fndecl=0x2ad42cf03400) at
/scratc


-- 


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

[Bug c/38387] [4.4 Regression] psim miscompiled

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|psim miscompiled|[4.4 Regression] psim
   |[regression]|miscompiled
   Target Milestone|--- |4.4.0


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

[Bug fortran/38220] C_LOC intrinsic non-pure and without explicit interface

[dfranke at gcc dot gnu dot org]

--- Comment #2 from dfranke at gcc dot gnu dot org  2008-12-09 20:49 ---
symbol.c (generate_isocbinding_symbol):

4139  /* Here, we're taking the simple approach.  We're defining
4140 c_loc as an external identifier so the compiler will put
4141 what we expect on the stack for the address we want the
4142 C address of.  */

4170  tmp_sym->attr.external = 1;
4171  tmp_sym->attr.if_source = IFSRC_UNKNOWN;



-- 


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

[Bug middle-end/38461] New: [graphite] internal compiler error: verify_ssa failed

[jv244 at cam dot ac dot uk]

lebedev.F fails with:

scratch/vondele/clean/cp2k/src/../src/lebedev.F: In function ‘load_sub_grid’:
/scratch/vondele/clean/cp2k/src/../src/lebedev.F:156: error: definition in
block 18 does not dominate use in block 16
for SSA_NAME: PARM_NOALIAS.233_1989 in statement:
# VUSE 
pretmp.462_1908 = *lgnum_39(D);
/scratch/vondele/clean/cp2k/src/../src/lebedev.F:156: internal compiler error:
verify_ssa failed

which traces to

#0  internal_error (gmsgid=0xc4eeb3 "verify_ssa failed") at
/scratch/vondele/gcc/graphite/gcc/diagnostic.c:652
#1  0x00821ede in verify_ssa (check_modified_stmt=0 '\0') at
/scratch/vondele/gcc/graphite/gcc/tree-ssa.c:894
#2  0x00aeb66e in gloog (scop=0x1352340, stmt=0x13bb9f0) at
/scratch/vondele/gcc/graphite/gcc/graphite.c:1844
#3  0x00aede56 in graphite_transform_loops () at
/scratch/vondele/gcc/graphite/gcc/graphite.c:5382
#4  0x007df337 in graphite_transforms () at
/scratch/vondele/gcc/graphite/gcc/tree-ssa-loop.c:298
#5  0x0066cb55 in execute_one_pass (pass=0x10827e0) at
/scratch/vondele/gcc/graphite/gcc/passes.c:1279
#6  0x0066cd41 in execute_pass_list (pass=0x10827e0) at
/scratch/vondele/gcc/graphite/gcc/passes.c:1328
#7  0x0066cd55 in execute_pass_list (pass=0x1082540) at
/scratch/vondele/gcc/graphite/gcc/passes.c:1329
#8  0x0066cd55 in execute_pass_list (pass=0x1081a00) at
/scratch/vondele/gcc/graphite/gcc/passes.c:1329
#9  0x0075dafc in tree_rest_of_compilation (fndecl=0x2b928a0ef400) at
/scratch/vondele/gcc/graphite/gcc/tree-optimize.c:418
#10 0x008d7ac0 in cgraph_expand_function (node=0x2b928a19da00) at
/scratch/vondele/gcc/graphite/gcc/cgraphunit.c:1038
#11 0x008d967d in cgraph_optimize () at
/scratch/vondele/gcc/graphite/gcc/cgraphunit.c:1097
#12 0x00485ffa in gfc_be_parse_file (set_yydebug=http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38461

[Bug tree-optimization/38458] copy-propagation doesn't handle cycles

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-12-09 20:45 ---
Thanks.  Mine then.


-- 

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
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-12-09 20:45:20
   date||


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

[Bug libmudflap/38462] New: test libmudflap.c/fail27-frag.c fails output pattern test for ppc64

[janis at gcc dot gnu dot org]

Test libmudflap.c/fail27-frag.c has failed an output pattern test on
powerpc64-linux with -m64 since before GCC 4.0 was released.  I don't know
enough about mudflap to know if this is an actual bug for that target or if the
test is written incorrectly.

Output for powerpc64-linux with -m32, and for i686-linux, is something like:

***
1   mudflap violation 1 (check/write): time=1228849502.371858 ptr=0xffaf5e91
size=1
pc=0xfefeaa0 location=`fail27-frag.c:17:1 (main)'  
  /home/janis/tools/gcc-trunk-patches/lib/libmudflap.so.0
  (__mf_check+0x50) [0xfefeaa0]
  ./a.out(main+0xc0) [0x1944]
  /home/janis/tools/gcc-trunk-patches/lib/libmudflap.so.0
  (__wrap_main+0x1f8) [0xfefe2d8]
2   Nearby object 1: checked region begins 771B before and ends 771B before
3   mudflap object 0x100911e8: name=`argv[]'
bounds=[0xffaf6194,0xffaf619b] size=8 area=static check=0r/0w liveness=0
alloc time=1228849502.371747 pc=0xfefe0b0
Nearby object 2: checked region begins 779B before and ends 779B before
mudflap object 0x10092d88: name=`environ[]'
bounds=[0xffaf619c,0xffaf62a7] size=268 area=static check=0r/0w liveness=0
alloc time=1228849502.371826 pc=0xfefe0b0
Nearby object 3: checked region begins 5B into and ends 5B into
3   mudflap dead object 0x10092fb0: name=`fail27-frag.c:9:17 (foo) buffer'
bounds=[0xffaf5e8c,0xffaf5e95] size=10 area=stack check=0r/0w liveness=0
3   alloc time=1228849502.371836 pc=0xfefe0b0
3   dealloc time=1228849502.371845 pc=0xfefdb88
number of nearby objects: 3

The numbers at the left are mine to show what is matched by

1   /* { dg-output "mudflap violation 1.*" } */
2   /* { dg-output "Nearby object.*" } */
3   /* { dg-output "mudflap object.*buffer.*alloc.*dealloc" } */

Output for powerpc64-linux with -m64 is:

***
mudflap violation 1 (check/write): time=1228849632.611370 ptr=0xf8109dd
size=1
pc=0x40493dc location=`fail27-frag.c:17:1 (main)'
 
/home/janis/tools/gcc-trunk-patches/lib64/libmudflap.so.0(__mf_check-0x2367c)
[0x40493dc]
  ./lmf64(main-0x10744) [0x1b9c]
 
/home/janis/tools/gcc-trunk-patches/lib64/libmudflap.so.0(__wrap_main-0x23df8)
[0x4048c30]
Nearby object 1: checked region begins 5B into and ends 5B into
mudflap dead object 0x10015a60: name=`fail27-frag.c:9:17 (foo) buffer'
bounds=[0xf8109d8,0xf8109e1] size=10 area=stack check=0r/0w liveness=0
alloc time=1228849632.611335 pc=0x40489dc
dealloc time=1228849632.611347 pc=0x40484a4
number of nearby objects: 1 

Here there is only one nearby object; argv[] and environ[] are missing.  The
third output pattern fails because there is no earlier "mudflap object".  In
both cases the line with "buffer" starts with "mudflap dead object", not
"mudflap object".

Should the objects argv and environ be reported in the -m64 output, or is the
test right in just looking for any non-dead mudflap object, and then "buffer"
sometime later?  Would it be correct for the test to instead look for "mudflap
dead object" before "buffer"?


-- 
   Summary: test libmudflap.c/fail27-frag.c fails output pattern
test for ppc64
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libmudflap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis at gcc dot gnu dot org
GCC target triplet: powerpc64-unknown-linux-gnu


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

[Bug middle-end/38461] [graphite] internal compiler error: verify_ssa failed

[jv244 at cam dot ac dot uk]

--- Comment #1 from jv244 at cam dot ac dot uk  2008-12-09 21:01 ---
Created an attachment (id=16864)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16864&action=view)
testcase

reduced


-- 


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

[Bug middle-end/38431] [graphite] several ICEs with CP2K (summery)

[jv244 at cam dot ac dot uk]

--- Comment #5 from jv244 at cam dot ac dot uk  2008-12-09 21:02 ---
lebedev.F on PR38461


-- 


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

[Bug middle-end/38459] [graphite] SEGFAULT in cloog_clast_create

[jv244 at cam dot ac dot uk]

--- Comment #4 from jv244 at cam dot ac dot uk  2008-12-09 21:04 ---
similar for gamma.F 

#0  0x2b69b539a066 in realloc () from /lib64/libc.so.6
#1  0x2b69b44a698c in __gmp_default_reallocate () from
/usr/lib64/libgmp.so.3
#2  0x2b69b44bba21 in __gmpz_realloc () from /usr/lib64/libgmp.so.3
#3  0x2b69b44bc554 in __gmpz_set () from /usr/lib64/libgmp.so.3
#4  0x2b69b46eadfc in insert_loop (loop=0x12050d0, level=2, scalar=0,
next=0x76824af0, infos=0x11e4bc0)
at source/ppl/clast.c:1446
#5  0x2b69b46eb367 in insert_loop (loop=0x1204ff0, level=1, scalar=0,
next=0x76824af0, infos=0x11e4bc0)
at source/ppl/clast.c:1480
#6  0x2b69b46eba41 in cloog_clast_create (program=0x11c5e80, options=) at source/ppl/clast.c:1518
#7  0x00ae667d in find_transform (scop=0x11fc320) at
/scratch/vondele/gcc/graphite/gcc/graphite.c:4238
#8  0x00aede4b in graphite_transform_loops () at
/scratch/vondele/gcc/graphite/gcc/graphite.c:5382
#9  0x007df337 in graphite_transforms () at
/scratch/vondele/gcc/graphite/gcc/tree-ssa-loop.c:298
#10 0x0066cb55 in execute_one_pass (pass=0x10827e0) at
/scratch/vondele/gcc/graphite/gcc/passes.c:1279
#11 0x0066cd41 in execute_pass_list (pass=0x10827e0) at
/scratch/vondele/gcc/graphite/gcc/passes.c:1328
#12 0x0066cd55 in execute_pass_list (pass=0x1082540) at
/scratch/vondele/gcc/graphite/gcc/passes.c:1329
#13 0x0066cd55 in execute_pass_list (pass=0x1081a00) at
/scratch/vondele/gcc/graphite/gcc/passes.c:1329
#14 0x0075dafc in tree_rest_of_compilation (fndecl=0x2b69b5dee800) at
/scratch/vondele/gcc/graphite/gcc/tree-optimize.c:418
#15 0x008d7ac0 in cgraph_expand_function (node=0x2b69b5e0fe00) at
/scratch/vondele/gcc/graphite/gcc/cgraphunit.c:1038
#16 0x008d967d in cgraph_optimize () a


-- 


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

[Bug middle-end/38463] New: [graphite] double free or corruption

[jv244 at cam dot ac dot uk]

on ps_wavelet_util.F we have

*** glibc detected ***
/scratch/vondele/gcc/build/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/f951:
double free or corruption (out): 0x0120b9e0 ***
=== Backtrace: =
/lib64/libc.so.6[0x2aeedf6dd21d]
/lib64/libc.so.6(cfree+0x76)[0x2aeedf6def76]
/scratch/vondele/gcc/build/lib/libcloog.so.0[0x2aeedea30501]
/scratch/vondele/gcc/build/lib/libcloog.so.0[0x2aeedea309ca]
/scratch/vondele/gcc/build/lib/libcloog.so.0[0x2aeedea31fe2]
/scratch/vondele/gcc/build/lib/libcloog.so.0(cloog_clast_create+0xd1)[0x2aeedea32a41]
/scratch/vondele/gcc/build/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/f951[0xae667d]
/scratch/vondele/gcc/build/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/f951[0xaede4b]
/scratch/vondele/gcc/build/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/f951[0x7df337]
/scratch/vondele/gcc/build/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/f951[0x66cb55]
/scratch/vondele/gcc/build/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/f951[0x66cd41]
/scratch/vondele/gcc/build/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/f951[0x66cd55]
/scratch/vondele/gcc/build/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/f951[0x66cd55]
/scratch/vondele/gcc/build/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/f951[0x75dafc]
/scratch/vondele/gcc/build/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/f951[0x8d7ac0]
/scratch/vondele/gcc/build/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/f951[0x8d967d]
/scratch/vondele/gcc/build/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/f951[0x485ffa]
/scratch/vondele/gcc/build/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/f951[0x70e55d]
/lib64/libc.so.6(__libc_start_main+0xf4)[0x2aeedf68cb54]
/scratch/vondele/gcc/build/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/f951[0x4054d9]
=== Memory map: 
0040-00dfa000 r-xp  08:09 1163693   
/scratch/vondele/gcc/build/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/f951
00ff9000-00ffa000 r--p 009f9000 08:09 1163693   
/scratch/vondele/gcc/build/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/f951
00ffa000-01086000 rw-p 009fa000 08:09 1163693   
/scratch/vondele/gcc/build/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/f951
01086000-012dd000 rw-p 01086000 00:00 0  [heap]
2aeede5c8000-2aeede5e4000 r-xp  08:05 1921376   
/lib64/ld-2.6.1.so
2aeede5e4000-2aeede5e5000 rw-p 2aeede5e4000 00:00 0
2aeede60e000-2aeede60f000 rw-p 2aeede60e000 00:00 0
2aeede60f000-2aeede64e000 r--p  08:05 1789813   
/usr/lib/locale/en_US.utf8/LC_CTYPE
2aeede64e000-2aeede655000 r--s  08:05 1789997   
/usr/lib64/gconv/gconv-modules.cache
2aeede655000-2aeede656000 r--p  08:05 1789788   
/usr/lib/locale/en_US.utf8/LC_MESSAGES/SYS_LC_MESSAGES
2aeede656000-2aeede7b3000 rw-p 2aeede656000 00:00 0
2aeede7e3000-2aeede7e5000 rw-p 0001b000 08:05 1921376   
/lib64/ld-2.6.1.so
2aeede7e5000-2aeede824000 r-xp  08:05 176   
/usr/lib64/libgmp.so.3.4.1
2aeede824000-2aeedea23000 ---p 0003f000 08:05 176   
/usr/lib64/libgmp.so.3.4.1
2aeedea23000-2aeedea25000 rw-p 0003e000 08:05 176   
/usr/lib64/libgmp.so.3.4.1
2aeedea25000-2aeedea44000 r-xp  08:09 491570
/scratch/vondele/gcc/build/lib/libcloog.so.0.0.0
2aeedea44000-2aeedec43000 ---p 0001f000 08:09 491570
/scratch/vondele/gcc/build/lib/libcloog.so.0.0.0
2aeedec43000-2aeedec44000 r--p 0001e000 08:09 491570
/scratch/vondele/gcc/build/lib/libcloog.so.0.0.0
2aeedec44000-2aeedec45000 rw-p 0001f000 08:09 491570
/scratch/vondele/gcc/build/lib/libcloog.so.0.0.0
2aeedec45000-2aeedec47000 rw-p 2aeedec45000 00:00 0
2aeedec47000-2aeedefa2000 r-xp  08:09 491565
/scratch/vondele/gcc/build/lib/libppl_c.so.2.0.0
2aeedefa2000-2aeedf1a2000 ---p 0035b000 08:09 491565
/scratch/vondele/gcc/build/lib/libppl_c.so.2.0.0
2aeedf1a2000-2aeedf1a3000 r--p 0035b000 08:09 491565
/scratch/vondele/gcc/build/lib/libppl_c.so.2.0.0
2aeedf1a3000-2aeedf1a7000 rw-p 0035c000 08:09 491565
/scratch/vondele/gcc/build/lib/libppl_c.so.2.0.0
2ae
Program received signal SIGABRT, Aborted.
0x2aeedf69fb45 in raise () from /lib64/libc.so.6
(gdb) bt
#0  0x2aeedf69fb45 in raise () from /lib64/libc.so.6
#1  0x2aeedf6a10e0 in abort () from /lib64/libc.so.6
#2  0x2aeedf6d7fbb in ?? () from /lib64/libc.so.6
#3  0x2aeedf6dd21d in ?? () from /lib64/libc.so.6
#4  0x2aeedf6def76 in free () from /lib64/libc.so.6
#5  0x2aeedea30501 in clast_bound_from_constraint (matrix=0x1283850,
line_num=, level=1, names=0x127e6e0)
at source/ppl/clast.c:688
#6  0x2aeedea309ca in clast_minmax (matrix=0x1283850, level=4, max=1,
guard=0, infos=0x1245fe0) at source/ppl/clast.c:831
#7  0x2aeedea31fe2 in insert_loop (loop=0x1283c00, l

[Bug middle-end/38431] [graphite] several ICEs with CP2K (summery)

[jv244 at cam dot ac dot uk]

--- Comment #6 from jv244 at cam dot ac dot uk  2008-12-09 21:11 ---
ps_wavelet_util.F is now PR38463 


-- 


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

[Bug middle-end/38463] [graphite] double free or corruption

[jv244 at cam dot ac dot uk]

--- Comment #1 from jv244 at cam dot ac dot uk  2008-12-09 21:12 ---
note that this trace also goes via cloog_clast_create so that might be a dup of
PR38459


-- 


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