[Bug middle-end/17544] [4.0 Regression] incorrect -Wunreachable-code warning for mains with a return statement

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2004-12-31 
10:38 ---
Testing a patch. 

-- 


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

[Bug libstdc++/19060] fstream.tellp() result not changed after some output

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2004-12-31 11:07 
---
In my opinion, this is definitely a (target dependent) code generation bug,
rather serious, if confirmed. As such, we should do our best to reduce it
and recategorize in the right way. Any chance you can try to reduce it to a
short, pure c++ snippet? The relevant library code is quite straightforward.

-- 


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

[Bug libstdc++/18970] 3.4 default memory allocator much slower than 3.3 allocator when large amounts of data are turned over

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2004-12-31 11:10 
---
I think we can definitely close this one: the various (configure) issues are 
well
known and no fixes are needed anywhere.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug libfortran/19213] New: CVS source broken on Solaris

[coudert at clipper dot ens dot fr]

CVS source dated 2004-12-31, 04:00 MET, doesn't build on sparc-sun-solaris2.9.
Failure is in libfortran, relevant errors are:

xgcc: ../../../../gcc/libgfortran/generated/cshift1_4.c: No such file or 
directory
xgcc: no input files
make[5]: *** [cshift1_4.lo] Error 1
make[4]: *** [all] Error 2
make[3]: *** [multi-do] Error 1
make[2]: *** [all-multi] Error 2
make[1]: *** [all] Error 2
make: *** [all-target-libgfortran] Error 2

The (exactly) same source compiles fine on i386-unknown-freebsd (another nigthly
 build of gfortran). CVS source date 2004-12-30, 04:00 MET built correctly on
sparc-sun-solaris2.9, so that finding the cause of regression should not be
difficult.

-- 
   Summary: CVS source broken on Solaris
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: coudert at clipper dot ens dot fr
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: sparc-sun-solaris2.9
  GCC host triplet: sparc-sun-solaris2.9
GCC target triplet: sparc-sun-solaris2.9


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

[Bug middle-end/17544] [4.0 Regression] incorrect -Wunreachable-code warning for mains with a return statement

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2004-12-31 
12:02 ---
(From update of attachment 7808)
Patch here: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg02140.html


-- 
   What|Removed |Added

Attachment #7808 is|0   |1
   obsolete||


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

[Bug tree-optimization/19108] [4.0 regression] ICE initializing arrays

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2004-12-31 
12:13 ---
I cannot reproduce this (it is monitored??). 
 
I still think something like Andrew's patch is necessary, 
but without a test case, well, how can we be sure?? 

-- 
   What|Removed |Added

 Status|ASSIGNED|WAITING


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

[Bug c++/19199] [3.3/3.4/4.0 Regression] Wrong warning about returning a reference to a temporary

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2004-12-31 
12:45 ---
Why would this cause wrong code?  It's just a cast from an enum to an int, 
I don't see what's wrong with that except that it's ugly. 
 
You have to actually show that this causes wrong code, not just make your 
usual exaggerated claims ;-) 
 
 

-- 
   What|Removed |Added

   Keywords|wrong-code  |


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

[Bug c/19031] [4.0 Regression] #pragma weak handling changes in 4.0.0

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2004-12-31 
13:15 ---
Not being able to build X is pretty critical. 

-- 
   What|Removed |Added

   Severity|normal  |critical
   Priority|P2  |P1


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

[Bug c++/19188] friend funtion inside a template class seems to have a problem

[lerdsuwa at gcc dot gnu dot org]

--- Additional Comments From lerdsuwa at gcc dot gnu dot org  2004-12-31 
13:23 ---
The 'typename' keyword is required because later C++ introduces a lot more
features.  Those that interfere with your code are partial specialization 
and specialization.  For example, you can now have specialization

  template <> class tstack {
int link;
...
  };

Then when you declare

  tstack t;

it will use the above declaration, where 'link' is now a member data
instead of a nested class.  So the code

  tstack::link* p;

which could be interpreted as declaring a variable which is a pointer to type
'tstack::link' if 'T' is 'int'.  But when 'T' is 'bool' it could means
multiplying a member data with another variable named 'p'.

To resolve the ambiguity, later C++ requires the 'typename' keyword to
treat as pointer declaration, otherwise it will be treated as muliplication.
Older C++ books don't have this 'typename' keyword but newer good books 
from respected authors coming out in the last few years should.  
(Many new C++ books are still wrong).

I know the parser error message could be improved, and there are plenty of
bug reports elsewhere about it.

-- 


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

[Bug target/19201] [m68k] Inefficient code for array accesses (from old PROBLEMS)

[schwab at suse dot de]

--- Additional Comments From schwab at suse dot de  2004-12-31 13:32 ---
Test case (see also 
): 
 
struct X { 
  char *a; 
  /* other members */ 
  int b; 
}; 
 
void f (struct X *x) 
{ 
  x->a[x->b] = 0; 
} 

-- 
   What|Removed |Added

 CC||schwab at suse dot de


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

[Bug target/19204] [m68k] pea can force reloads that cause inefficient code

[schwab at suse dot de]

-- 
   What|Removed |Added

 CC||schwab at suse dot de


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

[Bug target/19205] [m68k] avoid converting INDEX to SI mode if a narrower mode suffices

[schwab at suse dot de]

-- 
   What|Removed |Added

 CC||schwab at suse dot de


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

[Bug c++/19199] [3.3/3.4/4.0 Regression] Wrong warning about returning a reference to a temporary

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-31 
14:51 ---
(In reply to comment #2)
> Why would this cause wrong code?  It's just a cast from an enum to an int, 
> I don't see what's wrong with that except that it's ugly. 
>  
> You have to actually show that this causes wrong code, not just make your 
> usual exaggerated claims ;-) 

Ok, the reason why it is wrong code is because we return an address to a 
temporary which we can 
overwrite.  Yes this is wrong code.  The diagnostic is just an indication that 
it will be wrong code.

-- 
   What|Removed |Added

   Keywords||wrong-code


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

[Bug libfortran/19213] CVS source broken on Solaris

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-31 
14:56 ---
What were your configure options?
Could you attach the full build log?

-- 


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

[Bug target/19201] [m68k] Inefficient code for array accesses (from old PROBLEMS)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-31 
14:58 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
 GCC target triplet||m68k-*-*
   Last reconfirmed|-00-00 00:00:00 |2004-12-31 14:58:01
   date||


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

[Bug tree-optimization/19108] [4.0 regression] ICE initializing arrays

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2004-12-31 
16:08 ---
I can still reproduce it with the above testcase:
gcc version 4.0.0 20041230 (experimental) on i686-pc-linux-gnu.

Maybe it is target dependant?
Did you try larger array sizes than 6?


-- 


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

[Bug tree-optimization/19108] [4.0 regression] ICE initializing arrays

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-31 
16:10 ---
(In reply to comment #5)
> I can still reproduce it with the above testcase:
> gcc version 4.0.0 20041230 (experimental) on i686-pc-linux-gnu.
> 
> Maybe it is target dependant?

It is. You might have to use -march=i686.


-- 
   What|Removed |Added

 Status|WAITING |ASSIGNED


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

[Bug target/18701] [4.0 regression] mmix-knuth-mmixware gcc.c-torture/execute failures: 20010224-1.c, 20020216-1.c, 20040218-1.c, 20040709-2.c

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-31 
16:24 ---
Subject: Bug 18701

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-12-31 16:24:48

Modified files:
gcc: ChangeLog combine.c 

Log message:
PR target/18701
* combine.c (gen_lowpart_for_combine): When stripping SUBREG of
MEM, adjust imode and isize.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6987&r2=2.6988
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/combine.c.diff?cvsroot=gcc&r1=1.463&r2=1.464



-- 


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

[Bug target/18701] [4.0 regression] mmix-knuth-mmixware gcc.c-torture/execute failures: 20010224-1.c, 20020216-1.c, 20040218-1.c, 20040709-2.c

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-31 
16:28 ---
Subject: Bug 18701

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-12-31 16:28:34

Modified files:
gcc: ChangeLog combine.c 

Log message:
PR target/18701
* combine.c (combine_simplify_rtx): Do not allow paradoxical
subregs of MEM.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6988&r2=2.6989
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/combine.c.diff?cvsroot=gcc&r1=1.464&r2=1.465



-- 


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

[Bug target/18701] [4.0 regression] mmix-knuth-mmixware gcc.c-torture/execute failures: 20010224-1.c, 20020216-1.c, 20040218-1.c, 20040709-2.c

[hp at gcc dot gnu dot org]

--- Additional Comments From hp at gcc dot gnu dot org  2004-12-31 16:33 
---
http://gcc.gnu.org/ml/gcc-patches/2004-12/msg02151.html>

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug libstdc++/19060] fstream.tellp() result not changed after some output

[wanderer at rsu dot ru]

--- Additional Comments From wanderer at rsu dot ru  2004-12-31 17:13 
---
At this moment i can't extract simple testcase.
But problem indeed in miscompiletion.

I am use modified testcase (additionl debug output line before assert (and 
iostream header include:
  std::cout << "begin==" << startpos << " end==" << endpos << "\n";

Valid output: "begin==0 end==8"
Invalid output:"begin==-1 end==-1"

I bootstrap GCC from current sources with additional -save-temps flag and 
compile and link libsupc++.a library and requred for my testcase .ii (renamed 
to .cc) files from libstdc++ library.

Final testcase executible work without problems with valid output.
But if i compile basic_file.cc (renamed .ii version) with -O2 option
then testcase executible run terminated with invalid output "begin==-1 end==-
1" and assert fail.


-- 


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

[Bug libstdc++/19060] fstream.tellp() result not changed after some output

[wanderer at rsu dot ru]

--- Additional Comments From wanderer at rsu dot ru  2004-12-31 17:15 
---
Created an attachment (id=7847)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7847&action=view)
.ii file from gcc build object directory


-- 


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

[Bug libstdc++/19060] fstream.tellp() result not changed after some output

[wanderer at rsu dot ru]

--- Additional Comments From wanderer at rsu dot ru  2004-12-31 17:16 
---
Created an attachment (id=7848)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7848&action=view)
.s compiled from basic_file.cc with default oprions


-- 


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

[Bug libstdc++/19060] fstream.tellp() result not changed after some output

[wanderer at rsu dot ru]

--- Additional Comments From wanderer at rsu dot ru  2004-12-31 17:17 
---
Created an attachment (id=7849)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7849&action=view)
.s compiled from basic_file.cc with -O2 (miscompiled version)


-- 


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

[Bug c/19214] New: Internal compiler error in dwarf2out_finish, at dwarf2out.c:12301

[stolfi at ic dot unicamp dot br]

Compilation of the following short program dies with 
  
  Internal compiler error in dwarf2out_finish, at dwarf2out.c:12301

The bug disappears if "NUM" is replaced by "int", even though 
"NUM" is just a typedef for "int"

/* bug2.c */
/* Last edited on 2004-12-31 14:42:34 by stolfi */ 

typedef int NUM;

int p (int x)
  {
auto NUM F(void);
NUM F(void) { return x; }

return F();
  }
 
uname -a
Linux simoleo.ic.unicamp.br 2.4.20-8smp #1 SMP Thu Mar 13 16:43:01 EST 2003 i686
athlon i386 GNU/Linux
gcc --version
gcc (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
gcc -dumpmachine
i386-redhat-linux
gcc -c -g -save-temps -Wall bug2.c
bug2.c:13: Internal compiler error in dwarf2out_finish, at dwarf2out.c:12301

-- 
   Summary: Internal compiler error in dwarf2out_finish, at
dwarf2out.c:12301
   Product: gcc
   Version: 3.2.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stolfi at ic dot unicamp dot br
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i386-redhat-linux
  GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux


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

[Bug c/19214] Internal compiler error in dwarf2out_finish, at dwarf2out.c:12301

[stolfi at ic dot unicamp dot br]

--- Additional Comments From stolfi at ic dot unicamp dot br  2004-12-31 
17:40 ---
Created an attachment (id=7850)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7850&action=view)
Preprocessed file


-- 


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

[Bug c/19214] Internal compiler error in dwarf2out_finish, at dwarf2out.c:12301

[stolfi at ic dot unicamp dot br]

--- Additional Comments From stolfi at ic dot unicamp dot br  2004-12-31 
17:41 ---
Created an attachment (id=7851)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7851&action=view)
Assembler file


-- 


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

[Bug c/19214] Internal compiler error in dwarf2out_finish, at dwarf2out.c:12301

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-31 
17:46 ---
Fixed already in 3.3.  Yes I can reproduce it in 3.2.2.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Keywords||ice-on-valid-code
 Resolution||FIXED
   Target Milestone|--- |3.3


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

[Bug libstdc++/19060] fstream.tellp() result not changed after some output

[wanderer at rsu dot ru]

--- Additional Comments From wanderer at rsu dot ru  2004-12-31 17:58 
---
I extract problematic compiled (with -O2) function: 

---8X-
#include 
#include 

#include  // For ::max() and min() and ::max()

namespace std 
{
  streamoff
  __basic_file::seekoff(streamoff __off, ios_base::seekdir __way)
  {
if (__off > numeric_limits::max()
|| __off < numeric_limits::min())
  return -1L;
return lseek(this->fd(), __off, __way);
  }

}  // namespace std
---X8-


-- 


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

[Bug libstdc++/19060] fstream.tellp() result not changed after some output

[wanderer at rsu dot ru]

--- Additional Comments From wanderer at rsu dot ru  2004-12-31 17:58 
---
Created an attachment (id=7852)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7852&action=view)
.s compiled from basic_file.cc with default oprions


-- 


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

[Bug libstdc++/19060] fstream.tellp() result not changed after some output

[wanderer at rsu dot ru]

--- Additional Comments From wanderer at rsu dot ru  2004-12-31 17:59 
---
Created an attachment (id=7853)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7853&action=view)
.s compiled from basic_file.cc with -O2 (miscompiled version)


-- 


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

[Bug libstdc++/19060] fstream.tellp() result not changed after some output

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-31 
18:20 ---
Hmm, this is the reduced testcase but it was not miscompiled as far as I can 
see:
typedef int __attribute__((__mode__(__DI__))) __int64_t;
typedef __int64_t int64_t;
typedef int64_t streamoff;
typedef __int64_t __off_t;
typedef __off_t off_t;

static long long min() throw() { return -9223372036854775807LL - 1; }
static long long max() throw() { return 9223372036854775807LL; }
__off_t lseek(int, __off_t, int);
streamoff
seekoff(streamoff __off)
{
  if (__off > max() || __off < min())
return -1L;
  return 0;
}


-- 


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

[Bug libstdc++/19060] fstream.tellp() result not changed after some output

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2004-12-31 18:29 
---
Andrew, this is *definitely* target dependent: it's about such a basic feature
that we would have noticed, otherwise! (btw, thanks for the reduced testcase!)

-- 


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

[Bug libstdc++/19060] fstream.tellp() result not changed after some output

[wanderer at rsu dot ru]

--- Additional Comments From wanderer at rsu dot ru  2004-12-31 18:39 
---
This more simplifed version of your last testcase also catch -O2 problem:

#include

typedef int __attribute__((__mode__(__DI__))) off_t;

static long long min() throw() { return -9223372036854775807LL - 1; }
static long long max() throw() { return 9223372036854775807LL; }

void
seekoff(off_t __off)
{
  if (__off > max() || __off < min())
assert(false);
}

int main() {
  seekoff(10);
  return 0;
}


-- 


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

[Bug tree-optimization/19060] [4.0 Regression] fstream.tellp() result not changed after some output

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-31 
19:06 ---
Confirmed with your reduced testcase.

t21.dom1 is where the problem comes in.

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
  Component|libstdc++   |tree-optimization
 Ever Confirmed||1
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2004-12-31 19:06:10
   date||
Summary|fstream.tellp() result not  |[4.0 Regression]
   |changed after some output   |fstream.tellp() result not
   ||changed after some output
   Target Milestone|--- |4.0.0


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

[Bug tree-optimization/19060] [4.0 Regression] fstream.tellp() result not changed after some output

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-31 
19:13 ---
(In reply to comment #19)
> Confirmed with your reduced testcase.
> 
> t21.dom1 is where the problem comes in.

This also happens on i686-pc-linux.  I think this is related to HWI being only 
32bit as it works with a 
x86_64 and -m32.

-- 
   What|Removed |Added

   Severity|normal  |critical
  GCC build triplet|i386-unknown-freebsd5.3-RC1 |
   GCC host triplet|i386-unknown-freebsd5.3-RC1 |
 GCC target triplet|i386-unknown-freebsd5.3-RC1 |i386-unknown-freebsd5.3,
   ||i386-openbsd3.1
   Priority|P2  |P1


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

[Bug tree-optimization/17949] [4.0 Regression] Tree loop optimization generates unaligned access (STRICT_ALIGNMENT is set)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-31 
19:15 ---
Patch here: .

-- 
   What|Removed |Added

   Keywords||patch


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

[Bug tree-optimization/19060] [4.0 Regression] fstream.tellp() result not changed after some output

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2004-12-31 19:24 
---
Yes, I can reproduce with the last testcase. Still, I can't with the original 
one,
that explains why we haven't noticed yet... Thanks to everyone.

-- 


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

[Bug tree-optimization/19060] [4.0 Regression] fstream.tellp() result not changed after some output

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2004-12-31 19:27 
---
Ah, now I see: the problematic code path is actually used *only* when
_GLIBCXX_USE_LFS is not defined, whereas normally is defined, on linux.

-- 


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

[Bug rtl-optimization/19210] [4.0 Regression] not using do-loop for some loops

[dje at gcc dot gnu dot org]

--- Additional Comments From dje at gcc dot gnu dot org  2004-12-31 19:38 
---
Could we use/extend -ffinite-math-only option to cover this case and assert that
the loop will not be infinite?


-- 


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

[Bug tree-optimization/19060] [4.0 Regression] fstream.tellp() result not changed after some output

[belyshev at depni dot sinp dot msu dot ru]

--- Additional Comments From belyshev at depni dot sinp dot msu dot ru  
2004-12-31 19:38 ---
// C testcase

void abort (void);

static long long min ()
{
  return -9223372036854775807LL - 1;
}

void foo (long long j)
{
  if (j > 10 || j < min ())
abort ();
}

int main ()
{
  foo (10);
  return 0;
}


-- 
   What|Removed |Added

 GCC target triplet|i386-unknown-freebsd5.3,|
   |i386-openbsd3.1 |
  Known to fail||4.0.0
  Known to work||3.3.4 3.4.0


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

[Bug tree-optimization/19060] [4.0 Regression] fstream.tellp() result not changed after some output

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-31 
19:40 ---
Note this is only reproducible with HWI being 32bit (x86 is an example but I 
cannot think of another 
one).

-- 
   What|Removed |Added

 GCC target triplet||i?86-*-*


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

[Bug rtl-optimization/19210] [4.0 Regression] not using do-loop for some loops

[rakdver at atrey dot karlin dot mff dot cuni dot cz]

--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni 
dot cz  2004-12-31 20:36 ---
Subject: Re:  [4.0 Regression] not using do-loop for some loops

> Could we use/extend -ffinite-math-only option to cover this case and assert 
> that
> the loop will not be infinite?

I would not reuse this flag (it controls behavior of floating point arithmetics 
and
overloading it in this way does not seem a good idea to me).

However I would like having something like -funsafe-loop-opts that would
allow the optimizer to assume all such conditions that are practically
always true (e.g. that induction variables does not overflow, loops with
nontrivial exit condition are not infinite, etc.).


-- 


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

[Bug bootstrap/19215] New: Gcc 4.0 failed to bootstrap on x86_64-unknown-linux-gnu

[hjl at lucon dot org]

Gcc 4.0 checked at Fri Dec 31 12:18:14 PST 2004 failed to bootstrap
on x86_64-unknown-linux-gnu:

stage1/xgcc -Bstage1/ -B/usr/gcc-4.0/x86_64-unknown-linux-gnu/bin/ -c   -g -
O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-
prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-
definition -Werror-DHAVE_CONFIG_H-I. -I. -
I/net/gnu/export/gnu/src/gcc/gcc/gcc -I/net/gnu/export/gnu/src/gcc/gcc/gcc/. -
I/net/gnu/export/gnu/src/gcc/gcc/gcc/../include -
I/net/gnu/export/gnu/src/gcc/gcc/gcc/../libcpp/include  /net/gnu/export/gnu/src
/gcc/gcc/gcc/c-common.c -o c-common.o
/net/gnu/export/gnu/src/gcc/gcc/gcc/c-common.c: In function 
âhandle_vector_size_attributeâ:
/net/gnu/export/gnu/src/gcc/gcc/gcc/c-common.c:4919: internal compiler error: 
Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
make[4]: *** [c-common.o] Error 1
make[4]: Leaving directory `/export/build/gnu/gcc/build-x86_64-linux/gcc'

CVS at Dec 30 17:02 PST is OK.

-- 
   Summary: Gcc 4.0 failed to bootstrap on x86_64-unknown-linux-gnu
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug bootstrap/19215] Gcc 4.0 failed to bootstrap on x86_64-unknown-linux-gnu

[hjl at lucon dot org]

--- Additional Comments From hjl at lucon dot org  2004-12-31 20:41 ---
It failed to bootstrap on Linux/ia64 also:

/net/gnu/export/gnu/src/gcc/gcc/gcc/gimplify.c: In 
function 'gimplify_asm_expr':
/net/gnu/export/gnu/src/gcc/gcc/gcc/gimplify.c:3347: internal compiler error: 
Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
make[4]: *** [gimplify.o] Error 1
make[4]: *** Waiting for unfinished jobs


-- 


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

[Bug regression/19215] [4.0 Regression] Gcc 4.0 failed to bootstrap on x86_64-unknown-linux-gnu

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-31 
20:51 ---
Like any real bug report, we need how you configured gcc, and the preprocessed 
source.

-- 
   What|Removed |Added

  Component|bootstrap   |regression
   Keywords||build, ice-on-valid-code
Summary|Gcc 4.0 failed to bootstrap |[4.0 Regression] Gcc 4.0
   |on x86_64-unknown-linux-gnu |failed to bootstrap on
   ||x86_64-unknown-linux-gnu
   Target Milestone|--- |4.0.0


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

[Bug regression/19215] [4.0 Regression] Gcc 4.0 failed to bootstrap on x86_64-unknown-linux-gnu

[hjl at lucon dot org]

--- Additional Comments From hjl at lucon dot org  2004-12-31 21:52 ---
It is caused by

http://gcc.gnu.org/ml/gcc/2004-12/msg01271.html

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug target/19211] [4.0 Regression] GNAT bug box compiling a-exexda.adb with stage1 compiler

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-31 
22:06 ---
Fixed.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug target/19211] [4.0 Regression] GNAT bug box compiling a-exexda.adb with stage1 compiler

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-31 
22:08 ---
Subject: Bug 19211

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-12-31 22:07:48

Modified files:
gcc: ChangeLog 
gcc/config : darwin.c 

Log message:
2004-12-31  Andrew Pinski  <[EMAIL PROTECTED]>

PR target/19211
* config/darwin.c (machopic_legitimize_pic_address): If the orig
is subregister return orig.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6991&r2=2.6992
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/darwin.c.diff?cvsroot=gcc&r1=1.100&r2=1.101



-- 


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

[Bug debug/19191] [4.0 Regression] No DWARF2 DW_TAG_inlined_subroutine entry generated

[dberlin at gcc dot gnu dot org]

--- Additional Comments From dberlin at gcc dot gnu dot org  2004-12-31 
22:25 ---
This is really a duplicate of 17924

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

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||DUPLICATE


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

[Bug debug/17924] [4.0 Regression] gcc.dg/debug/dwarf2/dwarf-die7.c fails

[dberlin at gcc dot gnu dot org]

--- Additional Comments From dberlin at gcc dot gnu dot org  2004-12-31 
22:25 ---
*** Bug 19191 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||fnf at specifixinc dot com


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

[Bug debug/17924] [4.0 Regression] gcc.dg/debug/dwarf2/dwarf-die7.c fails

[dberlin at gcc dot gnu dot org]

--- Additional Comments From dberlin at gcc dot gnu dot org  2004-12-31 
22:46 ---
Okay.
What really happens here is that the blocks aren't getting marked properly
because we rearrange the block tree and then the used flags aren't set when the
subblocks of a block are used (which is what we expect in the debug outputters).

However, marking the blocks properly (see the attached patch, which fixes
dwarf-die-7) exposes bugs, and  I really need someone like Jason to tell me what
the heck is going on.

The bug it exposes is as follows (and maybe the real bug is in the inliner, i've
attached a testcase here).

When we inline a C++ constructor that isn't going to be output, we get the
following stuff:

a block for the inlined constructor, with an abstract origin of:
  a decl named __comp_ctor with an abstract origin of:
a decl named bad_typeid

we call gen_inlined_subroutine_die on the block, which calls 
block_ultimate_origin.
block_ultimate_origin returns *the __comp_ctor* decl.

We call dwarf2out_abstract_function on the __comp_ctor decl, which outputs a die
for the bad_typeid decl (which is the real origin).
Then we try to add an abstract attribute for the *comp_ctor* decl, because
that's what we think the ultimate origin of the block was. 
This aborts, because we have no die for that decl (because it's not the real
ultimate origin of the block).

When compiled with 3.4, we end up with

a block for the inlined constructor, with an abstract origin of:
a decl named bad_typeid

Which works properly.

I get the feeling that block_ultimate_origin of the block is supposed to be the
same as it was in 3.4.

But the documentation doesn't help me here.

Jason, if you can tell me what the block_ultimate_origin of the block is
supposed to really be (Ie is it correct or incorrect), i can fix this bug.

You need to apply the patch to see the bug, because without the patch, we simply
don't try to output an inlined subroutine die because the superblock isn't
marked as used, etc.

-- 
   What|Removed |Added

 CC||jason at redhat dot com
Version|4.0.0   |3.4.4


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

[Bug bootstrap/2670] Passing -fpic to cc gives warning

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-31 
22:46 ---
The patch which fixed this was reverted.

-- 
   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug bootstrap/19151] [4.0 Regression] configure: Could not load module ../libiberty/libiberty.a(libiberty.so.0)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-31 
22:47 ---
Fixed by reverting the patch which caused this.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug bootstrap/2670] Passing -fpic to cc gives warning

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|4.0.0   |---


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

[Bug target/18916] [4.0 Regression] mis-aligned vector code with copy memory (-maltivec)

[amodra at bigpond dot net dot au]

--- Additional Comments From amodra at bigpond dot net dot au  2004-12-31 
23:15 ---
This is a problem with the gcc's function call machinery.  The underlying
problem is that mem alignment of function args is taken from the type of the
arg, not the alignment given by function_arg_boundary.  At least, that's what
I'm seeing on investigating why g++.dg/ext/altivec-3.C is failing on
powerpc64-linux, and this looks like the same bug.

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |amodra at bigpond dot net
   |dot org |dot au
 Status|NEW |ASSIGNED
 GCC target triplet|apple-ppc-darwin|apple-ppc-darwin, powerpc*-
   ||*-linux
   Last reconfirmed|2004-12-10 03:35:51 |2004-12-31 23:15:05
   date||


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

[Bug c/19031] [4.0 Regression] #pragma weak handling changes in 4.0.0

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2004-12-31 23:30 
---
I think that this sort of thing *ought* to work.  How, exactly, to teach
cgraph to make it happen is perhaps tricky...

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rth at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-12-31 23:30:52
   date||


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

[Bug rtl-optimization/19210] [4.0 Regression] not using do-loop for some loops

[dje at gcc dot gnu dot org]

--- Additional Comments From dje at gcc dot gnu dot org  2004-12-31 23:55 
---
XLC includes the option

  strict_induction
  Turns off induction variable optimizations
  that have the potential to alter the semantics of a
  user's program. The default is "nostrict_induction" at
  -O2 or higher and "strict_induction" otherwise.
  "nostrict_induction" is recomended if your program does
  not have overflows or wrap arounds of loop induction
  variables.

We probably need something similar in GCC.  Note that XLC enables it when
optimizing.

Most programmers do not expect to be limited by the undefined wrapping behavior.
   They are not using the extremes.

-- 


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

[Bug c++/19199] [3.3/3.4/4.0 Regression] Wrong warning about returning a reference to a temporary

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2005-01-01 00:21 
---
When references are involved, like this, reduction to MAX_EXPR is wrong to 
begin with.  The cast is only an additional symptom.

-- 


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

[Bug tree-optimization/19042] Complex types are not SRA all the time.

[rth at gcc dot gnu dot org]

-- 
   What|Removed |Added

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


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

[Bug target/18910] [4.0 Regression] unrecognisable insn in regclass on x86/amd64

[gschafer at zip dot com dot au]

--- Additional Comments From gschafer at zip dot com dot au  2005-01-01 
01:18 ---
I've just hit this while trying to build Glibc with current GCC trunk. It's a
showstopper.

-- 
   What|Removed |Added

 CC||gschafer at zip dot com dot
   ||au


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

[Bug c++/19188] friend funtion inside a template class seems to have a problem

[max656 at hotmail dot com]

--- Additional Comments From max656 at hotmail dot com  2005-01-01 01:37 
---
Subject: RE:  friend funtion inside a template class seems to have a probl

Hi lerdsuwa

You came up with an interesting topic - class template specializtion.
I didn't know aboou it. I   need further research on that.

As you mentioned, the keyword "typename' is added and compiled and then it 
works fine.
Thanks a lot for your detailed explanation.
It haunted me a lot. I was completely stuck for a while even though I found 
some other ways.

Tyson

>From: "lerdsuwa at gcc dot gnu dot org" <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: [EMAIL PROTECTED]
>Subject: [Bug c++/19188] friend funtion inside a template class seems to 
>have a problem
>Date: 31 Dec 2004 13:23:03 -
>
>--- Additional Comments From lerdsuwa at gcc dot gnu dot org  
>2004-12-31 13:23 ---
>The 'typename' keyword is required because later C++ introduces a lot more
>features.  Those that interfere with your code are partial specialization
>and specialization.  For example, you can now have specialization
>
>   template <> class tstack {
> int link;
> ...
>   };
>
>Then when you declare
>
>   tstack t;
>
>it will use the above declaration, where 'link' is now a member data
>instead of a nested class.  So the code
>
>   tstack::link* p;
>
>which could be interpreted as declaring a variable which is a pointer to 
>type
>'tstack::link' if 'T' is 'int'.  But when 'T' is 'bool' it could means
>multiplying a member data with another variable named 'p'.
>
>To resolve the ambiguity, later C++ requires the 'typename' keyword to
>treat as pointer declaration, otherwise it will be treated as 
>muliplication.
>Older C++ books don't have this 'typename' keyword but newer good books
>from respected authors coming out in the last few years should.
>(Many new C++ books are still wrong).
>
>I know the parser error message could be improved, and there are plenty of
>bug reports elsewhere about it.
>
>--
>
>
>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19188
>
>--- You are receiving this mail because: ---
>You reported the bug, or are watching the reporter.




-- 


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

[Bug middle-end/17799] [4.0 Regression] Non-optimizing compile loses 'this'

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-01-01 
01:43 ---
Subject: Bug 17799

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-01-01 01:43:13

Modified files:
gcc: ChangeLog c-decl.c dwarf2asm.c function.c 
 gimplify.c tree-inline.c tree-outof-ssa.c 
 var-tracking.c 
gcc/cp : ChangeLog call.c class.c decl2.c init.c rtti.c 
 tree.c 

Log message:
PR middle-end/17799
* function.c (use_register_for_decl): Check DECL_IGNORED_P instead
of DECL_ARTIFICIAL.
(assign_parms_augmented_arg_list): Set DECL_IGNORED_P.
* c-decl.c (build_compound_literal): Likewise.
* dwarf2asm.c (dw2_force_const_mem): Likewise.
* gimplify.c (create_artificial_label): Likewise.
* tree-inline.c (expand_call_inline): Likewise.
* var-tracking.c (vt_initialize): Likewise.
* tree-outof-ssa.c (create_temp): Copy DECL_IGNORED_P.
cp/
* call.c (make_temporary_var_for_ref_to_temp): Set DECL_IGNORED_P.
* class.c (build_vtable): Don't conditionallize setting it
based on DWARF2_DEBUG.
(layout_class_type): Set DECL_IGNORED_P.
* decl2.c (get_guard): Likewise.
* rtti.c (get_tinfo_decl, build_lang_decl): Likewise.
* tree.c (build_local_temp): Likewise.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6992&r2=2.6993
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-decl.c.diff?cvsroot=gcc&r1=1.619&r2=1.620
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/dwarf2asm.c.diff?cvsroot=gcc&r1=1.40&r2=1.41
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/function.c.diff?cvsroot=gcc&r1=1.597&r2=1.598
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gimplify.c.diff?cvsroot=gcc&r1=2.100&r2=2.101
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-inline.c.diff?cvsroot=gcc&r1=1.160&r2=1.161
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-outof-ssa.c.diff?cvsroot=gcc&r1=2.38&r2=2.39
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/var-tracking.c.diff?cvsroot=gcc&r1=2.23&r2=2.24
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4564&r2=1.4565
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/call.c.diff?cvsroot=gcc&r1=1.525&r2=1.526
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/class.c.diff?cvsroot=gcc&r1=1.697&r2=1.698
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl2.c.diff?cvsroot=gcc&r1=1.762&r2=1.763
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/init.c.diff?cvsroot=gcc&r1=1.407&r2=1.408
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/rtti.c.diff?cvsroot=gcc&r1=1.207&r2=1.208
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/tree.c.diff?cvsroot=gcc&r1=1.421&r2=1.422



-- 


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

[Bug middle-end/17799] [4.0 Regression] Non-optimizing compile loses 'this'

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2005-01-01 01:45 
---
Fixed.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug libfortran/18778] ENDFILE is not functionnal

[bdavis at gcc dot gnu dot org]

--- Additional Comments From bdavis at gcc dot gnu dot org  2005-01-01 
02:14 ---
re-patch:

http://gcc.gnu.org/ml/fortran/2005-01/msg4.html

-- 


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

[Bug tree-optimization/19042] Complex types are not SRA all the time.

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-01-01 
02:38 ---
Subject: Bug 19042

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-01-01 02:38:06

Modified files:
gcc: ChangeLog tree-sra.c 

Log message:
PR tree-opt/19042
* tree-sra.c (decide_block_copy): Force use_block_copy false
for complex values.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6993&r2=2.6994
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-sra.c.diff?cvsroot=gcc&r1=2.48&r2=2.49



-- 


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

[Bug tree-optimization/19042] Complex types are not SRA all the time.

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2005-01-01 02:42 
---
Fixed.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug libstdc++/18970] 3.4 default memory allocator much slower than 3.3 allocator when large amounts of data are turned over

[mj1 at cog dot brown dot edu]

--- Additional Comments From mj1 at cog dot brown dot edu  2005-01-01 02:53 
---
Subject: Re:  3.4 default memory allocator much slower
 than 3.3 allocator when large amounts of data are turned over

Yes, although you might want to revert to the 3.3 default allocator, as 
the 3.4 default allocator is considerably slower for large programs.

Best,

Mark Johnson

pcarlini at suse dot de wrote:

>--- Additional Comments From pcarlini at suse dot de  2004-12-31 11:10 
>---
>I think we can definitely close this one: the various (configure) issues are 
>well
>known and no fixes are needed anywhere.
>
>  
>


-- 


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

[Bug tree-optimization/19042] Complex types are not SRA all the time.

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |4.0.0


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

[Bug debug/17924] [4.0 Regression] gcc.dg/debug/dwarf2/dwarf-die7.c fails

[dberlin at gcc dot gnu dot org]

--- Additional Comments From dberlin at gcc dot gnu dot org  2005-01-01 
03:17 ---
Just to further followup, the change between 3.4 and 4.0 in regard to what the
abstract origin of of the block is set to is because of the "inliner for java"
code that was made the default in 4.0.
So if it is indeed a bug, i can easily fix it (it's a one line fix).


-- 


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

[Bug libfortran/19216] New: formatted read with leading slash

[bdavis at gcc dot gnu dot org]

This is from FM923.FOR

$ cat b.f
   INTEGER J1I(3)
   DATA J1I / 3,2,1 /
   WRITE(20,'(A)')'/ 10 20 30'
   WRITE(20,'(A)')'1 2 3 4'
   WRITE(20,'(A)')'5 6 7 8'
   REWIND(20)
   READ(20,*) (J1I(IVI), IVI=1,3)
   PRINT*,(J1I(IVI), IVI=1,3)
   READ(20,*) I,J
   PRINT*,I,J
   READ(20,*) I,J
   PRINT*,I,J
   END
$ gfc b.f
$ ./a.out
   1   2   1
   5   6
At line 11 of file b.f
Fortran runtime error: End of file
$ g77 b.f
$ ./a.out
 3 2 1
 1 2
 5 6

$ gfc --version
GNU Fortran 95 (GCC 4.0.0 20050101 (experimental))

-- 
   Summary: formatted read with leading slash
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bdavis at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug libfortran/19216] list directed read with leading slash

[bdavis at gcc dot gnu dot org]

-- 
   What|Removed |Added

Summary|formatted read with leading |list directed read with
   |slash   |leading slash


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

[Bug libfortran/19216] list directed read with leading slash

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-01 
03:42 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-01-01 03:42:09
   date||


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

[Bug tree-optimization/19049] not vectorizing fortran loops because not moving user lables on the tree level

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-01-01 04:23:21
   date||


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

[Bug target/18910] [4.0 Regression] unrecognisable insn in regclass on x86/amd64

[aj at gcc dot gnu dot org]

--- Additional Comments From aj at gcc dot gnu dot org  2005-01-01 06:36 
---
Raise priority since this hits glibc. 

-- 
   What|Removed |Added

   Priority|P2  |P1


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

[Bug tree-optimization/19217] New: ICE: verify_stmts failed: address taken, but ADDRESSABLE bit not set

[aj at gcc dot gnu dot org]

I received the following ICE with current GCC CVS: 
 
$ /usr/lib/gcc/i586-suse-linux/4.0.0/cc1 -fpreprocessed splinesave.i -quiet 
-dumpbase splinesave.c -march=i686 -mtune=i686 -auxbase-strip splinesave.o -O2 
-Wall-Wmissing-prototypes -Wunused -Wimplicit -Wreturn-type -Wparentheses 
-Wformat -Wchar-subscripts -version -fmessage-length=0 -fno-strict-aliasing -o 
splinesave.s 
GNU C version 4.0.0 20041231 (experimental) (SUSE Linux) (i586-suse-linux) 
compiled by GNU C version 4.0.0 20041231 (experimental) (SUSE Linux). 
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 
splinesave.c: In function ?NumberHints?: 
splinesave.c:92: warning: ?i? may be used uninitialized in this function 
splinesave.c: In function ?_CvtPsSplineSet?: 
splinesave.c:862: error: address taken, but ADDRESSABLE bit not set 
temp3D.13981 
 
splinesave.c:862: internal compiler error: verify_stmts failed. 
Please submit a full bug report, 
with preprocessed source if appropriate. 
 
I reduced the testcase a little bit and get on Linux/x86-64 with -m32 the 
following additional information: 
(gdb) r -m32 -fpreprocessed splinesave.i -quiet -dumpbase splinesave.c 
-march=i686 -mtune=i686 -auxbase-strip splinesave.o -O2 -Wall 
-Wmissing-prototypes -Wunused -Wimplicit -Wreturn-type -Wparentheses -Wformat 
-Wchar-subscripts -version -fmessage-length=0 -fno-strict-aliasing -o 
splinesave.s 
GNU C version 4.0.0 20041231 (experimental) (x86_64-suse-linux-gnu) 
compiled by GNU C version 4.0.0 20041231 (experimental). 
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 
splinesave.i: In function ?_CvtPsSplineSet?: 
splinesave.i:6402: error: address taken, but ADDRESSABLE bit not set 
temp3D.12084 
 
 
Breakpoint 2, internal_error (msgid=0x850fdd "verify_stmts failed.") 
at /cvs/gcc/gcc/diagnostic.c:496 
496 { 
(gdb) bt 
#0  internal_error (msgid=0x850fdd "verify_stmts failed.") 
at /cvs/gcc/gcc/diagnostic.c:496 
#1  0x0046b1ae in verify_stmts () at /cvs/gcc/gcc/tree-cfg.c:3547 
#2  0x004f242b in tree_ssa_iv_optimize (loops=0xb7e1d0) 
at /cvs/gcc/gcc/tree-ssa-loop-ivopts.c:5155 
#3  0x0047bc46 in execute_pass_list (pass=0xa72d80) 
at /cvs/gcc/gcc/tree-optimize.c:525 
#4  0x0047bcdb in execute_pass_list (pass=0xa730e0) 
at /cvs/gcc/gcc/tree-optimize.c:563 
#5  0x0047bcdb in execute_pass_list (pass=0xa6e0c0) 
at /cvs/gcc/gcc/tree-optimize.c:563 
#6  0x0047bf39 in tree_rest_of_compilation (fndecl=0x2a95a76b60) 
at /cvs/gcc/gcc/tree-optimize.c:661 
#7  0x00419c73 in c_expand_body (fndecl=0x2a95a76b60) 
at /cvs/gcc/gcc/c-decl.c:6383 
#8  0x0078af50 in cgraph_expand_function (node=0x2a95a7b000) 
at /cvs/gcc/gcc/cgraphunit.c:822 
#9  0x0078c5b1 in cgraph_optimize () at /cvs/gcc/gcc/cgraphunit.c:1689 
#10 0x007381b1 in toplev_main (argc=Variable "argc" is not available. 
) at /cvs/gcc/gcc/toplev.c:1005 
#11 0x002a9568900d in __libc_start_main () from /lib64/tls/libc.so.6 
#12 0x004025ea in _start () at start.S:113

-- 
   Summary: ICE: verify_stmts failed: address taken, but ADDRESSABLE
bit not set
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aj at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,rakdver at gcc dot gnu
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=19217

[Bug tree-optimization/19217] ICE: verify_stmts failed: address taken, but ADDRESSABLE bit not set

[aj at gcc dot gnu dot org]

--- Additional Comments From aj at gcc dot gnu dot org  2005-01-01 06:56 
---
Created an attachment (id=7857)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7857&action=view)
Preprocessed source file


-- 


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

[Bug tree-optimization/19217] [4.0 Regression] ICE: verify_stmts failed: address taken, but ADDRESSABLE bit not set

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Keywords||ice-on-valid-code
Summary|ICE: verify_stmts failed:   |[4.0 Regression] ICE:
   |address taken, but  |verify_stmts failed: address
   |ADDRESSABLE bit not set |taken, but ADDRESSABLE bit
   ||not set
   Target Milestone|--- |4.0.0


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

[Bug target/18916] [4.0 Regression] mis-aligned vector code with copy memory (-maltivec)

[amodra at bigpond dot net dot au]

--- Additional Comments From amodra at bigpond dot net dot au  2005-01-01 
07:17 ---
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00014.html

-- 
   What|Removed |Added

   Keywords||patch


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

[Bug tree-optimization/19217] [4.0 Regression] ICE: verify_stmts failed: address taken, but ADDRESSABLE bit not set

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-01 
07:28 ---
Confirmed, reduced testcase:
void flexto(int *current,int instance_count)
{
  int *end, temp, j;
  for ( j=0; jhttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=19217

[Bug tree-optimization/19217] [4.0 Regression] ICE: verify_stmts failed: address taken, but ADDRESSABLE bit not set

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-01 
07:38 ---
(In reply to comment #2)
> Confirmed, reduced testcase:
> void flexto(int *current,int instance_count)
> {
>   int *end, temp, j;
>   for ( j=0; j end = &temp;
>   *current = *end;
> }

Just a note, this is broken before the loop optimizations are run and it looks 
like it was caused by (my 
patch):
2004-11-30  Andrew Pinski  <[EMAIL PROTECTED]>

PR tree-opt/18298
* tree-optimize.c (init_tree_optimization_passes): Add a may_alias
pass right after fold builtins.

But It just exposes a latent bug in may_alias as we don't keep temp marked as a 
non gimple register 
even though the variable has its address taken still  (yes adding a dce pass 
right before may_alias will 
work around the problem but that does not fix the other problem, we should be 
able to call may_alias 
even without calling dce).

-- 
   What|Removed |Added

 CC||dnovillo at gcc dot gnu dot
   ||org


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

[Bug tree-optimization/19217] [4.0 Regression] ICE: verify_stmts failed: address taken, but ADDRESSABLE bit not set

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-01 
07:53 ---
(In reply to comment #3)
One more note, this does not happen on the tcb but that is because we call dce 
after the first ccp and 
before the next may_alias.

-- 


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