[Bug fortran/19352] Recursive IO functions are not allowed (F2003)

[Thomas dot Koenig at online dot de]

--- Additional Comments From Thomas dot Koenig at online dot de  2005-01-12 
08:19 ---
I think the error message can be improved.

Disallowing recursive I/O is not an "internal error".

What about "Calling I/O from function in I/O list not allowed" ?

-- 


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

[Bug target/19379] [4.0 Regression] ICE during build of newlib's e_atan2.c when soft-float

[rth at gcc dot gnu dot org]

-- 
   What|Removed |Added

 Status|ASSIGNED|WAITING


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

[Bug middle-end/18820] ACATS c95300[123] and c980002 fail at runtime

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-01-12 
09:12 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00522.html


-- 
   What|Removed |Added

   Keywords||patch


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

[Bug middle-end/19391] [4.0 Regression] missed optimization with size of 8 vectors

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2005-01-12 
09:23 ---
Is this a regression that may be caused by RTH's rewrite? 
 

-- 
   What|Removed |Added

 CC||rth at gcc dot gnu dot org


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

[Bug target/18562] SSE constant vector initialization produces dead constant values on stack

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2005-01-12 
09:24 ---
If this is closed, let's be sure to find that enhancement request and close 
this as a dup. 

-- 


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

[Bug rtl-optimization/10469] constant V4SF loads get moved inside loop

[rguenth at tat dot physik dot uni-tuebingen dot de]

--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen 
dot de  2005-01-12 09:35 ---
I guess we won't ever fix this for 3.3 and new-ra is dead, so this is "fixed".

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work|3.4.1   |3.4.1 3.4.3 4.0.0
 Resolution||FIXED


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

[Bug rtl-optimization/13246] [new-ra][meta-bug] new-ra related problems

[rguenth at tat dot physik dot uni-tuebingen dot de]

-- 
Bug 13246 depends on bug 10469, which changed state.

Bug 10469 Summary: constant V4SF loads get moved inside loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10469

   What|Old Value   |New Value

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

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

[Bug target/18562] SSE constant vector initialization produces dead constant values on stack

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2005-01-12 
09:37 ---
AMD64 has this at -O2: 
 
Test case 1: 
main: 
.LFB499: 
subq$24, %rsp 
.LCFI0: 
movl$.LC1, %edi 
movl$4, %eax 
movaps  .LC0(%rip), %xmm0 
movups  %xmm0, (%rsp) 
cvtss2sd12(%rsp), %xmm3 
cvtss2sd8(%rsp), %xmm2 
cvtss2sd4(%rsp), %xmm1 
cvtss2sd(%rsp), %xmm0 
callprintf 
xorl%eax, %eax 
addq$24, %rsp 
ret 
.LFE499: 
 
 
Test case 2: 
main: 
.LFB499: 
subq$40, %rsp 
.LCFI0: 
movl$.LC4, %edi 
movl$4, %eax 
movl$0x3fa6, 16(%rsp) 
movl$0x3fb3, 20(%rsp) 
movl$0x3fc0, 24(%rsp) 
movl$0x3fcd, 28(%rsp) 
movups  16(%rsp), %xmm0 
movups  %xmm0, (%rsp) 
cvtss2sd12(%rsp), %xmm3 
cvtss2sd8(%rsp), %xmm2 
cvtss2sd4(%rsp), %xmm1 
cvtss2sd(%rsp), %xmm0 
callprintf 
xorl%eax, %eax 
addq$40, %rsp 
ret 
 
 
 
With -m32 -march=pentium4 -mtune=prescott I get this: 
 
Test case 1: 
main: 
pushl   %ebp 
movl%esp, %ebp 
subl$56, %esp 
andl$-16, %esp 
subl$16, %esp 
movaps  .LC0, %xmm0 
movups  %xmm0, -16(%ebp) 
flds-4(%ebp) 
fstpl   28(%esp) 
flds-8(%ebp) 
fstpl   20(%esp) 
flds-12(%ebp) 
fstpl   12(%esp) 
flds-16(%ebp) 
fstpl   4(%esp) 
movl$.LC1, (%esp) 
callprintf 
xorl%eax, %eax 
leave 
ret 
 
Test case 2 (which is basically the same as Uros' code): 
main: 
pushl   %ebp 
movl%esp, %ebp 
subl$72, %esp 
andl$-16, %esp 
subl$16, %esp 
movl$0x3fa6, -16(%ebp) 
movl$0x3fb3, -12(%ebp) 
movl$0x3fc0, -8(%ebp) 
movl$0x3fcd, -4(%ebp) 
movups  -16(%ebp), %xmm0 
movups  %xmm0, -32(%ebp) 
flds-20(%ebp) 
fstpl   28(%esp) 
flds-24(%ebp) 
fstpl   20(%esp) 
flds-28(%ebp) 
fstpl   12(%esp) 
flds-32(%ebp) 
fstpl   4(%esp) 
movl$.LC4, (%esp) 
callprintf 
xorl%eax, %eax 
leave 
ret 
 

-- 


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

[Bug c++/10611] operations on vector mode not recognized in C++

[rguenth at tat dot physik dot uni-tuebingen dot de]

--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen 
dot de  2005-01-12 09:44 ---
What is the status on this issue?  I.e. +,-,*,/ on vector types for C++?  Note
that trying to work around this missing feature with operator overloading like

v4sf operator+(const v4sf& a, const v4sf& b)
{
return __builtin_ia32_addps(a, b);
}

(which would be again machine specific, but anyhow) doesn't work:

t.c:3: error: 'float __vector__ operator+(const float __vector__&, const float
__vector__&)' must have an argument of class or enumerated type.

-- 


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

[Bug middle-end/19391] [4.0 Regression] missed optimization with size of 8 vectors

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2005-01-12 09:54 
---
Try again with  functions.

It is absolutely ESSENTIAL that we do NOT emit mmx vector operations UNLESS
the  routines are used.  Doing so without the compiler also 
being able to insert emms instructions is wrong-code.

-- 


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

[Bug target/19392] New: [4.0 regression] mmix-knuth-mmixware testsuite failure: gcc.c-torture/execute/931004-11.c execution, -O0

[hp at gcc dot gnu dot org]

With LAST_UPDATED: "Wed Jan 12 02:41:59 UTC 2005" I get:
FAIL: gcc.c-torture/execute/931004-11.c execution,  -O0

With the message in the .log being:
*** EXIT code 4242
(a call to abort)

Last known to work with code from: "Tue Jan 11 08:13:03 UTC 2005".

-- 
   Summary: [4.0 regression] mmix-knuth-mmixware testsuite failure:
gcc.c-torture/execute/931004-11.c execution,  -O0
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: mmix-knuth-mmixware


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

[Bug target/19379] [4.0 Regression] ICE during build of newlib's e_atan2.c when soft-float

[corsepiu at gcc dot gnu dot org]

--- Additional Comments From corsepiu at gcc dot gnu dot org  2005-01-12 
10:30 ---
(In reply to comment #3)
> What do you want the ABI for soft-float to be?
> As RTEMS is probably the only user of -msoft-float, you get to choose.
-msoft-float basically is just a synomym for -no-80387 (-MASK_80387 in i386.h),
so there probably are more users.

> Do you want -msoft-float to imply -mno-fp-ret-in-387, do you want to supply
> it yourself, or do you want to admit that all shipping processors have an
> fpu and/or the os has an emulator?
Neither.

The actual problem is people using RTEMS on original i386dx's for whom previous
verions of gcc had required -mtune=i386 -mno-80387 -no-fp-ret-in-387 rsp.
-mcpu=i386 -msoft-float -no-fp-in-387.

For other cpus, coupling -msoft-float with -no-fp-in-387 has proven not to be
necessary.

This all is the reason for RTEMS gcc to use this kind of multilibs:
i386-rtems4.7-gcc --print-multi-lib
.;
m486;@mtune=i486
mpentium;@mtune=pentium
mpentiumpro;@mtune=pentiumpro
k6;@mtune=k6
athlon;@mtune=athlon
soft-float;@msoft-float
soft-float/nofp;@[EMAIL PROTECTED]
m486/soft-float;@[EMAIL PROTECTED]

-- 


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

[Bug bootstrap/19393] New: Assembler error: branch out of range

[corsepiu at gcc dot gnu dot org]

Building today's (2005-01-12) gcc-CVS/trunk for arm-rtems4.7 fails in libiberty:

/users/rtems/src/rpms/BUILD/rtems-4.7-arm-rtems4.7-gcc-newlib-gcc3.4.4newlib1.13.0/build/gcc/xgcc
-B/users/rtems/src/rpms/BUILD/rtems-4.7-arm-rtems4.7-gcc-newlib-gcc3.4.4newlib1.13.0/build/gcc/
-nostdinc
-B/users/rtems/src/rpms/BUILD/rtems-4.7-arm-rtems4.7-gcc-newlib-gcc3.4.4newlib1.13.0/build/arm-rtems4.7/newlib/
-isystem
/users/rtems/src/rpms/BUILD/rtems-4.7-arm-rtems4.7-gcc-newlib-gcc3.4.4newlib1.13.0/build/arm-rtems4.7/newlib/targ-include
-isystem
/users/rtems/src/rpms/BUILD/rtems-4.7-arm-rtems4.7-gcc-newlib-gcc3.4.4newlib1.13.0/gcc-3.4.4/newlib/libc/include
-B/opt/rtems-4.7/arm-rtems4.7/bin/ -B/opt/rtems-4.7/arm-rtems4.7/lib/ -isystem
/opt/rtems-4.7/arm-rtems4.7/include -isystem
/opt/rtems-4.7/arm-rtems4.7/sys-include -c -DHAVE_CONFIG_H -O2 -g -O2  -mthumb
-I. -I../../../../gcc-3.4.4/libiberty/../include  -W -Wall -Wtraditional
-pedantic ../../../../gcc-3.4.4/libiberty/regex.c -o regex.o
In file included from ../../../../gcc-3.4.4/libiberty/../include/xregex.h:26,
 from ../../../../gcc-3.4.4/libiberty/regex.c:195:
../../../../gcc-3.4.4/libiberty/../include/xregex2.h:548: warning: ISO C90 does
not support `static' or type qualifiers in parameter array declarators
../../../../gcc-3.4.4/libiberty/regex.c: In function `xregcomp':
../../../../gcc-3.4.4/libiberty/regex.c:8043: warning: signed and unsigned type
in conditional expression
../../../../gcc-3.4.4/libiberty/regex.c: At top level:
../../../../gcc-3.4.4/libiberty/regex.c:8178: warning: unused parameter 'preg'
/tmp/ccPZWeWX.s: Assembler messages:
/tmp/ccPZWeWX.s:3602: Error: branch out of range
make[3]: *** [regex.o] Error 1
make[3]: Leaving directory
`/users/rtems/src/rpms/BUILD/rtems-4.7-arm-rtems4.7-gcc-newlib-gcc3.4.4newlib1.13.0/build/arm-rtems4.7/thumb/libiberty'
make[2]: *** [multi-do] Error 1

-- 
   Summary: Assembler error: branch out of range
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: corsepiu at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,joel at oarcorp dot com
GCC target triplet: arm-rtems4.7


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

[Bug tree-optimization/19341] [4.0 Regression] DCE eliminating non-dead code

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2005-01-12 
10:37 ---
Is an asm a pointer escape point even if it does not have a memory clobber 
constraint? 
 
 
 

-- 


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

[Bug bootstrap/19393] Assembler error: branch out of range

[corsepiu at gcc dot gnu dot org]

--- Additional Comments From corsepiu at gcc dot gnu dot org  2005-01-12 
10:38 ---
Sorry, this is gcc-3.4-branch, not gcc-4.0.x ...


-- 
   What|Removed |Added

Version|4.0.0   |3.4.4


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

[Bug ada/17307] Bug box in Gigi, code=116, 'Unrestricted_Access of a protected subprogram

[charlet at adacore dot com]

--- Additional Comments From charlet at adacore dot com  2005-01-12 10:41 
---
Subject: Re:  Bug box in Gigi, code=116, 'Unrestricted_Access of a protected 
subprogram

> Hmm, now I get on the mainline:
> test_269775.adb:18:23: non-local pointer cannot point to local object
> So this rejects valid now?

Not really, since 'Unrestricted_Access is a GNAT specific attribute,
we can give it any semantic we like.

In this particular case, I do not think we want nor claim to support
access to nested protected procedure.

Instead, the code should be fixed to be valid Ada 95 and use 'Access
on a protected object declared at library level (= in a package).

Arno


-- 


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

[Bug middle-end/19304] [4.0 Regression] wrong code for spec test from emit_move_change_mode

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2005-01-12 
10:41 ---
Janis, why don't you post the patch to gcc-patches? 

-- 


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

[Bug c++/19377] Using declaration in "private" part causes "protected" diagnostic

[lerdsuwa at gcc dot gnu dot org]

--- Additional Comments From lerdsuwa at gcc dot gnu dot org  2005-01-12 
10:46 ---
The bug is simply incorrect error message logic.
The 'protected' comes from the point that 'A::i' is
declared, not the actual access computed.

-- 


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

[Bug rtl-optimization/15139] [3.4 Regression] cc1 uses excessive amounts of memory compiling small routine

[jakub at gcc dot gnu dot org]

--- Additional Comments From jakub at gcc dot gnu dot org  2005-01-12 10:47 
---
Patch here: 

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Keywords||patch
   Last reconfirmed|2004-06-22 17:38:00 |2005-01-12 10:47:27
   date||


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

[Bug c++/19311] [3.4/4.0 Regression] ICE in resolve_overloaded_unification

[lerdsuwa at gcc dot gnu dot org]

--- Additional Comments From lerdsuwa at gcc dot gnu dot org  2005-01-12 
10:49 ---
Patch in progress.

-- 


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

[Bug c++/16617] Fail to do access checking correctly for non-dependent qualified-id

[lerdsuwa at gcc dot gnu dot org]

--- Additional Comments From lerdsuwa at gcc dot gnu dot org  2005-01-12 
10:50 ---
May be fixed together with PR19311.

-- 


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

[Bug target/18562] SSE constant vector initialization produces dead constant values on stack

[uros at kss-loka dot si]

--- Additional Comments From uros at kss-loka dot si  2005-01-12 10:54 
---
Another testcase that I think should be optimized:
#include 

__m128 test() {
float val1[4] = {0.0f, 0.0f, 0.0f, 0.0f};

return _mm_loadu_ps(val1);
}

This is currently compiled to:
test:
pushl  %ebp
movl   $0x, %eax
movl   %esp, %ebp
subl   $16, %esp
movl   %eax, -16(%ebp)
movl   %eax, -12(%ebp)
movl   %eax, -8(%ebp)
movl   %eax, -4(%ebp)
movups -16(%ebp), %xmm0
leave
ret

But I think gcc it should produce something like:
test:
pushl  %ebp
xorps  %xmm0, %xmm0
movl   %esp, %ebp
subl   $16, %esp
(*) movups %xmm0, -16(%ebp)
leave
ret

Perhaps even the store to stack is not necessary in this particular case.


-- 


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

[Bug rtl-optimization/11707] [3.4 Regression] [new unroller] constants not propagated in unrolled loop iterations with a conditional

[rguenth at tat dot physik dot uni-tuebingen dot de]

--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen 
dot de  2005-01-12 11:05 ---
I can re-confirm that the patch moves 3.4 to the state of 3.3 - i.e. with an
extra imull compared to 2.95 and 4.0.  The patch has bootstrapped with checking
enabled and -funroll-loops on ia64, testing is in process.  I'll formally submit
the patch shortly.

For the imull regression I'll file a separate bug with a possibly reduced 
testcase.

-- 
   What|Removed |Added

 CC||rakdver at gcc dot gnu dot
   ||org
  Known to fail|3.4.0   |3.4.0 3.4.3


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

[Bug tree-optimization/19333] [4.0 Regression] Compilation SEGFAULTs with -O1 -finline-functions on the x86_64 architecture.

[drab at kepler dot fjfi dot cvut dot cz]

--- Additional Comments From drab at kepler dot fjfi dot cvut dot cz  
2005-01-12 11:25 ---
(In reply to comment #7)
> Hmm, I think this is a bad gcc extension:
> extern short int aa[][];
> Note with -pedantic we warning about it.

I agree, I would personally never use it. However, this came out during
compilation of XviD (if I remember correctly).

-- 


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

[Bug c++/19375] [3.4/4.0 Regression] Access violation diagnostic given twice

[lerdsuwa at gcc dot gnu dot org]

--- Additional Comments From lerdsuwa at gcc dot gnu dot org  2005-01-12 
11:26 ---
Got it.

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |lerdsuwa at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2005-01-11 15:13:41 |2005-01-12 11:26:17
   date||


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

[Bug tree-optimization/19241] [4.0 Regression] ICE in make_decl_rtl with inliner

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2005-01-12 
11:45 ---
We choque on expanding this: 
 
inline void Iterator::IsEnd () const 
{ 
  compare (this, static_cast(0)->end()); 
} 
 
Which looks like this at -O: 
compare (&D.2008, &D.2013) 
 
(gdb) 
#11 0x007008d1 in expand_call (exp=0x2a959f6820, target=0x0, ignore=1) 
at calls.c:2543 
2543  precompute_register_parameters (num_actuals, args, 
®_parm_seen); 
(gdb) p debug_tree(args[0]->tree_value) 
  
unit size  
align 8 symtab 0 alias set -1 fields  
   needs-constructor X() X(constX&) this=(X&) n_parents=0 
use_template=0 interface-unknown 
pointer_to_this  reference_to_this 
 chain > 
public unsigned DI 
size  
unit size  
align 64 symtab 0 alias set -1> 
invariant 
arg 0  
addressable used ignored BLK file t.C line 22 size  unit size  
align 8 context  abstract_origin 
 
(mem/s:BLK (plus:DI (reg/f:DI 54 virtual-stack-vars) 
(const_int -1 [0x])) [0 D.2013+0 S1 A8])>> 
$18 = void 
(gdb) p debug_tree(args[1]->tree_value) 
  
unit size  
align 8 symtab 0 alias set -1 fields  
   needs-constructor X() X(constX&) this=(X&) n_parents=0 
use_template=0 interface-unknown 
pointer_to_this  reference_to_this 
 chain > 
public unsigned DI 
size  
unit size  
align 64 symtab 0 alias set -1> 
invariant 
arg 0  
addressable used ignored BLK file t.C line 22 size  unit size  
align 8 context  abstract_origin 
>> 
$19 = void 
(gdb) 
 
Note that the arg 1 does not have RTL yet.  We eventually die expanding that 
arg when we trigger an assert: 
 
#1  0x00a4eceb in make_decl_rtl (decl=0x2a959f7270) at varasm.c:868 
868 abort (); 
(gdb) p debug_tree(decl) 
  
unit size  
align 8 symtab 0 alias set -1 
fields  
nonlocal decl_4 VOID file t.C line 12 
align 1 context  
   > 
   needs-constructor X() X(constX&) this=(X&) n_parents=0 use_template=0 
interface-unknown 
pointer_to_this  reference_to_this 
 chain > 
addressable used ignored BLK file t.C line 22 size  unit size  
align 8 context  abstract_origin > 
$31 = void 
(gdb) l 
863   || (TREE_CODE (decl) == VAR_DECL 
864   && !TREE_STATIC (decl) 
865   && !TREE_PUBLIC (decl) 
866   && !DECL_EXTERNAL (decl) 
867   && !DECL_REGISTER (decl))) 
868 abort (); 
869   /* And that we were not given a type or a label.  */ 
870   else if (TREE_CODE (decl) == TYPE_DECL 
871|| TREE_CODE (decl) == LABEL_DECL) 
872 abort (); 
(gdb) p debug_tree (decl) 
  
unit size  
align 8 symtab 0 alias set -1 
fields  
nonlocal decl_4 VOID file t.C line 12 
align 1 context  
   > 
   needs-constructor X() X(constX&) this=(X&) n_parents=0 use_template=0 
interface-unknown 
pointer_to_this  reference_to_this 
 chain > 
addressable used ignored BLK file t.C line 22 size  unit size  
align 8 context  abstract_origin > 
$36 = void 
 

-- 


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

[Bug tree-optimization/19241] [4.0 Regression] ICE in make_decl_rtl with inliner

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2005-01-12 
11:51 ---
This is the .generic dump: 
 
void Iterator::IsEnd() const (this) 
{ 
  struct Iterator D.1926; 
 
  end (&D.1926, 0B) [return slot addr]; 
  compare (this, &D.1926); 
} 
 
 
Iterator::Iterator() (this) 
{ 
  IsEnd (this); 
} 
 
 
Iterator Map::end() const (this) 
{ 
  struct Iterator & D.1937; 
 
  D.1937 = ; 
  __comp_ctor  (D.1937); 
  return ; 
} 
 
 
void Foo() () 
{ 
  struct Iterator D.1941; 
 
  { 
struct Map f; 
 
end (&D.1941, &f) [return slot addr]; 
  } 
} 
 
 
 
In the gimple dump we suddenly have 9 compare calls, so that the .cfg dump 
looks like this: 
 
  # BLOCK 0 
  # PRED: ENTRY (fallthru) 
  D.1937 = ; 
  this = D.1937; 
  this = this; 
  D.1951 = &D.1952; 
  this = D.1951; 
  this = this; 
  D.1959 = &D.1960; 
  this = D.1959; 
  this = this; 
  D.1967 = &D.1968; 
  this = D.1967; 
  this = this; 
  D.1975 = &D.1976; 
  this = D.1975; 
  this = this; 
  D.1983 = &D.1984; 
  this = D.1983; 
  this = this; 
  D.1991 = &D.1992; 
  this = D.1991; 
  this = this; 
  D.1999 = &D.2000; 
  this = D.1999; 
  this = this; 
  D.2007 = &D.2008; 
  this = D.2007; 
  this = this; 
  end (&D.2013, 0B) [return slot addr]; 
  compare (this, &D.2013); 
  compare (this, &D.2005); 
  compare (this, &D.1997); 
  compare (this, &D.1989); 
  compare (this, &D.1981); 
  compare (this, &D.1973); 
  compare (this, &D.1965); 
  compare (this, &D.1957); 
  compare (this, &D.1949); 
  return ; 
  # SUCC: EXIT 
 
 
 

-- 


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

[Bug target/18329] [4.0 regression] mmix-knuth-mmixware testsuite failure: execute/920501-7.c, execute/comp-goto-2.c

[hp at gcc dot gnu dot org]

--- Additional Comments From hp at gcc dot gnu dot org  2005-01-12 12:14 
---
This obsolete #7.
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00649.html>

-- 


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

[Bug target/19389] [4.0 Regression] Odd gpr mem load unrecognizable insn

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-01-12 
12:23 ---
Subject: Bug 19389

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-01-12 12:22:28

Modified files:
gcc: ChangeLog 
gcc/config/rs6000: rs6000.md 

Log message:
PR target/19389
* config/rs6000/rs6000.md (movtf_internal): Replace r->o and m->r
with r->Y and Y->r.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7101&r2=2.7102
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/rs6000.md.diff?cvsroot=gcc&r1=1.339&r2=1.340



-- 


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

[Bug target/19389] [4.0 Regression] Odd gpr mem load unrecognizable insn

[amodra at bigpond dot net dot au]

--- Additional Comments From amodra at bigpond dot net dot au  2005-01-12 
12:24 ---
Fixed.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to fail|4.0.0   |
 Resolution||FIXED
   Target Milestone|4.0.0   |---


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

[Bug target/19389] [4.0 Regression] Odd gpr mem load unrecognizable insn

[amodra at bigpond dot net dot au]

-- 
   What|Removed |Added

   Target Milestone|--- |4.0.0


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

[Bug c/6689] GCC-3.1: ICE / insn does not satisfy its constraints

[k dot ponting at aurix dot com]

--- Additional Comments From k dot ponting at aurix dot com  2005-01-12 
12:39 ---
I have an apparently similar problem attempting to build a gcc 3.4.3 cross-
compiler for tms320c30 (target c4x).

I have built and installed binutils 2.15 then get ICE when building gcc.
Cross-compiler build sequence:

1) Build binutils 2.15:

mkdir tms320
cd tms320
../binutils-2.15/configure --prefix=/usr/local/tms320 --program-prefix=tms320- -
-target=c4x > ../configure.binutils.log
make -s > ../make.binutils.log 2>&1
make install
rm -rf *

2) Create directory which seems to be wanted by build
mkdir /usr/local/tms320/lib/gcc/c4x/3.4.3/../../../../c4x/sys-include

3) Update path to reference installed tms320 tools 
   (first build attempt failed at this point)
PATH=/usr/local/tms320/bin:$PATH
export PATH

4) Attempt to build which ended in failure

../gcc-3.4.3/configure --prefix=/usr/local/tms320 --program-prefix=tms320- --
target=c4x --enable-languages=c,c++ > ../configure.gcc.log
nice make -s > ../build.gcc.log 2>&1

Output of gcc -v from host:
~~
Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/specs
Configured with: /GCC/gcc-3.3.1-3/configure --with-gcc --with-gnu-ld --with-gnu-
as --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --
libexecdir=/usr/sbin --mandir=/usr/share/man --infodir=/usr/share/info --enable-
languages=c,ada,c++,f77,pascal,java,objc --enable-libgcj --enable-
threads=posix --with-system-zlib --enable-nls --without-included-gettext --
enable-interpreter --enable-sjlj-exceptions --disable-version-specific-runtime-
libs --enable-shared --disable-win32-registry --enable-java-gc=boehm --disable-
hash-synchronization --verbose --target=i686-pc-cygwin --host=i686-pc-cygwin --
build=i686-pc-cygwin
Thread model: posix
gcc version 3.3.1 (cygming special)

Command which failed

cd gcc
/cygdrive/c/cygnus/gcc/tms320/gcc/xgcc -save-temps -
B/cygdrive/c/cygnus/gcc/tms320/gcc/ -B/usr/local/tms320/c4x/bin/ -
B/usr/local/tms320/c4x/lib/ -isystem /usr/local/tms320/c4x/include -
isystem /usr/local/tms320/c4x/sys-include -O2  -DIN_GCC -DCROSS_COMPILE   -W -
Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-
definition  -isystem ./include  -Dexit=unused_exit -g  -DIN_LIBGCC2 -
D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../gcc-3.4.3/gcc -
I../../gcc-3.4.3/gcc/. -I../../gcc-3.4.3/gcc/../include   -msmall -DL__main -
c ../../gcc-3.4.3/gcc/libgcc2.c -o libgcc/small/__main.o

Output of xgcc -v
~
Using built-in specs.
Configured with: ../gcc-3.4.3/configure --prefix=/usr/local/tms320 --program-
prefix=tms320- --target=c4x --enable-languages=c,c++
Thread model: single
gcc version 3.4.3

Output of failed command

../../gcc-3.4.3/gcc/libgcc2.c: In function `__do_global_dtors':
../../gcc-3.4.3/gcc/libgcc2.c:1607: error: insn does not satisfy its 
constraints:
(insn:HI 44 53 45 0 ../../gcc-3.4.3/gcc/libgcc2.c:1594 (set (reg/s/f:QI 8 ar0 
[orig:37 p ] [37])
(mem/f:QI (symbol_ref:QI ("*p$1") [flags 0x2] ) 
[5 p+0 S1 A32])) 8 {movqi_noclobber} (nil)
(nil))
../../gcc-3.4.3/gcc/libgcc2.c:1607: 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.
mkdir tms320
cd tms320
../binutils-2.15/configure --prefix=/usr/local/tms320 --program-prefix=tms320- -
-target=c4x > configure.binutils.log


-- 


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

[Bug fortran/19394] New: g77: confused equivalences not detected

[Thomas dot Koenig at online dot de]

$ cat confused-equivalences.f
  real a(2), b(2), c(3)
  equivalence (a(1), b(2)), (b(1), c(1)), (c(2), a(2))
  end
$ g77 confused-equivalences.f
$ g77 -v
Reading specs from /usr/lib/gcc-lib/ia64-redhat-linux/3.2.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit 
--host=ia64-redhat-linux
Thread model: posix
gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-49)

If one of the variables is put into common, then an error
is indeed generated:

$ cat confused-equivalences+common.f
  real a(2), b(2), c(3)
  common c
  equivalence (a(1), b(2)), (b(1), c(1)), (c(2), a(2))
  end
$ g77 confused-equivalences+common.f
Mismatched EQUIVALENCE requirements for placement of `a' at both 4 and 0 bytes
offset from `_BLNK__'

gfortran gets this right, which is nice:

$ gfortran confused-equivalences.f
 In file confused-equivalences.f:1

  real a(2), b(2), c(3)
  2 1
Error: Inconsistent equivalence rules involving 'b' at (1) and 'a' at (2)

Maybe this could be turned into a test case.

-- 
   Summary: g77: confused equivalences not detected
   Product: gcc
   Version: 3.2.3
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug target/19307] [4.0 Regression] ICE with -msse2 -mno-80387

[uros at kss-loka dot si]

--- Additional Comments From uros at kss-loka dot si  2005-01-12 12:43 
---
(In reply to comment #3)
> And it works with today's compiler too.

It works with '-O2 -mno-80387 -msse2 -mno-fp-ret-in-387', but without
-mno-fp-ret-in-387 it still fails. I think that the problem here is again SSE FP
compare that gets splitted to x87 compare, when the output value is returned in
x87 reg.

-- 


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

[Bug target/19379] [4.0 Regression] ICE during build of newlib's e_atan2.c when soft-float

[joel at gcc dot gnu dot org]

--- Additional Comments From joel at gcc dot gnu dot org  2005-01-12 12:50 
---
(In reply to comment #4)
> (In reply to comment #3)
> > What do you want the ABI for soft-float to be?
> > As RTEMS is probably the only user of -msoft-float, you get to choose.
> -msoft-float basically is just a synomym for -no-80387 (-MASK_80387 in 
> i386.h),
> so there probably are more users.

If you are tuly using soft-float, then the results can't be returned in the
non-existent FPU registers so I have never understood from a practical matter
why it didn't already imply avoiding returning values in FPU registers.
 
> > Do you want -msoft-float to imply -mno-fp-ret-in-387, do you want to supply
> > it yourself, or do you want to admit that all shipping processors have an
> > fpu and/or the os has an emulator?
> Neither.

Richard gave four options.  

  (1) -msoft-float to imply -mno-fp-ret-in-387
  (2) supply "it" yourself (?? do you mean explicitly state -mno-fp-ret-in-387)
  (3) admit that all shipping processors have an FPU
  (4) add an FPU emulator to RTEMS

(3) is quite an assertion.  There are lots of x86 clones now and many of those
are targetted to the embedded space.  All desktop x86 CPUs do have FPUs but
all x86's do not target that space.  Even Intel still ships some no FPU x86
variants for embedded space
(http://developer.intel.com/design/intarch/intel386/index.htm).  Ignoring that,
this choice would result in us being unable to provide OS upgrades to users of
non-FPU x86 CPUs.

(4) is not likely to happen.  It hasn't been needed yet and it is unlikely a 
volunteer is going to show up just because gcc suddenly needs one after 10
years of not needing it. 

(2) I am not sure what  this means exactly but if the user has to provide 
an extra argument, it is error prone and the multilib match has to be there
anyway. 

This leaves us with (1).  If that is all that is required to fix the problem,
then (a) how hard is this to implement and (b) what is the potential impact
on user code?  RTEMS, all support code, and all application would be
recompiled with the new ABI so that is OK.  The impact would be any assembly
routines.  I doubt there are many.

> The actual problem is people using RTEMS on original i386dx's for whom 
> previous
> verions of gcc had required -mtune=i386 -mno-80387 -no-fp-ret-in-387 rsp.
> -mcpu=i386 -msoft-float -no-fp-in-387.
> 
> For other cpus, coupling -msoft-float with -no-fp-in-387 has proven not to be
> necessary.

I checked the i386ex BSPs and one used 
-msoft-float -mno-fp-ret-in-387 and the other only used -msoft-float.
The pc386dx BSP uses both options.

I am willing to go with (1).  Can this be done all the time
for -msoft-float?  Just change i386.h like this:

{ "soft-float", (-MASK_80387|-MASK_FLOAT_RETURNS|, N_("Do not use 
hardware fp")
},  \

Is that enough?


> This all is the reason for RTEMS gcc to use this kind of multilibs:
> i386-rtems4.7-gcc --print-multi-lib
> .;
> m486;@mtune=i486
> mpentium;@mtune=pentium
> mpentiumpro;@mtune=pentiumpro
> k6;@mtune=k6
> athlon;@mtune=athlon
> soft-float;@msoft-float
> soft-float/nofp;@[EMAIL PROTECTED]
> m486/soft-float;@[EMAIL PROTECTED]



-- 


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

[Bug c++/19395] New: [3.3/3.4/4.0 regression] invalid scope qualifier allowed in typedef

[reichelt at gcc dot gnu dot org]

The following invalid code snippet is accepted since gcc 3.0
(without warning, even with -pedantic -Wall -W):

===
struct A
{
typedef int ::X;
};
===

-- 
   Summary: [3.3/3.4/4.0 regression] invalid scope qualifier allowed
in typedef
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/19396] New: [3.4/4.0 regression] Invalid template in typedef accepted

[reichelt at gcc dot gnu dot org]

Without "-pedantic" the following invalid code snippet is accepted
since gcc 3.4.0:


template struct A
{
typedef int A::template X;
};


-- 
   Summary: [3.4/4.0 regression] Invalid template in typedef
accepted
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/19397] New: [3.4 regression] ICE with invalid typedef

[reichelt at gcc dot gnu dot org]

The following invalid code causes an ICE with gcc 3.4.x
(3.3.x and mainline are not affected):


template struct A
{
typedef int ::template;
};


bug.cc:3: error: expected id-expression before "template"
bug.cc:3: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]

-- 
   Summary: [3.4 regression] ICE with invalid typedef
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, error-recovery
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug target/19022] mmix-knuth-mmixware testsuite failure: gcc.dg/ftrapv-2.c ICE

[hp at gcc dot gnu dot org]

--- Additional Comments From hp at gcc dot gnu dot org  2005-01-12 13:27 
---
Works with "Wed Jan 12 10:28:53 UTC 2005", apparently thanks to:
2005-01-11  Roger Sayle  <[EMAIL PROTECTED]>

* builtins.c (fold_builtin_fabs): Convert argument to the appropriate
type as args of unprototyped builtins aren't automatically promoted.
(fold_builtin_abs): Likewise.


-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug target/19398] New: Non-optimal code with cvttss2si

[uros at kss-loka dot si]

The testcase:
int test (float a) {
return (a*a);
}

produces non-optimal asm code, when compiled with '-O2 -msse -mfpmath=387':
test:
pushl  %ebp
movl   %esp, %ebp
subl   $4, %esp
flds   8(%ebp)
fmul   %st(0), %st
fstps  -4(%ebp)
(*) movss  -4(%ebp), %xmm0
(*) cvttss2si   %xmm0, %eax
leave
ret

A cvttss2si insn could use memory input operand, so movss to %xmm0 is not
needed. Following RTL sequence is generated in ._.23.greg:

(insn 31 11 32 0 (set (mem:SF (plus:SI (reg/f:SI 6 bp)
(const_int -4 [0xfffc])) [0 S4 A8])
(reg/v:SF 8 st [orig:59 a ] [59])) 61 {*movsf_1} (nil)
(nil))

(insn 32 31 12 0 (set (reg:SF 21 xmm0)
(mem:SF (plus:SI (reg/f:SI 6 bp)
(const_int -4 [0xfffc])) [0 S4 A8])) 61 {*movsf_1} (nil)
(nil))

(insn:HI 12 32 16 0 (set (reg:SI 0 ax [60])
(fix:SI (reg:SF 21 xmm0))) 112 {fix_truncsfsi_sse}
(insn_list:REG_DEP_TRUE 11 (nil))
(nil))

It looks like gcc does not take into account the fact that cvttss2si can use
memory input operand.

-- 
   Summary: Non-optimal code with cvttss2si
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uros at kss-loka dot si
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=19398

[Bug tree-optimization/19038] [4.0 Regression] out-of ssa causing loops to have more than one BB

[amacleod at redhat dot com]

--- Additional Comments From amacleod at redhat dot com  2005-01-12 13:34 
---
So let me see, If I read this properly, this is no longer an out of ssa problem?

notes:
- changing where we place copies based on jeffs observations in comment 25 ought
not be difficult.
- If we wish to change the coalesce algorithm, we should be able to simply plug
a  new one in. The existing one was just a quick straightforward implementation
to get it working with the full intention of improving it later. Its also
reasonably flexible and cost driven.  tree-outof-ssa.c::coalesce_ssa_name() does
all the setup work. A list of possible coalesces is created, given costs and the
sorted. Coalesces are then performed by calling
tree-ssa-live::coalesce_tpa_members() (tpa's are generic lists which associate
trees, ie VAR trees to a partition index).  The routine
tree-ssa-live.c::pop_best_coalesce() deterimes the order to attempt coalesces. 
currently this simply retreives them in sorted ordered by "cost". cost is
calculated during the building of the coalesce list via calls to
tree-ssa-live.c::add_coalesce(), and is a cost value passed to the routine.

The current implementation simply calls add_coalesce with a value of 1 all the
time, so it ends up being simply a copy count.. ie, we try to coalesce variables
which are copied between each other 4 times before we try those copied once. The
original intention was to multiple each copy by 10^nest_level_of_copy, but that
info wasnt easily available when I implemented it. I beleive it is now, and just
haven't gotten around to doing it. It would be trivial to add that to the calls
to add_coalesce.  

We could increase the cost again if its going to insert a copy on a latch edge
quite easily. (maybe 20^nest_level instead or some such thing) Making those even
more important.

add_coalesce should probably be changed to avoid wraparound as well I suppose. 

-- 


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

[Bug AWT/16203] need to kill awt helper threads on gui app exit

[chris dot pickett at mail dot mcgill dot ca]

--- Additional Comments From chris dot pickett at mail dot mcgill dot ca  
2005-01-12 14:03 ---
Thank-you kindly.  Can you summarize your solution?

-- 


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

[Bug target/19379] [4.0 Regression] ICE during build of newlib's e_atan2.c when soft-float

[corsepiu at gcc dot gnu dot org]

--- Additional Comments From corsepiu at gcc dot gnu dot org  2005-01-12 
14:19 ---
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > What do you want the ABI for soft-float to be?
> > > As RTEMS is probably the only user of -msoft-float, you get to choose.
> > -msoft-float basically is just a synomym for -no-80387 (-MASK_80387 in 
> > i386.h),
> > so there probably are more users.
> 
> If you are tuly using soft-float, then the results can't be returned in the
> non-existent FPU registers so I have never understood from a practical matter
> why it didn't already imply avoiding returning values in FPU registers.
This is not how i386-gcc-rtems is set up until now.

> > > Do you want -msoft-float to imply -mno-fp-ret-in-387, do you want to 
> > > supply
> > > it yourself, or do you want to admit that all shipping processors have an
> > > fpu and/or the os has an emulator?
> > Neither.
> 
> Richard gave four options.  
> 
>   (1) -msoft-float to imply -mno-fp-ret-in-387
IMO, this proposal is meaningless unless
-mno-80387 also is changed to imply -mno-fp-ret-in-387.

>   (2) supply "it" yourself (?? do you mean explicitly state 
> -mno-fp-ret-in-387)
>   (3) admit that all shipping processors have an FPU
>   (4) add an FPU emulator to RTEMS
> 
> (3) is quite an assertion.
ACK, this is not feasible.

> (4) is not likely to happen.
Hmm? What is -msoft-float -mno-fp-ret-in-387 using, then?

> This leaves us with (1).
Cf. above.

Theoretically, letting -msoft-float imply -mno-fp-ret-in-387 should provide a
multilib variant applicable to i386dx's. 
 
> > The actual problem is people using RTEMS on original i386dx's for whom 
> > previous
> > verions of gcc had required -mtune=i386 -mno-80387 -no-fp-ret-in-387 rsp.
> > -mcpu=i386 -msoft-float -no-fp-in-387.
> > 
> > For other cpus, coupling -msoft-float with -no-fp-in-387 has proven not to 
> > be
> > necessary.
> 
> I checked the i386ex BSPs and one used 
> -msoft-float -mno-fp-ret-in-387
The pc386dx BSP uses this one.

> and the other only used -msoft-float.
> The pc386dx BSP uses both options.
No, the pc386 BSP uses this one.

The source code is identical, the only differnence is -mno-fp-ret-in-387

> I am willing to go with (1).  Can this be done all the time
> for -msoft-float?  Just change i386.h like this:
> 
> { "soft-float",   (-MASK_80387|-MASK_FLOAT_RETURNS|, N_("Do not 
> use hardware fp")
> },  \
> 
> Is that enough?
To provide RTEMS with a work-around, yes, this should be sufficient.
However, cf. above. IMO, this is not sufficient for GCC.

-- 


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

[Bug c++/19399] New: gthread_recursive_mutex's missing

[corsepiu at gcc dot gnu dot org]

GCC 4.0 has broken rtems thread support for all targets:

# configure --enable-languages=c,c++ --enable-threads=rtems\
[more options]
...
# make
...
/users/rtems/src/rpms/BUILD/rtems-4.7-arm-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/gcc/xgcc
-shared-libgcc
-B/users/rtems/src/rpms/BUILD/rtems-4.7-arm-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/gcc/
-nostdinc++
-L/users/rtems/src/rpms/BUILD/rtems-4.7-arm-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/arm-rtems4.7/libstdc++-v3/src
-L/users/rtems/src/rpms/BUILD/rtems-4.7-arm-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/arm-rtems4.7/libstdc++-v3/src/.libs
-nostdinc
-B/users/rtems/src/rpms/BUILD/rtems-4.7-arm-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/arm-rtems4.7/newlib/
-isystem
/users/rtems/src/rpms/BUILD/rtems-4.7-arm-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/arm-rtems4.7/newlib/targ-include
-isystem
/users/rtems/src/rpms/BUILD/rtems-4.7-arm-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/gcc-4.0.0/newlib/libc/include
-B/opt/rtems-4.7/arm-rtems4.7/bin/ -B/opt/rtems-4.7/arm-rtems4.7/lib/ -isystem
/opt/rtems-4.7/arm-rtems4.7/include -isystem
/opt/rtems-4.7/arm-rtems4.7/sys-include
-I/users/rtems/src/rpms/BUILD/rtems-4.7-arm-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/gcc-4.0.0/libstdc++-v3/../gcc
-I/users/rtems/src/rpms/BUILD/rtems-4.7-arm-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/arm-rtems4.7/libstdc++-v3/include/arm-rtems4.7
-I/users/rtems/src/rpms/BUILD/rtems-4.7-arm-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/arm-rtems4.7/libstdc++-v3/include
-I/users/rtems/src/rpms/BUILD/rtems-4.7-arm-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/gcc-4.0.0/libstdc++-v3/libsupc++
-O2 -g -O2 -g -O2 -fno-implicit-templates -Wall -Wextra -Wwrite-strings
-Wcast-qual -fdiagnostics-show-location=once -c
../../../../gcc-4.0.0/libstdc++-v3/libsupc++/guard.cc -o guard.o
../../../../gcc-4.0.0/libstdc++-v3/libsupc++/guard.cc:51: error:
'__gthread_recursive_mutex_t' does not name a type
../../../../gcc-4.0.0/libstdc++-v3/libsupc++/guard.cc:62: error:
'__gthread_recursive_mutex_t' does not name a type
../../../../gcc-4.0.0/libstdc++-v3/libsupc++/guard.cc: In static member function
'static void::static_mutex::lock()':
../../../../gcc-4.0.0/libstdc++-v3/libsupc++/guard.cc:81: error: 'mutex' was not
declared in this scope
../../../../gcc-4.0.0/libstdc++-v3/libsupc++/guard.cc:81: error:
'__gthread_recursive_mutex_lock' was not declared in this scope
../../../../gcc-4.0.0/libstdc++-v3/libsupc++/guard.cc: In static member function
'static void::static_mutex::unlock()':
../../../../gcc-4.0.0/libstdc++-v3/libsupc++/guard.cc:86: error: 'mutex' was not
declared in this scope
../../../../gcc-4.0.0/libstdc++-v3/libsupc++/guard.cc:86: error:
'__gthread_recursive_mutex_unlock' was not declared in this scope

Without having looked into details, something in GCC seems to have changed which
silently breaks gthr-rtems.h.

-- 
   Summary: gthread_recursive_mutex's missing
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: corsepiu at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,joel at gcc dot gnu dot
org
GCC target triplet: *-rtems*


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

[Bug c++/19399] gthread_recursive_mutex's missing

[corsepiu at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Known to fail||4.0.0


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

[Bug target/19379] [4.0 Regression] ICE during build of newlib's e_atan2.c when soft-float

[joel at gcc dot gnu dot org]

--- Additional Comments From joel at gcc dot gnu dot org  2005-01-12 14:41 
---
(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > (In reply to comment #3)
> > If you are tuly using soft-float, then the results can't be returned in the
> > non-existent FPU registers so I have never understood from a practical 
> > matter
> > why it didn't already imply avoiding returning values in FPU registers.
> This is not how i386-gcc-rtems is set up until now.

Right but there is nothing preventing it from changing and all BSPs with
recent test reports specify -mno-fp-ret-in-387 flag anyway.   Since we don't
have a simulator which handle the FP not present trap handler, this is
really the only one which can work.
 
> > > > Do you want -msoft-float to imply -mno-fp-ret-in-387, do you want to 
> > > > supply
> > > > it yourself, or do you want to admit that all shipping processors have 
> > > > an
> > > > fpu and/or the os has an emulator?
> > > Neither.
> > 
> > Richard gave four options.  
> > 
> >   (1) -msoft-float to imply -mno-fp-ret-in-387
> IMO, this proposal is meaningless unless
> -mno-80387 also is changed to imply -mno-fp-ret-in-387.
> 
> >   (2) supply "it" yourself (?? do you mean explicitly state 
> > -mno-fp-ret-in-387)
> >   (3) admit that all shipping processors have an FPU
> >   (4) add an FPU emulator to RTEMS
> > 
> > (3) is quite an assertion.
> ACK, this is not feasible.

I don't even think it is an accurate reflection of shipping CPUs today.

> > (4) is not likely to happen.
> Hmm? What is -msoft-float -mno-fp-ret-in-387 using, then?

By FPU emulator I mean (and assume Richard means) a handler for the FPU
not present (trap #7) handler.  We don't have one so we have to eliminate
all FPU operations.  

Unfortunately, I think soft-float doesn't completely eliminate all uses of
the FPU so you have to add the no-fp-ret-in-387 argument.

> > This leaves us with (1).
> Cf. above.
> 
> Theoretically, letting -msoft-float imply -mno-fp-ret-in-387 should provide a
> multilib variant applicable to i386dx's. 

That's what I think and it gives us exactly what BSPs are specifying now.
It looks like in practical terms, when you really need soft-float, you need
no-fp-ret-in-i387 since you are saying there is no i387 and you are 
emulating one via a trap handler.
  
> > > The actual problem is people using RTEMS on original i386dx's for whom
previous
> > > verions of gcc had required -mtune=i386 -mno-80387 -no-fp-ret-in-387 rsp.
> > > -mcpu=i386 -msoft-float -no-fp-in-387.
> > > 
> > > For other cpus, coupling -msoft-float with -no-fp-in-387 has proven not 
> > > to be
> > > necessary.
> > 
> > I checked the i386ex BSPs and one used 
> > -msoft-float -mno-fp-ret-in-387
> The pc386dx BSP uses this one.
> 
> > and the other only used -msoft-float.
> > The pc386dx BSP uses both options.
> No, the pc386 BSP uses this one.
> 
> The source code is identical, the only differnence is -mno-fp-ret-in-387
> 
> > I am willing to go with (1).  Can this be done all the time
> > for -msoft-float?  Just change i386.h like this:
> > 
> > { "soft-float", (-MASK_80387|-MASK_FLOAT_RETURNS|, N_("Do not 
> > use hardware fp")
> > },  \
> > 
> > Is that enough?
> To provide RTEMS with a work-around, yes, this should be sufficient.
> However, cf. above. IMO, this is not sufficient for GCC.

Ignoring my syntax error, in the typing above.  Richard has said RTEMS is
the only target who cares about soft-float.  If this is a workable 
solution, then I say we go for it.  I am trying it now and will report in.

-- 


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

[Bug c++/19399] gthread_recursive_mutex's missing

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-01-12 
14:50 ---
> Without having looked into details, something in GCC seems to have changed
> which silently breaks gthr-rtems.h.

Indeed, things rarely break without reason. :-)


It's

2004-08-27  Jason Merrill  <[EMAIL PROTECTED]>

PR c++/13684
* gimplify.c (gimplify_cleanup_point_expr): Handle CLEANUP_EH_ONLY.
(gimple_push_cleanup): Add eh_only parm.
(gimplify_target_expr): Pass it.
* c.opt (-fno-threadsafe-statics): New option.
* c-opts.c (c_common_handle_option): Handle it.
* c-common.h (flag_threadsafe_statics): Declare it.
* c-common.c (flag_threadsafe_statics): Record it.
* doc/invoke.texi: Document it.
* tsystem.h (_GNU_SOURCE): Define.
* gthr-posix.h (__gthread_recursive_mutex_t): New typedef.
(__GTHREAD_RECURSIVE_MUTEX_INIT): New macro.
(__GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION): New macro.
(__gthread_recursive_mutex_init_function): New fn.
(__gthread_recursive_mutex_lock): New fn.
(__gthread_recursive_mutex_trylock): New fn.
(__gthread_recursive_mutex_unlock): New fn.
* gthr-solaris.h, gthr-single.h, gthr-dce.h: Likewise.
* gthr-win32.h, gthr-vxworks.h: Likewise.
* gthr.h: Document.

See gthr-win32.h or gthr-posix95.h or gthr-solaris.h for an example of
implementation of recursive mutexes.


-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-01-12 14:50:27
   date||


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

[Bug target/19399] [4.0 Regression] mutexes support broken

[ebotcazou at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|c++ |target
  Known to work||3.4.0
Summary|gthread_recursive_mutex's   |[4.0 Regression] mutexes
   |missing |support broken
   Target Milestone|--- |4.0.0


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

[Bug c++/19400] New: vector keyword in typedef inside struct ignored

[leblanc at skycomputers dot com]

This program

 1  #include 
 2  #include 
 3
 4  struct s {
 5  typedef vector float vf;
 6  vf v1;
 7  vector float v2;
 8  } S;
 9
10  int main () {
11  printf ("sizeof(s::vf) is %d\n",sizeof(s::vf));
12  printf ("sizeof(S.v1) is %d\n",sizeof(S.v1));
13  printf ("sizeof(S.v2) is %d\n",sizeof(S.v2));
14  printf ("sizeof(S) is %d\n",sizeof(S));
15  return 0;
16  }

prints

sizeof(s::vf) is 4
sizeof(S.v1) is 4
sizeof(S.v2) is 16
sizeof(S) is 32

I would expect the 4-s to be 16-s.

-- 
   Summary: vector keyword in typedef inside struct ignored
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: leblanc at skycomputers dot com
CC: gcc-bugs at gcc dot gnu dot org,paavola at skycomputers
dot com
 GCC build triplet: ppc-yellowdog-linux
  GCC host triplet: ppc-yellowdog-linux
GCC target triplet: ppc-yellowdog-linux


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

[Bug target/19379] [4.0 Regression] ICE during build of newlib's e_atan2.c when soft-float

[corsepiu at gcc dot gnu dot org]

--- Additional Comments From corsepiu at gcc dot gnu dot org  2005-01-12 
15:02 ---
(In reply to comment #7)
> (In reply to comment #6)

> > > If you are tuly using soft-float, then the results can't be returned in 
> > > the
> > > non-existent FPU registers so I have never understood from a practical 
> > > matter
> > > why it didn't already imply avoiding returning values in FPU registers.
> > This is not how i386-gcc-rtems is set up until now.
> 
> Right but there is nothing preventing it from changing and all BSPs with
> recent test reports specify -mno-fp-ret-in-387 flag anyway.

> Unfortunately, I think soft-float doesn't completely eliminate all uses of
> the FPU so you have to add the no-fp-ret-in-387 argument.

True, but ... -msoft-float == -mno-80387

The RTEMS user using the i386dx had proven this not to work on original i386dx
w/o i387.

However, he has proven -msoft-float -mno-fp-ret-in-387 to work for him.

=> IMO, the actual fix would be to merge MASK_FLOAT_RETURNS into MASK_80387 and
to abandon MASK_FLOAT_RETURNS.

> Richard has said RTEMS is
> the only target who cares about soft-float.
I don't agree to his statement.

-- 


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

[Bug c++/19400] vector keyword in typedef inside struct ignored

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-12 
15:27 ---
This is a dup of bug 9573 which is fixed for 4.0.0.

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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/9573] typedef with __attribute__ ((mode(....))) doesnt seem to work inside a struct/class

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-12 
15:27 ---
*** Bug 19400 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||leblanc at skycomputers dot
   ||com


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

[Bug middle-end/19391] [4.0 Regression] missed optimization with size of 8 vectors

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-12 
15:31 ---
(In reply to comment #3)
> Try again with  functions.
> 
> It is absolutely ESSENTIAL that we do NOT emit mmx vector operations UNLESS
> the  routines are used.  Doing so without the compiler also 
> being able to insert emms instructions is wrong-code.

Ok, but please add something to the changes page as I had thought I had saw 
this wording in a patch 
but I did not for sure.



-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug target/14552] compiled trivial vector intrinsic code is ineffiencent

[pinskia at gcc dot gnu dot org]

-- 
Bug 14552 depends on bug 19391, which changed state.

Bug 19391 Summary: [4.0 Regression] missed optimization with size of 8 vectors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19391

   What|Old Value   |New Value

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX

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

[Bug target/19393] Assembler error: branch out of range

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-12 
15:37 ---
I think this is related to PR 16626, it might also be a latent bug.

-- 
   What|Removed |Added

  Component|bootstrap   |target
   Keywords||wrong-code


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

[Bug c++/19397] [3.4 regression] ICE with invalid typedef

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |3.4.4
Version|4.0.0   |3.4.4


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

[Bug c++/19396] [3.4/4.0 regression] Invalid template in typedef accepted

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-12 
15:53 ---
: Search converges between 2002-12-14-trunk (#159) and 2002-12-29-trunk (#160).

Confirmed, looks like the new parser change the meaning of this case.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-01-12 15:53:52
   date||
   Target Milestone|--- |3.4.4


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

[Bug c++/19395] [3.3/3.4/4.0 regression] invalid scope qualifier allowed in typedef

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-12 
15:54 ---
Confirmed we have been accepting this since at least 2000-12-31.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-01-12 15:54:37
   date||
   Target Milestone|--- |3.4.4


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

[Bug c++/19397] [3.4 regression] ICE with invalid typedef

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-12 
15:55 ---
Broke: Search converges between 2002-12-14-trunk (#159) and 2002-12-29-trunk 
(#160).
Fixed on the mainline: Search converges between 2004-07-02-trunk (#477) and 
2004-07-04-trunk 
(#478).

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-01-12 15:55:49
   date||


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

[Bug target/19398] Non-optimal code with cvttss2si

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||missed-optimization


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

[Bug tree-optimization/19401] New: Trivial loop not unrolled

[rguenth at tat dot physik dot uni-tuebingen dot de]

We do not unroll the loop in

double foo(double __x)
{
unsigned int __n = 2;
double __y = __n % 2 ? __x : 1;

while (__n >>= 1)
  {
__x = __x * __x;
if (__n % 2)
  __y = __y * __x;
  }

return __y;
}

with -O2 which causes us to emit gratiously worse code
for std::pow(x, 2) than for std::pow(x, 2.0).

We should definitely get this right without -funroll-loops
and all its side-effects.

-- 
   Summary: Trivial loop not unrolled
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at tat dot physik dot uni-tuebingen dot de
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug tree-optimization/19401] Trivial loop not unrolled

[rguenth at tat dot physik dot uni-tuebingen dot de]

-- 
   What|Removed |Added

OtherBugsDependingO||11706
  nThis||


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

[Bug tree-optimization/19401] Trivial loop not unrolled

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-12 
16:13 ---
Really -funroll-loops should be added to -O3 by default and maybe a tweewed 
version to -O2/-Os 
(one which only unroll loops which can be unrolled fully and don't produce more 
code than the loop 
itself).

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||missed-optimization
   Last reconfirmed|-00-00 00:00:00 |2005-01-12 16:13:54
   date||


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

[Bug libstdc++/11706] std::pow(T, int) implementation pessimizes code

[rguenth at tat dot physik dot uni-tuebingen dot de]

--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen 
dot de  2005-01-12 16:17 ---
Current status is that with -O2 on mainline we generate the same
(better) code for ::pow(x, 2) and std::pow(x, 2.0) than for
std::pow(x, 2) which looses because of the lack of unrolling
(PR19401).

Also, ::pow(x, 27) and other exponents will always generate better
code than the std::pow(x, 27) variant due to the technically
superior implementation of gcc/builtins.c:expand_powi.

The attached patch solves all of these problems, unfortunately
in ways the libstdc++ maintainer(s) do not like.

-- 


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

[Bug tree-optimization/19401] Trivial loop not unrolled

[rguenth at tat dot physik dot uni-tuebingen dot de]

--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen 
dot de  2005-01-12 16:19 ---
In 3.4 one was able to do this by specifying -fpeel-loops and got complete loop
peeling enabled.  In 4.0 this is also the case, but only for the RTL unroller -
the tree unroller is not affected and as such _this_ unrolling does not help
PR11706.  - Just another datapoint.

-- 


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

[Bug tree-optimization/19401] Trivial loop not unrolled

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-12 
16:21 ---
Another trivial loop which is not unrolled but should be:

int f(int x)
{
  int i, x1;
  x1 = x;
  for(i = 0;i<2;i++)
   x1 *= x1;
  return x1;
}

-- 


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

[Bug tree-optimization/19401] Trivial loop not unrolled

[rguenth at tat dot physik dot uni-tuebingen dot de]

--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen 
dot de  2005-01-12 16:24 ---
Or stuff often found in C++ libraries:

template 
struct Vector
{
  Vector(float init)
  {
for (int i=0; ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=19401

[Bug ada/19337] [4.0 Regression] ada does not compile at -O3

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-12 
16:43 ---
I can confirm this on ppc-darwin also.

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org


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

[Bug middle-end/19304] [4.0 Regression] wrong code for spec test from emit_move_change_mode

[janis187 at us dot ibm dot com]

--- Additional Comments From janis187 at us dot ibm dot com  2005-01-12 
16:48 ---
I suspect that the patch is a clue to what's wrong rather than a real fix,
but if nothing happens in a couple of days I'll post it anyway.

-- 


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

[Bug tree-optimization/19337] [4.0 Regression] ada does not compile at -O3 (nested functions related)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-12 
16:53 ---
Reduced C testcase, just compile at -O3:
void write_char(char);
int len(char*);
void f(char *a)
{
  int col = 0;
  int i;
  void wchar(char c)
  {
if (c == '\t')
 {
  do {
   wchar(' ');
  } while ((col%8)!=0);
 }
else
 {
   write_char (c);
   col++;
 }
  }
  for(i =0;ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=19337

[Bug tree-optimization/19337] [4.0 Regression] ada does not compile at -O3 (nested functions related)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-12 
16:55 ---
(In reply to comment #16)
> Reduced C testcase, just compile at -O3:
One note this was a semi-direct translation of the Ada code, I was just trying 
to understand the Ada 
code even though I don't know Ada that much.

-- 


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

[Bug tree-optimization/18880] DSE is not doing its job for global variables

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2005-01-12 
16:56 ---
I'll have a look at Jeff's patch. 

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |steven at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2004-12-08 18:03:40 |2005-01-12 16:56:17
   date||


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

[Bug tree-optimization/19401] Trivial loop not unrolled

[gdr at integrable-solutions dot net]

--- Additional Comments From gdr at integrable-solutions dot net  
2005-01-12 17:05 ---
Subject: Re:  Trivial loop not unrolled

"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:

| Really -funroll-loops should be added to -O3 by default and maybe a
| tweewed version to -O2/-Os  

I don't think the issue is to have -funroll-loops as default at higher
level. I think it is more about the compiler understanding loops with
constant bounds, just like we handle if(0) or if(1) branches.

-- Gaby


-- 


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

[Bug tree-optimization/19401] Trivial loop not unrolled

[gdr at integrable-solutions dot net]

--- Additional Comments From gdr at integrable-solutions dot net  
2005-01-12 17:06 ---
Subject: Re:  Trivial loop not unrolled

"rguenth at tat dot physik dot uni-tuebingen dot de" <[EMAIL PROTECTED]> writes:

| Or stuff often found in C++ libraries:
| 
| template 
| struct Vector
| {
|   Vector(float init)
|   {
| for (int i=0; ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=19401

[Bug target/19399] [4.0 Regression] mutexes support broken

[joel at gcc dot gnu dot org]

--- Additional Comments From joel at gcc dot gnu dot org  2005-01-12 17:15 
---
(In reply to comment #3)

> I think the most flexible and simple solution would be to add a 
> rtems_gxx_recursive_mutex_init to RTEMS.
> 
> Also, I'd prefer to use this definition
> typedef void * __gthread_recursive_mutex_t;

Grrr.. looking back through the old mail and mail lists, that was indeed the 
intent when this was first mentioned.  I just added a new GCC patch and the
corresponding RTEMS patch (for reference).  What do you think of them?


-- 


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

[Bug c++/19263] [3.4/4.0 regression]: wrong-code: explicit inicialization of v8qi miscompiled

[jakub at gcc dot gnu dot org]

--- Additional Comments From jakub at gcc dot gnu dot org  2005-01-12 17:30 
---
Yeah, with PR c++/15172, http://gcc.gnu.org/ml/gcc-patches/2004-11/msg1.html


-- 
   What|Removed |Added

 CC||mark at codesourcery dot com


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

[Bug middle-end/19402] New: __builtin_powi? still missing

[pcarlini at suse dot de]

In order to efficiently implement in the c++ run-time library the overloads of
std::pow for integer (*) exponent mandated in 26.5, three additional builtins 
are
badly needed, for float, double and long double base. For a discussion, see this
thread:

  http://gcc.gnu.org/ml/gcc-patches/2003-07/msg02738.html

See also libstdc++/11706.

(*) But not necessarily constant!

-- 
   Summary: __builtin_powi? still missing
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pcarlini at suse dot de
CC: gcc-bugs at gcc dot gnu dot org,gdr at integrable-
solutions dot net,roger at eyesopen dot com


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

[Bug debug/19192] [4.0 Regression] Current development gcc generates incorrect line info for example code

[amacleod at redhat dot com]

--- Additional Comments From amacleod at redhat dot com  2005-01-12 17:46 
---
Created an attachment (id=7940)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7940&action=view)
proposed patch

Give this a try. I havent checked it in, Im running it through the testsuites.
I'm unlikely to be able to check it in until next week. This is likely to
change the debug info quite a bit, but it should be more detailed. Let me know
if you think it is OK, and if not, what it is doing wrong.

for the specified testcase I get:
  [a.c : 8] D.1150 = [a.c : 8] add2 (3, 4);
  [a.c : 13] printf (&"%d\n"[0], [a.c : 8] D.1150 + 2) [tail call];
  [a.c : 14] return;

so that looks reasonable. something artificial and slightly more complex gives
me:
x = a + b;
y = x * 3;
z = y << 2 + x;
x = z * 10;
printf ("%d\n", x * 44);
  [d.c : 6] x = a + b;
  [d.c : 10] printf (&"%d\n"[0], ([d.c : 8] [d.c : 7] x * 3 << x + 2) * 440)
[tail call];
  [d.c : 13] return;

which looks like it ought to be about right, but is a little tricky to read :-)


anyway, give it a shot and let me know if you think this is better.

Andrew

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |amacleod at redhat dot com
   |dot org |
 Status|NEW |ASSIGNED


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

[Bug preprocessor/17110] #include_next fails following #include that specifies an absolute path

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-01-12 
17:58 ---
AFAICS this has never worked as you intended: GCC 2.95.3, 2.96, 3.0.4, 3.1.1,
3.2.3 and 3.3.5 issue

#error "got wrong "

which means that #include_next was behaving like #include in that case.  So the
error is a progress, as Geoff and Neil said in the thread linked to above.


-- 
   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org
 Status|NEW |RESOLVED
   Priority|P1  |P2
 Resolution||INVALID
Summary|[3.4/4.0 Regression]|#include_next fails
   |#include_next fails |following #include that
   |following #include that |specifies an absolute path
   |specifies an absolute path  |
   Target Milestone|3.4.4   |---


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

[Bug c++/19263] [3.4/4.0 regression]: wrong-code: explicit inicialization of v8qi miscompiled

[jakub at gcc dot gnu dot org]

--- Additional Comments From jakub at gcc dot gnu dot org  2005-01-12 18:00 
---
This seems to be because of the CONSTRUCTOR_ELTS (init) = NULL;
added in http://gcc.gnu.org/ml/gcc-patches/2004-01/msg00832.html
by Richard.
If I remove it, the testcase works, as well as this bigger one below.
Wiping the initializers of the vector can't be right, so either that line
can be just deleted, or we want to create zero vector and then initialize
it field by field with the original values.
typedef signed char v8qi __attribute__ ((vector_size (8)));

extern "C" void abort (void);

static unsigned char S[16];

struct A
{
  int i;
  v8qi j, k;
  int l;
};

void
foo (unsigned char v)
{
  A a = { 1, { v, v, v, v, v, v, v, v },
 { v + 1, v + 1, v + 1, v + 1, v + 1, v + 1, v + 1, v + 1 }, 3 };
  v8qi *s = (v8qi *) & S[0];
  *s = a.j;
  s[1] = a.k;
}

void
bar (unsigned char v)
{
  v8qi val8 = { v, v, v, v, v, v, v, v };
  v8qi *s = (v8qi *) & S[0];
  *s = val8;
}

int
main ()
{
  int i;
  foo (1);
  for (i = 0; i < 8; ++i)
if (S[i] != 1)
  abort ();
  for (; i < 16; ++i)
if (S[i] != 2)
  abort ();
  bar (3);
  for (i = 0; i < 8; ++i)
if (S[i] != 3)
  abort ();
  return 0;
}



-- 
   What|Removed |Added

 CC||rth at gcc dot gnu dot org


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

[Bug c++/19403] New: name lookup is broken

[Woebbeking at web dot de]

Hi, 
 
the following code doesn't compile: 
 
struct A {}; 
 
namespace Boo 
{ 
struct B 
{ 
friend struct A; 
 
B(const A&) {}; 
}; 
} 
 
int main() 
{ 
A a; 
Boo::B b(a); 
return 0; 
} 
 
It compiles with g++ < 4.0.

-- 
   Summary: name lookup is broken
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Woebbeking at web dot de
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug target/7525] [ARM/Thumb] long calls stubs only in one code section, cannot branch to them from other section

[rearnsha at gcc dot gnu dot org]

--- Additional Comments From rearnsha at gcc dot gnu dot org  2005-01-12 
18:11 ---
In the general case of calling library support functions, this really needs
fixing in the linker.  I'm going to fix this for the specific case of
__call_via_ because this is necessary to generate code that conforms to the
EABI (__call_via_ isn't a recognized library entry point).

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rearnsha at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2004-01-26 15:43:48 |2005-01-12 18:11:28
   date||


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

[Bug c++/19263] [3.4/4.0 regression]: wrong-code: explicit inicialization of v8qi miscompiled

[jakub at gcc dot gnu dot org]

--- Additional Comments From jakub at gcc dot gnu dot org  2005-01-12 18:30 
---
Tested to also test static initializers:
typedef signed char v8qi __attribute__ ((vector_size (8)));

extern "C" void abort (void);

static unsigned char S[16];

struct A
{
  int i;
  v8qi j, k;
  int l;
};

void
foo (unsigned char v)
{
  A a = { 1, { v, v, v, v, v, v, v, v },
  { v + 1, v + 1, v + 1, v + 1, v + 1, v + 1, v + 1, v + 1 }, 3 };
  v8qi *s = (v8qi *) &S[0];
  *s = a.j;
  s[1] = a.k;
}

void
bar (unsigned char v)
{
  v8qi val8 = { v, v, v, v, v, v, v, v };
  v8qi *s = (v8qi *) &S[0];
  *s = val8;
}

int n = 5, cnt;

int
num (void)
{
  ++cnt;
  return n;
}

void
baz (void)
{
  static A a = { 0, { num (), num (), num (), num (), 6, 6, 6, 6 },
 { 7, 7, 7, 7, 8, 8, 8, 8 }, 0 };
  v8qi *s = (v8qi *) &S[0];
  *s = a.j;
  s[1] = a.k;
}

int
main ()
{
  int i;
  foo (1);
  for (i = 0; i < 8; ++i)
if (S[i] != 1)
  abort ();
  for (; i < 16; ++i)
if (S[i] != 2)
  abort ();
  bar (3);
  for (i = 0; i < 8; ++i)
if (S[i] != 3)
  abort ();
  baz ();
  if (cnt != 4)
abort ();
  for (i = 0; i < 16; ++i)
if (S[i] != 5 + (i / 4))
  abort ();
  return 0;
}

Works with G++ 3.2.x, fails with 3.4.x and mainline, even with:
--- typeck2.c.jj2005-01-12 18:34:32.0 +0100
+++ typeck2.c   2005-01-12 19:19:28.602047217 +0100
@@ -348,8 +348,9 @@ split_nonconstant_init_1 (tree dest, tre
 case VECTOR_TYPE:
   if (!initializer_constant_valid_p (init, type))
{
+ tree cons = copy_node (init);
  CONSTRUCTOR_ELTS (init) = NULL;
- code = build (MODIFY_EXPR, type, dest, init);
+ code = build (MODIFY_EXPR, type, dest, cons);
  code = build_stmt (EXPR_STMT, code);
  pcode = &TREE_CHAIN (code);
}

patch.

-- 


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

[Bug c++/19403] [4.0 Regression] name lookup is broken with friends

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-12 
18:42 ---
: Search converges between 2004-11-25-014001-trunk (#656) and 
2004-11-25-161001-trunk 
(#657).

Yes this is valid code. we should have found the global A for the statement 
"friend struct A;" but instead 
it adds a class to the namespace Boo which is wrong.

I am alomst certain it is caused by one of the "Friend class name lookup" 
patches.

-- 
   What|Removed |Added

 CC||lerdsuwa at users dot
   ||sourceforge dot net
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||rejects-valid
   Last reconfirmed|-00-00 00:00:00 |2005-01-12 18:42:20
   date||
Summary|name lookup is broken   |[4.0 Regression] name lookup
   ||is broken with friends
   Target Milestone|--- |4.0.0


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

[Bug c++/19404] New: error: 'QSizePolicy::' uses anonymous type

[Woebbeking at web dot de]

Hi, 
 
the following Code doesn't compile: 
 
 
class Base; 
 
 
template 
inline 
Base& 
operator<<(Base& rConfiguration, 
   Type const& rType) 
{ 
return rConfiguration; 
} 
 
 
template 
inline 
Base const& 
operator>>(Base const& rConfiguration, 
   Type& rType) 
{ 
return rConfiguration; 
} 
 
 
struct QSizePolicy 
{ 
enum { HSize = 6, HMask = 0x3f, VMask = HMask << HSize }; 
 
enum SizeType { Fixed = 0 }; 
 
SizeType verData() const { return (SizeType)( (data & VMask) >> HSize ); } 
 
void setVerData( SizeType d ) { data = (unsigned int)(data & ~(HMask << 
HSize)) | 
(d << HSize); } 
 
unsigned int data; 
}; 
 
It compiles with g++ < 4.0. 
 
 
Cheers, 
André

-- 
   Summary: error: 'QSizePolicy::' uses anonymous
type
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Woebbeking at web dot de
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/19404] [4.0 Regression] error: 'QSizePolicy::' uses anonymous type

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-12 
18:53 ---
Confirmed, reduced testcase:
class Base; 
template 
inline  Base const& operator>>(Base const& rConfiguration, Type& rType) ;
enum { HSize = 6, HMask = 0x3f, VMask = HMask << HSize }; 
int verData(unsigned int data){ return (int)( (data & VMask) >> HSize ); } 

Note it start failing after "2004-12-11".

This is valid code we should reject the template as it does not fit with the 
arguments.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||rejects-valid
   Last reconfirmed|-00-00 00:00:00 |2005-01-12 18:53:44
   date||
Summary|error:  |[4.0 Regression] error:
   |'QSizePolicy::' uses anonymous type  |enum>' uses anonymous type
   Target Milestone|--- |4.0.0


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

[Bug target/19405] New: [4.0 Regression] 18_support/numeric_limits.cc fails on ppc-darwin (long doubles)

[pinskia at gcc dot gnu dot org]

The long double part of 18_support/numeric_limits.cc started to fail when the 
following patch was 
applied:
2005-01-06  Geoffrey Keating  <[EMAIL PROTECTED]>

* c-cppbuiltin.c (builtin_define_float_constants): Set __*_EPSILON__
for IBM long double format correctly.

Which means that the epsilon definition is not correct any more as this 
libstdc++ tests (almong other 
things "1.0+epsilon != 1.0" so we are getting an asser from that.

-- 
   Summary: [4.0 Regression] 18_support/numeric_limits.cc fails on
ppc-darwin (long doubles)
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,geoffk at apple dot com
GCC target triplet: powerpc-darwin


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

[Bug target/19405] [4.0 Regression] 18_support/numeric_limits.cc fails on ppc-darwin (long doubles)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-12 
18:57 ---
http://gcc.gnu.org/ml/gcc-regression/2005-01/msg00021.html

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-01-12 18:57:36
   date||
   Target Milestone|--- |4.0.0


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

[Bug c++/19263] [3.4/4.0 regression]: wrong-code: explicit inicialization of v8qi miscompiled

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-12 
19:16 ---
Patch here: .

-- 
   What|Removed |Added

   Keywords||patch


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

[Bug c++/19403] [4.0 Regression] name lookup is broken with friends

[gdr at integrable-solutions dot net]

--- Additional Comments From gdr at integrable-solutions dot net  
2005-01-12 19:37 ---
Subject: Re:  [4.0 Regression] name lookup is broken with friends

"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:

| : Search converges between 2004-11-25-014001-trunk (#656) and 
2004-11-25-161001-trunk 
| (#657).
| 
| Yes this is valid code. we should have found the global A for the statement 
"friend struct A;" but instead 
| it adds a class to the namespace Boo which is wrong.

Excuse me?

The behaviour mandated by the C++ standard is that if there is no
declaration for type A in the innermost enclosing namespace then an
implicit one is added -- because A is used unqualified.  In
particular, the global A should not be found. Thus the code is
ill-formed.
The PR should be closed as invalid.

-- Gaby


-- 


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

[Bug c++/14513] Friend name injection problem (implicit declaration)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-12 
19:47 ---
*** Bug 19403 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||Woebbeking at web dot de


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

[Bug c++/19403] [4.0 Regression] name lookup is broken with friends

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-12 
19:47 ---
(In reply to comment #2)
> Excuse me?

You are right, but what is werid here is that ICC even in strict mode and 
Comeau accept the code.

This is invalid code and a dup of bug 14513.

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

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/19379] [4.0 Regression] ICE during build of newlib's e_atan2.c when soft-float

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2005-01-12 19:47 
---
In reply to comment #5:

Perhaps I am out of touch with what's extant in the embedded space.
I havn't been paid to care about that in quite some time.  I'll defer.

Using "-MASK_80387|-MASK_FLOAT_RETURNS" is incorrect.  It should
be "-(MASK_80387|MASK_FLOAT_RETURNS)".  I agree with Ralf's later
comment that -mno-80387 and -msoft-float should probably stay in
sync.  Though of course -msoft-float doesn't really mean as much
as it sounds like it ought in conjunction with -mfpmath.

In reply to comment #7:

Yes, I did mean trap #7 handler for an fpu emulator.  Though of
course there are different levels of emulation.  One thing that
has been done before for MIPS is to provide a trap handler, but
only implement the move instructions.  This allows the ABI to
remain unchanged by pretending that the appropriate registers
exist, but not having to incur most of the overhead for trapping
for all arithmetic instructions.

Since RTEMS is multilibed, this is much less of an advantage.

In any case, Joel, would you please take ownership of this bug
and see it through?  You're the one that would have to be doing
the RTEMS testing anyway...

-- 
   What|Removed |Added

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


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

[Bug bootstrap/18033] --disable-aix64 doesn't remove ppc64 from multilib list

[dje at gcc dot gnu dot org]

--- Additional Comments From dje at gcc dot gnu dot org  2005-01-12 20:30 
---
confirmed

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-01-12 20:30:12
   date||


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

[Bug bootstrap/18033] --disable-aix64 doesn't remove ppc64 from multilib list

[dje at gcc dot gnu dot org]

--- Additional Comments From dje at gcc dot gnu dot org  2005-01-12 20:30 
---
config-ml.in bug

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dje at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2005-01-12 20:30:12 |2005-01-12 20:30:39
   date||


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

[Bug bootstrap/18033] --disable-aix64 doesn't remove ppc64 from multilib list

[dje at gcc dot gnu dot org]

--- Additional Comments From dje at gcc dot gnu dot org  2005-01-12 20:31 
---
config-ml.in see the option surrounded by single quotes and it does not match.

Index: config-ml.in
===
RCS file: /cvs/gcc/gcc/config-ml.in,v
retrieving revision 1.32
diff -c -p -r1.32 config-ml.in
*** config-ml.in7 Nov 2004 23:37:28 -   1.32
--- config-ml.in12 Jan 2005 20:28:36 -
*** ml_realsrcdir=${srcdir}
*** 108,113 
--- 108,118 
  ml_verbose=--verbose
  for option in ${ac_configure_args}
  do
+ # strip single quotes added unconditionally by autoconf 2.59
+   case $option in
+   \'*\') option=`echo $option | sed -e s/^\'// -e s/\'$//`
+   esac
+ 
case $option in
--*) ;;
-*) option=-$option ;;


-- 


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

[Bug c++/19404] [4.0 Regression] anonymous types and templates and rejecting valid code

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-12 
20:35 ---
The only patch which makes sense (as it is not really that bogus really as 
shown in this example):
PR c++/17413
* pt.c (check_instantiated_args): Remove bogus SFINAE code.

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org, mmitchel at gcc dot gnu
   ||dot org


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

[Bug middle-end/19402] __builtin_powi? still missing

[rguenth at tat dot physik dot uni-tuebingen dot de]

-- 
   What|Removed |Added

 CC||rguenth at tat dot physik
   ||dot uni-tuebingen dot de


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

[Bug c++/19406] New: ICE: in force_decl_die, at dwarf2out.c:12442

[Woebbeking at web dot de]

Hi, 
 
I get the mentioned ICE if I compile the following code with -g 
(gcc < 4 works fine): 
 
struct A 
{ 
virtual int foo(); 
 
double d; 
}; 
 
 
struct B : public A 
{ 
A::d; 
}; 
 
 
int main() 
{ 
return 0; 
} 
 
 
Cheers, 
André

-- 
   Summary: ICE: in force_decl_die, at dwarf2out.c:12442
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Woebbeking at web dot de
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/19406] [4.0 Regression] ICE: in force_decl_die, at dwarf2out.c:12442

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-12 
21:06 ---
: Search converges between 2004-01-27-trunk (#442) and 2004-01-28-trunk (#443).

Confirmed.

Caused by:
2004-01-27  Devang Patel  <[EMAIL PROTECTED]>

* name-lookup.c: Include "debug.h"
(do_namespace_alias): Invoke debug_hooks to emit debug info
for namespace alias.
(do_local_using_decl): Invoke debug_hooks to emit debug info
for using decl.
(do_class_using_decl): Same.
(do_toplevel_using_decl): Same.
(do_using_directive): Same.
(cp_emit_debug_info_for_using): New function.
* Make-lang.in (cp/parser.o): Depend on debug.h
(cp/name-lookup.o): Same.

-- 
   What|Removed |Added

 CC||dpatel at apple dot com
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||ice-on-valid-code
   Last reconfirmed|-00-00 00:00:00 |2005-01-12 21:06:16
   date||
Summary|ICE: in force_decl_die, at  |[4.0 Regression] ICE: in
   |dwarf2out.c:12442   |force_decl_die, at
   ||dwarf2out.c:12442
   Target Milestone|--- |4.0.0


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