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

[domob at gcc dot gnu dot org]

--- Comment #9 from domob at gcc dot gnu dot org  2009-12-27 09:31 ---
Subject: Bug 22552

Author: domob
Date: Sun Dec 27 09:30:57 2009
New Revision: 155479

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155479
Log:
2009-12-27  Francois-Xavier Coudert  
Daniel Kraft  

PR fortran/22552
* lang.opt (Wimplicit-procedure): New option.
* gfortran.h (struct gfc_option_t): New member
`warn_implicit_procedure'
* options.c (gfc_handle_option): Handle -Wimplicit-procedure.
* interface.c (gfc_procedure_use): Warn about procedure never
explicitly declared if requested by the new flag.
* invoke.texi: Document new flag -Wimplicit-procedure.

2009-12-27  Francois-Xavier Coudert  
Daniel Kraft  

PR fortran/22552
* gfortran.dg/warn_implicit_procedure_1.f90: New test.

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


-- 


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 #10 from domob at gcc dot gnu dot org  2009-12-27 09:33 ---
Implemented on trunk with (basically) the patch attached.


-- 

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

[Bug fortran/39171] Misleading warning for negative character length

[domob at gcc dot gnu dot org]

--- Comment #3 from domob at gcc dot gnu dot org  2009-12-27 09:34 ---
Will work on this, as Tobias suggested the warning could depend on -Wsurprising


-- 

domob at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |domob at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-02-19 05:56:36 |2009-12-27 09:34:56
   date||


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

[Bug c++/42514] [4.3/4.4/4.5 Regression] Invalid Destructor Name of A Template Class Is Accepted

[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
   Keywords||accepts-invalid
  Known to fail||4.3.3 4.4.2 4.5.0
  Known to work||4.2.5
   Last reconfirmed|-00-00 00:00:00 |2009-12-27 10:09:12
   date||
Summary|Invalid Destructor Name of A|[4.3/4.4/4.5 Regression]
   |Template Class Is Accepted  |Invalid Destructor Name of A
   ||Template Class Is Accepted


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

[Bug target/42503] gcc-4.4-20091215 broke libjava on ARM

[ramana at gcc dot gnu dot org]

--- Comment #2 from ramana at gcc dot gnu dot org  2009-12-27 11:37 ---
The correct fix is potentially a version of the fix for PR40133 / PR40134 for
arm-linux-gnueabi. Looking at this.


-- 


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

[Bug fortran/42484] ICE with -fopenmp

[janus at gcc dot gnu dot org]

--- Comment #6 from janus at gcc dot gnu dot org  2009-12-27 11:38 ---
One more observation: The Fortran test case works, with return as well as goto,
giving the correct error message, if one removes the 'if' statement:

  subroutine sub
!$omp critical
return
!$omp end critical
  end subroutine

"error: invalid branch to/from an OpenMP structured block"


-- 


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

[Bug target/42503] gcc-4.4-20091215 broke libjava on ARM

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2009-12-27 11:59 
---
Yes, unless Matthias has a good explanation and fix for what's going on, those
changes should be immediately reverted, I will do that anyway in 3-4 days max.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||doko at gcc dot gnu dot org


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

[Bug c++/42515] New: internal compiler error: verify_stmts failed

[jarrod dot chesney at gmail dot com]

I get an ICE when compiling this file using this command (file to be attached.)
C:\>g++ -c  -Wreturn-type -fno-strict-aliasing -O2 -frtti -fexceptions
-mthreads  -o RenderMenuList.o RenderMenuList.ii
rendering/RenderMenuList.cpp: In member function
'WebCore::RenderMenuList::contr
olClipRect(int, int) const':
rendering/RenderMenuList.cpp:217:9: error: address taken, but ADDRESSABLE bit
no
t set

platform/graphics/IntRect.h:179:19: note: in statement
# .MEM_119 = VDEF <.MEM_117>
WebCore::IntRect::intersect (&, &innerBox);

rendering/RenderMenuList.cpp:217:9: internal compiler error: verify_stmts
failed

Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: internal compiler error: verify_stmts failed
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jarrod dot chesney at gmail dot com
 GCC build triplet: x86_64-w64-mingw32
  GCC host triplet: x86_64-w64-mingw32
GCC target triplet: x86_64-w64-mingw32


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

[Bug c++/42515] internal compiler error: verify_stmts failed

[jarrod dot chesney at gmail dot com]

--- Comment #1 from jarrod dot chesney at gmail dot com  2009-12-27 12:15 
---
Created an attachment (id=19396)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19396&action=view)
The preprocessed file that causes the problem


-- 


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

[Bug target/42503] gcc-4.4-20091215 broke libjava on ARM

[paolo dot carlini at oracle dot com]

--- Comment #4 from paolo dot carlini at oracle dot com  2009-12-27 12:18 
---
Note, however, that something is definitely wrong in the analysis: PR40133 and
PR40134 have been fixed **only in mainline**, thus per se those changes cannot
be involved in a breakage involving 4_4-branch. As far as libstdc++ is
concerned, in particular, in 4_4-branch we are not trying to do link-test
anywhere, we cannot make mistakes about static libgcc symbols. Still, I'm
seeing something puzzling and alarming here from the point of view of those
issues and I would recommend Matthias to also have a look.


-- 


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

[Bug c++/42515] internal compiler error: verify_stmts failed

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2009-12-27 12:29 
---


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


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE
Summary|internal compiler error:|internal compiler error:
   |verify_stmts failed |verify_stmts failed


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

[Bug c++/42507] internal compiler error: verify_stmts failed

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2009-12-27 12:29 
---
*** Bug 42515 has been marked as a duplicate of this bug. ***


-- 


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

[Bug c++/42507] internal compiler error: verify_stmts failed

[jarrod dot chesney at gmail dot com]

--- Comment #2 from jarrod dot chesney at gmail dot com  2009-12-27 12:33 
---
Created an attachment (id=19397)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19397&action=view)
The preprocessed file that causes the problem


-- 


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

[Bug fortran/42484] ICE with -fopenmp

[janus at gcc dot gnu dot org]

--- Comment #7 from janus at gcc dot gnu dot org  2009-12-27 12:53 ---
Interestingly, the test case also works when using an 'if ... then ... end if'
instead of a simple 'if':

  subroutine sub
integer :: nRead
!$omp critical
if (nRead<3) then
  goto 100
end if
!$omp end critical
100 nRead=4
  end subroutine


-- 


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

[Bug fortran/42484] ICE with -fopenmp

[janus at gcc dot gnu dot org]

--- Comment #8 from janus at gcc dot gnu dot org  2009-12-27 13:05 ---
The reason for the failure of comment #0 and #4 is that these cases run into
the following optimization in gimplify_cond_expr (gimplify.c):

  if (TREE_OPERAND (expr, 1) != NULL
  && TREE_CODE (TREE_OPERAND (expr, 1)) == GOTO_EXPR
  && TREE_CODE (GOTO_DESTINATION (TREE_OPERAND (expr, 1))) == LABEL_DECL
  && (DECL_CONTEXT (GOTO_DESTINATION (TREE_OPERAND (expr, 1)))
  == current_function_decl)
  /* For -O0 avoid this optimization if the COND_EXPR and GOTO_EXPR
 have different locations, otherwise we end up with incorrect
 location information on the branches.  */
  && (optimize
  || !EXPR_HAS_LOCATION (expr)
  || !EXPR_HAS_LOCATION (TREE_OPERAND (expr, 1))
  || EXPR_LOCATION (expr) == EXPR_LOCATION (TREE_OPERAND (expr, 1
{
  label_true = GOTO_DESTINATION (TREE_OPERAND (expr, 1));
  have_then_clause_p = true;
}

Note that one only runs into this, if the locations of the IF condition and the
THEN clause are the same, which is the case for the simple IF in Fortran, but
not for IF...THEN...END IF statements. In C, the locations always seem to be
different, also for the simple one-lined case.

So, I guess the solution is to apply different locations to the simple IF
statement in Fortran.


-- 


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

[Bug c/448] -related issues (C99 issues)

[laurent at guerby dot net]

--- Comment #27 from laurent at guerby dot net  2009-12-27 13:37 ---
Hi,

Is the following page up to date?

http://gcc.gnu.org/c99status.html


-- 

laurent at guerby dot net changed:

   What|Removed |Added

 CC||laurent at guerby dot net


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

[Bug target/42503] gcc-4.4-20091215 broke libjava on ARM

[mikpe at it dot uu dot se]

--- Comment #5 from mikpe at it dot uu dot se  2009-12-27 13:59 ---
(In reply to comment #4)
> Note, however, that something is definitely wrong in the analysis: PR40133 and
> PR40134 have been fixed **only in mainline**, thus per se those changes cannot
> be involved in a breakage involving 4_4-branch.

I believe it's the *absence* of the PR40134 fix on 4_4-branch that's causing
the backport of __sync_synchronize() support to regress. I'm currently testing
4.4-20091215 with relevant bits of PR40134 backported (r151568 + r152975): that
cured the build failure, but the testsuite run is not yet finished.


-- 


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

[Bug target/42503] gcc-4.4-20091215 broke libjava on ARM

[paolo dot carlini at oracle dot com]

--- Comment #6 from paolo dot carlini at oracle dot com  2009-12-27 14:41 
---
Thus you mean only 40134 is involved. Because 40133 *assumes* that on the
relevant linux targets there are no surprises with shared vs static libgcc. 

In general, I want to make sure nothing changes in the compiler-proper that
breaks the assumptions of 40133, which then would have to be reverted. For now
mainline seems still ok, I think Matthias tests regularly those targets.


-- 


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

[Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop

[ebotcazou at gcc dot gnu dot org]

--- Comment #4 from ebotcazou at gcc dot gnu dot org  2009-12-27 14:43 
---
> It may be caused by revision 147716:
> 
> http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00693.html

Same trigger as the other so the same partial reversion works:

Index: tree-scalar-evolution.c
===
--- tree-scalar-evolution.c (revision 155361)
+++ tree-scalar-evolution.c (working copy)
@@ -1159,7 +1159,7 @@ follow_ssa_edge_expr (struct loop *loop,

   switch (code)
 {
-CASE_CONVERT:
+case NOP_EXPR:
   /* This assignment is under the form "a_1 = (cast) rhs.  */
   res = follow_ssa_edge_expr (loop, at_stmt, TREE_OPERAND (expr, 0),
  halting_phi, evolution_of_loop, limit);
@@ -1222,7 +1222,7 @@ follow_ssa_edge_in_rhs (struct loop *loo

   switch (code)
 {
-CASE_CONVERT:
+case NOP_EXPR:
   /* This assignment is under the form "a_1 = (cast) rhs.  */
   res = follow_ssa_edge_expr (loop, stmt, gimple_assign_rhs1 (stmt),
  halting_phi, evolution_of_loop, limit);


-- 


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

[Bug fortran/42484] ICE with -fopenmp

[janus at gcc dot gnu dot org]

--- Comment #9 from janus at gcc dot gnu dot org  2009-12-27 15:57 ---
Here is a patch which fixes the ICE, and gives the correct error messages:


Index: gcc/fortran/trans.c
===
--- gcc/fortran/trans.c (revision 155304)
+++ gcc/fortran/trans.c (working copy)
@@ -1043,7 +1043,9 @@ void
 gfc_set_backend_locus (locus * loc)
 {
   gfc_current_backend_file = loc->lb->file;
-  input_location = loc->lb->location;
+  /* 'loc->lb->location' only gives the location of the start of the line,
+ so we add the column number here.  */
+  input_location = loc->lb->location + loc->nextc - loc->lb->line;
 }


Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c (revision 155304)
+++ gcc/fortran/match.c (working copy)
@@ -1602,7 +1602,7 @@ got_match:
   p = gfc_get_code ();
   p->next = gfc_get_code ();
   *p->next = new_st;
-  p->next->loc = gfc_current_locus;
+  p->next->loc = old_loc2;

   p->expr1 = expr;
   p->op = EXEC_IF;


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |janus at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-12-27 15:57:18
   date||


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

[Bug target/42516] New: [m68k] Suboptimal halfword swap on coldfire

[nizze86 at hotmail dot com]

When compiling the following function for a coldfire target, such as mcf5249:
(using the following command line m68k-elf-gcc hswap.c -mcpu=5249 -S -O2)
unsigned hswap(unsigned x)
{
return (x << 16) | (x >> 16);
}

gcc produces:

hswap:
link.w %fp,#0
move.l 8(%fp),%d1
move.l %d1,%d0
clr.w %d0
swap %d0
swap %d1
clr.w %d1
or.l %d1,%d0
unlk %fp
rts

Optimization level affects only instr ordering.

the same function compiled for 68020
(using the following command line m68k-elf-gcc hswap.c -mcpu=68020 -S -O2)

hswap:
link.w %fp,#0
move.l 8(%fp),%d0
swap %d0
unlk %fp
rts

which is valid code for the coldfire target too and much smaller and faster

this is using gcc 4.4.2 configured with 
--enable-languages=c --disable-libssp --with-arch=cf --with-cpu=5249

the same behaviour is present in gcc 3.4.6 too.


-- 
   Summary: [m68k] Suboptimal halfword swap on coldfire
   Product: gcc
   Version: 4.4.2
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nizze86 at hotmail dot com
  GCC host triplet: amd64-unknown-linux
GCC target triplet: m68k-elf


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

[Bug target/42516] [m68k] Suboptimal halfword swap on coldfire

[schwab at linux-m68k dot org]

--- Comment #1 from schwab at linux-m68k dot org  2009-12-27 17:19 ---
This is part of the rotlsi3 pattern which is disabled for coldfire since it
does not have rotate insns.


-- 

schwab at linux-m68k dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   GCC host triplet|amd64-unknown-linux |
 GCC target triplet|m68k-elf|m68k-*-*
   Last reconfirmed|-00-00 00:00:00 |2009-12-27 17:19:24
   date||


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

[Bug fortran/42517] New: Bogus runtime error with -fopemp -fcheck=recursion

[janus at gcc dot gnu dot org]

Consider this simple test case:

use omp_lib
implicit none
integer :: i

!$omp parallel do
do i=1,10
  call sub(i)
end do
!$omp end parallel do

contains

  subroutine sub (n)
integer :: n
print '(A,i3,A,i3)',"loop =",n," | thread =",omp_get_thread_num()
call sleep(1)
  end subroutine

end


Compiling this with -fopenmp gives the expected results. But when adding
-fcheck=recursion, one gets a runtime error:

Fortran runtime error: Recursive call to nonrecursive procedure 'sub'

-fcheck=recursion is new in 4.5, therefore I'm not sure if one can call this a
regression. In any case this bug makes -fcheck=all unusable for OpenMP code.


-- 
   Summary: Bogus runtime error with -fopemp -fcheck=recursion
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: wrong-code, openmp
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janus at gcc dot gnu dot org


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

[Bug c/448] -related issues (C99 issues)

[joseph at codesourcery dot com]

--- Comment #28 from joseph at codesourcery dot com  2009-12-27 18:33 
---
Subject: Re:  -related issues (C99 issues)

On Sun, 27 Dec 2009, laurent at guerby dot net wrote:

> Is the following page up to date?
> 
> http://gcc.gnu.org/c99status.html

The table appears to be up to date.  The note about bug 30789 should be 
removed and the note about math_errhandling updated to indicate that glibc 
now has such more limited math_errhandling implementation as can be done 
without compiler support (see glibc's CONFORMANCE file for details).


-- 


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

[Bug c/448] -related issues (C99 issues)

[joseph at codesourcery dot com]

--- Comment #29 from joseph at codesourcery dot com  2009-12-27 18:37 
---
Subject: Re:  -related issues (C99 issues)

Actually, the Broken marker for complex numbers support should now be 
Done, as per what I said in 
.


-- 


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

[Bug fortran/42517] Bogus runtime error with -fopenmp -fcheck=recursion

[janus at gcc dot gnu dot org]

--- Comment #1 from janus at gcc dot gnu dot org  2009-12-27 18:39 ---
An easy way to fix this is to simply disable the recursion check if -fopenmp is
given:

Index: gcc/fortran/trans-decl.c
===
--- gcc/fortran/trans-decl.c(revision 155479)
+++ gcc/fortran/trans-decl.c(working copy)
@@ -4318,7 +4318,8 @@ gfc_generate_function_code (gfc_namespace * ns)
is_recursive = sym->attr.recursive
  || (sym->attr.entry_master
  && sym->ns->entries->sym->attr.recursive);
-   if ((gfc_option.rtcheck & GFC_RTCHECK_RECURSION) && !is_recursive)
+   if ((gfc_option.rtcheck & GFC_RTCHECK_RECURSION) && !is_recursive
+   && !gfc_option.flag_openmp)
  {
char * msg;

@@ -4395,7 +4396,8 @@ gfc_generate_function_code (gfc_namespace * ns)
   gfc_add_expr_to_block (&block, tmp);

   /* Reset recursion-check variable.  */
-  if ((gfc_option.rtcheck & GFC_RTCHECK_RECURSION) && !is_recursive)
+  if ((gfc_option.rtcheck & GFC_RTCHECK_RECURSION) && !is_recursive
+ && !gfc_option.flag_openmp)
{
  gfc_add_modify (&block, recurcheckvar, boolean_false_node);
  recurcheckvar = NULL;
@@ -4426,7 +4428,8 @@ gfc_generate_function_code (gfc_namespace * ns)
 {
   gfc_add_expr_to_block (&block, tmp);
   /* Reset recursion-check variable.  */
-  if ((gfc_option.rtcheck & GFC_RTCHECK_RECURSION) && !is_recursive)
+  if ((gfc_option.rtcheck & GFC_RTCHECK_RECURSION) && !is_recursive
+ && !gfc_option.flag_openmp)
   {
gfc_add_modify (&block, recurcheckvar, boolean_false_node);
recurcheckvar = NULL;


-- 


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

[Bug middle-end/42178] [4.5 Regression] gcc.dg/graphite/interchange-8.c causes ICE

[hjl dot tools at gmail dot com]

--- Comment #14 from hjl dot tools at gmail dot com  2009-12-27 18:53 
---
On Linux/x86-64,  revision 155479 gave:

==25359== Invalid read of size 8
==25359==at 0xC714EE: lst_interchange_select_inner
(graphite-interchange.c:708)
==25359==by 0xC714DC: lst_interchange_select_inner
(graphite-interchange.c:684)
==25359==by 0xC72725: lst_interchange_select_outer
(graphite-interchange.c:732)
==25359==by 0xC7278D: lst_interchange_select_outer
(graphite-interchange.c:743)
==25359==by 0xC727CB: scop_do_interchange (graphite-interchange.c:754)
==25359==by 0xBE5A37: apply_poly_transforms (graphite-poly.c:260)
==25359==by 0xBDF68F: graphite_transform_loops (graphite.c:276)
==25359==by 0x883286: graphite_transforms (tree-ssa-loop.c:300)
==25359==by 0x70F54A: execute_one_pass (passes.c:1561)
==25359==by 0x70F7D4: execute_pass_list (passes.c:1616)
==25359==by 0x70F7E6: execute_pass_list (passes.c:1617)
==25359==by 0x70F7E6: execute_pass_list (passes.c:1617)
==25359==  Address 0xb78ac20 is not stack'd, malloc'd or (recently) free'd
==25359==
==25359== Invalid read of size 4
==25359==at 0xC713BF: lst_interchange_select_inner
(graphite-interchange.c:706)
==25359==by 0xC714DC: lst_interchange_select_inner
(graphite-interchange.c:684)
==25359==by 0xC72725: lst_interchange_select_outer
(graphite-interchange.c:732)
==25359==by 0xC7278D: lst_interchange_select_outer
(graphite-interchange.c:743)
==25359==by 0xC727CB: scop_do_interchange (graphite-interchange.c:754)
==25359==by 0xBE5A37: apply_poly_transforms (graphite-poly.c:260)
==25359==by 0xBDF68F: graphite_transform_loops (graphite.c:276)
==25359==by 0x883286: graphite_transforms (tree-ssa-loop.c:300)
==25359==by 0x70F54A: execute_one_pass (passes.c:1561)
==25359==by 0x70F7D4: execute_pass_list (passes.c:1616)
==25359==by 0x70F7E6: execute_pass_list (passes.c:1617)
==25359==by 0x70F7E6: execute_pass_list (passes.c:1617)
==25359==  Address 0x50 is not stack'd, malloc'd or (recently) free'd
==25359==
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gcc.dg/graphite/interchange-8.c:
In function âfooâ:
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gcc.dg/graphite/interchange-8.c:2:1:
internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
==25359==
==25359== HEAP SUMMARY:
==25359== in use at exit: 2,988,596 bytes in 63,676 blocks
==25359==   total heap usage: 33,696,767 allocs, 33,633,091 frees,
1,196,915,069 bytes allocated
==25359==
==25359== LEAK SUMMARY:
==25359==definitely lost: 24 bytes in 1 blocks
==25359==indirectly lost: 48 bytes in 1 blocks
==25359==  possibly lost: 23,256 bytes in 901 blocks
==25359==still reachable: 2,965,268 bytes in 62,773 blocks
==25359== suppressed: 0 bytes in 0 blocks
==25359== Rerun with --leak-check=full to see details of leaked memory
==25359==
==25359== For counts of detected and suppressed errors, rerun with: -v
==25359== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 6 from 6)


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

  GCC build triplet|x86_64-apple-darwin10   |
   GCC host triplet|x86_64-apple-darwin10   |
 GCC target triplet|x86_64-apple-darwin10   |
   Last reconfirmed|2009-12-14 19:20:10 |2009-12-27 18:53:51
   date||


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

[Bug middle-end/42510] [4.5 Regression] Invalid memory access in graphite

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2009-12-27 18:54 ---


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


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug middle-end/42178] [4.5 Regression] gcc.dg/graphite/interchange-8.c causes ICE

[hjl dot tools at gmail dot com]

--- Comment #15 from hjl dot tools at gmail dot com  2009-12-27 18:54 
---
*** Bug 42510 has been marked as a duplicate of this bug. ***


-- 


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

[Bug c++/42514] [4.3/4.4/4.5 Regression] Invalid Destructor Name of A Template Class Is Accepted

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2009-12-27 19:36 ---
It is caused by revision 143502:

http://gcc.gnu.org/ml/gcc-cvs/2009-01/msg00515.html

and revision 144314:

http://gcc.gnu.org/ml/gcc-cvs/2009-02/msg00481.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||jason at redhat dot com


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

[Bug target/42516] [m68k] Suboptimal halfword swap on coldfire

[mkuvyrkov at gcc dot gnu dot org]

--- Comment #2 from mkuvyrkov at gcc dot gnu dot org  2009-12-27 20:05 
---
Thanks for the bug report.  I've posted a proposed patch in
http://gcc.gnu.org/ml/gcc-patches/2009-12/msg01142.html.


-- 


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

[Bug middle-end/41344] [4.4/4.5 Regression] ICE / Bus error on OpenMP compile

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2009-12-27 20:58 ---
Gcc 4.3.4 gave

pr41344.f: In function âxrotateâ:
pr41344.f:10: error: invalid exit from OpenMP structured block


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

   Target Milestone|4.5.0   |4.4.3
Version|4.5.0   |4.4.2


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

[Bug middle-end/41889] [4.5 Regression] ICE from '-O2 -fno-omit-frame-pointer -ftracer -fsched2-use-superblocks'

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2009-12-27 21:32 ---
This is caused by revision 147995:

http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00974.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||rth at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-12-27 21:32:31
   date||


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

[Bug middle-end/41883] [4.5 Regression] ICE from '-O -fprofile-arcs -fsched2-use-superblocks -ftree-vrp -fschedule-insns2 -freorder-blocks'

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2009-12-27 21:34 ---
This is caused by revision 147995:

http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00974.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||rth at gcc dot gnu dot org


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

[Bug ada/42518] New: Alignment issue prevents building 64 bit RTS on Snow Leopard

[simon at pushface dot org]

While attempting to compile a-direct.adb the build fails with

/Users/simon/gcc-build/./gcc/xgcc -B/Users/simon/gcc-build/./gcc/
-B/opt/gcc-4.4.2-x86_64/x86_64-apple-darwin10.2.0/bin/
-B/opt/gcc-4.4.2-x86_64/x86_64-apple-darwin10.2.0/lib/ -isystem
/opt/gcc-4.4.2-x86_64/x86_64-apple-darwin10.2.0/include -isystem
/opt/gcc-4.4.2-x86_64/x86_64-apple-darwin10.2.0/sys-include -c -g -O2  -fPIC
-pipe -fno-common  -W -Wall -gnatpg   a-direct.adb -o
a-direct.o
a-direct.ads:424:09: alignment for "Search_Typeb82s" must be at least 8
a-direct.ads:424:09: alignment for "Search_Typer80s" must be at least 8
a-direct.ads:424:09: alignment for "Search_Typet77s" must be at least 8
make[6]: *** [a-direct.o] Error 1

I constructed a small test case

with Ada.Finalization;
package Bug_Investigation is
   type C is new Ada.Finalization.Controlled with null record;
end Bug_Investigation;

which failed in the same way:

$ /Users/simon/gcc-build/./gcc/xgcc -B/Users/simon/gcc-build/./gcc/
-B/opt/gcc-4.4.2-x86_64/x86_64-apple-darwin10.2.0/bin/
-B/opt/gcc-4.4.2-x86_64/x86_64-apple-darwin10.2.0/lib/ -isystem
/opt/gcc-4.4.2-x86_64/x86_64-apple-darwin10.2.0/include -isystem
/opt/gcc-4.4.2-x86_64/x86_64-apple-darwin10.2.0/sys-include -c -g -O2  -fPIC
-pipe -fno-common  -W -Wall -gnatpg bug_investigation.ads
-o bug_investigation.o
bug_investigation.ads:3:09: alignment for "Cb43s" must be at least 8
bug_investigation.ads:3:09: alignment for "Cr41s" must be at least 8
bug_investigation.ads:3:09: alignment for "Ct38s" must be at least 8

For info, Xcode 3.2.1.

$ /Users/simon/gcc-build/./gcc/xgcc -v
Using built-in specs.
Target: x86_64-apple-darwin10.2.0
Configured with: ../gcc-4.4.2/configure --prefix=/opt/gcc-4.4.2-x86_64
--with-gmp=/opt/gnu --with-mpfr=/opt/gnu --disable-multilib
--enable-languages=c,ada --build=x86_64-apple-darwin10.2.0
Thread model: posix
gcc version 4.4.2 (GCC)


-- 
   Summary: Alignment issue prevents building 64 bit RTS on Snow
Leopard
   Product: gcc
   Version: 4.4.2
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: simon at pushface dot org
 GCC build triplet: x86_64-apple-darwin10.2.0
  GCC host triplet: i386-apple-darwin10.2.0


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

[Bug tree-optimization/42231] [4.4 Regression] Wrong generated code when using a callback function (possible callback function inlining bug ?)

[jamborm at gcc dot gnu dot org]

--- Comment #8 from jamborm at gcc dot gnu dot org  2009-12-27 22:40 ---
Subject: Bug 42231

Author: jamborm
Date: Sun Dec 27 22:39:58 2009
New Revision: 155481

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155481
Log:
2009-12-27  Martin Jambor  

PR tree-optimization/42231
* ipa-cp.c (ipcp_update_cloned_node): Add missing edges manually
instead of relying on rebuild_cgraph_edges and mark them as
indirect calls.
(ipcp_update_callgraph): Always redirect indirect edges.

* testsuite/gcc.c-torture/execute/pr42231.c: New test.


Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr42231.c
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/ipa-cp.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/41344] [4.4/4.5 Regression] ICE / Bus error on OpenMP compile

[hjl dot tools at gmail dot com]

--- Comment #6 from hjl dot tools at gmail dot com  2009-12-27 23:57 ---
It is caused by tuples merge:

http://gcc.gnu.org/ml/gcc-cvs/2008-07/msg00919.html


-- 


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

[Bug target/42503] [4.4 Regression] gcc-4.4-20091215 broke libjava on ARM

[mikpe at it dot uu dot se]

--- Comment #7 from mikpe at it dot uu dot se  2009-12-28 00:46 ---
(In reply to comment #5)
> I believe it's the *absence* of the PR40134 fix on 4_4-branch that's causing
> the backport of __sync_synchronize() support to regress. I'm currently testing
> 4.4-20091215 with relevant bits of PR40134 backported (r151568 + r152975): 
> that
> cured the build failure, but the testsuite run is not yet finished.

The testsuite run now finished with no regressions compared to 4.4 snapshots
from before this regression.


-- 


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

[Bug middle-end/41344] [4.4/4.5 Regression] ICE / Bus error on OpenMP compile

[hjl dot tools at gmail dot com]

--- Comment #7 from hjl dot tools at gmail dot com  2009-12-28 01:09 ---
The omplower pass turns

---
  #pragma omp parallel private(ix) private(ndfl)
{
  ix = 0;
  {
integer(kind=4) D.1393;

D.1393 = dfm.ndfl;
#pragma omp for private(i)
for (i = 1; i <= D.1393; i = i + 1)
  {
ix = ix + 1;
if (ix > 5) goto __label_009000; else goto ;
:
L.1:
  }
  }
}
  __label_009000:
---

into:

---
{
#pragma omp parallel private(ix) private(ndfl) [child fn: xrotate_.omp_fn.0
(???)]
  {
ix = 0;
{
  integer(kind=4) D.1393;

  D.1393 = dfm.ndfl;
  {
integer(kind=4) D.1407;
integer(kind=4) i;

D.1407 = D.1393;
#pragma omp for private(i)
for (i = 1; i <= D.1407; i = i + 1)
ix = ix + 1;
if (ix > 5) goto ; else goto ;
:
:
#pragma omp continue (i, i)
#pragma omp return
  }
}
#pragma omp return
  }
  }
  __label_009000:
---

D.1404 isn't defined anywhere. Also I didn't see diagnose_sb_2 handle
GIMPLE_COND stmt with GIMPLE_GOTO stmt.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||jakub at redhat dot com


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

[Bug tree-optimization/42231] [4.4 Regression] Wrong generated code when using a callback function (possible callback function inlining bug ?)

[jamborm at gcc dot gnu dot org]

--- Comment #9 from jamborm at gcc dot gnu dot org  2009-12-28 01:41 ---
Subject: Bug 42231

Author: jamborm
Date: Mon Dec 28 01:41:07 2009
New Revision: 155485

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155485
Log:
2009-12-27  Martin Jambor  

PR tree-optimization/42231
* testsuite/gcc.c-torture/execute/pr42231.c: New test.


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


-- 


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

[Bug tree-optimization/42231] [4.4 Regression] Wrong generated code when using a callback function (possible callback function inlining bug ?)

[jamborm at gcc dot gnu dot org]

--- Comment #10 from jamborm at gcc dot gnu dot org  2009-12-28 01:45 
---
Fixed.


-- 

jamborm at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug c++/35421] ICE on Valid Code

[mckelvey at maskull dot com]

--- Comment #9 from mckelvey at maskull dot com  2009-12-28 02:07 ---
(In reply to comment #8)
> Feedback not forthcoming.
> 

Will try again as soon as I can build latest SVN.


-- 


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

[Bug middle-end/41344] [4.4/4.5 Regression] ICE / Bus error on OpenMP compile

[hjl dot tools at gmail dot com]

--- Comment #8 from hjl dot tools at gmail dot com  2009-12-28 02:19 ---
Created an attachment (id=19398)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19398&action=view)
A patch

Does this patch make any senses?


-- 


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