[Bug target/20166] Bootstrap failure due to lack of fixinclude of pthread problem

[themis_hv at yahoo dot co dot uk]

--- Additional Comments From themis_hv at yahoo dot co dot uk  2005-02-24 
08:18 ---
(In reply to comment #1)
> It is not just debian but anyone who used a bad glibc in the first place.  I
have no idea when this was 
> introduced at all.
It was introduced by fix for GCC Bug ID 19333




-- 


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

[Bug target/20166] Bootstrap failure due to lack of fixinclude of pthread problem

[themis_hv at yahoo dot co dot uk]

-- 
   What|Removed |Added

 CC||themis_hv at yahoo dot co
   ||dot uk


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

[Bug middle-end/18902] Naive (default) complex division algorithm

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-02-24 
09:24 ---
Subject: Bug 18902

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-02-24 09:24:18

Modified files:
gcc: ChangeLog c-opts.c common.opt opts.c toplev.c 
gcc/doc: invoke.texi 

Log message:
PR middle-end/18902
* c-opts.c (c_common_post_options): Set flag_complex_method to 2
for c99.
* common.opt (fcx-limited-range): New.
* opts.c (set_fast_math_flags): Set flag_cx_limited_range.
* toplev.c (flag_complex_method): Initialize to 1.
(process_options): Set flag_complex_method to 0 if
flag_cx_limited_range.
* doc/invoke.texi (-fcx-limited-range): New.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7576&r2=2.7577
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-opts.c.diff?cvsroot=gcc&r1=1.135&r2=1.136
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/common.opt.diff?cvsroot=gcc&r1=1.61&r2=1.62
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/opts.c.diff?cvsroot=gcc&r1=1.93&r2=1.94
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/toplev.c.diff?cvsroot=gcc&r1=1.943&r2=1.944
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/invoke.texi.diff?cvsroot=gcc&r1=1.582&r2=1.583



-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[rth at gcc dot gnu dot org]

-- 
Bug 5900 depends on bug 18902, which changed state.

Bug 18902 Summary: Naive (default) complex division algorithm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18902

   What|Old Value   |New Value

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

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

[Bug middle-end/18902] Naive (default) complex division algorithm

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2005-02-24 09:25 
---
Fixed.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/19693] optimization problem with LAPACK routine cgtts2.f

[rth at gcc dot gnu dot org]

-- 
Bug 19693 depends on bug 18902, which changed state.

Bug 18902 Summary: Naive (default) complex division algorithm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18902

   What|Old Value   |New Value

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

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

[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran

[rth at gcc dot gnu dot org]

-- 
Bug 19292 depends on bug 18902, which changed state.

Bug 18902 Summary: Naive (default) complex division algorithm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18902

   What|Old Value   |New Value

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

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

[Bug target/19019] GCC ldouble format incompatibility with XLC long double

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-02-24 
09:27 ---
Subject: Bug 19019

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED]   2005-02-24 09:27:01

Modified files:
gcc: ChangeLog mklibgcc.in Makefile.in 
gcc/config/rs6000: t-linux64 darwin-ldouble.c 
Added files:
gcc/config/rs6000: darwin-ldouble-shared.c 

Log message:
PR target/19019
* Makefile.in (LIB2FUNCS_SHARED_EXTRA, LIB2ADD_SH): New.
(libgcc.mk): Depend on $(LIB2ADD_SH), pass LIB2ADD_SH to mklibgcc.
(LIBGCC_DEPS): Add $(LIB2ADD_SH).
* mklibgcc.in: Handle LIB2ADD_SH.
* config/rs6000/t-linux64 (LIB2FUNCS_EXTRA): Remove darwin-ldouble.c.
(LIB2FUNCS_STATIC_EXTRA, LIB2FUNCS_SHARED_EXTRA): Set.
* config/rs6000/darwin-ldouble.c: Protect .symver asm also with
defined IN_LIBGCC2_S.
* config/rs6000/darwin-ldouble-shared.c: New file.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.2326.2.804&r2=2.2326.2.805
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/mklibgcc.in.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.67.4.3&r2=1.67.4.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/Makefile.in.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.1223.2.22&r2=1.1223.2.23
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/darwin-ldouble-shared.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/t-linux64.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.5.16.2&r2=1.5.16.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/darwin-ldouble.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3.4.2&r2=1.3.4.3



-- 


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

[Bug c++/20184] New: assignment error in inline function

[dirk at cle-mens dot de]

// Postet by [EMAIL PROTECTED]
// Compiler Error found:
//  gcc (GCC) 3.3.4 (pre 3.3.5 20040809)
//  under SuSE Linux kernel 2.6.8-24.10-default (i386)
//
// If this littel programm is compiled with the option -O2
// the assignment in the inline function data::data() is wrong.
// If I remove the 'inline' the result is correct.
//
// Compiled with: g++ -Wall error.cpp
//  -> OK, printout = :
//
// Compiled with: g++ -Wall -O2 error.cpp
//  -> ERROR, printout = :b408
//
// Compiled with: g++ -Wall -O2 error.cpp,, but without 'inline'
//  -> OK, printout = :
//

#include 
#include 

typedef unsigned int uint32;
typedef unsigned long long uint64;

class data
{
 public:
uint32 lo;
uint32 hi;

data ( uint32 num );
};

inline data::data ( uint32 num ) { *(uint64*)this = num; }


int main()
{
printf("sizeof(uint32)=%d\n",sizeof(uint32));
printf("sizeof(uint64)=%d\n",sizeof(uint64));
printf("sizeof(data)  =%d\n",  sizeof(data));

uint32 tab[] = { 0,0,0,0,0 };
uint32 *p = tab;

data D = data(*p++);
printf("%08x:%08x\n",D.hi,D.lo);
}

-- 
   Summary: assignment error in inline function
   Product: gcc
   Version: 3.3.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dirk at cle-mens dot de
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/20184] assignment error in inline function

[falk at debian dot org]

--- Additional Comments From falk at debian dot org  2005-02-24 10:21 
---
You are accessing an object of type "class data" via a pointer to uint64, which
is not allowed in C++. So this is invalid.


-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/20185] New: assignment error in inline function

[dirk at cle-mens dot de]

// Postet by [EMAIL PROTECTED]
// Compiler Error found:
//  gcc (GCC) 3.3.4 (pre 3.3.5 20040809)
//  under SuSE Linux kernel 2.6.8-24.10-default (i386)
//
// This Bug is a little bit different in relation to bug #20184
//
// If this littel programm is compiled with the option -O2
// the assignment in the inline function was wrong.
// If I remove the 'inline' the result is correct.
//
// Compiled with: g++ -Wall error.cpp
//  -> OK, printout = 
//
// Compiled with: g++ -Wall -O2 error.cpp
//  -> ERROR, printout = 0804836d
//
// Compiled with: g++ -Wall -O2 error.cpp,,
//  but without 'inline' for func data::data()
//  -> OK, printout = 
//

#include 
#include 

typedef unsigned int uint32;
typedef unsigned long long uint64;

class data
{
 public:
uint32 lo;
uint32 hi;

data ( uint32 num );
operator uint64 () const;
};

inline data::data ( uint32 num ) { lo = num; hi = -(num<0); }
inline data::operator uint64 () const { return *(uint64*)this; }

int main()
{
printf("sizeof(uint32)=%d\n",sizeof(uint32));
printf("sizeof(uint64)=%d\n",sizeof(uint64));
printf("sizeof(data)  =%d\n",  sizeof(data));

uint32 tab[] = { 0,0,0,0,0 };
uint32 *p = tab;

uint64 u64 = data(*p++);
printf("%016llx\n",u64);
}

-- 
   Summary: assignment error in inline function
   Product: gcc
   Version: 3.3.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dirk at cle-mens dot de
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c/11751] wrong evaluation order of an expression

[schlie at comcast dot net]

--- Additional Comments From schlie at comcast dot net  2005-02-24 10:34 
---
Although I can confidently say that I've been less than enthusiastic with
some of GCC's standards interpretations; here GCC's results in each of the
examples you cite are within the set of semantically consent values which
should be expected to result from an unspecified evaluation and/or value
assignment order. (Although do agree that GCC has no license to return any
value other than those which would result from these ordering ambiguities).

(Although do believe that GCC should adopt an lr evaluation order; as
expressions which are otherwise ambitious are useless, and those which are
unaffected are insensitive to it; resulting in no harm, only benefit; and with a
little luck may lead to the C/C++ committees coming to their senses in time.)


-- 


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

[Bug c++/20184] assignment error in inline function

[dirk at cle-mens dot de]

--- Additional Comments From dirk at cle-mens dot de  2005-02-24 10:35 
---
The cast is, perhaps, illegal. But after the cast there is an assignment from
uint32 to uin64. And that assignment does not work.

-- 
   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug c++/20184] assignment error in inline function

[dirk at cle-mens dot de]

--- Additional Comments From dirk at cle-mens dot de  2005-02-24 10:38 
---
The reinterpret_cast solves the problem with this old code.

inline data::data ( uint32 num ) { *reinterpret_cast(this) = num; }


-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/20184] assignment error in inline function

[falk at debian dot org]

--- Additional Comments From falk at debian dot org  2005-02-24 10:57 
---
(In reply to comment #2)
> The cast is, perhaps, illegal.

No, the cast is fine. The access is bad.

> But after the cast there is an assignment from
> uint32 to uin64. And that assignment does not work.

Since this has undefined behaviour, it cannot possibly "not work".


-- 


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

[Bug c++/20184] assignment error in inline function

[falk at debian dot org]

--- Additional Comments From falk at debian dot org  2005-02-24 10:58 
---
(In reply to comment #3)
> The reinterpret_cast solves the problem with this old code.
> 
> inline data::data ( uint32 num ) { *reinterpret_cast(this) = num; }

That is pure luck; the code is still invalid.


-- 


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

[Bug c++/20099] -pthreads should imply -fno-threadsafe-statics

[gniccolai at yahoo dot com]

--- Additional Comments From gniccolai at yahoo dot com  2005-02-24 11:00 
---
(In reply to comment #18)
> I think this is a waste really for this bug to be open as non of the GCC
people commented on it and 
> when the orginal bug was filed, there was a huge opportunity to talk over this
and nothing was done.
> 
> So I am going to close as will not fix.

Is there any of the GCC people in the POSIX committee working at the PTHREAD
sub-standard? 
Because David Butenhof (member of the above and writer of the book "Programming
with POSIX® Threads") has strongly argued against this feature:



Obviously, (excessive) locking does NOT allow for simultaneous execution.

A lot of people are used to write old good ST code and "add some locks 
to
make it thread-safe" afterwards. The realworld result is always frustrating:
the application is terribly slow and doesn't scale.
Sure, we need some synchronization primitives (such as mutexes) to 
implement
inter-thread communication. As a rule, thoroughly designed MT application is a
set of fully independent threads which communicate via the message queues. The
synchronization primitives are used inside these queues and virtually no locks
are supposed outside the queues.
But what we see in real life is herds of mutexes spread across the code.
"MT-aware classes" try to lock almost every method... And even more, some
"industrial-strength" PLs have the built-in mutex per every object! IMHO there
is no excuse for this madness.



I have found no other competent opinion arguing the other way around (that is,
the thing that you want to do); every competent opinion is in this direction.

The ABI closure is actually based on a non-standard solution, and on a "lack of
interest" (and presumabily competence) in this field. Also, a bug cannot be
considered closed "because no-one protested yet". 

BTW; I am going to see Stallman today and speak with him about this fact. Is in
Milan today.

Bests,
Giancarlo Niccolai


-- 


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

[Bug c++/20185] assignment error in inline function

[falk at debian dot org]

--- Additional Comments From falk at debian dot org  2005-02-24 11:00 
---
Invalid for the same reason as PR 20184...


-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/20186] New: ICE on boost-1.32 with latest cvs

[jan dot dvorak at kraxnet dot cz]

Got ICE compiling boost-1.32 with 4.0.0 20050223

preprocessed file: http://napalm.sf.cz/xml_oarchive.ii.gz

# g++ -v ./xml_oarchive.ii 
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages=c,c++
--enable-threads=posix --enable-share
Thread model: posix
gcc version 4.0.0 20050223 (experimental)
 /usr/local/libexec/gcc/i686-pc-linux-gnu/4.0.0/cc1plus -fpreprocessed
./xml_oarchive.ii -quiet -dumpbase xml_oarchive.ii -mtune=pentiumpro -auxbase
xml_oarchive -version -o /tmp/ccN4IMmj.s
GNU C++ version 4.0.0 20050223 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.0.0 20050223 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
./boost/archive/detail/oserializer.hpp: In static member function 'static void
boost::archive::detail::save_enum_type::invoke(Archive&, const T&)':
./boost/archive/detail/oserializer.hpp:491: 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.

-- 
   Summary: ICE on boost-1.32 with latest cvs
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot dvorak at kraxnet dot cz
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug c++/20175] [3.4/4.0 Regression] Warnings are issued when initializing struct members with "strings"

[jakub at gcc dot gnu dot org]

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2005-02-23 18:27:26 |2005-02-24 11:44:57
   date||


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

gcc-bugs@gcc.gnu.org

[heinrich dot brand at fujitsu-siemens dot com]

Function test has value 0. Should have value 1;

#include 
int a=0x101;
int b=0x100;

int test(){
 return (
  ((unsigned char)(unsigned long long) ( (a?a:1) & (a*b) ))
  ?  0 : 1 );
}

int main(void){
 if((unsigned char)(unsigned long long) (a&(a*b)))return 2;
 if( test() ){
printf("successful\n"); return 0;
 } else { 
printf("failed\n"); return 1;
 } 
} 

Related to Bug 19606? 

GNU CPP version 2.95.2 19991024 (release) (sparc) successful
GNU C version 3.3.3 (sparc-sun-solaris2.8)  failed

GNU CPP version 3.2 (cpplib) (i386 Linux/ELF) failed 
GNU C version 3.3.2 (i686-pc-linux-gnu) failed
GNU C version 3.3.5 (i686-pc-linux-gnu) failed
GNU C version 3.4.3 (i686-pc-linux-gnu) failed

-- 
   Summary: wrong code for ((unsigned char)(unsigned long
long)((a?a:1)&(a*b)))?0:1)
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: heinrich dot brand at fujitsu-siemens dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux
  GCC host triplet: i686-pc-linux
GCC target triplet: i686-pc-linux


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

[Bug c++/20186] [4.0 regression] ICE on boost-1.32 with latest cvs

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2005-02-24 
12:12 ---
Confirmed. Reduced testcase:

==
template void foo(T &t)
{
int i = static_cast(t);
}
==


-- 
   What|Removed |Added

 CC||reichelt at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||ice-on-valid-code, monitored
   Last reconfirmed|-00-00 00:00:00 |2005-02-24 12:12:53
   date||
Summary|ICE on boost-1.32 with  |[4.0 regression] ICE on
   |latest cvs  |boost-1.32 with latest cvs
   Target Milestone|--- |4.0.0


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

[Bug c++/20142] [3.3/3.4/4.0 regression] implicit assignment operator with multi-dimensional array is broken

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2005-02-24 
12:21 ---
Here's an even shorter testcase. It should return 0, but doesn't since
GCC 3.3. If I remove A's constructor, we get the failure since GCC 3.0.

==
int n=4;

struct A
{
A() {}
A& operator= (const A&) { --n; return *this; }
};

struct B
{
A x[2][2];
};

int main()
{
B b;
b = b;
return n;
}
==


-- 
   What|Removed |Added

  Known to fail|3.3 3.3.5 3.4.3 4.0.0   |3.0 3.2.3 3.3 3.3.5 3.4.3
   ||4.0.0
  Known to work|2.95.3 3.0.4 3.2.3  |2.95.3


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

[Bug c++/20185] assignment error in inline function

[dirk at cle-mens dot de]

--- Additional Comments From dirk at cle-mens dot de  2005-02-24 12:21 
---
(In reply to comment #1)
> Invalid for the same reason as PR 20184...
> 

I get the same failure if I use (little endian system)
  inline data::operator uint64 () const 
{ return *reinterpret_cast(this); }
or
  inline data::operator uint64 () const 
{ return *reinterpret_cast(&lo); }
or
  inline data::operator uint64 () const 
{ return *(uint64*)&lo; }

It looks like an optimation failure.
The function has to copy 64 bits, but it only copies the low 32 bits into the
result. For verifying this, I have changed the values of table 'tab[]' into
{1,1,1,1,1}

Let's have a lokk into the assembler listing

movl$1, -48(%ebp)
movl$0, -44(%ebp)  // this is data::data(1) -> u64

pushl   %edx// the hi-32-bits of u64, but edx was not set
movl-48(%ebp), %eax // the low-32-bit of u64
pushl   %eax
pushl   $.LC3
callprintf

And again: This failure appears only with the combination of inline and the
option -O2.

---
Another question: I marked this bug 'reopen' while I'm posting this. Is this the
correct way?

-- 
   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug c++/20157] [4.0 Regression] Internal compiler error on invalid code

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2005-02-24 
12:27 ---
Hmm. I don't know whether this is really a regression.
We never treated this code correctly. We have an ICE in 2.95.x
and mainline. In 3.0 - 3.4.4 we accept the code where we shouldn't.


-- 
   What|Removed |Added

 CC||reichelt at gcc dot gnu dot
   ||org
   Keywords||monitored


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

[Bug c++/20175] [3.4/4.0 Regression] Warnings are issued when initializing struct members with "strings"

[jakub at gcc dot gnu dot org]

--- Additional Comments From jakub at gcc dot gnu dot org  2005-02-24 12:34 
---
Patch here: 

-- 
   What|Removed |Added

   Keywords||patch


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

[Bug c++/20185] assignment error in inline function

[falk at debian dot org]

--- Additional Comments From falk at debian dot org  2005-02-24 12:59 
---
(In reply to comment #2)
> (In reply to comment #1)
> > Invalid for the same reason as PR 20184...
> > 
> 
> I get the same failure if I use (little endian system)
>   inline data::operator uint64 () const 
> { return *reinterpret_cast(this); }

Okay, once again. The ISO C++ standard says (3.10:15):

  If a program attempts to access the stored value of an object through
  an lvalue of other than one of the following types the behavior is
  undefined:

   -- the dynamic type of the object,
   -- a cv-qualified version of the dynamic type of the object,
   -- a type that is the signed or unsigned type corresponding to the
  dynamic type of the object,
   -- a type that is the signed or unsigned type corresponding to a
  cv-qualified version of the dynamic type of the object,
   -- an aggregate or union type that includes one of the
  aforementioned types among its members (including, recursively, a
  member of a subaggregate or contained union),
   -- a type that is a (possibly cv-qualified) base class type of the
  dynamic type of the object,
   -- a char or unsigned char type.

You are accessing an object of type "class data" through an lvalue of type
"uint64". The type "uint64" here matches none of the mentioned cases; therefore,
the behavior is undefined. This means that printing , printing
0804836d, crashing, or formatting your hard disk are all correct
results of your code, and there is no bug in the compiler for generating
code that does this.


-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug libgcj/20160] [4.0 Regression] link errors building libgcj tests

[rearnsha at gcc dot gnu dot org]

--- Additional Comments From rearnsha at gcc dot gnu dot org  2005-02-24 
13:19 ---
Yes, that's the patch that introduces the problem.


-- 
   What|Removed |Added

 Status|WAITING |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-02-24 13:19:31
   date||


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

[Bug other/20188] New: glibc-2.3.4 misscompilation.

[pluto at pld-linux dot org]

I get an error during `make install`: 
  
(...)  
/home/users/pluto/rpm/BUILD/glibc-2.3.4/builddir/timezone/zic  
-d /tmp/glibc-2.3.4-root-pluto/usr/share/zoneinfo -L /dev/null  
-y ./yearistype solar87  
"solar87", line 385: can't determine time zone abbreviation  
                     to use just after until time   
make[2]: *** [/tmp/glibc-2.3.4-root-pluto/usr/share/zoneinfo/Asia/Riyadh87]  
Error 1  
 
gcc-4.0.0-20050220+pr13397 - fails. 
gcc-3.3.5 - ok.

-- 
   Summary: glibc-2.3.4 misscompilation.
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at pld-linux dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pld-linux
  GCC host triplet: i686-pld-linux
GCC target triplet: i686-pld-linux


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

[Bug other/20188] glibc-2.3.4 misscompilation.

[pluto at pld-linux dot org]

--- Additional Comments From pluto at pld-linux dot org  2005-02-24 13:30 
---
(In reply to comment #0)  
 
> gcc-4.0.0-20050220+pr13397 - fails.   
 
s/13397/19937/  
  

-- 


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

[Bug tree-optimization/20122] Wrong code with gcc 4.0 tree-vectorizer

[irar at il dot ibm dot com]

--- Additional Comments From irar at il dot ibm dot com  2005-02-24 13:41 
---
I found the problem that causes this. I'll send the patch next week.
Ira

-- 


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

[Bug libfortran/19678] DOS files don't work for list directed input

[coudert at clipper dot ens dot fr]

--- Additional Comments From coudert at clipper dot ens dot fr  2005-02-24 
13:46 ---
I submitted a patch to fix this bug. See
http://gcc.gnu.org/ml/fortran/2005-02/msg00303.html

-- 
   What|Removed |Added

 CC||coudert at clipper dot ens
   ||dot fr


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

[Bug c++/20186] [4.0 regression] ICE on boost-1.32 with latest cvs

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Severity|normal  |critical
   Priority|P2  |P1


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

[Bug rtl-optimization/20182] Improper code generation causes stack corruption

[rearnsha at gcc dot gnu dot org]

--- Additional Comments From rearnsha at gcc dot gnu dot org  2005-02-24 
13:47 ---
This was fixed in gcc-3.3

2002-07-16  Richard Earnshaw  <[EMAIL PROTECTED]>

* arm.md (stack_tie): New insn.  Use an idiom that the alias code
understands to be a memory clobber.
* arm.c (arm_expand_prologue): Use it.


-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug c/20189] New: assignment error in inline function

[dirk at cle-mens dot de]

This error was similar to bug #20185,
but now it is a C-Programm and not C++


// Postet by [EMAIL PROTECTED]
// Compiler Error found:
//  gcc (GCC) 3.3.4 (pre 3.3.5 20040809)
//  under SuSE Linux kernel 2.6.8-24.10-default (i386)
//
// This Bug is a little bit different in relation to bug #20184
//
// If this littel programm is compiled with the option -O2
// the assignment in the inline function was wrong.
// If I remove the 'inline' of any of both functions the result is correct.
//
// Compiled with: gcc -Wall error.cpp
//  -> OK, last line of printout: 0001
//
// Compiled with: gcc -Wall -O2 error.cpp
//  -> ERROR, last line of printout: 080482c50001
//
// Compiled with: gcc -Wall -O2 error.cpp
//  but without 'inline' for GenData() and/or GetData()
//  -> OK, last line of printout: 0001
//

#include 
#include 

typedef unsigned int uint32;
typedef unsigned long long uint64;

struct data
{
uint32 lo;
uint32 hi;
};

inline struct data * GenData ( struct data * d, uint32 num )
{
d->lo = num; d->hi = -(num<0);
return d;
}

inline uint64 GetData ( const struct data * d )
{
return *(uint64*)&d->lo;
}

int main ( int argc, char ** argv )
{ 
printf("sizeof(uint32)=%d\n",sizeof(uint32));
printf("sizeof(uint64)=%d\n",sizeof(uint64));
printf("sizeof(data)=  %d\n",sizeof(struct data));

uint32 tab[] = { 1,1,1,1,1 };
uint32 *p = tab;

struct data D;
printf("D=%p lo=%p hi=%p\n",&D,&D.lo,&D.hi);

uint64 u64 = GetData(GenData(&D,*p++));
printf("%016llx\n",u64);

return 0;
}

-- 
   Summary: assignment error in inline function
   Product: gcc
   Version: 3.3.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dirk at cle-mens dot de
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/20185] assignment error in inline function

[dirk at cle-mens dot de]

--- Additional Comments From dirk at cle-mens dot de  2005-02-24 13:56 
---
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
>
> You are accessing an object of type "class data" through an lvalue of type
> "uint64". The type "uint64" here matches none of the mentioned cases; 

But if you take this line:
 inline data::operator uint64 () const 
{ return *(uint64*)&lo; }
... we have no class data.

And please see bug #20189: same error with a C example.

---
Another question again: I marked this bug 'reopen' while I'm posting this. Is
this the
correct way?


-- 
   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug libgcj/20160] [4.0 Regression] link errors building libgcj tests

[rearnsha at gcc dot gnu dot org]

-- 
   What|Removed |Added

 CC||rth at gcc dot gnu dot org
   Target Milestone|--- |4.0.0


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

[Bug middle-end/18902] Naive (default) complex division algorithm

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |4.0.0


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

[Bug bootstrap/20143] 4.0 bootstrap unreasonably requires 64-bit target type mode support.

[ericw at evcohs dot com]

--- Additional Comments From ericw at evcohs dot com  2005-02-24 14:04 
---
Subject: Re:  4.0 bootstrap unreasonably requires 64-bit
 target type mode support.

schlie at comcast dot net wrote:

>--- Additional Comments From schlie at comcast dot net  2005-02-24 02:49 
>---
>Subject: Re:  4.0 bootstrap unreasonably requires
> 64-bit target type mode support.
>
>  
>
>>Please explain why you think it is a bug for the avr to support long long.
>>Your description sounds like an opinion.
>>
>>The pointer size on the AVR is currently 16 bits. This will change in the
>>near future to either 24 bits or 32 bits.
>>
>>
>
>Simply because no data type size support should be required beyond that
>reasonably required by the source language itself.
>  
>
This is not an explanation; you are simply restating what you said earlier.

>Please note that enabling the compiler to build with limited but perfectly
>reasonable 32-bit maxim data types, does not prohibit the it's ability to
>support significantly larger data types if desired for whatever reason; so
>nor should the desire to restrict data type size support be inhibited.)
>  
>
If you experiment with the code, then you need to be prepared to 
unforseen limits.

>As an aside, please don't confuse support of > 64KB FLASH program memory on
>larger AVR's, with the architecture's inherent 16-bit data pointer / 64KB
>data address space, as the two are orthogonal.  Atmel has already clearly
>positioned ARM to pick up where the AVR architecture leaves off; so although
>we may likely see 256KB program + 8KB-32KB data memory versions forthcoming,
>that's likely about it; as avr's target market has no corresponding need of
>significantly more, not to mention it would bring the avr (an 8-bit machine)
>needlessly to it's knees attempting to shuffle extended pointers around,
>which wouldn't be too clever even if Atmel were to facilitate them; hence
>Atmel's, and others, positioning of ARM and similar 16/32 based embedded
>controllers. (Atmel understands what the avr is/isn't, to their credit.)
>
>  
>
And a GCC bug report is not the place to get into a philosophical 
argument concerning Atmel's marketing practices. Please choose a more 
appropriate place to expound upon things unrelated to a GCC bug.

You filed this "bug report" because you experimented and changed 
*working code* in CVS. The answer is "don't do that then". The change 
you made was not approved by either of the AVR maintainers and you ran 
into a limitation of the DWARF2 debugging format.

I don't see how this is valid bug. The bug is in *your* changes, not in 
the FSF tree. GCC Bugzilla is a place for bugs in working FSF releases 
or for future extensions that are currently be worked on. AFAIK, there 
are no current plans to change long long to 32 bits. Feel free to 
contact either of the AVR maintainers, Denis Chertykov or Marek 
Michalkiewicz about this. But as this stands, this not a bug.





-- 


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

[Bug c/20189] assignment error in inline function

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-24 
14:04 ---
Invalid you are violating C90/C99 aliasing rules.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/20185] assignment error in inline function

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-24 
14:04 ---
Invalid you are violating C++98 aliasing rules.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug java/20190] New: [4.0 regression] 81 java regressions for arm-elf, undefined references

[hp at gcc dot gnu dot org]

Using Geoff Keatings contrib/regression/btest-gcc.sh, I notice regression in
the test-results, all in the libjava test-suite.  These tests passed with
LAST_UPDATED: "Sat Feb 12 07:27:15 UTC 2005"
and fail with LAST_UPDATED: "Wed Feb 23 22:28:12 UTC 2005":
+libjava.sum ArrayClass
+libjava.sum AssertBug
+libjava.sum Case
+libjava.sum G19990210_1
+libjava.sum G19990210_2
+libjava.sum G19990210_3
+libjava.sum G19990217_01
+libjava.sum G19990225_01
+libjava.sum InnerExcept
+libjava.sum N19990310_01
+libjava.sum N19990317
+libjava.sum OperatorBenchmark
+libjava.sum PR12374
+libjava.sum PR12857
+libjava.sum PR13024
+libjava.sum PR13237
+libjava.sum PR1343
+libjava.sum PR15769
+libjava.sum PR16249
+libjava.sum PR16675
+libjava.sum PR16701
+libjava.sum PR19295
+libjava.sum PR206
+libjava.sum PR209
+libjava.sum PR232
+libjava.sum PR232B
+libjava.sum PR234
+libjava.sum PR235
+libjava.sum PR295
+libjava.sum PR374
+libjava.sum PR375
+libjava.sum PR5902
+libjava.sum PR5913
+libjava.sum PR6026
+libjava.sum Semi
+libjava.sum Statics
+libjava.sum SuperConstr
+libjava.sum SyncTest
+libjava.sum T20020529
+libjava.sum T20020604
+libjava.sum TLtest
+libjava.sum TestEarlyGC
+libjava.sum TestLeak
+libjava.sum TestMultiple
+libjava.sum TestParent
+libjava.sum Thread_Alive
+libjava.sum Thread_Interrupt
+libjava.sum Thread_Join
+libjava.sum Thread_Monitor
+libjava.sum Thread_Sleep
+libjava.sum Thread_Wait
+libjava.sum Thread_Wait_2
+libjava.sum Thread_Wait_Interrupt
+libjava.sum Twice
+libjava.sum XercesBug
+libjava.sum assignment
+libjava.sum assignment_2
+libjava.sum comment
+libjava.sum final_initialization_in_ctor
+libjava.sum final_local_switch
+libjava.sum iface
+libjava.sum inner_data
+libjava.sum inner_inherit
+libjava.sum inner_priv
+libjava.sum inner_pub
+libjava.sum linking
+libjava.sum narrow_case
+libjava.sum perc
+libjava.sum plusplus
+libjava.sum pr10459
+libjava.sum pr172
+libjava.sum pr17329
+libjava.sum pr174
+libjava.sum pr17500
+libjava.sum pr176
+libjava.sum pr7912
+libjava.sum pr8712
+libjava.sum pr8955
+libjava.sum static_init2
+libjava.sum static_inner
+libjava.sum zeroexp

The failures look like this:
Executing on host:
/home/hp/cvs_areas/combined/arm-regobj/arm-unknown-elf/libjava/testsuite/../libtool
--silent --tag=GCJ --mode=\
link /home/hp/cvs_areas/combined/arm-regobj/gcc/gcj
-B/home/hp/cvs_areas/combined/arm-regobj/gcc/ -nostdinc -B/home/hp/cvs_areas/\
combined/arm-regobj/arm-unknown-elf/newlib/ -isystem
/home/hp/cvs_areas/combined/arm-regobj/arm-unknown-elf/newlib/targ-include -\
isystem /home/hp/cvs_areas/combined/combined/newlib/libc/include
-B/tmp/reg-arm/arm-unknown-elf/bin/ -B/tmp/reg-arm/arm-unknown-e\
lf/lib/ -isystem /tmp/reg-arm/arm-unknown-elf/include -isystem
/tmp/reg-arm/arm-unknown-elf/sys-include -L/home/hp/cvs_areas/comb\
ined/arm-regobj/ld --encoding=UTF-8
-B/home/hp/cvs_areas/combined/arm-regobj/arm-unknown-elf/libjava/testsuite/../
/home/hp/cvs_a\
reas/combined/combined/libjava/testsuite/libjava.compile/ArrayClass.java  
-no-install --main=ArrayClass-L/home/hp/cvs_areas/\
combined/arm-regobj/ld  -g 
-L/home/hp/cvs_areas/combined/arm-regobj/arm-unknown-elf/libjava/testsuite/../../libjava/.libs
-lm   \
-o
/home/hp/cvs_areas/combined/arm-regobj/arm-unknown-elf/libjava/testsuite/ArrayClass.exe
   
(timeout = 300)
/home/hp/cvs_areas/combined/arm-regobj/arm-unknown-elf/libjava/testsuite/../../libjava/.libs/libgcj.a(jni.o):
In function `_Jv_JN\
I_GetAnyMethodID<0u>':^M
/home/hp/cvs_areas/combined/combined/libjava/jni.cc:730: undefined reference to
`java::lang::StringBuffer::StringBuffer(java::lan\
g::String*)'^M
/home/hp/cvs_areas/combined/combined/libjava/jni.cc:736: undefined reference to
`java::lang::StringBuffer::class$'^M
/home/hp/cvs_areas/combined/arm-regobj/arm-unknown-elf/libjava/testsuite/../../libjava/.libs/libgcj.a(jni.o):
In function `_Jv_JN\
I_GetAnyMethodID<1u>':^M
/home/hp/cvs_areas/combined/combined/libjava/jni.cc:730: undefined reference to
`java::lang::StringBuffer::StringBuffer(java::lan\
g::String*)'^M
/home/hp/cvs_areas/combined/combined/libjava/jni.cc:736: undefined reference to
`java::lang::StringBuffer::class$'^M
/home/hp/cvs_areas/combined/arm-regobj/arm-unknown-elf/libjava/testsuite/../../libjava/.libs/libgcj.a(link.o):
In function `_Jv_L\
inker::find_field(java::lang::Class*, java::lang::Class*, _Jv_Utf8Const*,
_Jv_Utf8Const*)':^M
/home/hp/cvs_areas/combined/combined/libjava/link.cc:178: undefined reference to
`java::lang::StringBuffer::StringBuffer()'^M
/home/hp/cvs_areas/combined/combined/libjava/link.cc:202: undefined reference to
`java::lang::StringBuffer::StringBuffer()'^M
/home/hp/cvs_areas/combined/combined/libjava/link.cc:197: undefined reference to
`java::lang::StringBuffer::class$'^M
/home/hp/cvs_areas/combined/arm-regobj/arm-unknown-elf/libjava/testsuite/../../libjava/.libs/libgcj.a(link.o):
In function `_Jv_L\
inker::search_method_in_class(java::lang::Class*, java::lang::Class*,
_Jv_Utf8Const*, _Jv_Utf8Const*)':^M
...
FAIL: ArrayClass compilation

[Bug java/20190] [4.0 regression] 81 java regressions for arm-elf, undefined references

[rearnsha at gcc dot gnu dot org]

--- Additional Comments From rearnsha at gcc dot gnu dot org  2005-02-24 
14:11 ---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug libgcj/20160] [4.0 Regression] link errors building libgcj tests

[rearnsha at gcc dot gnu dot org]

--- Additional Comments From rearnsha at gcc dot gnu dot org  2005-02-24 
14:12 ---
*** Bug 20190 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||hp at gcc dot gnu dot org


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

[Bug c++/17972] [3.4 Regression] const/pure functions result in bad asm

[mostrows at watson dot ibm dot com]

--- Additional Comments From mostrows at watson dot ibm dot com  2005-02-24 
14:18 ---
New test case exhibits same problem.

struct demo {
int s;
};

extern struct demo * const *xd;

static inline struct demo *fn1(void) __attribute__((pure));
static inline struct demo *fn1(void)
{
struct demo {
int s;
};

extern struct demo * const *xd;

static inline struct demo *fn1(void) __attribute__((pure));
static inline struct demo *fn1(void)
{
struct demo **d;
return *xd;
}


unsigned long foo() {
unsigned long old = 0;
old = (fn1()->s) & (((1UL << (8))-1) << 0);
(fn1()->s) -= old;
return old;
}

Here's how the generated code looks like, note the branch to self.

[EMAIL PROTECTED]:/tmp$ /opt/crosstool/bin/powerpc64-linux-gcc -x c++ -O -c 
/tmp/bug.C -S -o -
.file   "bug.C"
.section".text"
.align 2
.globl _Z3foov
.section".opd","aw"
.align 3
_Z3foov:
.quad   ._Z3foov,[EMAIL PROTECTED],0
.previous
.size   _Z3foov,24
.type   ._Z3foov,@function
.globl  ._Z3foov
._Z3foov:
.LFB3:
.L3:
b .L3
.long 0
.byte 0,9,0,0,0,0,0,0
.LFE3:
.size   ._Z3foov,.-._Z3foov
.section.note.GNU-stack,"",@progbits
.ident  "GCC: (GNU) 3.4.4 20050211 (prerelease)"

Specifying language as "C" instead of C++ results in correct code generation.

-- 
   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug c++/20185] assignment error in inline function

[falk at debian dot org]

--- Additional Comments From falk at debian dot org  2005-02-24 14:21 
---
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > (In reply to comment #1)
> >
> > You are accessing an object of type "class data" through an lvalue of type
> > "uint64". The type "uint64" here matches none of the mentioned cases; 
> 
> But if you take this line:
>  inline data::operator uint64 () const 
> { return *(uint64*)&lo; }
> ... we have no class data.

But an object of type uint32 = unsigned int, for which the same holds.


-- 


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

[Bug bootstrap/20143] 4.0 bootstrap unreasonably requires 64-bit target type mode support.

[schlie at comcast dot net]

--- Additional Comments From schlie at comcast dot net  2005-02-24 14:22 
---
Subject: Re:  4.0 bootstrap unreasonably requires
 64-bit target type mode support.

>>> Comments From ericw at evcohs dot com  2005-02-24 14:04
>>> Please explain why you think it is a bug for the avr to support long long.

- I'll try to type it slower, but don't think it would help; what's being
  asserted is that the support of 64-bit long long should not be required to
  build the compiler. (Any particular reason you believe it should be?)

> This is not an explanation; you are simply restating what you said earlier.
> ...

- Maybe if you read it a over few times it may hopefully become apparent?
  (sorry, I don't know how to state it any clearer or simpler than I have)





-- 


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

[Bug c++/20157] [4.0 Regression] Internal compiler error on invalid code

[sstrasser at systemhaus-gruppe dot de]

--- Additional Comments From sstrasser at systemhaus-gruppe dot de  
2005-02-24 14:24 ---
(In reply to comment #2) 
 
I think it is a minor regression. 
3.3/3.4 treats the code correctly if the specialization(unlike above) is a 
definition. 4.0 does not.  
 
no regression with exactly this testcase though. 

-- 


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

[Bug c++/20157] [4.0 Regression] Internal compiler error on invalid code

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-24 
14:28 ---
(In reply to comment #3)
> (In reply to comment #2) 
And any ICE is a regression even if it was changed from accepts invalid code.  
There was a discussion 
about this before already.

-- 


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

[Bug other/20188] glibc-2.3.4 misscompilation.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-24 
14:30 ---
We really need a testcase.

-- 


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

[Bug bootstrap/20143] 4.0 bootstrap unreasonably requires 64-bit target type mode support.

[ericw at evcohs dot com]

--- Additional Comments From ericw at evcohs dot com  2005-02-24 14:31 
---
Subject: Re:  4.0 bootstrap unreasonably requires 64-bit
 target type mode support.

schlie at comcast dot net wrote:

>--- Additional Comments From schlie at comcast dot net  2005-02-24 14:22 
>---
>Subject: Re:  4.0 bootstrap unreasonably requires
> 64-bit target type mode support.
>
>  
>
Comments From ericw at evcohs dot com  2005-02-24 14:04
Please explain why you think it is a bug for the avr to support long long.


>
>- I'll try to type it slower, but don't think it would help; what's being
>  asserted is that the support of 64-bit long long should not be required to
>  build the compiler. (Any particular reason you believe it should be?)
>  
>
The code in CVS works. Your personal change did not. You need to explain 
why you think your personal change, to not support 64-bit long long, 
should be the new default for the avr port. And you need to explain it 
on the gcc mailing list, not in the context of a GCC bug report that 
describes a bug in your personal experimental changes. And as a courtesy 
you should CC the AVR maintainers.

Again, you're just restating what you've said earlier without giving a 
reason.


-- 


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

[Bug bootstrap/20143] 4.0 bootstrap unreasonably requires 64-bit target type mode support.

[schlie at comcast dot net]

--- Additional Comments From schlie at comcast dot net  2005-02-24 14:32 
---
Subject: Re:  4.0 bootstrap unreasonably requires
 64-bit target type mode support.


> --- Additional Comments From schlie at comcast dot net  2005-02-24 14:22
> Subject: Re:  4.0 bootstrap unreasonably requires
>  64-bit target type mode support.
> 
 Comments From ericw at evcohs dot com  2005-02-24 14:04
 Please explain why you think it is a bug for the avr to support long long.
> 
> - I'll try to type it slower, but don't think it would help; what's being
>   asserted is that the support of 64-bit long long should not be required to
>   build the compiler. (Any particular reason you believe it should be?)
> 
>> This is not an explanation; you are simply restating what you said earlier.
>> ...
> 
> - Maybe if you read it a over few times it may hopefully become apparent?
>   (sorry, I don't know how to state it any clearer or simpler than I have)

Maybe I can be clearer, I am not stating that the avr port should not
support 64-bit long long; just asserting that any port should not require
64-bit integers to be able to build the compiler, if the language it's
being built to support does not correspondingly require it.

(the avr port was simply used as an example demonstration of the problem)




-- 


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

[Bug rtl-optimization/20182] Improper code generation causes stack corruption

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |3.3


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

[Bug libfortran/19678] DOS files don't work for list directed input

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Keywords||patch


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

[Bug objc/20191] New: ICE in reload_cse_simplify_operands, on powerpc linux

[stephane dot goujet at kat dot fi]

Here is the output of gcc when compiling NSTextView.m :


Reading specs from /usr/local/lib/gcc/powerpc-unknown-linux-gnu/3.4.4/specs
Configured with: ../gcc-3.4-20050218/configure --enable-threads --enable-
altivec --enable-languages=c,objc
Thread model: posix
gcc version 3.4.4 20050218 (prerelease)
 /usr/local/libexec/gcc/powerpc-unknown-linux-gnu/3.4.4/cc1obj -E -quiet -v -
I ../Headers/ -I /usr/GNUstep/System/Library/Headers/ -D__unix__ -
D__gnu_linux__ -D__linux__ -Dunix -D__unix -Dlinux -D__linux -Asystem=linux -
Asystem=unix -Asystem=posix NSTextView.m -fconstant-string-
class=NSConstantString -O2 -o NSTextView.mi
ignoring nonexistent directory "NONE/include"
ignoring nonexistent directory "/usr/local/lib/gcc/powerpc-unknown-linux-
gnu/3.4.4/../../../../powerpc-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 ../Headers/
 /usr/GNUstep/System/Library/Headers/
 /usr/local/include
 /usr/local/lib/gcc/powerpc-unknown-linux-gnu/3.4.4/include
 /usr/include
End of search list.
 /usr/local/libexec/gcc/powerpc-unknown-linux-gnu/3.4.4/cc1obj -fpreprocessed 
NSTextView.mi -quiet -dumpbase NSTextView.m -auxbase NSTextView -O2 -version -
fconstant-string-class=NSConstantString -o NSTextView.s
GNU Objective-C version 3.4.4 20050218 (prerelease) (powerpc-unknown-linux-gnu)
compiled by GNU C version 4.0.0 20050213 (experimental).
GGC heuristics: --param ggc-min-expand=51 --param ggc-min-heapsize=39686
NSTextView.m: In function `-[NSTextView(GSTextView) sync::updateState:]':
NSTextView.m:371: warning: `NSTextView' may not respond to `-
_updateInputMethodState'
NSTextView.m:371: warning: (Messages without a matching method signature
NSTextView.m:371: warning: will be assumed to return `id' and accept
NSTextView.m:371: warning: `...' as arguments.)
NSTextView.m: At top level:
NSTextView.m:2341: warning: incomplete implementation of class `NSTextView'
NSTextView.m:2341: warning: method definition for `-selectedRange' not found
NSTextView.m:2341: warning: class `NSTextView' does not fully implement the 
`NSTextInput' protocol
NSTextView.m: In function `-[NSTextView setConstrainedFrameSize:]':
NSTextView.m:1574: error: insn does not satisfy its constraints:
(insn:HI 144 139 140 14 (set (reg:SF 66 ctr [orig:164 
._maxSize.width ] [164])
(reg:SF 66 ctr [162])) 252 {*movsf_hardfloat} (nil)
(nil))
NSTextView.m:1574: internal compiler error: in reload_cse_simplify_operands, 
at postreload.c:391
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

-- 
   Summary: ICE  in reload_cse_simplify_operands, on powerpc linux
   Product: gcc
   Version: 3.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: objc
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stephane dot goujet at kat dot fi
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: powerpc-unknown-linux-gnu
  GCC host triplet: powerpc-unknown-linux-gnu
GCC target triplet: powerpc-unknown-linux-gnu


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

[Bug objc/20191] ICE in reload_cse_simplify_operands, on powerpc linux

[stephane dot goujet at kat dot fi]

--- Additional Comments From stephane dot goujet at kat dot fi  2005-02-24 
14:51 ---
Created an attachment (id=8270)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8270&action=view)
preprocessed objective-c file


-- 


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

[Bug target/20191] ICE in reload_cse_simplify_operands, on powerpc linux

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-24 
15:01 ---
Hmm,
(insn:HI 144 139 140 14 (set (reg:SF 66 ctr [orig:164 
._maxSize.width ] [164])
(reg:SF 66 ctr [162])) 252 {*movsf_hardfloat} (nil)
(nil))

This looks like either a target problem or a reload problem.  The reason why it 
is hard to reduce is 
because you need the right situation to reproduce this bug, mainly using the 
ctr register for floating 
point which really does not work.

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
  Component|objc|target
   Keywords||ice-on-valid-code


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

gcc-bugs@gcc.gnu.org

[falk at debian dot org]

This function:

#define PMD_MASK(~((1UL << 23) - 1))
void clear_pmd_range(unsigned long start, unsigned long end) 
{ 
if (!(start & ~PMD_MASK) && !(end & ~PMD_MASK)) 
f(); 
} 

should be optimized to generate the same code as this function:
 
void clear_pmd_range2(unsigned long start, unsigned long end) 
{ 
if (!((start | end) & ~PMD_MASK)) 
f(); 
} 

that is, use only one conditional branch (see also
http://linux.bkbits.net:8080/linux-2.5/[EMAIL PROTECTED]|[EMAIL PROTECTED]).

-- 
   Summary: Unnecessary jump from &&
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: falk at debian dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug libgcj/20193] New: Variable names incorrectly resolved in inner classes.

[thhal at mailblocks dot com]

An inner class that references a static variable in an outer class will fail if
the super class of that outer class defines the same variable with a visibility
that makes it inaccessible to the inner class.

-- 
   Summary: Variable names incorrectly resolved in inner classes.
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: thhal at mailblocks dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org


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

[Bug libgcj/20193] Variable names incorrectly resolved in inner classes.

[thhal at mailblocks dot com]

--- Additional Comments From thhal at mailblocks dot com  2005-02-24 15:16 
---
Created an attachment (id=8271)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8271&action=view)
Java class that illustrates the problem.

Try gcj -c ScopeProblem.java. It fails with:
ScopeProblem.java:12: error: Can't access package-private field ...


-- 


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

[Bug java/20193] Variable names incorrectly resolved in inner classes.

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|libgcj  |java
   Keywords||rejects-valid


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

[Bug c/20194] New: gcc-4.0.0 20050220 miscompiles Linux/ppc32 kernel at -O1 and -O2

[mikpe at csd dot uu dot se]

/* gcc4bug.c
 * Written by Mikael Pettersson <[EMAIL PROTECTED]>, 2005-02-24.
 *
 * This program is abstracted from arch/ppc/mm/init.c in
 * the 2.6.11-rc4 Linux kernel sources.
 *
 * With gcc-3.4.3, gcc-3.3.5, or gcc-3.2.3, mem_init()
 * correctly returns 245.
 *
 * With gcc-4.0.0 20050220, mem_init() erroneously returns 0.
 * The error occurs with -O1, and -O2.
 * Compiling at -O0, or -O3 or higher, hides the error.
 *
 * All gcc versions were configured for powerpc-unknown-linux-gnu.
 */
#include 

#define PAGE_SIZE 4096
unsigned long PAGE_OFFSET;
unsigned long high_memory;
unsigned long etext;
unsigned long init_begin;
unsigned long init_end;
unsigned long klimit;

int mem_init(void)
{
unsigned long addr;
int codepages = 0;
int datapages = 0;
int initpages = 0;

for (addr = PAGE_OFFSET; addr < high_memory; addr += PAGE_SIZE) {
if (addr < etext)
codepages++;
else if (addr >= init_begin && addr < init_end)
initpages++;
else if (addr < klimit)
datapages++;
}
printf("datapages == %d, initpages == %d, codepages == %d\n", datapages,
initpages, codepages);
return datapages;
}

int main(void)
{
int datapages;

PAGE_OFFSET = 0xc000;
etext   = 0xc01bb958;
init_begin  = 0xc0264000;
init_end= 0xc0288000;
klimit  = 0xc02d4378;
high_memory = 0xd000;
datapages = mem_init();
if (datapages != 245) {
fprintf(stderr, "gcc bug! mem_init() returned %d\n", datapages);
return 1;
} else
return 0;
}

-- 
   Summary: gcc-4.0.0 20050220 miscompiles Linux/ppc32 kernel at -O1
and -O2
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikpe at csd dot uu dot se
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: powerpc-unknown-linux-gnu
  GCC host triplet: powerpc-unknown-linux-gnu
GCC target triplet: powerpc-unknown-linux-gnu


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

[Bug middle-end/19410] Overlapping memcpy with big struct copies (ACATS c64106a)

[bosch at gcc dot gnu dot org]

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ebotcazou at libertysurf dot
   |dot org |fr
 Status|NEW |ASSIGNED


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

[Bug bootstrap/20143] 4.0 bootstrap unreasonably requires 64-bit target type mode support.

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2005-02-24 
15:46 ---
Can't you work around this by disabling dwarf2 support?

-- 


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

[Bug target/20191] ICE in reload_cse_simplify_operands, on powerpc linux

[dje at gcc dot gnu dot org]

-- 
   What|Removed |Added

 CC||dje at gcc dot gnu dot org


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

[Bug c++/20195] New: Internal compiler error on legal code

[romein at astron dot nl]

g++4 yields an internal compiler error in do_nonmember_using_decl, at
cp/name-lookup.c:2074 when compiling:

namespace std
{
  template class complex;
  template complex<_Tp> conj(const complex<_Tp>&);
}

using std::conj;


Kinds Regards,  John Romein

---

dr. John W. Romein
Stichting ASTRON (Netherlands Foundation for Research in Astronomy)
Oude Hoogeveensedijk 4
7991 PD  Dwingeloo
The Netherlands

-- 
   Summary: Internal compiler error on legal code
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: romein at astron dot nl
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: x86_64-redhat-linux
  GCC host triplet: x86_64-redhat-linux
GCC target triplet: x86_64-redhat-linux


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

[Bug ada/19900] [4.0 Regression] ACATS c391002 c432002 ICE categorize_ctor_elements_1

[bosch at gcc dot gnu dot org]

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |kenner at vlsi1 dot ultra
   |dot org |dot nyu dot edu
 Status|NEW |ASSIGNED


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

[Bug target/20191] ICE in reload_cse_simplify_operands, on powerpc linux

[dje at gcc dot gnu dot org]

--- Additional Comments From dje at gcc dot gnu dot org  2005-02-24 15:51 
---
The 0->!h alternative should match.

Completely preventing SFmode from being placed in CTR can cause more problems,
but we can do a better job to avoid preferencing that class.  I would suggest
trying changing

"=!r,!r,m,f,f,m,!cl,!q,!r,!h,!r,!r"

to

"=!r,!r,m,f,f,m,!*cl,!*q,!r,!*h,!r,!r"

so that the register allocator does not use those special registers for
preferencing decisions.  See if that helps.

-- 


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

[Bug ada/20012] 'pragma Compile_Time_Warning' adds quotation marks to warning text

[bosch at gcc dot gnu dot org]

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |bosch at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-02-24 15:55:54
   date||


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

[Bug target/20196] New: Miscompilation of mem_init in 32-bit ppc linux kernel

[jakub at gcc dot gnu dot org]

/* Origin: Mikael Pettersson <[EMAIL PROTECTED]> and the Linux kernel.  */

extern void abort (void);
unsigned long a = 0xc000, b = 0xd000;
unsigned long c = 0xc01bb958, d = 0xc0264000;
unsigned long e = 0xc0288000, f = 0xc02d4378;

void
foo (int x, int y, int z)
{
  if (x != 245 || y != 36 || z != 444)
abort ();
}

int
main (void)
{
  unsigned long g;
  int h = 0, i = 0, j = 0;

  for (g = a; g < b; g += 0x1000)
if (g < c)
  h++;
else if (g >= d && g < e)
  j++;
else if (g < f)
  i++;
  foo (i, j, h);
  return 0;
}

is miscompiled on ppc at -O{1,2,3,s} -m32.  Works with -O0 or -m64 at any
optimization level.

-- 
   Summary: Miscompilation of mem_init in 32-bit ppc linux kernel
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: target
AssignedTo: jakub at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: powerpc64-redhat-linux


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

[Bug c++/17972] [3.4 Regression] const/pure functions result in bad asm

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-02-24 
15:59 ---
> New test case exhibits same problem.

Confirmed.  Reduced testcase:

struct demo {
int s;
};

extern struct demo * const *xd;

static inline struct demo *fn1(void) __attribute__((pure));
static inline struct demo *fn1(void)
{
struct demo **d;
return *xd;
}

unsigned long foo()
{
unsigned long old = 0;
fn1()->s -= 1;
return old;
}

The code is correct with an explicit decrement operator.


-- 


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

[Bug c++/20099] -pthreads should imply -fno-threadsafe-statics

[gniccolai at yahoo dot com]

--- Additional Comments From gniccolai at yahoo dot com  2005-02-24 16:04 
---
(In reply to comment #20)
> 

Sorry, the correct citation is:
 

"multithreading is defined by an application design that ALLOWS FOR concurrent
or simultaneous execution"


The rest is cited from Sergey P. Derevyago COMMENTING this sentence.

(I missed the "" in the first reading of his message). 

-- 


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

[Bug bootstrap/20143] 4.0 bootstrap unreasonably requires 64-bit target type mode support.

[schlie at comcast dot net]

--- Additional Comments From schlie at comcast dot net  2005-02-24 16:14 
---
Subject: Re:  4.0 bootstrap unreasonably requires
 64-bit target type mode support.

> Maybe I can be clearer, I am not stating that the avr port should not
> support 64-bit long long; just asserting that any port should not require
> 64-bit integers to be able to build the compiler, if the language it's
> being built to support does not correspondingly require it.
> 
> (the avr port was simply used as an example demonstration of the problem)

The further good news is that upon reviewing the DWARF2 spec in detail,
and GCC's implementation, it's clear that a 32-bit DWARF data structure
is sufficient to support any target with 32-bit or less data type sizes.

(which seems that it may be reasonably easy to support by declaring the
DWARF data structure size as a function of the size of target's the maxim
declared data type size; although possibly limited to a practical minimum
of 32-bits, which seems much more reasonable for smaller targets)

[ I'll try  a few experiments ]





-- 


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

[Bug other/19897] [treelang] External references don't work.

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-02-24 
16:14 ---
Subject: Bug 19897

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-02-24 16:14:20

Modified files:
gcc/testsuite/treelang: ChangeLog 
Added files:
gcc/testsuite/treelang/compile: exit.tree extref.tree 
function-1.tree syntax-1.tree 

Log message:
2005-02-24  James A. Morrison  <[EMAIL PROTECTED]>

PR other/19897
* compile/exit.tree, compile/extref.tree, compile/function-1.tree,
compile/syntax-1.tree: New tests.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/treelang/ChangeLog.diff?cvsroot=gcc&r1=1.6&r2=1.7
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/treelang/compile/exit.tree.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/treelang/compile/extref.tree.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/treelang/compile/function-1.tree.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/treelang/compile/syntax-1.tree.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug other/19897] [treelang] External references don't work.

[phython at gcc dot gnu dot org]

--- Additional Comments From phython at gcc dot gnu dot org  2005-02-24 
16:15 ---
Fixed

-- 
   What|Removed |Added

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


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

[Bug ada/20035] failed run-time assertion : Tasking not implemented on this configuration on sparc-linux

[bosch at gcc dot gnu dot org]

--- Additional Comments From bosch at gcc dot gnu dot org  2005-02-24 16:20 
---
No bug seems to be reported. As the message states, no tasking support is 
implemented for your 
configuration. Your attachment doesn't provide such support. If you want to add 
this, look at the sparc 
and linux system specific files in the gcc/ada directory. Any patch would also 
need changes to 
Makefile.in. A complete tested patch, following the GCC guidelines (see 
http://gcc.gnu.org/
contribute.html) may be submitted to [EMAIL PROTECTED] and will be considered 
for inclusion. 
You may post any questions that arise during development to [EMAIL PROTECTED] 
More specific 
questions tend to get better answers.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug bootstrap/20143] 4.0 bootstrap unreasonably requires 64-bit target type mode support.

[ericw at evcohs dot com]

--- Additional Comments From ericw at evcohs dot com  2005-02-24 16:21 
---
Subject: Re:  4.0 bootstrap unreasonably requires 64-bit
 target type mode support.

schlie at comcast dot net wrote:

>--- Additional Comments From schlie at comcast dot net  2005-02-24 16:14 
>---
>Subject: Re:  4.0 bootstrap unreasonably requires
> 64-bit target type mode support.
>
>  
>
>>Maybe I can be clearer, I am not stating that the avr port should not
>>support 64-bit long long; just asserting that any port should not require
>>64-bit integers to be able to build the compiler, if the language it's
>>being built to support does not correspondingly require it.
>>
>>(the avr port was simply used as an example demonstration of the problem)
>>
>>
>
>The further good news is that upon reviewing the DWARF2 spec in detail,
>and GCC's implementation, it's clear that a 32-bit DWARF data structure
>is sufficient to support any target with 32-bit or less data type sizes.
>
>(which seems that it may be reasonably easy to support by declaring the
>DWARF data structure size as a function of the size of target's the maxim
>declared data type size; although possibly limited to a practical minimum
>of 32-bits, which seems much more reasonable for smaller targets)
>
>[ I'll try  a few experiments ]
>
>
>
>  
>
Good.

Can somebody with sufficient permissions please close this non-bug?






-- 


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

[Bug other/19896] [treelang] Static variables don't work

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-02-24 
16:23 ---
Subject: Bug 19896

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-02-24 16:23:15

Modified files:
gcc/treelang   : ChangeLog treetree.c 

Log message:
2005-02-24  James A. Morrison  <[EMAIL PROTECTED]>

PR other/19896
* treetree.c (tree_code_create_variable): Initialize DECL_EXTERNAL,
TREE_PUBLIC, and TREE_STATIC for var_decl to zero.  Don't call
rest_of_decl_compilation on static variables.
(pushdecl): Put DECL_EXPRs into the current BIND_EXPR for automatic
variables.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/treelang/ChangeLog.diff?cvsroot=gcc&r1=1.106&r2=1.107
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/treelang/treetree.c.diff?cvsroot=gcc&r1=1.54&r2=1.55



-- 


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

[Bug other/19896] [treelang] Static variables don't work

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-02-24 
16:24 ---
Subject: Bug 19896

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-02-24 16:24:25

Modified files:
gcc/testsuite/treelang: ChangeLog 
Added files:
gcc/testsuite/treelang/execute: execute.exp funccall-2.tree 
funccall.tree initial.tree 
main.tree static.tree 

Log message:
2005-02-24  James A. Morrison  <[EMAIL PROTECTED]>

PR other/19896
* execute/execute.exp: New file.
* execute/funccall.tree, execute/funccall-2.tree, execute/initial.tree,
execute/main.tree, execute/static.tree: New tests.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/treelang/ChangeLog.diff?cvsroot=gcc&r1=1.7&r2=1.8
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/treelang/execute/execute.exp.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/treelang/execute/funccall-2.tree.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/treelang/execute/funccall.tree.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/treelang/execute/initial.tree.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/treelang/execute/main.tree.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/treelang/execute/static.tree.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug other/19896] [treelang] Static variables don't work

[phython at gcc dot gnu dot org]

--- Additional Comments From phython at gcc dot gnu dot org  2005-02-24 
16:24 ---
Fixed

-- 
   What|Removed |Added

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


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

[Bug libfortran/20124] gfortran prints -.01 incorrectly

[coudert at clipper dot ens dot fr]

--- Additional Comments From coudert at clipper dot ens dot fr  2005-02-24 
16:24 ---
$ cat pr20124.f 
  x = -.01
  y = .01
  write(*,'(2f10.2)') x, y
  print *, x, y
  end
$ ./bin/gfortran -static pr20124.f && ./a.out
  0.00  0.00
 -9.998E-03  9.998E-03

It looks like we're not handling the rounding correctly in this case (if you try
with x=-0.05, which can be represented in a real exactly, it doesn't happen).

-- 


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

[Bug ada/20042] [4.0 regression] ACATS cxaca01 assembler Bad Absolute Expression error on ppc-darwin

[bosch at gcc dot gnu dot org]

-- 
   What|Removed |Added

Summary|ACATS cxaca01 assembler Bad |[4.0 regression] ACATS
   |Absolute Expression error on|cxaca01 assembler Bad
   |ppc-darwin  |Absolute Expression error on
   ||ppc-darwin


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

[Bug ada/20042] [4.0 regression] ACATS cxaca01 assembler Bad Absolute Expression error on

[bosch at gcc dot gnu dot org]

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |bosch at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed||1
 GCC target triplet||powerpc-apple-darwin7.8.0
  Known to fail||4.0.0
  Known to work||3.4.4
   Last reconfirmed|-00-00 00:00:00 |2005-02-24 16:33:00
   date||
Summary|[4.0 regression] ACATS  |[4.0 regression] ACATS
   |cxaca01 assembler Bad   |cxaca01 assembler Bad
   |Absolute Expression error on|Absolute Expression error on
   |ppc-darwin  |


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

[Bug other/20197] New: [3.4.3] "input|gcc -S -save-temps ..." internal error

[cgweav at email dot com]

gcc internal error when passing "-save-temps" to gcc-3.4.3
with stdin as input to a "gcc -S ..." command
("script_output | gcc -S ... -save-temps ...").
Same input compiles fine without -save-temps.

platform:
gcc-3.4.3, glibc-2.3.3-200410112214, binutils-2.15.92.0.2,
linux-2.4.29, pIII/733. gcc compiled with
CFLAGS="-march=i686 -O2" ../gcc-3.4.3/configure ...".

gcc -v:

Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/specs
Configured with: ../gcc-3.4.3/configure --prefix=/usr \
--enable-shared --enable-threads=posix \
--enable-checking --enable-__cxa_atexit \
--enable-languages=c,c++ --disable-nls
Thread model: posix
gcc version 3.4.3

gcc error report:

gawk -f ../scripts/gen-as-const.awk 
../linuxthreads/sysdeps/i386/tcb-offsets.sym 
\
| gcc -S -o /scratch/glibc.build/tcb-offsets.hT3 -std=gnu99 -O2 -Wall -Winline -
Wstrict-prototypes -Wwrite-strings -fno-strict-aliasing -march=i686 -save-temps 
-v -mpreferred-stack-boundary=4 -I../include -I. -I/scratch/glibc.build/csu 
-I.. -I../libio  -I/scratch/glibc.build -I../sysdeps/i386/elf -I../libidn/
sysdeps/unix -I../linuxthreads/sysdeps/unix/sysv/linux/i386 -I../linuxthreads/
sysdeps/unix/sysv/linux -I../linuxthreads/sysdeps/pthread -I../sysdeps/pthread -
I../linuxthreads/sysdeps/unix/sysv -I../linuxthreads/sysdeps/unix -I../
linuxthreads/sysdeps/i386/i686 -I../linuxthreads/sysdeps/i386 -I../sysdeps/unix/
sysv/linux/i386/i686 -I../sysdeps/unix/sysv/linux/i386 -I../sysdeps/unix/sysv/
linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../
sysdeps/unix/inet -I../sysdeps/unix/sysv/i386/i686 -I../sysdeps/unix/sysv/i386 -
I../sysdeps/unix/sysv -I../sysdeps/unix/i386/i686 -I../sysdeps/unix/i386 -I../
sysdeps/unix -I../sysdeps/posix -I../sysdeps/i386/i686/fpu -I../sysdeps/i386/
i686 -I../sysdeps/i386/i486 -I../linuxthreads/sysdeps/i386/i486 -I../sysdeps/
i386/fpu -I../sysdeps/i386 -I../sysdeps/wordsize-32 
-I../sysdeps/ieee754/ldbl-96 
-I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 -I.
./sysdeps/generic/elf -I../sysdeps/generic  -D_LIBC_REENTRANT -include ../
include/libc-symbols.h   -DHAVE_INITFINI -x c - \
-MD -MP -MF /scratch/glibc.build/tcb-offsets.h.dT -MT 
'/scratch/glibc.build/
tcb-offsets.h.d /scratch/glibc.build/tcb-offsets.h'
Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/specs
Configured with: ../gcc-3.4.3/configure --prefix=/usr --enable-shared --enable-
threads=posix --enable-checking --enable-__cxa_atexit --enable-languages=c,c++ -
-disable-nls
Thread model: posix
gcc version 3.4.3
 /usr/libexec/gcc/i686-pc-linux-gnu/3.4.3/cc1 -E -quiet -v -I../include -I. -I/
scratch/glibc.build/csu -I.. -I../libio -I/scratch/glibc.build -I../sysdeps/
i386/elf -I../libidn/sysdeps/unix 
-I../linuxthreads/sysdeps/unix/sysv/linux/i386 
-I../linuxthreads/sysdeps/unix/sysv/linux -I../linuxthreads/sysdeps/pthread -I..
/sysdeps/pthread -I../linuxthreads/sysdeps/unix/sysv -I../linuxthreads/sysdeps/
unix -I../linuxthreads/sysdeps/i386/i686 -I../linuxthreads/sysdeps/i386 -I../
sysdeps/unix/sysv/linux/i386/i686 -I../sysdeps/unix/sysv/linux/i386 -I../
sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/
unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/sysv/i386/i686 -I../sysdeps/
unix/sysv/i386 -I../sysdeps/unix/sysv -I../sysdeps/unix/i386/i686 -I../sysdeps/
unix/i386 -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/i386/i686/fpu -I../
sysdeps/i386/i686 -I../sysdeps/i386/i486 -I../linuxthreads/sysdeps/i386/i486 -I.
./sysdeps/i386/fpu -I../sysdeps/i386 -I../sysdeps/wordsize-32 -I../sysdeps/
ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../
sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -MD /scratch/
glibc.build/tcb-offsets.d -MF /scratch/glibc.build/tcb-offsets.h.dT -MP -MT /
scratch/glibc.build/tcb-offsets.h.d /scratch/glibc.build/tcb-offsets.h -MQ /
scratch/glibc.build/tcb-offsets.hT3 -D_LIBC_REENTRANT -DHAVE_INITFINI -include .
./include/libc-symbols.h - -march=i686 -mpreferred-stack-boundary=4 -std=gnu99 -
Wall -Winline -Wstrict-prototypes -Wwrite-strings -fno-strict-aliasing -O2 -o -.
i
#include "..." search starts here:
#include <...> search starts here:
 ../include
 .
 /scratch/glibc.build/csu
 ..
 ../libio
 /scratch/glibc.build
 ../sysdeps/i386/elf
 ../libidn/sysdeps/unix
 ../linuxthreads/sysdeps/unix/sysv/linux/i386
 ../linuxthreads/sysdeps/unix/sysv/linux
 ../linuxthreads/sysdeps/pthread
 ../sysdeps/pthread
 ../linuxthreads/sysdeps/unix/sysv
 ../linuxthreads/sysdeps/unix
 ../linuxthreads/sysdeps/i386/i686
 ../linuxthreads/sysdeps/i386
 ../sysdeps/unix/sysv/linux/i386/i686
 ../sysdeps/unix/sysv/linux/i386
 ../sysdeps/unix/sysv/linux
 ../sysdeps/gnu
 ../sysdeps/unix/common
 ../sysdeps/unix/mman
 ../sysdeps/unix/inet
 ../sysdeps/unix/sysv/i386/i686
 ../sysdeps/unix/sysv/i386
 ../sysdeps/unix/sysv
 ../sysdeps/unix/i386/i686
 ../sysdeps/unix/i386
 ../sysdeps/unix
 ../sysdeps/posix
 ../sysdeps/i386/i686/fpu
 ../sysdeps/i

[Bug c++/17972] [3.4 Regression] const/pure functions result in bad asm

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-02-24 
16:49 ---
Hum... again a consequence of the C++ front-end not setting TREE_SIDE_EFFECTS on
every CALL_EXPR, like the C front-end.  The sequence of events is as follows:

1. fn1()->s -= 1 is expanded to the 3-operand form in build_modify_expr

{
  /* A binary op has been requested.  Combine the old LHS
 value with the RHS producing the value we should actually
 store into the LHS.  */

  my_friendly_assert (!PROMOTES_TO_AGGR_TYPE (lhstype, REFERENCE_TYPE),
  978652);
  lhs = stabilize_reference (lhs);
  newrhs = cp_build_binary_op (modifycode, lhs, rhs);
  if (newrhs == error_mark_node)
{
  error ("  in evaluation of `%Q(%#T, %#T)'", modifycode,
 TREE_TYPE (lhs), TREE_TYPE (rhs));
  return error_mark_node;
}
  
  /* Now it looks like a plain assignment.  */
  modifycode = NOP_EXPR;
}

Note the call to stabilize_reference.  However, it doesn't stabilize anything
here because the lhs is advertised as having no side-effects.

2. The tree-inliner inlines the call.  Since the same tree is referenced twice
in the expression, the inlined body is also referenced twice is the expression
and, therefore, expanded twice to RTL.  However labels are not expanded multiple
times but reused, so the second block of RTL ends up referencing the first and
all hell breaks loose.

At this point my conclusion is that the only safe approach is that of the C
front-end.

Mark, do you recall having reviewed the initial patch (see comment #22)?  What
do you think?  Thanks in advance.


-- 
   What|Removed |Added

 CC||mark at codesourcery dot com


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

[Bug target/20196] Miscompilation of mem_init in 32-bit ppc linux kernel

[jakub at gcc dot gnu dot org]

--- Additional Comments From jakub at gcc dot gnu dot org  2005-02-24 17:03 
---
The problem is that with the
http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00672.html
patch the earlyclobbers got lost.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-02-24 17:03:04
   date||


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

[Bug middle-end/19410] Overlapping memcpy with big struct copies (ACATS c64106a)

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-02-24 
17:06 ---
Note that I don't plan to work on this in the very near future, as the problem
is no breaking news and doesn't appear to cause much harm in practice.


-- 
   What|Removed |Added

 AssignedTo|ebotcazou at libertysurf dot|ebotcazou at gcc dot gnu dot
   |fr  |org
   Priority|P2  |P3


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

[Bug tree-optimization/17863] [4.0 Regression] threefold performance loss, not inlining as much

[rguenth at gcc dot gnu dot org]

--- Additional Comments From rguenth at gcc dot gnu dot org  2005-02-24 
17:09 ---
With __attribute__((leafify)) sticked to v4c_quad and mult_pq runtime goes down
from 16.0s to 4.4s with recent gcc 4.0.  For gcc 3.4.3 runtimes are 5.0s and 
4.9s.

We indeed do not very well on estimating the size of template metaprograms in 
4.0.

-- 


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

[Bug target/20196] [4.0 Regression] Miscompilation of mem_init in 32-bit ppc linux kernel

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Keywords||wrong-code
Summary|Miscompilation of mem_init  |[4.0 Regression]
   |in 32-bit ppc linux kernel  |Miscompilation of mem_init
   ||in 32-bit ppc linux kernel
   Target Milestone|--- |4.0.0


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

[Bug bootstrap/20143] 4.0 bootstrap unreasonably requires 64-bit target type mode support.

[schlie at comcast dot net]

--- Additional Comments From schlie at comcast dot net  2005-02-24 17:11 
---
Subject: Re:  4.0 bootstrap unreasonably requires
 64-bit target type mode support.

> From: ericw at evcohs dot com <[EMAIL PROTECTED]>
> Can somebody with sufficient permissions please close this non-bug?

I'm sorry, but have to ask: why are you so apparently negatively concerned
about the resolution of topic which would only provide the WINAVR product,
which you apparently have a vested interest in, and other small targets,
with increased build flexibility to seemingly everyone's benefit?

(I can only surmise you still don't understand this to be the case?)

How may I help clear up your confusion?





-- 


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

[Bug c/20194] gcc-4.0.0 20050220 miscompiles Linux/ppc32 kernel at -O1 and -O2

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-24 
17:11 ---
Even though this was filed earlier than this bug, I am closing this as a dup of 
bug 20196 because it has 
a shorter testcase and has identified the patch which caused it. 

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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/20196] [4.0 Regression] Miscompilation of mem_init in 32-bit ppc linux kernel

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-24 
17:11 ---
*** Bug 20194 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||mikpe at csd dot uu dot se


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

[Bug bootstrap/20143] 4.0 bootstrap unreasonably requires 64-bit target type mode support.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-24 
17:17 ---
Not a bug.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug bootstrap/20143] 4.0 bootstrap unreasonably requires 64-bit target type mode support.

[schlie at comcast dot net]

--- Additional Comments From schlie at comcast dot net  2005-02-24 17:25 
---
Subject: Re:  4.0 bootstrap unreasonably requires
 64-bit target type mode support.

> --- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-24
> Not a bug.
>What|Removed |Added
> 
>  Status|UNCONFIRMED |RESOLVED
>  Resolution||WONTFIX

Unfortunately understand the necessity to presently mark it as such.

And, sorry for the apparent confusion invoked by it's presence.





-- 


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

[Bug c++/20099] -pthreads should imply -fno-threadsafe-statics

[qrczak at knm dot org dot pl]

--- Additional Comments From qrczak at knm dot org dot pl  2005-02-24 17:31 
---
> "multithreading is defined by an application design that ALLOWS FOR concurrent
> or simultaneous execution"

Initializers of static locals cannot execute concurrently, no matter whether
they are automatically locked or not.

The only thing which would change when you remove the automatically inserted
locking is that some programs which used to work are now broken, and that some
other programs which used to deadlock now invoke undefined behavior from
entering an initializer recursively.

-- 


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

[Bug c++/20195] Internal compiler error on legal code

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-24 
17:36 ---
I cannot reproduce this with gcc "4.0.0 20050224"

-- 
   What|Removed |Added

   Severity|critical|normal
   Keywords||ice-on-valid-code


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

[Bug libfortran/20124] gfortran prints -.01 incorrectly

[coudert at clipper dot ens dot fr]

--- Additional Comments From coudert at clipper dot ens dot fr  2005-02-24 
17:38 ---
Patch proposed in http://gcc.gnu.org/ml/fortran/2005-02/msg00315.html

-- 


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

gcc-bugs@gcc.gnu.org

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-24 
17:49 ---
Confirmed.

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-02-24 17:49:00
   date||


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

[Bug target/20196] [4.0 Regression] Miscompilation of mem_init in 32-bit ppc linux kernel

[jakub at gcc dot gnu dot org]

--- Additional Comments From jakub at gcc dot gnu dot org  2005-02-24 17:54 
---
Patch here: 

-- 
   What|Removed |Added

   Keywords||patch


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

[Bug libgcj/20198] New: java.security.CodeSource.getLocation output is different than expected

[bkonrath at redhat dot com]

GCJ version:

% gij4 --version
gij (GNU libgcj) version 4.0.0 20050217 (Red Hat 4.0.0-0.27)

Test class:

public class Test {
public static void main(String[] args) {
System.out.println(Test.class.getProtectionDomain().
getCodeSource().getLocation());
}
}

With Sun VM 1.4.2_06 I get:

% j2sdk1.4.2_06/bin/java Test
file:/home/bkonrath/

With GCJ I get: 

% gij4 Test
file:./

I also noticed that the SUN vm returns a URL that has symlinks resolved. Let me
know if you need more info or if I should file this bug somewhere else.

-- 
   Summary: java.security.CodeSource.getLocation output is different
than expected
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bkonrath at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org


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