[Bug fortran/31608] wrong types in character array/scalar binop

[burnus at gcc dot gnu dot org]

--- Comment #40 from burnus at gcc dot gnu dot org  2007-10-25 06:36 ---
(In reply to comment #37)
> Test is failing on hppa-unknown-linux-gnu:
> PASS: gfortran.dg/char_cast_1.f90  -O  (test for excess errors)
> FAIL: gfortran.dg/char_cast_1.f90  -O  scan-tree-dump-times \[S.5\]\[1\] 2

While on x86_64-gnu-linux the dump has:
  int8 S.5;
the variable on hppa-unknown-linux-gnu is:
  int4 S___5;

Thus the following check fails:

! The sign that all is well is that [S.5][1] appears twice.
! { dg-final { scan-tree-dump-times "\\\[S\.5\\\]\\\[1\\\]" 2 "original" } }

The tree (dump) itself seems to be ok.


-- 


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

[Bug fortran/33888] ICE - CHARACTER expression using an ELEMENTAL FUNCTION as actual arg

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2007-10-25 06:30 ---
Valgrind:

==28333== Invalid read of size 8
==28333==at 0x73B006: get_frame_type (tree-nested.c:198)
==28333==by 0x73B387: get_chain_decl (tree-nested.c:304)
==28333==by 0x73C55C: get_nonlocal_debug_decl (tree-nested.c:851)
==28333==by 0x7401EA: convert_nonlocal_reference (tree-nested.c:922)
==28333==by 0x872C1C: walk_tree_1 (tree.c:8369)

where in gcc/tree-nested.c:
get_frame_type (struct nesting_info *info)
{
  tree type = info->frame_type; // <--- line 198


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu dot
   ||org
OtherBugsDependingO||32834
  nThis||
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  GCC build triplet|i686-pc-cygwin  |
   GCC host triplet|i686-pc-cygwin  |
 GCC target triplet|i686-pc-cygwin  |
   Keywords||ice-on-valid-code
  Known to fail||4.1.2 4.2.2 4.3.0
   Last reconfirmed|-00-00 00:00:00 |2007-10-25 06:30:06
   date||


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

[Bug c++/33887] Reference to bitfield gets wrong value when optimizing

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2007-10-25 05:21 ---
  int f2 = sv.f2;

That should sign extend as far as I know.


-- 


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

[Bug c++/33887] Reference to bitfield gets wrong value when optimizing

[ian at airs dot com]

--- Comment #2 from ian at airs dot com  2007-10-25 05:07 ---
Nothing is taking the address of a bitfield.  It's a const reference, which
should get initialized with the value.  If the reference is not const, then the
compiler gives an error.

In any case, this code fails the same way, and clearly does not take the
address of a bitfield.

extern "C" void abort() __attribute__ ((noreturn));

template
void fn(const t1, const t2) __attribute__ ((noinline));

template
void fn(const t1 v1, const t2 v2)
{
  if (v1 != v2)
abort();
}

struct s
{
  unsigned long long f1 : 40;
  unsigned int f2 : 24;
};

s sv;

int main()
{
  sv.f1 = 0;
  sv.f2 = (1 << 24) - 1;
  int f2 = sv.f2;
  fn(f2, (1 << 24) - 1);
  ++sv.f2;
  f2 = sv.f2;
  fn(f2, 0);
  return 0;
}


-- 


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

[Bug libgcj/33891] New: unresponsive to mouse and keyboard input

[debian-gcc at lists dot debian dot org]

[forwarded from http://bugs.debian.org/445930]

this is regression against the classpath generices backport for 4.1/4.2 as used
by some distributions, found in 4.3, fixed in the classpath-0.96.1 merge.

import javax.swing.*;
import java.awt.*;

public class Exo1 extends JFrame{
public Exo1 (){
setLayout (new FlowLayout ());
JButton b1 = new JButton ("OK");
JButton b2 = new JButton ("Cancel");
getContentPane().add (b1);
getContentPane().add (b2);

JCheckBox c = new JCheckBox ("A cocher");
getContentPane().add (c);

setDefaultCloseOperation (EXIT_ON_CLOSE);
setSize (350, 350);
setVisible (true);
}
public static void main (String args[]){
new Exo1 ();
}
}


-- 
   Summary: unresponsive to mouse and keyboard input
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org


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

[Bug c++/33890] internal compiler error: in tsubst_copy

[schnetter at aei dot mpg dot de]

--- Comment #1 from schnetter at aei dot mpg dot de  2007-10-25 04:31 
---
Created an attachment (id=14411)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14411&action=view)
Failing preprocessed source code


-- 


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

[Bug c++/33890] New: internal compiler error: in tsubst_copy

[schnetter at aei dot mpg dot de]

I receive an internal compiler error for a certain C++ source file when
enabling OpenMP.  I compile with

$ /usr/local/packages/numrel/gcc-129614/bin/g++-129614 -c reduce.ii -fopenmp

and receive the error message

/home/eschnett/Calpha/arrangements/Carpet/CarpetReduce/src/reduce.cc: In
function ‘void CarpetReduce::reduce(const int*, const int*, const int*, const
std::vector >&, const
std::vector >&, void*, void*, const CCTK_REAL8*,
CCTK_REAL8) [with T = int, OP = CarpetReduce::count::op]’:
/home/eschnett/Calpha/arrangements/Carpet/Carpet/src/typecase:126:  
instantiated from here
/home/eschnett/Calpha/arrangements/Carpet/CarpetReduce/src/reduce.cc:512:
internal compiler error: in tsubst_copy, at cp/pt.c:9828

I am using the following version of g++:

$ /usr/local/packages/numrel/gcc-129614/bin/g++-129614 -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /home/eschnett/src/gcc/configure
--prefix=/usr/local/packages/numrel/gcc-129614 --disable-multilib
--with-gmp=/usr/local/packages/numrel/gmp-4.2.1
--with-mpfr=/usr/local/packages/numrel/mpfr-2.2.1
--enable-languages=c,c++,fortran,java,objc,treelang --program-suffix=-129614
Thread model: posix
gcc version 4.3.0 20071024 (experimental) (GCC) 

I append the preprocessed source code.


-- 
   Summary: internal compiler error: in tsubst_copy
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schnetter at aei dot mpg dot de
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug ada/33889] New: Inefficient code expansion for extended return statement

[vgodunko at rostel dot ru]

For this simple code

package P is
   type T is limited interface;
   function F return not null access T'Class;
end P;

package body P is
   function X return not null access T'Class;
   pragma Import (C, X);
   function F return not null access T'Class is
   begin
  return Result : not null access T'Class := X do
 null;
  end return;
   end F;
end P;

GNAT generate to many RTL calls:

$ gcc -O2 -S -gnatdg p.adb

   function p__f return not null access p__t'class is

  procedure p__f___clean is
  begin
 system__soft_links__abort_defer.all;
 system__soft_links__complete_master.all;
 system__soft_links__abort_undefer.all;
 return;
  end p__f___clean;
   begin
  system__soft_links__enter_master.all;
  R3b : declare
 _master : constant integer := 
   system__soft_links__current_master.all;
 T4bM : integer renames _master;
 [subtype p__T1s is access not null p__TtC]
 result : not null not null access p__t'class := p__T1s!(
   $ada__tags__displace (system__address!(x), p__tP));
  begin
null;
 return p__T1s!($ada__tags__displace (system__address!(result), 
   p__tP));
  end R3b;
   at end
  p__f___clean;
   end p__f;

Computation of accessibility level don't needed in this case.


-- 
   Summary: Inefficient code expansion for extended return statement
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vgodunko at rostel dot ru
  GCC host triplet: x86-pc-linux-gnu


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

[Bug fortran/31608] wrong types in character array/scalar binop

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #38 from dave at hiauly1 dot hia dot nrc dot ca  2007-10-25 
02:39 ---
Subject: Re:  wrong types in character array/scalar binop

Tree dump attached.

Dave


--- Comment #39 from dave at hiauly1 dot hia dot nrc dot ca  2007-10-25 
02:39 ---
Created an attachment (id=14410)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14410&action=view)


-- 


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

[Bug fortran/31608] wrong types in character array/scalar binop

[danglin at gcc dot gnu dot org]

--- Comment #37 from danglin at gcc dot gnu dot org  2007-10-25 02:31 
---
Test is failing on hppa-unknown-linux-gnu:

Executing on host:
/home/dave/gnu/gcc-4.3/objdir/gcc/testsuite/gfortran/../../gf
ortran -B/home/dave/gnu/gcc-4.3/objdir/gcc/testsuite/gfortran/../../
/home/dave/
gnu/gcc-4.3/gcc/gcc/testsuite/gfortran.dg/char_cast_1.f90   -O  -O2
-fdump-tree-
original -S  -o char_cast_1.s(timeout = 300)
PASS: gfortran.dg/char_cast_1.f90  -O  (test for excess errors)
FAIL: gfortran.dg/char_cast_1.f90  -O  scan-tree-dump-times \[S.5\]\[1\] 2
Executing on host:
/home/dave/gnu/gcc-4.3/objdir/gcc/testsuite/gfortran/../../gf


-- 


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

[Bug fortran/33888] New: ICE - CHARACTER expression using an ELEMENTAL FUNCTION as actual arg

[w6ws at earthlink dot net]

The following causes an ICE:

$ cat ftn95bug.f90
program ftn95bug
  implicit none

  character(8) :: indata(4) = (/  &
'12344321', '98766789', 'abcdefgh', 'ABCDEFGH'  &
  /)

  call process (myfunc (indata))  ! <- This causes a gfortran ICE !

contains

  elemental function myfunc (s)
character(*), intent(in) :: s
character(len (s)) :: myfunc

myfunc = s

  end function

  subroutine process (strings)
character(*), intent(in) :: strings(:)

print *, strings

  end subroutine

end program

[EMAIL PROTECTED] /cygdrive/d/usr/wws/fortran/utils
$ gfortran --version
GNU Fortran (GCC) 4.3.0 20071005 (experimental) [trunk revision 127783]
Copyright (C) 2007 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING


[EMAIL PROTECTED] /cygdrive/d/usr/wws/fortran/utils
$ gfortran ftn95bug.f90
ftn95bug.f90:8: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[EMAIL PROTECTED] /cygdrive/d/usr/wws/fortran/utils
$


-- 
   Summary: ICE - CHARACTER expression using an ELEMENTAL FUNCTION
as actual arg
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: w6ws at earthlink dot net
 GCC build triplet: i686-pc-cygwin
  GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin


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

[Bug c++/33887] Reference to bitfield gets wrong value when optimizing

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-10-24 23:51 ---
As far as I know this code is invlaid as you should not able take the address
of the bitfield.


-- 


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

[Bug c++/33887] New: Reference to bitfield gets wrong value when optimizing

[ian at airs dot com]

This C++ test case passes a bitfield value to a function which expects a const
reference.  When optimizing, the function gets the wrong value: it gets the
value 0x100, which is an acceptable value for a 24-bit bitfield, but is the
wrong value for extending the bitfield out to a 32-bit integer.  This failure
happens on i686-pc-linux-gnu with -O2.  The test passes without optimization.

extern "C" void abort() __attribute__ ((noreturn));

template
void fn(const t1&, const t2&) __attribute__ ((noinline));

template
void fn(const t1& v1, const t2& v2)
{
  if (v1 != v2)
abort();
}

struct s
{
  unsigned long long f1 : 40;
  unsigned int f2 : 24;
};

s sv;

int main()
{
  sv.f1 = 0;
  sv.f2 = (1 << 24) - 1;
  fn(sv.f1, 0);
  fn(sv.f2, (1 << 24) - 1);
  ++sv.f2;
  fn(sv.f2, 0);
  return 0;
}


-- 
   Summary: Reference to bitfield gets wrong value when optimizing
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at airs dot com


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

[Bug rtl-optimization/33886] [4.3 regression] internal compiler error: canonical types differ for identical types

[bero at arklinux dot org]

--- Comment #1 from bero at arklinux dot org  2007-10-24 23:25 ---
Created an attachment (id=14409)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14409&action=view)
bzip2-ed preprocessed source


-- 


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

[Bug rtl-optimization/33886] New: [4.3 regression] internal compiler error: canonical types differ for identical types

[bero at arklinux dot org]

While compiling OpenOffice.org with gcc 4.3 at -O2 or higher (-O1 and -O0 are
ok):

/usr/src/ark/BUILD/ooo-build/build/oog680-m7/i18npool/source/nativenumber/nativenumbersupplier.cxx:85:
internal compiler error: canonical types differ for identical types sal_Unicode
[31] and sal_uInt16 [31]
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: [4.3 regression] internal compiler error: canonical
types differ for identical types
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bero at arklinux dot org
 GCC build triplet: i586-pc-linux-gnu
  GCC host triplet: i586-pc-linux-gnu
GCC target triplet: i586-pc-linux-gnu


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

[Bug tree-optimization/32921] [4.3 Regression] Revision 126326 causes 12% slowdown

[pthaugen at gcc dot gnu dot org]

--- Comment #35 from pthaugen at gcc dot gnu dot org  2007-10-24 23:15 
---
I reran leslie3d on PowerPC with --param max-aliased-vops=1. The result was
a 90% improvement over my prior revision 129550 run (218% improvement over the
original mainline run).


-- 


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

[Bug fortran/33883] gfortran compile / LD_LIBRARY_PATH error

[jvdelisle at gcc dot gnu dot org]

--- Comment #2 from jvdelisle at gcc dot gnu dot org  2007-10-24 23:15 
---
Also, you must enable c as well: This is biggest problem

--enable-languages=c,fortran


-- 


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

[Bug fortran/33883] gfortran compile / LD_LIBRARY_PATH error

[jvdelisle at gcc dot gnu dot org]

--- Comment #1 from jvdelisle at gcc dot gnu dot org  2007-10-24 22:57 
---
Try reversing the order here:

./configure --enable-languages=fortran --with-gmp=/home/local/gmp-4.2.2
--with-mpfr=/home/local/mpfr-2.3.0 

to:

./configure --enable-languages=fortran --with-mpfr=/home/local/mpfr-2.3.0
--with-gmp=/home/local/gmp-4.2.2


-- 


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

[Bug bootstrap/33879] bootstrapping revision 129600 fails

[olga at gcc dot gnu dot org]

-- 

olga at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||sam at rfc1149 dot net
 Status|ASSIGNED|WAITING


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

[Bug bootstrap/33879] bootstrapping revision 129600 fails

[olga at gcc dot gnu dot org]

--- Comment #5 from olga at gcc dot gnu dot org  2007-10-24 22:06 ---
Two patches were provided by Samuel Tardieu:

http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01427.html
http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01426.html

Slightly modified:
http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01435.html

and committed with ChangeLog:

2007-10-24  Samuel Tardieu  <[EMAIL PROTECTED]>
Olga Golovanevsky <[EMAIL PROTECTED]>

* ipa-struct-reorg.c (replace_field_acc): Make it clear to
the compiler that wr.wrap and wr.domain are initialized in
any case.

2007-10-24  Samuel Tardieu  <[EMAIL PROTECTED]>

* ipa-struct-reorg.c (sum_counts): Use HOST_WIDEST_PRINT_DEC
to print gcov_type values.


-- 


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

[Bug c++/33885] member reference to a temporary object being deleted too eary

[gzljg at hotmail dot com]

--- Comment #1 from gzljg at hotmail dot com  2007-10-24 20:15 ---
Created an attachment (id=14408)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14408&action=view)
a compilable C source

compile and run it to see the actual outcome.


-- 


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

[Bug c++/33885] New: member reference to a temporary object being deleted too eary

[gzljg at hotmail dot com]

class A{
// 
};

class B{
public:
  explicit B(const A& a)
: i_a(a)
  {
  }
  ~B()
  {
  }
private:
  const A& i_a;
};

A returnA( const char* arg )
{
   return A(/*arg*/);
}

foo()
{
   const A& aRef = returnA("FirstObject");  // . (1)
   {
 const B b(returnA("SecondObject"));// . (2)
 ///...
 typedef int outofscope_block;  // . (3)  
   }
   typedef char outofscope_function;// . (4)
}

temporary object created and referenced by aRef is being deleted when aRef goes
out of scope in foo, as Expected.
temporary object created and referenced by B::i_a is being deleted right after
object b's construction, Not expected.  It should(?) have the same life time as
the B::i_a(thus b), such as deleted _after_ line (3) --- If this assumpsion is
false, then what's the difference between a 'plain reference' and 'member
reference' herein??

BTW, it works as expected on SunCC compiler. It core dumps on gcc 3.3.3 while
having (empty/invalid) data for i_a on gcc 4.1.2 but not coring.


-- 
   Summary: member reference to a temporary object being deleted too
eary
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gzljg at hotmail dot com


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

[Bug debug/28834] [4.0/4.1/4.2/4.3 Regression] -g crashes sometimes when using may_alias and structs (ICE in splice_child_die)

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-02-05 13:51:52 |2007-10-24 19:59:54
   date||


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

[Bug c++/57] [DR 325] GCC can't parse a non-parenthesized comma in a template-id within a default argument

[jason at gcc dot gnu dot org]

--- Comment #35 from jason at gcc dot gnu dot org  2007-10-24 19:48 ---
Created an attachment (id=14407)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14407&action=view)
updated patch

Here's a cleaned up version of Liu Guanwei's patch that passes regression
testing with current 4.3 sources.  I've pinged him for a copyright assignment
so I can check it in.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

Attachment #8545 is|0   |1
   obsolete||
Attachment #8546 is|0   |1
   obsolete||


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

[Bug libfortran/33583] FAIL: gfortran.dg/gamma_1.f90

[tkoenig at gcc dot gnu dot org]

--- Comment #6 from tkoenig at gcc dot gnu dot org  2007-10-24 19:30 ---
I'll do this together with PR 33698.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||33698
 AssignedTo|unassigned at gcc dot gnu   |tkoenig at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-10-24 19:30:32
   date||


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

[Bug fortran/33884] New: data-initialized unused variables not detected

[tkoenig at gcc dot gnu dot org]

$ cat data.f 
  subroutine foo
  real a
  data a /1.3/
  end
$ gfortran -c -Wall -O3 data.f
$ g77 -c -Wall -O3 data.f
data.f: In subroutine `foo':
In file included from data.f:0:
data.f:2: warning: unused variable 'a'

I'd expect a warning, like g77.


-- 
   Summary: data-initialized unused variables not detected
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: enhancement
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
OtherBugsDependingO 33056
 nThis:


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

[Bug bootstrap/33879] bootstrapping revision 129600 fails

[olga at gcc dot gnu dot org]

-- 

olga at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug bootstrap/33879] bootstrapping revision 129600 fails

[ubizjak at gmail dot com]

-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 CC||ubizjak at gmail dot com
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-10-24 17:58:53
   date||


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

[Bug bootstrap/33879] bootstrapping revision 129600 fails

[ubizjak at gmail dot com]

--- Comment #4 from ubizjak at gmail dot com  2007-10-24 17:58 ---
I'm reopening this bug, because now we fail on x86_64:

cc1: warnings being treated as errors
../../gcc-svn/trunk/gcc/ipa-struct-reorg.c: In function ‘create_new_field_acc’:
../../gcc-svn/trunk/gcc/ipa-struct-reorg.c:960: error: ‘wr.wrap’ may be used
uninitialized in this function
../../gcc-svn/trunk/gcc/ipa-struct-reorg.c:960: note: ‘wr.wrap’ was declared
here
../../gcc-svn/trunk/gcc/ipa-struct-reorg.c:960: error: ‘wr.domain’ may be used
uninitialized in this function
../../gcc-svn/trunk/gcc/ipa-struct-reorg.c:960: note: ‘wr.domain’ was declared
here
gmake[3]: *** [ipa-struct-reorg.o] Error 1


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
  GCC build triplet|powerpc-apple-darwin8   |x86_64-pc-gnu-linux
   GCC host triplet|powerpc-apple-darwin8   |x86_64-pc-linux-gnu
 GCC target triplet|powerpc-apple-darwin8   |x86_64-pc-linux-gnu
 Resolution|FIXED   |


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

[Bug target/33755] Gcc 4.2.2 broken for mips linux kernel builds

[rsandifo at gcc dot gnu dot org]

--- Comment #17 from rsandifo at gcc dot gnu dot org  2007-10-24 17:55 
---
Patches applied to mainline and 4.2.


-- 

rsandifo at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug target/33755] Gcc 4.2.2 broken for mips linux kernel builds

[rsandifo at gcc dot gnu dot org]

--- Comment #16 from rsandifo at gcc dot gnu dot org  2007-10-24 17:54 
---
Subject: Bug 33755

Author: rsandifo
Date: Wed Oct 24 17:54:40 2007
New Revision: 129607

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129607
Log:
gcc/
PR target/33755
* config/mips/mips.c (override_options): Always move
flag_delayed_branch to mips_flag_delayed_branch.
(mips_lo_sum_offset): New structure.
(mips_hash_base, mips_lo_sum_offset_hash, mips_lo_sum_offset_eq)
(mips_lo_sum_offset_lookup, mips_record_lo_sum)
(mips_orphaned_high_part_p: New functions.
(mips_avoid_hazard): Don't check INSN_P here.
(mips_avoid_hazards): Rename to...
(mips_reorg_process_insns): ...this.  Cope with
!TARGET_EXPLICIT_RELOCS.  Delete orphaned high-part relocations,
or turn them into nops.
(mips_reorg): Remove TARGET_EXPLICIT_RELOCS check from calls to
dbr_schedule and mips_avoid_hazards/mips_reorg_process_insns.

gcc/testsuite/
PR target/33755
* gcc.target/mips/pr33755.c: New test.

Added:
branches/gcc-4_2-branch/gcc/testsuite/gcc.target/mips/pr33755.c
Modified:
branches/gcc-4_2-branch/gcc/ChangeLog
branches/gcc-4_2-branch/gcc/config/mips/mips.c
branches/gcc-4_2-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug target/33755] Gcc 4.2.2 broken for mips linux kernel builds

[rsandifo at gcc dot gnu dot org]

--- Comment #15 from rsandifo at gcc dot gnu dot org  2007-10-24 17:52 
---
Subject: Bug 33755

Author: rsandifo
Date: Wed Oct 24 17:52:16 2007
New Revision: 129606

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129606
Log:
gcc/
PR target/33755
* config/mips/mips.c (mips_lo_sum_offset): New structure.
(mips_hash_base, mips_lo_sum_offset_hash, mips_lo_sum_offset_eq)
(mips_lo_sum_offset_lookup, mips_record_lo_sum)
(mips_orphaned_high_part_p: New functions.
(mips_avoid_hazard): Don't check INSN_P here.
(mips_avoid_hazards): Rename to...
(mips_reorg_process_insns): ...this.  Cope with
!TARGET_EXPLICIT_RELOCS.  Delete orphaned high-part relocations,
or turn them into nops.
(mips_reorg): Remove TARGET_EXPLICIT_RELOCS check from calls to
dbr_schedule and mips_avoid_hazards/mips_reorg_process_insns.
(mips_set_mips16_mode): Don't set flag_delayed_branch here.
(mips_override_options): Set flag_delayed_branch to 0.

gcc/testsuite/
PR target/33755
* gcc.target/mips/pr33755.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/mips/pr33755.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/mips/mips.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug libmudflap/31845] Need to adjust libmudflap timeout values in testsuite.

[janis at gcc dot gnu dot org]

--- Comment #5 from janis at gcc dot gnu dot org  2007-10-24 17:23 ---
Rob, thanks for investigating this and finding new values.  No one seems to
have paid any attention here, so please send this as a patch to
[EMAIL PROTECTED] (let me know privately if you have questions about
that) and if there are no objections I'll check it in.


-- 

janis at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||janis at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-10-24 17:23:06
   date||


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

[Bug fortran/33883] New: gfortran compile / LD_LIBRARY_PATH error

[rogerabq at yahoo dot com]

This is the same error message reported in bug fortran/33058 on August 13th,
2007, however, the suggestion provided in that thread did not solve the problem
for me.  Just wondering if there is something else that might be the problem.

When I try to compile gcc-4.2.2 on Linux to create the gfortran compiler, it
fails:

./configure --enable-languages=fortran --with-gmp=/home/local/gmp-4.2.2
--with-mpfr=/home/local/mpfr-2.3.0 

And as suggested in the 8/13/07 thread, my LD_LIBRARY_PATH was set the the
following:

[atria ~]$ echo $LD_LIBRARY_PATH
/home/local/gmp-4.2.2/lib:/home/local/mpfr-2.3.0/lib

...
updating cache ./config.cache
configure: loading cache ./config.cache
checking for i686-pc-linux-gnu-gfortran...
/home/rogerb/gcc-4.2.2/host-i686-pc-linux-gnu/gcc/gfortran
-B/home/rogerb/gcc-4.2.2/host-i686-pc-linux-gnu/gcc/
-B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/
-isystem /usr/local/i686-pc-linux-gnu/include -isystem
/usr/local/i686-pc-linux-gnu/sys-include
checking whether we are using the GNU Fortran compiler... no
checking whether /home/rogerb/gcc-4.2.2/host-i686-pc-linux-gnu/gcc/gfortran
-B/home/rogerb/gcc-4.2.2/host-i686-pc-linux-gnu/gcc/
-B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/
-isystem /usr/local/i686-pc-linux-gnu/include -isystem
/usr/local/i686-pc-linux-gnu/sys-include accepts -g... no
checking whether the GNU Fortran compiler is working... no
configure: error: GNU Fortran is not working; the most common reason for that
is that you might have linked it to shared GMP and/or MPFR libraries, and not
set LD_LIBRARY_PATH accordingly. If you suspect any other reason, please report
a bug in http://gcc.gnu.org/bugzilla, attaching
/home/rogerb/gcc-4.2.2/i686-pc-linux-gnu/libgfortran/config.log
make[1]: *** [configure-target-libgfortran] Error 1
make[1]: Leaving directory `/home/rogerb/gcc-4.2.2'
make: *** [all] Error 2


-- 
   Summary: gfortran compile / LD_LIBRARY_PATH error
   Product: gcc
   Version: 4.2.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rogerabq at yahoo dot com


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

[Bug fortran/33881] allocate negative memory

[william dot mitchell at nist dot gov]

--- Comment #3 from william dot mitchell at nist dot gov  2007-10-24 15:48 
---
(In reply to comment #2)
Sorry I forgot to give the computer information.  This is a 32 bit CentOS 5
Linux distribution on an Intel Core 2 Duo T7700

[EMAIL PROTECTED]> gfortran -v
Using built-in specs.
Target: i386-pc-linux-gnu
Configured with: /home/fx/gfortran_nightbuild/trunk/configure
--prefix=/home/fx/gfortran_nightbuild/irun-20071023
--enable-languages=c,fortran --build=i386-pc-linux-gnu
--enable-checking=release --with-gmp=/home/fx/gfortran_nightbuild/software
Thread model: posix
gcc version 4.3.0 20071023 (experimental) [trunk revision 129569] (GCC)

[EMAIL PROTECTED]> uname -a
Linux speedy.cam.nist.gov 2.6.18-8.1.10.el5 #1 SMP Thu Sep 13 12:17:54 EDT 2007
i686 i686 i386 GNU/Linux


-- 


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

[Bug c++/57] [DR 325] GCC can't parse a non-parenthesized comma in a template-id within a default argument

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|SUSPENDED   |ASSIGNED
   Last reconfirmed|2006-03-27 05:40:24 |2007-10-24 15:46:18
   date||


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

[Bug tree-optimization/33680] [4.3 Regression] ICE when compilling elbg.c from ffmpeg (vectorizer)

[pinskia at gcc dot gnu dot org]

--- Comment #19 from pinskia at gcc dot gnu dot org  2007-10-24 15:37 
---
*** Bug 33882 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||gregoire dot favre at gmail
   ||dot com


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

[Bug c/33882] ICE when compiling ffmpeg svn

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-10-24 15:37 ---


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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug fortran/33881] allocate negative memory

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2007-10-24 15:33 ---
> Fortran runtime error: Attempt to allocate a negative amount of memory.

This error usually means that you allocate that much memory that an integer(4)
variable overflows. I cannot reproduce the error here with -m32 or -m64 on
x86_64/Linux (20071016 (experimental) [trunk revision 129378]).

(Using valgrind I get a lot of unintialized-variable warnings which are due to
the fact that create_watch_actual is only a stub.)

Which platform are you using (CPU + operating system; "gfortran -v" shows this
in the "Target:" line.)


-- 


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

[Bug tree-optimization/32921] [4.3 Regression] Revision 126326 causes 12% slowdown

[rguenth at gcc dot gnu dot org]

--- Comment #34 from rguenth at gcc dot gnu dot org  2007-10-24 15:19 
---
Created an attachment (id=14406)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14406&action=view)
partition heuristics change

The idea is to change the statistics to make the values in the fields
match their names and based on that avoid partitioning for variables
that are often directly accessed or indirectly accessed as mostly
reads or writes.  It probably makes sense to change the field names
and weight the individual accesses with their BB frequency again.

Of course the patch is not finished and is untested apart from throwing
it on the 2nd testcase.


-- 


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

[Bug tree-optimization/32921] [4.3 Regression] Revision 126326 causes 12% slowdown

[rguenth at gcc dot gnu dot org]

--- Comment #33 from rguenth at gcc dot gnu dot org  2007-10-24 15:18 
---
DOM does, so scheduling another dominator pass after PRE (where alias is
re-run)
fixes the problem.  One problem with partitioning is that we don't collect
statistics for symbols inside a partition, which makes all but the first
paritioning run prefer already partitioned symbols.


-- 


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

[Bug c/33882] New: ICE when compiling ffmpeg svn

[gregoire dot favre at gmail dot com]

http://ffmpeg.mplayerhq.hu/download.html and in libavcodec.
With gcc-4.3.0-alpha20071019:
gcc -I"/usr/src/CVS/ffmpeg-gcc43"/libavcodec  -DHAVE_AV_CONFIG_H
-I"/usr/src/CVS/ffmpeg-gcc43" -I"/usr/src/CVS/ffmpeg-gcc43"/libavutil -O3  -o
elbg.o elbg.c
elbg.c: In function ‘try_shift_candidate’:
elbg.c:245: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Changing to -O2 it compils fine, also going down to gcc-4.2.2 let it compil
with -O3.

Sorry if my report is not well done : first one in gcc...

gcc -v :
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.3.0_alpha20071019/work/gcc-4.3-20071019/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.0-alpha20071019
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.0-alpha20071019/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.0-alpha20071019
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.0-alpha20071019/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.0-alpha20071019/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.0-alpha20071019/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--enable-nls --without-included-gettext --with-system-zlib --disable-checking
--disable-werror --enable-secureplt --disable-libunwind-exceptions
--enable-multilib --enable-libmudflap --disable-libssp --disable-libgcj
--enable-languages=c,c++ --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 4.3.0-alpha20071019  (experimental) (GCC)


-- 
   Summary: ICE when compiling ffmpeg svn
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gregoire dot favre at gmail dot com


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

[Bug tree-optimization/32921] [4.3 Regression] Revision 126326 causes 12% slowdown

[rguenth at gcc dot gnu dot org]

--- Comment #32 from rguenth at gcc dot gnu dot org  2007-10-24 15:02 
---
I have a patch to "fix" the heuristics, but it doesn't have effect as nobody
hoists PHI nodes that have become invariant apperantly.  After PRE I see



:
  # HEAP.202_828 = PHI 

:
  # SMT.222_639 = PHI 
  # dtvol_656 = PHI 
  # MPT.242_668 = PHI 
  # l_1 = PHI <1(100), l_428(152)>
  # VUSE 
  D.1241_376 = du.data;
... (more VUSEs of MPT.242_668, the only VDEFs in the loop follow)
  # dtvol_655 = VDEF 
  # SMT.222_599 = VDEF 
  (*D.1242_377)[D.1259_397] = D.1277_426;
  l_428 = l_1 + 1;
  if (l_1 == 5)
goto ;
  else
goto ;

:
  goto ;

:

the

  # SMT.222_639 = PHI 

could be hoisted to BB100 (even to BB92).  Who is supposed to do this?


-- 


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

[Bug fortran/33881] allocate negative memory

[william dot mitchell at nist dot gov]

--- Comment #1 from william dot mitchell at nist dot gov  2007-10-24 14:10 
---
Created an attachment (id=14405)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14405&action=view)
this is the program


-- 


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

[Bug fortran/33881] New: allocate negative memory

[william dot mitchell at nist dot gov]

With this program I get a runtime error message
Fortran runtime error: Attempt to allocate a negative amount of memory.
The error occurs at line 33.  I suspect the "allocation" is the constant array
actual argument (/name/).
This program is a little longer than I like my bug reports to be, but any
attempt to shorten it changes the error to a segmentation fault, except for
removing the print statement in the main program which results in the program
running correctly.

[EMAIL PROTECTED]> gfortran --version
GNU Fortran (GCC) 4.3.0 20071023 (experimental) [trunk revision 129569]
Copyright (C) 2007 Free Software Foundation, Inc.

[EMAIL PROTECTED]> gfortran bug071024.f90
[EMAIL PROTECTED]> a.out
 something
Fortran runtime error: Attempt to allocate a negative amount of memory.


-- 
   Summary: allocate negative memory
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: william dot mitchell at nist dot gov


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

[Bug bootstrap/33879] bootstrapping revision 129600 fails

[ubizjak at gmail dot com]

--- Comment #3 from ubizjak at gmail dot com  2007-10-24 13:46 ---
Closed as fixed.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

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


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

[Bug middle-end/33880] ICE: in extract_omp_for_data, at omp-low.c:162

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2007-10-24 13:23 ---
/* PR middle-end/33880 */
/* { dg-do compile } */
/* { dg-options "-O2 -fopenmp" } */

int
foo (void)
{
  int i = 0;
  void bar (void) { i++; }
  bar ();
  #pragma omp parallel for
for (i = 0; i < 10; i++)
  ;
  i = 3;
  bar ();
  return i;
}

ICEs the same way.


-- 


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

[Bug bootstrap/33879] bootstrapping revision 129600 fails

[dominiq at lps dot ens dot fr]

--- Comment #2 from dominiq at lps dot ens dot fr  2007-10-24 13:20 ---
I am now at stage2 with revision 129601. So this PR seems fixed.

Thanks


-- 


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

[Bug tree-optimization/33875] Small performance improvement

[ubizjak at gmail dot com]

-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2007-
   ||10/msg01392.html
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-10-24 12:55:12
   date||
Version|unknown |4.3.0


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

[Bug debug/33868] [4.3 Regression] Gross memory usage of var-tracking

[matz at gcc dot gnu dot org]

--- Comment #5 from matz at gcc dot gnu dot org  2007-10-24 12:55 ---
Fixed.


-- 

matz at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug debug/33868] [4.3 Regression] Gross memory usage of var-tracking

[matz at gcc dot gnu dot org]

--- Comment #4 from matz at gcc dot gnu dot org  2007-10-24 12:54 ---
Subject: Bug 33868

Author: matz
Date: Wed Oct 24 12:54:24 2007
New Revision: 129602

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129602
Log:
PR debug/33868
* var-tracking.c (variable_union): Don't break after one loop
* iteration
but only when a difference is found.
(dump_variable): Also print DECL_UID.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/var-tracking.c


-- 


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

[Bug bootstrap/33879] bootstrapping revision 129600 fails

[andreasmeier80 at gmx dot de]

--- Comment #1 from andreasmeier80 at gmx dot de  2007-10-24 12:28 ---
The last commit of Olga was not complete. The two new files weren't commited


-- 

andreasmeier80 at gmx dot de changed:

   What|Removed |Added

 CC||olga at il dot ibm dot com


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

[Bug tree-optimization/32921] [4.3 Regression] Revision 126326 causes 12% slowdown

[rguenth at gcc dot gnu dot org]

--- Comment #31 from rguenth at gcc dot gnu dot org  2007-10-24 12:23 
---
This is a partitioning issue.  We allocate the same MPT to loads and stores
in a loop.  Fixed with for example --param max-aliased-vops=1.

Diego, this is yours.  Avoiding false aliasing of loads and stores should
be top priority in the partitioning heuristics.

Though even with no paritioning we are not able to move the invariant load
of dtvol:

.L68:
movsd   (%rsi), %xmm0
addl$1, %ecx
addq%rdi, %rsi
subsd   (%rdx), %xmm0
addq%rdi, %rdx 
mulsd   __les3d_data_MOD_dtvol(%rip), %xmm0
xorpd   %xmm1, %xmm0
movsd   %xmm0, (%rax)
addq%r8, %rax 
cmpl$6, %ecx
jne .L68

because:

  # VUSE 
  dtvol.23_424 = dtvol; 
  D.1276_425 = D.1274_423 * dtvol.23_424;
  D.1277_426 = -D.1276_425;
  # dtvol_1865 = VDEF 
  # HEAP.185_1160 = VDEF 
  # HEAP.186_1142 = VDEF 
  # HEAP.202_1108 = VDEF 
  (*pretmp.248_955)[D.1259_397] = D.1277_426;

as we think that pretmp.248_955 might point to dtvol.  The pointers just
have a constraint like

pretmp.246_921 = du

and

du = &ANYTHING
du.ubound = &ANYTHING
du.lbound = &ANYTHING
du.stride = &ANYTHING
du.ubound = &ANYTHING
du.lbound = &ANYTHING
du.stride = &ANYTHING
du.ubound = &ANYTHING
du.lbound = &ANYTHING
du.stride = &ANYTHING
du.ubound = &ANYTHING
du.lbound = &ANYTHING
du.stride = &ANYTHING
du.dtype = &ANYTHING
du.offset = &ANYTHING

and dtvol and DU are global variables.  So we are possibly out of luck
for this one.


-- 


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

[Bug middle-end/33880] New: ICE: in extract_omp_for_data, at omp-low.c:162

[burnus at gcc dot gnu dot org]

This is with both 4.2 and 4.3 on x86_64/Linux.

gfortran-4.3 -fopenmp a.f90
a.f90: In function 'MAIN__':
a.f90:3: internal compiler error: in extract_omp_for_data, at omp-low.c:162

Test case (by Xavier Andrade):
--
program testbug
  integer :: ii
  !$omp parallel do
  do ii = 1, 1000
  end do
contains
  subroutine something()
ii = 0
  end subroutine something
end program testbug
--


-- 
   Summary: ICE: in extract_omp_for_data, at omp-low.c:162
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, openmp
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug debug/31412] inf loop/long compile time, time spent in var-tracking.c

[zadeck at naturalbridge dot com]

--- Comment #16 from zadeck at naturalbridge dot com  2007-10-24 12:14 
---
Subject: Re:  inf loop/long compile time, time spent in var-tracking.c

rguenth at gcc dot gnu dot org wrote:
> --- Comment #15 from rguenth at gcc dot gnu dot org  2007-10-24 12:01 
> ---
> Btw, I can no longer reproduce the problem.  var-tracking is not fast, but
> even a cc1 compiled with checking and -O0 does not take multiple hours to
> compile this (but just a minute):
>
>  variable tracking :  11.34 (23%) usr   0.20 (12%) sys  11.54 (23%) wall  
> 46131 kB (25%) ggc
>  TOTAL :  48.36 1.6650.07
> 183405 kB
>
>
>   
I think that given the most likely cause of the problem, the problem is
just hiding.  My guess is that the problem is that there is an oddball
case where the dataflow equations do not converge and we will see this
again.  But it is clearly very rare.

kenny


-- 


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

[Bug debug/31412] inf loop/long compile time, time spent in var-tracking.c

[rguenth at gcc dot gnu dot org]

--- Comment #15 from rguenth at gcc dot gnu dot org  2007-10-24 12:01 
---
Btw, I can no longer reproduce the problem.  var-tracking is not fast, but
even a cc1 compiled with checking and -O0 does not take multiple hours to
compile this (but just a minute):

 variable tracking :  11.34 (23%) usr   0.20 (12%) sys  11.54 (23%) wall  
46131 kB (25%) ggc
 TOTAL :  48.36 1.6650.07
183405 kB


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |WAITING
Summary|[4.3] inf loop/long compile |inf loop/long compile time,
   |time, time spent in var-|time spent in var-tracking.c
   |tracking.c  |


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

[Bug tree-optimization/33870] [4.3 Regression] miscompiles sqlite

[rguenth at gcc dot gnu dot org]

--- Comment #13 from rguenth at gcc dot gnu dot org  2007-10-24 11:56 
---
And another one:

http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01398.html


unassigning - I neither feel responsible nor competent enough to fix this
design
issue.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug bootstrap/33879] New: bootstrapping revision 129600 fails

[dominiq at lps dot ens dot fr]

While trying to update to revision 129600, I got the following error:

gcc -c   -g -fkeep-inline-functions -DIN_GCC   -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-Wmissing-format-attribute -fno-common   -DHAVE_CONFIG_H -DGENERATOR_FILE -I.
-Ibuild -I../../gcc-4.3-work/gcc -I../../gcc-4.3-work/gcc/build
-I../../gcc-4.3-work/gcc/../include -I../../gcc-4.3-work/gcc/../libcpp/include
-I/sw/include  -I../../gcc-4.3-work/gcc/../libdecnumber
-I../../gcc-4.3-work/gcc/../libdecnumber/dpd -I../libdecnumber -I/sw/include  
-o build/gengtype-parse.o ../../gcc-4.3-work/gcc/gengtype-parse.c
gcc   -g -fkeep-inline-functions -DIN_GCC   -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-Wmissing-format-attribute -fno-common   -DHAVE_CONFIG_H -DGENERATOR_FILE  -o
build/gengtype \
build/gengtype.o build/gengtype-lex.o build/gengtype-parse.o
build/errors.o ../build-powerpc-apple-darwin8/libiberty/libiberty.a
make[3]: *** No rule to make target
`../../gcc-4.3-work/gcc/ipa-struct-reorg.c', needed by `s-gtype'.  Stop.

A fresh bootstrap failed the same way.


-- 
   Summary: bootstrapping revision 129600 fails
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
 GCC build triplet: powerpc-apple-darwin8
  GCC host triplet: powerpc-apple-darwin8
GCC target triplet: powerpc-apple-darwin8


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

[Bug fortran/33759] Unequal character lengths in MERGE intrinsic not detected at run time

[dominiq at lps dot ens dot fr]

--- Comment #5 from dominiq at lps dot ens dot fr  2007-10-24 11:36 ---
With the patch in comment #4, the code in #2 yields the same results as other
compilers without regression.


-- 


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

[Bug target/29524] [4.2/4.3 Regression] Too much RAM used: __clz_tab[] linked

[wvangulik at xs4all dot nl]

--- Comment #13 from wvangulik at xs4all dot nl  2007-10-24 11:16 ---
(In reply to comment #10)

Something like this is smaller, faster and works for all registers (no need for
LD_regs). And could easily be writtin in to a insn:

; rOut: output register
; rIn:  input register
; rIn, Z, N are clobbered, C is set
clzqi_init:
clr rOut   ; clear to zero
neg rOut   ; make -1, and set C (C used for garanteed termination)
clzqi_loop1:
inc rOut   ; inc output (C not touched)
rol rIn; push MSB into C
brcc clz_loop1 ; if C is cleared (msb was not set), continue loop
clzqi_end:

A clz on a hi/si/di would be almost the same. Extend the "rol rIn" to a rol per
sub_reg.
Of course there can be speed optimisation for hi/si/di, but for the AVR the
optimizer is in most cases set for size.
A library call to this is shorter but it may impose extra mov instruction to
fit the register constraints.


-- 


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

[Bug tree-optimization/33870] [4.3 Regression] miscompiles sqlite

[rguenth at gcc dot gnu dot org]

--- Comment #12 from rguenth at gcc dot gnu dot org  2007-10-24 10:13 
---
One working patch/workaround:

http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01377.html


-- 


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

[Bug fortran/33814] Failure of gfortran n Mac Mini

[fxcoudert at gcc dot gnu dot org]

--- Comment #3 from fxcoudert at gcc dot gnu dot org  2007-10-24 10:09 
---
Hi Peter,

The following:

>  f951 strauss.f90 -fPIC -quiet -dumpbase strauss.f90 -mmacosx-version-min=10.4
> -mtune=generic -auxbase strauss -version -ffixed-form -ffixed-line-length-132
> -fbounds-check -fmax-errors-0 -fintrinsic-modules-path finclude -o
> /var/tmp//ccZtzWga.s
> gfortran: error trying to exec 'f951': execvp: No such file or directory

shows that it's a packaging problem and not a problem with the compiler
codebase. Because you talk about "gfortran-intel-bin.tar", I suppose you use
the binaries from http://hpc.sourceforge.net/, so you should report the problem
to them. Meanwhile, there are 2 things you can do to get a working compiler:

  1. Add /usr/local/libexec/gcc/i686-apple-darwin8.8.1/4.3.0 to you PATH
environment variable. If packaging was correct, this shouldn't be needed, but
in the current situation this will get the compiler working. (NB: the last two
components of the path above may be slightly different; the bottom line is,
find what is the subdirectory of /usr/local/libexec that contains an executable
file named f951)

  2. You can alternatively try downloading the binaries provided by the
gfortran team (well, by me, in fact), at
http://gcc.gnu.org/wiki/GFortranBinaries  They come as an Apple installer
(which might be better or worse, depending on your point of view!) and should
work out of the box.

Since this is not a bug in GCC/gfortran, I'm closing this bug-report.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug fortran/33862] Support .FTN file extension for Fortran fixed-format source files

[fxcoudert at gcc dot gnu dot org]

--- Comment #1 from fxcoudert at gcc dot gnu dot org  2007-10-24 10:00 
---
(In reply to comment #0)
> +{".ftn", "@f77", 0, 0, 0},
> +{".FTN", "@f77", 0, 0, 0},

Question is: do both case variants actually exist, and does the uppercase one
requires preprocessing?


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-10-24 10:00:30
   date||


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

[Bug fortran/33686] FORALL loop gives wrong result

[pault at gcc dot gnu dot org]

--- Comment #12 from pault at gcc dot gnu dot org  2007-10-24 10:00 ---
I have prototype fix for this which works OK and does not break anything.  It
copies 'p' to a temporary before the FORALL and uses the temporary for the
references.  This method will also cure the problem with character substring
dependences but I have not tested it yet.

This fix will not be very efficient in cases where the FORALL only visits a
small subsection of the 'value' variable but I can see no straightforward of
handling the generality of dependences in the 'value' references.

Watch this space - a "one size fits all" patch for the FORALL and assignment
woes is on its way.

Paul  


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pault at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-10-08 12:15:58 |2007-10-24 10:00:19
   date||


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

[Bug fortran/29784] [doc] No I/O conversion of logical/integer

[fxcoudert at gcc dot gnu dot org]

--- Comment #1 from fxcoudert at gcc dot gnu dot org  2007-10-24 09:44 
---
We should document the current situation and close this
(http://gcc.gnu.org/ml/fortran/2007-10/msg00263.html).


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|enhancement |trivial
  Component|libfortran  |fortran
   Keywords||documentation
   Last reconfirmed|2007-03-18 17:53:23 |2007-10-24 09:44:40
   date||
Summary|Converting logical <->  |[doc] No I/O conversion of
   |integer in IO   |logical/integer


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

[Bug fortran/29240] optional argument for signal intrinsic not supported

[fxcoudert at gcc dot gnu dot org]

--- Comment #7 from fxcoudert at gcc dot gnu dot org  2007-10-24 09:42 
---
(In reply to comment #6)
> FX, you confirmed this enhancement: is do-as-the-others-do really good enough 
> a
> reason to implement this?

No (see http://gcc.gnu.org/ml/fortran/2007-10/msg00263.html). The SIGNAL
intrinsic in its current form is not greatly portable, and the best way to
achieve this is now to use ISO_C_BINDING. Moreover, POSIX bindings will be
included in 4.4, and this will be covered.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX


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

[Bug fortran/26305] No support for non-standard CARRIAGECONTROL, DEFAULTFILE, DISPOSE and RECORDTYPE

[fxcoudert at gcc dot gnu dot org]

--- Comment #2 from fxcoudert at gcc dot gnu dot org  2007-10-24 09:40 
---
No plan to work on this one, see
http://gcc.gnu.org/ml/fortran/2007-10/msg00263.html.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org
 Status|NEW |RESOLVED
 Resolution||WONTFIX


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

[Bug tree-optimization/33804] ICE in vect_transform_stmt, at tree-vect-transform.c:6131 with -ftree-vectorize

[irar at gcc dot gnu dot org]

--- Comment #9 from irar at gcc dot gnu dot org  2007-10-24 09:35 ---
Subject: Bug 33804

Author: irar
Date: Wed Oct 24 09:35:00 2007
New Revision: 129599

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129599
Log:
PR tree-optimization/33804
* tree-vect-transform.c (vectorizable_operation): Remove the
checks that the vectorization is worthwhile from the transformation
phase.


Added:
trunk/gcc/testsuite/gcc.dg/vect/pr33804.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-transform.c


-- 


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

[Bug c++/33878] New: Pure virtual method body omitted from template

[herwig at gdsys dot de]

The following stripped down code shows pure virtual method definitions for both
a normal base class and a templated base class. To my surprise, the templated
class' body is not generated, leading to a "pure virtual method called"
termination in my actual threaded code. Leaving out the "= 0" in the template
generates the body TBase::pvMethod() but is inacceptable due to not
forcing implementation by the derived classes.

Regards,

Björn A. Herwig
Guntermann & Drunck GmbH Systementwicklung 
Dortmunder Str. 4a 
D-57234 Wilnsdorf - Germany

---

[EMAIL PROTECTED]:~/Programming$ LC_ALL=C g++ -v -save-temps -O0 -Wall -o test
test.cpp
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr
--enable-targets=all --enable-checking=release --build=i486-linux-gnu
--host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.2.3 20071014 (prerelease) (Debian 4.2.2-3)
 /usr/lib/gcc/i486-linux-gnu/4.2.3/cc1plus -E -quiet -v -D_GNU_SOURCE test.cpp
-mtune=generic -Wall -O0 -fpch-preprocess -o test.ii
ignoring nonexistent directory "/usr/local/include/i486-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../i486-linux-gnu/include"
ignoring nonexistent directory "/usr/include/i486-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/4.2
 /usr/include/c++/4.2/i486-linux-gnu
 /usr/include/c++/4.2/backward
 /usr/local/include
 /usr/lib/gcc/i486-linux-gnu/4.2.3/include
 /usr/include
End of search list.
 /usr/lib/gcc/i486-linux-gnu/4.2.3/cc1plus -fpreprocessed test.ii -quiet
-dumpbase test.cpp -mtune=generic -auxbase test -O0 -Wall -version -o test.s
GNU C++ version 4.2.3 20071014 (prerelease) (Debian 4.2.2-3) (i486-linux-gnu)
compiled by GNU C version 4.2.3 20071014 (prerelease) (Debian 4.2.2-3).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: c541ec01cc4b43709b709460c241205f
 as -V -Qy -o test.o test.s
GNU assembler version 2.18 (i486-linux-gnu) using BFD version (GNU Binutils for
Debian) 2.18
 /usr/lib/gcc/i486-linux-gnu/4.2.3/collect2 --eh-frame-hdr -m elf_i386
--hash-style=both -dynamic-linker /lib/ld-linux.so.2 -o test
/usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/crt1.o
/usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/crti.o
/usr/lib/gcc/i486-linux-gnu/4.2.3/crtbegin.o
-L/usr/lib/gcc/i486-linux-gnu/4.2.3 -L/usr/lib/gcc/i486-linux-gnu/4.2.3
-L/usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib -L/lib/../lib
-L/usr/lib/../lib -L/usr/lib/gcc/i486-linux-gnu/4.2.3/../../.. test.o -lstdc++
-lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/i486-linux-gnu/4.2.3/crtend.o
/usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/crtn.o
[EMAIL PROTECTED]:~/Programming$ cat test.cpp
class Base
{
public:
virtual void pvMethod() = 0;
};

void Base::pvMethod()
{
}

class Derived :
public Base
{
public:
void pvMethod() { }
};

template
class TBase
{
public:
virtual void pvMethod() = 0;
};

template
void TBase::pvMethod()
{
}

class TDerived :
public TBase
{
public:
void pvMethod() { }
};

int main(int argc, char** argv)
{
Derived d;
TDerived td;
return 0;
}
[EMAIL PROTECTED]:~/Programming$ cat test.ii
# 1 "test.cpp"
# 1 ""
# 1 ""
# 1 "test.cpp"
class Base
{
public:
 virtual void pvMethod() = 0;
};

void Base::pvMethod()
{
}

class Derived :
 public Base
{
public:
 void pvMethod() { }
};

template
class TBase
{
public:
 virtual void pvMethod() = 0;
};

template
void TBase::pvMethod()
{
}

class TDerived :
 public TBase
{
public:
 void pvMethod() { }
};

int main(int argc, char** argv)
{
 Derived d;
 TDerived td;
 return 0;
}
[EMAIL PROTECTED]:~/Programming$ objdump -t test | c++filt | grep ::pvMethod
08048506  wF .text  0005  TDerived::pvMethod()
080484c4 g F .text  0005  Base::pvMethod()
08048500  wF .text  0005  Derived::pvMethod()


-- 
   Summary: Pure virtual method body omitted from template
   Product: gcc
   Version: 4.2.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: herwig at gdsys dot de


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

[Bug c/33877] New: Request for __VA_ARGC__

[michael at fig dot org]

It would be really convenient if the C preprocessor exposed the number of
variable arguments supplied to a variadic macro as an integer.  I tried to come
up with ways of working around this missing feature, but I can't figure out how
to do it without evaluating the macro arguments twice or causing compiler
warnings.

I can supply a patch, if I am blessed with my proposed solution, to have
__VA_ARGC__ be an integer count of the number of __VA_ARGS__.  If you have
suggestions for a better design, I'd like to hear them!

Thanks,
Michael.


-- 
   Summary: Request for __VA_ARGC__
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michael at fig dot org


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

[Bug tree-optimization/33866] [4.3 Regression] ICE in vect_get_vec_def_for_stmt_copy, at tree-vect-transform.c:1937

[irar at il dot ibm dot com]

--- Comment #4 from irar at il dot ibm dot com  2007-10-24 07:48 ---
In this testcase we perform vectorization of strided accesses in a loop with
multiple types. In vectorizable_store() we gather all the scalar operands of
the stores in the strided accesses group and later call
vect_get_vec_def_for_stmt_copy () to get vectorized copies for the scalar
operands. We (erroneously) assumed that the def stmts of those scalars stmts
are of the the same type, i.e., either they all are loop invariants or loop
variants.  But this is not the case here:

  points[num_points_36][0] = start$0_20(D);
  D.1561_14 = (long int) j_35;
  D.1563_16 = D.1561_14 + start$1_19(D);
  points[num_points_36][1] = D.1563_16;

start$0_20(D) is loop invariant, while D.1563_16 is not.

I am working on a fix.

Ira


-- 

irar at il dot ibm dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-10-24 07:48:07
   date||


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