[Bug target/19511] [4.0 Regression] ICE in in reload_cse_simplify_operands, at postreload.c:391

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2005-01-20 06:58 
---
Fixed.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug regression/19174] wrong code regression or library problem in gcc-4.0-20041226

[rth at gcc dot gnu dot org]

-- 
Bug 19174 depends on bug 19511, which changed state.

Bug 19511 Summary: [4.0 Regression] ICE in in reload_cse_simplify_operands, at 
postreload.c:391
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19511

   What|Old Value   |New Value

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

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

[Bug target/19511] [4.0 Regression] ICE in in reload_cse_simplify_operands, at postreload.c:391

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-01-20 
06:47 ---
Subject: Bug 19511

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

Modified files:
gcc: ChangeLog 
gcc/config/i386: i386.c i386.h i386.md 

Log message:
PR target/19511
* config/i386/i386.c (ix86_preferred_reload_class): Return a proper
subclass of the input class.
(ix86_secondary_memory_needed): Always true for cross-MMX classes.
Always true for cross-SSE1 classes.  Rationalize conditionals.
* config/i386/i386.h (SSE_CLASS_P, MMX_CLASS_P): Use straight equality.
* config/i386/i386.md (movsi_1): Add MMX/SSE zeros.  Fix alternatives
for SSE1.  Don't check TARGET_INTER_UNIT_MOVES.
(movdi_2): Add MMX/SSE zeros.
(movdi_1_rex64): Likewise.  Don't check TARGET_INTER_UNIT_MOVES.
(movsf_1): Don't check TARGET_INTER_UNIT_MOVES.
(zero_extendsidi2_32, zero_extendsidi2_rex64): Likewise.
(movsi_1_nointernunit, movdi_1_rex64_nointerunit): Remove.
(movsf_1_nointerunit, zero_extendsidi2_32_1): Remove.
(zero_extendsidi2_rex64_1): Remove.
(MOV0 peephole): Check GENERAL_REG_P.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7195&r2=2.7196
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.c.diff?cvsroot=gcc&r1=1.782&r2=1.783
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.h.diff?cvsroot=gcc&r1=1.418&r2=1.419
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.md.diff?cvsroot=gcc&r1=1.607&r2=1.608



-- 


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

[Bug target/19427] [4.0 Regression] gcc.c-torture/execute/simd-1.c compilation fails for i686 with -msse

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2005-01-20 06:37 
---
Fixed.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug target/19427] [4.0 Regression] gcc.c-torture/execute/simd-1.c compilation fails for i686 with -msse

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-01-20 
06:35 ---
Subject: Bug 19427

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

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

Log message:
PR target/19427
* config/i386/i386.c (ix86_expand_vector_set): Fix third and fourth
shufps elements.
(ix86_expand_vector_extract): Likewise.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7194&r2=2.7195
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.c.diff?cvsroot=gcc&r1=1.781&r2=1.782



-- 


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

[Bug c++/19476] Missed null checking elimination with new

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-20 
06:29 ---
Diego raised some questions about this around the same time I filed it so 
confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-01-20 06:29:09
   date||


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

[Bug ada/19539] missing operand: B * -A

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-20 
06:25 ---
Hmm, is *- special operand in Ada or is this just a parse error in the 
front-end (I don't know Ada that at 
all, well I know enough to be able to read it a little).
But you can reproduce it with the following also with out the use of a function:
procedure X is
  B : float;
begin
  B := 90.0;
  B := B*-B;
end;


-- 
   What|Removed |Added

Summary|missing operand: 90.0 * -   |missing operand: B * -A
   |Sin(A)  |


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

[Bug c++/18098] zero covariant return pointer adjustment results in segfault

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-20 
06:14 ---
We can easy see the problem on the mainline by looking at the tree dumps:
  [pr18098.cc : 31] D.1709 = [pr18098.cc : 31] top (this);
  [pr18098.cc : 31] D.1707 = D.1709;
  [pr18098.cc : 31] D.1710 = D.1707;
  [pr18098.cc : 31] D.1711 = (int (*__vtbl_ptr_type) (void) * *) D.1710;
  [pr18098.cc : 31] D.1712 = *D.1711;


Note how we dereference D.1711 but this is also the return value from top where 
the problem comes 
from.

-- 
   What|Removed |Added

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


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

[Bug target/19293] avr-gcc crashes when using shifts with negative shift count

[bernie at develer dot com]

--- Additional Comments From bernie at develer dot com  2005-01-20 05:46 
---
(In reply to comment #10)
> Hi, 
>  
> here is the changed patch for avr.c . I hope that it is now compliant to the 
> gcc coding standards. I however did not understand what you have meant with 
> "this hunk adds spurious whitespace". 

There's a change of one line that adds a single
whitespace after an opening brace.

Also, there's an if-block that has the braces
indented by one space instead of two spaces.

Sorry for being picky.  I'll fix these before
committing if the patch gets approved.


-- 


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

[Bug fortran/19294] intrinsic_transpose.f90 runtime crash

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-20 
04:37 ---
Newest patch posted here: 
.

-- 


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

[Bug c++/19508] [4.0 regression] dwarf2, ICE on __attribute__(aligned) in class template

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-20 
04:36 ---
Hmm, after applying the attributes we get:

nonlocal VOID file t.cc line 4
align 1 context > attributes 
result >
   >

Notice how we have a copy in TREE_TYPE, the orginal which we would have done 
correctly is in 
DECL_ORIGINAL_TYPE.

-- 
   What|Removed |Added

   Last reconfirmed|2005-01-18 17:20:18 |2005-01-20 04:36:26
   date||


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

[Bug target/18956] [hppa] 'bus error' at runtime while passing a special struct to a C++ member function

[danglin at gcc dot gnu dot org]

-- 
   What|Removed |Added

 CC||danglin at gcc dot gnu dot
   ||org


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

[Bug target/18956] [hppa] 'bus error' at runtime while passing a special struct to a C++ member function

[danglin at gcc dot gnu dot org]

--- Additional Comments From danglin at gcc dot gnu dot org  2005-01-20 
04:25 ---
I can reproduce this 3.3.3 and 3.4.3.  However, 4.0.0 doesn't have the
problem.  While this problem may be target specific (ie., a big endian
target with downward padding for structures), I don't believe this is
actually a target specific problem.

The 3.4.3 code generated in main to call "foo" looks like this:

stw %r2,-20(%r30)
copy %r3,%r1
copy %r30,%r3
stwm %r1,128(%r30)
stw %r3,-4(%r30)
stw %r26,-36(%r3)
stw %r25,-40(%r3)
ldw 16(%r3),%r19
stw %r19,-54(%r30)
ldh 20(%r3),%r19
sth %r19,-50(%r30)
ldo 8(%r3),%r26
ldi 0,%r25
ldi 0,%r24
.CALL ARGW0=GR,ARGW1=GR,ARGW2=GR
bl _ZN1A3fooEii12WrongPadding,%r2
nop

The "stw %r19,-54(%r30)" insn is a misaligned store and causes the problem.

I also can't duplicate the problem in C.  In that case, half-word loads and
stores are used for storing the struct to the stack for the call.  Thus, I
suspect that this actually is a C++ bug.


-- 


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

[Bug c++/19508] [4.0 regression] dwarf2, ICE on __attribute__(aligned) in class template

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-20 
04:25 ---
We get <<< Unknown tree: template_type_parm >>> in is_base_type, that seems 
wrong

-- 


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

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

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2005-01-20 04:22 
---
Fixed.

-- 
   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED


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

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

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-01-20 
04:18 ---
Subject: Bug 19304

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-01-20 04:18:08

Modified files:
gcc: ChangeLog expr.c 

Log message:
PR middle-end/19304
* expr.c (emit_move_change_mode): New argument force; use
simplify_gen_subreg if true.
(emit_move_via_alt_mode): Merge into ...
(emit_move_via_integer): ... here.
(emit_move_ccmode): Use emit_move_change_mode directly.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7193&r2=2.7194
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/expr.c.diff?cvsroot=gcc&r1=1.770&r2=1.771



-- 


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

[Bug c/17913] [4.0 Regression] ICE jumping into statement expression

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-20 
04:15 ---
Note with --disable-checking I still get an ICE but this time a seg fault.

-- 


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

[Bug target/19518] [alpha] unrecognizable insn (set (reg:V4HI) (const_vector:V4HI)) with builtins

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |4.0.0


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

[Bug target/19518] [alpha] unrecognizable insn (set (reg:V4HI) (const_vector:V4HI)) with builtins

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2005-01-20 04:13 
---
Fixed.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug libstdc++/19495] basic_string::_M_rep() can produce an unnaturally aligned pointer to _Rep

[gdr at integrable-solutions dot net]

--- Additional Comments From gdr at integrable-solutions dot net  
2005-01-20 04:08 ---
Subject: Re:  basic_string::_M_rep() can produce an unnaturally aligned pointer 
to _Rep

"pcarlini at suse dot de" <[EMAIL PROTECTED]> writes:

| This is way I'm proposing, *for 4.0, only for 4.0*, to document
| a bit some weaknesses wrt alignment, which we always had, only
| implicitly, and change a bit the ext/array_allocator things to
| not trigger problems, currently (see patch posted on the v3 list)
| 
| Sounds reasonable?

Works for me.


-- Gaby


-- 


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

[Bug rtl-optimization/18427] [meta-bug] We need a better register allocator

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-20 
04:01 ---
I should note that I added the keyword ra but that is because even after this 
meta-bug goes away (when 
we get a better register allocator) we can still still track problems which are 
caused by the register 
allocator.

-- 


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

[Bug target/19518] [alpha] unrecognizable insn (set (reg:V4HI) (const_vector:V4HI)) with builtins

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-01-20 
03:59 ---
Subject: Bug 19518

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-01-20 03:59:01

Modified files:
gcc: ChangeLog 
gcc/config/alpha: alpha-protos.h alpha.c alpha.h alpha.md 
  predicates.md 
Added files:
gcc/testsuite/gcc.target/alpha: alpha.exp pr19518.c 

Log message:
PR target/19518
* config/alpha/alpha.c (alpha_rtx_costs): Handle HIGH.
(alpha_preferred_reload_class): Handle CONST_VECTOR.
(alpha_emit_set_const_1): Add no_output parameter; don't emit
rtl if true.
(alpha_emit_set_const): Likewise.  Make static.
(alpha_emit_set_long_const): Make static.
(alpha_extract_integer): Split out from alpha_expand_mov.
(alpha_split_const_mov): Likewise.
(alpha_expand_mov): Use them.  Handle CONST_VECTOR.
(alpha_legitimate_constant_p): New.
* config/alpha/alpha-protos.h: Update.
* config/alpha/alpha.h (REGISTER_MOVE_COST): Correct fp<->gp cost.
(LEGITIMATE_CONSTANT_P): Re-implement with a function.
* config/alpha/alpha.md (movsi): Add n alternative.
(movsi_nt_vms, movdi_er_nofix, movdi_er_fix, movdi_fix): Likewise.
(mov_fix, mov_nofix): Add i alternative.
(splitters for all of the above): Use alpha_split_const_mov.
* config/alpha/predicates.md (non_add_const_operand): New.
(non_zero_const_operand): New.
(input_operand): Use alpha_legitimate_constant_p after reload.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7192&r2=2.7193
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/alpha/alpha-protos.h.diff?cvsroot=gcc&r1=1.59&r2=1.60
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/alpha/alpha.c.diff?cvsroot=gcc&r1=1.407&r2=1.408
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/alpha/alpha.h.diff?cvsroot=gcc&r1=1.236&r2=1.237
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/alpha/alpha.md.diff?cvsroot=gcc&r1=1.231&r2=1.232
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/alpha/predicates.md.diff?cvsroot=gcc&r1=1.2&r2=1.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/alpha/alpha.exp.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/alpha/pr19518.c.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug fortran/19294] intrinsic_transpose.f90 runtime crash

[phython at gcc dot gnu dot org]

--- Additional Comments From phython at gcc dot gnu dot org  2005-01-20 
03:35 ---
Created an attachment (id=7999)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7999&action=view)
Make transpose_c[48] functions


-- 
   What|Removed |Added

Attachment #7962 is|0   |1
   obsolete||
 AssignedTo|unassigned at gcc dot gnu   |phython at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED


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

[Bug ada/19539] New: missing operand: 90.0 * -Sin(A)

[dave at synergy dot org]

As the repro included shows:

A := 90.0;
B := 30.0 * -Sin(A);

fails with a missing operand compile-time error, but:

A := 90.0;
B := -Sin(A);
B := 30 * B;

works.

with Ada.Numerics.Elementary_Functions;
use Ada.Numerics.Elementary_Functions;

procedure X is

  A : float;
  B : float;

begin
  A := 90.0;
  -- This works.
  B := -Sin(A);
  B := B * 30.0;
  -- This produces a compile-time error: x.adb:15:14: missing operand
  B := 30.0 * -Sin(A);
end;

-- 
   Summary: missing operand: 90.0 * -Sin(A)
   Product: gcc
   Version: 3.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dave at synergy dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i586-suse-linux
  GCC host triplet: i586-suse-linux
GCC target triplet: i586-suse-linux


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

[Bug c++/19208] [3.4/4.0 Regression] Spurious error about variably modified type

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2005-01-20 
03:08 ---
Testing a patch

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |giovannibajo at libero dot
   |dot org |it
 Status|NEW |ASSIGNED
   Last reconfirmed|2004-12-30 14:27:10 |2005-01-20 03:08:01
   date||


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

[Bug target/18617] missed volatile variable optimizations

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Keywords||ra


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

[Bug c++/19299] [4.0 Regression] ICE with volatile non-PODs pointers

[dnovillo at redhat dot com]

--- Additional Comments From dnovillo at redhat dot com  2005-01-20 02:32 
---
Subject: Re:  [4.0 Regression] ICE with volatile non-PODs pointers

pinskia at gcc dot gnu dot org wrote:

>>$ gcc/xgcc -Bgcc -O2 -c pr19299.C --version
>>xgcc (GCC) 4.0.0 20050117 (experimental)
>>
> 
> 
> --version makes the compiler to do nothing except for printing out the 
> version.
> 
I know.  I collapsed both outputs for brevity.

Never mind.  I was using a --disabled-checking binary.


Diego.


-- 


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

Re: [Bug c++/19299] [4.0 Regression] ICE with volatile non-PODs pointers

[Diego Novillo]

pinskia at gcc dot gnu dot org wrote:
$ gcc/xgcc -Bgcc -O2 -c pr19299.C --version
xgcc (GCC) 4.0.0 20050117 (experimental)


--version makes the compiler to do nothing except for printing out the version.
I know.  I collapsed both outputs for brevity.
Never mind.  I was using a --disabled-checking binary.
Diego.

[Bug target/19530] MMX load intrinsic produces SSE superflus instructions (movlps)

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Keywords||ra


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

[Bug c++/19299] [4.0 Regression] ICE with volatile non-PODs pointers

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-20 
02:23 ---
(In reply to comment #6)
> Works for me.  What's the problem?
Or does it, see below. 

> $ gcc/xgcc -Bgcc -O2 -c pr19299.C --version
> xgcc (GCC) 4.0.0 20050117 (experimental)
> 

--version makes the compiler to do nothing except for printing out the version.

It still ICEs for me:
[zhivago:gcc/objdir/gcc] pinskia% ./xgcc -B. t43.cc 
t43.cc: In function 'void execute(volatile V*)':
t43.cc:7: internal compiler error: in create_tmp_var, at gimplify.c:368
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

GNU C++ version 4.0.0 20050119 (experimental) (powerpc-apple-darwin7.7.0)


-- 


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

[Bug c++/19299] [4.0 Regression] ICE with volatile non-PODs pointers

[dnovillo at gcc dot gnu dot org]

--- Additional Comments From dnovillo at gcc dot gnu dot org  2005-01-20 
02:17 ---

Works for me.  What's the problem?

$ gcc/xgcc -Bgcc -O2 -c pr19299.C --version
xgcc (GCC) 4.0.0 20050117 (experimental)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.



-- 


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

[Bug rtl-optimization/5739] "const" and "pure" function attributes pessimize code

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Keywords||ra
   Last reconfirmed|2004-08-26 00:38:25 |2005-01-20 02:17:01
   date||


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

[Bug libstdc++/19535] Wrong return types for __pair_get<1>

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-01-20 02:16 
---
Fixed, thanks Pétur.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug libstdc++/19535] Wrong return types for __pair_get<1>

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-01-20 
02:14 ---
Subject: Bug 19535

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

Modified files:
libstdc++-v3   : ChangeLog 
libstdc++-v3/include/tr1: utility 
Added files:
libstdc++-v3/testsuite/tr1/6_containers/utility: 19535.cc 

Log message:
2005-01-19  Paolo Carlini  <[EMAIL PROTECTED]>

PR libstdc++/19535
* include/tr1/utility (struct __pair_get<1>::__get, __const_get):
Fix typo in the return type.
* testsuite/tr1/6_containers/utility/19535.cc: New.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcc&r1=1.2862&r2=1.2863
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/tr1/utility.diff?cvsroot=gcc&r1=1.2&r2=1.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/tr1/6_containers/utility/19535.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug c++/19299] [4.0 Regression] ICE with volatile non-PODs pointers

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2005-01-20 
02:09 ---
For the log, this is blocking Boost (test: python/bienstman1).

-- 


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

[Bug c++/19538] Missing diagnostic for typedef name in elaborated type specifier

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-20 
01:56 ---
Confirmed.  [2] was PR 11036 by the way.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||accepts-invalid, diagnostic
   Last reconfirmed|-00-00 00:00:00 |2005-01-20 01:56:59
   date||


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

[Bug c++/19538] New: Missing diagnostic for typedef name in elaborated type specifier

[austern at apple dot com]

Consider the following code sample:

struct A { };
typedef struct A A;
struct A a; // [1]

struct wrapper {
  struct B { };
  typedef struct B B;
  struct B b;   // [2]
};

Mainline gives an error for line [2], but not for line [1].  My reading of the 
standard is that there 
shouldn't be any difference.  In both cases we're using an elaborated type 
specifier with a name that 
resolves to a typedef-name.  A program that does that is ill formed, so the 
compiler is required to 
admit a diagnostic.  We're doing that for line [2], but we're failing to do it 
for line [1].

Relevant passages in the standard: 3.4.4/2, 7.1.3/4, 7.1.5.3/2.

-- 
   Summary: Missing diagnostic for typedef name in elaborated type
specifier
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: austern at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: powerpc-apple-darwin7.7.0
  GCC host triplet: powerpc-apple-darwin7.7.0
GCC target triplet: powerpc-apple-darwin7.7.0


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

[Bug libstdc++/19510] [4.0 regression] Warning using list iterators

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2005-01-20 
01:47 ---
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01280.html

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |reichelt at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Keywords||monitored, patch
   Last reconfirmed|2005-01-18 20:20:05 |2005-01-20 01:47:54
   date||


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

[Bug tree-optimization/17884] asm 'volatile' is not honored as documented

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2005-01-20 01:33 
---
In reply to comment #20:

Again, this is not scheduling, per se.  This is register
rematerialization.  We have a value at some point, and we
decide that it's cheaper to move the computation rather
than store and reload it.

This is really no different than if we decided to CSE the
computation as in

__fnstsw(&s1);
__fldenv(envp->x87);/* volatile */
__fnstsw(&s2);
->
__fnstsw(&s1);
__fldenv(envp->x87);/* volatile */
s2 = s1;

I must repeat myself that the original source code is 
buggy.  You've got asms that affect, or are affected by,
architectural state that is not visible to the compiler.
As such you REALLY REALLY MUST mark the asm as volatile.

-- 


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

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

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-20 
01:15 ---
(In reply to comment #45)
>From -details .optimized file:
> Coalesce list: (0)ivtmp.3_12 & (1)ivtmp.3_20 [map: 0, 1] : Fail due to 
> conflict
Huh, how do they conflict, I don't see how.

Hmm, I assume that tree-ssa-live is wrong here.

-- 


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

[Bug target/19427] [4.0 Regression] gcc.c-torture/execute/simd-1.c compilation fails for i686 with -msse

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2005-01-20 01:02 
---
Testing a patch.

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rth at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2005-01-14 07:17:07 |2005-01-20 01:03:00
   date||


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

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

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-20 
00:46 ---
Here is another reduced testcase:
  subroutine thin6d(max)
  parameter(maxindex=64)
  common array1(maxindex)
  save
  do 20 j=1,max
array1(j)=1.0
   20   continue
  return
  end


but note disabling ivopts "fixes" the problem but it is not caused by ivopts 
per say this time:
Before out of SSA:
  # ivtmp.6_21 = PHI ;
  # ivtmp.3_12 = PHI <0(1), ivtmp.3_20(3)>;
:;
  [thin6d.f : 6] *ivtmp.6_21 = 1.0e+0;

__label_20:;
  ivtmp.3_20 = ivtmp.3_12 + 1;
  ivtmp.6_22 = ivtmp.6_21 + 4B;
  [thin6d.f : 1] D.493_30 = D.451_4 - 1;
  [thin6d.f : 1] D.494_31 = () D.493_30;
  [thin6d.f : 1] D.495_32 = D.494_31 + 1;
  [thin6d.f : 5] if (ivtmp.3_20 == D.495_32) [thin6d.f : 5] goto ; else 
goto ;

Note this is looks very normal and like it should work correctly (except for 
the ((cast)(a-1))+1 but I 
know Zdenek has a patch for that).

But for some reason (have not looked actually) we add an extra BB in out of SSA:
:;
  [thin6d.f : 6] *ivtmp.6 = 1.0e+0;

__label_20:;
  ivtmp.10 = ivtmp.3 + 1;
  ivtmp.6 = ivtmp.6 + 4B;
  [thin6d.f : 5] if (ivtmp.10 == () (D.451 - 1) + 1) [thin6d.f : 
5] goto ; else goto 
;

:;
  ivtmp.3 = ivtmp.10;
  goto  ();

Looks like we are not coalescing the following PHI:
  # ivtmp.3_12 = PHI <0(1), ivtmp.3_20(3)>;

But why not.

-- 


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

[Bug target/18404] unnecessary sll when -mint64 (MIPS)

[echristo at redhat dot com]

--- Additional Comments From echristo at redhat dot com  2005-01-20 00:37 
---
The discussion was held offline between Richard Sandiford and I. 

Having a -mint64 option changes the abi for anything that is built with that
option and in no abi defined for mips is int defined to 64. You may want longs
equal to 64-bit which I can easily understand, especially for 64-bit
architectures. Pointers can also be 64-bit under the n64 abi (-mabi=64).

As far as 64-bit ints being "natural", in fact, only the unicosmk abi for alpha
(not the rest of the port) defines the size of an integer to 64-bit or allows 
it.

-eric

-- 


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

[Bug libstdc++/19495] basic_string::_M_rep() can produce an unnaturally aligned pointer to _Rep

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-01-20 00:34 
---
Hi Gaby,

> Yes.  Basically, we need to have tha aligned attribute work correctly.

Agreed, in principle: indeed, we are filing together and taking care of
many PRs in this area.

> | is not present in the original design. I don't think we can implement it
> | now, for 4.0, without changing the ABI. I think we should just document
> | that for our current basic_string memory rerurned by the allocator should
> | be maximally aligned (in some cases less aligned is ok, but details become
> | tricky to spell out).
>
> I rather we fix it.  Remember, this is more an optimization issue
> than a semantics issue.  An optimization issue that had causes us
> more trouble than benefits I believe.  I don't believe it is wise 
> for us to go that path down putting more an more restrictions.
> With people playing with fancy allocator around, it is likely that
> we're going to have more and more of this issue popping up.

Again, in principle I agree, but remember that:
1- It's almost impossible (see messages from Mark) that the
__attribute__(aligned) machinery will be satisfactorily fixed for
4.0.
2- We do *not* want to break the ABI for 4.0, in particular, in
the basic_string area. Indeed, as you can see, we are always
monitoring check-abi and very careful about everything (see
constructor / assignment issue of yesterday)

This is way I'm proposing, *for 4.0, only for 4.0*, to document
a bit some weaknesses wrt alignment, which we always had, only
implicitly, and change a bit the ext/array_allocator things to
not trigger problems, currently (see patch posted on the v3 list)

Sounds reasonable?

-- 
   What|Removed |Added

 CC||gdr at integrable-solutions
   ||dot net


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

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

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-20 
00:31 ---
(In reply to comment #43)
> (In reply to comment #42)
> > Now it is back to out of ssa causing one extra BB.
> I will try get a smaller testcase for this problem now.  Thanks Zdenek for 
> fixing the IV-OPTs related 
> problem.

Here is the reduced fortran testcase (I tried to convert it to C but I must not 
be matching all the syntax 
correctly) and change the names so I would not get into trouble with SPEC:
  subroutine function11(max)
  parameter(maxindex=64)
  common array1(maxindex),array2(maxindex)
  save
  do 20 j=1,max
array1(j)=array2(j)
   20   continue
  return
  end


-- 


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

[Bug tree-optimization/14741] missing transformations lead to poorly optimized code

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-19 
23:38 ---
We now get:
L33:
lfd f13,0(r11)
add r11,r11,r8
lfd f0,0(r10)
addi r10,r10,8
fmadd f0,f13,f0,f12
fmr f12,f0
bdnz L33

Which is much better, thanks Zdenek.

The only problem left looks a coalescing problem with out of ssa
Before out of ssa:
  # ivtmp.89_54 = PHI ;
  # lsm_tmp.85_52 = PHI ;
  # k_3 = PHI <1(2), k_7(3)>;
:;
  D.529_38 = k_3 * stride.10_5;
  D.530_39 = i_2 + D.529_38;
  D.531_40 = offset.11_9 + D.530_39;
  D.532_42 = (*a_41)[D.531_40];
  b_30 = ivtmp.89_54;
  D.536_47 = *b_30;
  D.537_48 = D.532_42 * D.536_47;
  D.538_49 = D.537_48 + lsm_tmp.85_52;
  D.773_12 = () k_3;
  D.774_8 = D.773_12 + 1;
  k_7 = (int4) D.774_8;
  ivtmp.89_33 = ivtmp.89_54 + 8B;
  D.771_18 = () k_7;
  D.772_17 = D.771_18 + 4294967295;
  k_13 = (int4) D.772_17;
  if (stride.10_5 == k_13) goto ; else goto ;

After:
:;
  D.538 = (*a)[offset.11 + i + k * stride.10] * *ivtmp.89 + lsm_tmp.85;
  k = (int4) (() k + 1);
  ivtmp.89 = ivtmp.89 + 8B;
  lsm_tmp.85 = D.538;
  if (stride.10 == (int4) (() k + 4294967295)) goto ; else 
goto ;

We should have coalesced lsm_tmp.85 and D.538 together.

-- 
   What|Removed |Added

   Severity|normal  |enhancement


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

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

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-19 
23:33 ---
(In reply to comment #42)
> Now it is back to out of ssa causing one extra BB.
I will try get a smaller testcase for this problem now.  Thanks Zdenek for 
fixing the IV-OPTs related 
problem.

-- 


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

[Bug target/19492] can not build crosscompiler for solaris2.8 (when building libstdc++ - error wcslen...:Link tests are not allowed after GCC_NO_EXECUTABLES)

[andreev at comm dot mot dot com]

--- Additional Comments From andreev at comm dot mot dot com  2005-01-19 
23:27 ---
Created an attachment (id=7998)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7998&action=view)
libstdc++-v3/config.log

Andrew, here is the config.log. It has errors about _dlopen(close, etc), but
i've checked the libraries (they are in $target/lib directory and they have
those functions).
/opt/SOLsdk/target/i686-pc-solaris2.8> cat 1.c 
int main( void )
{
_dlopen( "aa", "bb" );
return 0;
}
/opt/SOLsdk/target/i686-pc-solaris2.8> gcc 1.c lib/libdl.so.1
/opt/SOLsdk/target/i686-pc-solaris2.8> /opt/SOLsdk/bin/i686-pc-solaris2.8-nm
lib/lib 
/opt/SOLsdk/target/i686-pc-solaris2.8> /opt/SOLsdk/bin/i686-pc-solaris2.8-nm
lib/libdl.so.1
 A SUNW_0.7
 A SUNW_0.8
 A SUNW_1.1
 A SUNW_1.2
 A SUNW_1.3
 A SUNWprivate_1.1
0074 D _DYNAMIC
077c b _END_
 A _PROCEDURE_LINKAGE_TABLE_
 d _START_
0760 T _dladdr
0754 T _dlclose
0764 T _dldump
0758 T _dlerror
0734 T _dlinfo
073c t _dlmap
0740 T _dlmopen
0748 T _dlopen
074c T _dlsym
 A _edata
077c B _end
0775 B _etext
076c T _ld_concurrency
0770 T _ld_libc
0778 b dbg_mask
0760 W dladdr
0754 W dlclose
0764 W dldump
0758 W dlerror
0734 W dlinfo
073c t dlmap
0740 W dlmopen
0748 W dlopen
074c W dlsym
/opt/SOLsdk/target/i686-pc-solaris2.8> 


-- 


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

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

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-19 
23:25 ---
Now it is back to out of ssa causing one extra BB.

-- 
   What|Removed |Added

Summary|[4.0 Regression] ivopts |[4.0 Regression] out of ssa
   |causing loops to have more  |causing loops to have more
   |than one BB |than one BB


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

[Bug bootstrap/19468] gcc+binutils combined fails bootstrap

[hp at gcc dot gnu dot org]

--- Additional Comments From hp at gcc dot gnu dot org  2005-01-19 23:12 
---
...and closed as invalid, as this is a binutils bug.  See comment #2.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug bootstrap/19468] gcc+binutils combined fails bootstrap

[hp at gcc dot gnu dot org]

--- Additional Comments From hp at gcc dot gnu dot org  2005-01-19 23:11 
---
Reopened as it's not a duplicate... (wait for it)

-- 
   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|DUPLICATE   |


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

[Bug c++/19448] Different value representation for bitfield width exceeding its type size.

[janis at gcc dot gnu dot org]

--- Additional Comments From janis at gcc dot gnu dot org  2005-01-19 23:08 
---
Mark closed this based on early comments discussing invalid code, but later
comments discuss a problem with valid code.

-- 
   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

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

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-01-19 
22:50 ---
Subject: Bug 19038

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-01-19 22:50:06

Modified files:
gcc: ChangeLog tree-ssa-loop-ivopts.c 

Log message:
PR tree-optimization/19038
* tree-ssa-loop-ivopts.c (allow_ip_end_pos_p): New function.
(add_candidate): Add ivs with increment in latch only if
allow_ip_end_pos_p is true.
(determine_iv_cost): Use empty_block_p.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7191&r2=2.7192
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-loop-ivopts.c.diff?cvsroot=gcc&r1=2.41&r2=2.42



-- 


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

[Bug objc/18408] [4.0 Regression] ICE compiling code that involves casting classes

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-19 
22:49 ---
(In reply to comment #9)
> Objective-C is not part of the release criteria; removing target milestone.

I should note that this PR blocks building GNUstep with 4.0.0.

-- 


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

[Bug objc/18408] [4.0 Regression] ICE compiling code that involves casting classes

[mmitchel at gcc dot gnu dot org]

--- Additional Comments From mmitchel at gcc dot gnu dot org  2005-01-19 
22:46 ---
Objective-C is not part of the release criteria; removing target milestone.

-- 
   What|Removed |Added

   Target Milestone|4.0.0   |---


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

[Bug objc/19324] [3.4/4.0 Regression] weird message for interface way in implementation

[mmitchel at gcc dot gnu dot org]

--- Additional Comments From mmitchel at gcc dot gnu dot org  2005-01-19 
22:46 ---
Objective-C is not part of the release criteria; removing target milestone.

-- 
   What|Removed |Added

   Target Milestone|3.4.4   |---


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

[Bug objc/18862] [4.0 Regression] ICE on gcc-4.0-20041205/gcc/testsuite/objc.dg/selector-1.m

[mmitchel at gcc dot gnu dot org]

--- Additional Comments From mmitchel at gcc dot gnu dot org  2005-01-19 
22:46 ---
Objective-C is not part of the release criteria; removing target milestone.

-- 
   What|Removed |Added

   Target Milestone|4.0.0   |---


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

[Bug java/19295] [4.0 regression] Incorrect bytecode produced for bitwise AND

[mark at codesourcery dot com]

--- Additional Comments From mark at codesourcery dot com  2005-01-19 22:44 
---
Subject: Re:  [4.0 regression] Incorrect bytecode produced
 for bitwise AND

steven at gcc dot gnu dot org wrote:
> --- Additional Comments From steven at gcc dot gnu dot org  2005-01-19 
> 19:24 ---
> Mark, can we keep known wrong-code bugs targeted for 4.0 please?  Java/Ada 
> or other languages shouldn't make a difference for wrong code bugs.  They 
> are the most serious kind we have. 

I'm changing things so that only release-blockers have the 4.0 target. 
Java bugs are never release-blockers.  I'm writing up an email about 
this which I hope to send out today.

Thanks,



-- 


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

[Bug java/19295] [4.0 regression] Incorrect bytecode produced for bitwise AND

[tromey at gcc dot gnu dot org]

--- Additional Comments From tromey at gcc dot gnu dot org  2005-01-19 
22:37 ---
I'm working on this.


-- 
   What|Removed |Added

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


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

[Bug libfortran/19451] Read after a write with a read only file

[Thomas dot Koenig at online dot de]

--- Additional Comments From Thomas dot Koenig at online dot de  2005-01-19 
22:17 ---
Patch:

http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01266.html

-- 


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

[Bug libfortran/19451] Read after a write with a read only file

[Thomas dot Koenig at online dot de]

--- Additional Comments From Thomas dot Koenig at online dot de  2005-01-19 
21:35 ---
(In reply to comment #1)
> Confirmed, changing the summary a little more.
> 
> Also if the file contained anything, we seg fault when finishing the write
(which seems wrong).

Here's a test case for that:

$ cat open+write2.f90
program main
  call system("rm -f asdf.dat; echo foo > asdf.dat; chmod u-w asdf.dat")
  open(file="asdf.dat",unit=10,action="read")
  write(10,*,iostat=i) "Hello, world"
end
$ gfortran open+write2.f90
$ ./a.out
Segmentation fault

Same thing with iostat= as with err=.  Without it, things work:
$ cat open+write3.f90
program main
  call system("rm -f asdf.dat; echo foo > asdf.dat; chmod u-w asdf.dat")
  open(file="asdf.dat",unit=10,action="read")
  write(10,*) "Hello, world"
end
$ gfortran open+write3.f90
$ ./a.out
At line 4 of file open+write3.f90
Fortran runtime error: Cannot write to file opened for READ

... which is correct behaviour.

After some poking around, it seems that finalize_transfer()
insists on doing something even if ioparm.library_return
is not equal to LIBRARY_OK.

I've tried out the following patch:

Index: transfer.c
===
RCS file: /cvsroot/gcc/gcc/libgfortran/io/transfer.c,v
retrieving revision 1.26
diff -c -r1.26 transfer.c
*** transfer.c  15 Jan 2005 08:10:19 -  1.26
--- transfer.c  19 Jan 2005 21:26:07 -
***
*** 1383,1388 
--- 1383,1391 
  static void
  finalize_transfer (void)
  {
+   if (ioparm.library_return != LIBRARY_OK)
+ return;
+
if ((ionml != NULL) && (ioparm.namelist_name != NULL))
  {
 if (ioparm.namelist_read_mode)

which didn't seem to do any harm (no testcase failures) and
which appears to fix the problem, but I don't know wether this
introduces any cleanup issues.

Thomas

-- 


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

[Bug target/19529] [4.0 regression] sh-rtems multilibs broken

[corsepiu at gcc dot gnu dot org]

--- Additional Comments From corsepiu at gcc dot gnu dot org  2005-01-19 
21:31 ---
Patch commited.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug target/19529] [4.0 regression] sh-rtems multilibs broken

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-01-19 
21:25 ---
Subject: Bug 19529

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-01-19 21:25:35

Modified files:
gcc: ChangeLog config.gcc 
Added files:
gcc/config/sh  : t-rtems 

Log message:
2005-01-19  Ralf Corsepius  <[EMAIL PROTECTED]>

PR target/19529
* config/sh/t-rtems: New.
* config.gcc (sh-*-rtems*): Reflect having added config/sh/t-rtems.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7189&r2=2.7190
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config.gcc.diff?cvsroot=gcc&r1=1.508&r2=1.509
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/sh/t-rtems.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug target/19293] avr-gcc crashes when using shifts with negative shift count

[bjoern dot m dot haase at web dot de]

--- Additional Comments From bjoern dot m dot haase at web dot de  
2005-01-19 21:25 ---
Hi, 
 
here is the changed patch for avr.c . I hope that it is now compliant to the 
gcc coding standards. I however did not understand what you have meant with 
"this hunk adds spurious whitespace". 
 
Yours, 
 
Björn 
 
 
Index: avr.c 
=== 
RCS file: /cvsroot/gcc/gcc/gcc/config/avr/avr.c,v 
retrieving revision 1.108.4.3 
diff -U10 -r1.108.4.3 avr.c 
--- avr.c   28 Sep 2004 01:13:55 -  1.108.4.3 
+++ avr.c   19 Jan 2005 21:19:49 - 
@@ -3288,20 +3288,27 @@ 
 const char * 
 ashrqi3_out (rtx insn, rtx operands[], int *len) 
 { 
   if (GET_CODE (operands[2]) == CONST_INT) 
 { 
   int k; 
  
   if (!len) 
len = &k; 
  
+  /* Test for illegal or strange shift count.  */   
+  if ( (INTVAL (operands[2]) <= 0 ) || ( INTVAL (operands[2]) > 7) ) 
+   {  
+ *len = 0; 
+ return ""; 
+   } 
+ 
   switch (INTVAL (operands[2])) 
{ 
case 1: 
  *len = 1; 
  return AS1 (asr,%0); 
  
case 2: 
  *len = 2; 
  return (AS1 (asr,%0) CR_TAB 
  AS1 (asr,%0)); 
@@ -3357,20 +3364,27 @@ 
 { 
   if (GET_CODE (operands[2]) == CONST_INT) 
 { 
   int scratch = (GET_CODE (PATTERN (insn)) == PARALLEL); 
   int ldi_ok = test_hard_reg_class (LD_REGS, operands[0]); 
   int k; 
   int *t = len; 

   if (!len) 
len = &k; 
+  
+  /* Test for illegal or strange shift count.  */  
+  if ( (INTVAL (operands[2]) <= 0) || (INTVAL (operands[2]) > 15) ) 
+{  
+  *len = 0; 
+  return ""; 
+} 
  
   switch (INTVAL (operands[2])) 
{ 
case 4: 
case 5: 
  /* XXX try to optimize this too? */ 
  break; 
  
case 6: 
  if (optimize_size) 
@@ -3517,21 +3531,27 @@ 
 const char * 
 ashrsi3_out (rtx insn, rtx operands[], int *len) 
 { 
   if (GET_CODE (operands[2]) == CONST_INT) 
 { 
   int k; 
   int *t = len; 

   if (!len) 
len = &k; 
-   
+ 
+  /* Test for illegal or strange shift count.  */ 
+  if ((INTVAL (operands[2]) <= 0) || (INTVAL (operands[2])>31))  
+{  
+  *len = 0; 
+  return ""; 
+}  
   switch (INTVAL (operands[2])) 
{ 
case 8: 
  { 
int reg0 = true_regnum (operands[0]); 
int reg1 = true_regnum (operands[1]); 
*len=6; 
if (reg0 <= reg1) 
  return (AS2 (mov,%A0,%B1) CR_TAB 
  AS2 (mov,%B0,%C1) CR_TAB 
@@ -3633,20 +3653,27 @@ 
 const char * 
 lshrqi3_out (rtx insn, rtx operands[], int *len) 
 { 
   if (GET_CODE (operands[2]) == CONST_INT) 
 { 
   int k; 
  
   if (!len) 
len = &k; 

+  /* Test for illegal or not useful shift count.  */ 
+  if ( (INTVAL (operands[2]) <= 0) | (INTVAL (operands[2]) > 7) )  
+{  
+  *len = 0; 
+  return ""; 
+} 
+ 
   switch (INTVAL (operands[2])) 
{ 
default: 
  *len = 1; 
  return AS1 (clr,%0); 
  
case 1: 
  *len = 1; 
  return AS1 (lsr,%0); 
  
@@ -3719,29 +3746,36 @@ 
  insn, operands, len, 1); 
   return ""; 
 } 
  
 /* 16bit logic shift right ((unsigned short)x >> i) */ 
  
 const char * 
 lshrhi3_out (rtx insn, rtx operands[], int *len) 
 { 
   if (GET_CODE (operands[2]) == CONST_INT) 
-{ 
+{  
   int scratch = (GET_CODE (PATTERN (insn)) == PARALLEL); 
   int ldi_ok = test_hard_reg_class (LD_REGS, operands[0]); 
   int k; 
   int *t = len; 
  
   if (!len) 
len = &k; 

+  /* Test for illegal or not useful shift count.  */  
+  if ((INTVAL (operands[2]) <= 0) || (INTVAL (operands[2]) > 15))  
+   {  
+ *len = 0; 
+ return ""; 
+   } 
+
   switch (INTVAL (operands[2])) 
{ 
case 4: 
  if (optimize_size && scratch) 
break;  /* 5 */ 
  if (ldi_ok) 
{ 
  *len = 6; 
  return (AS1 (swap,%B0)  CR_TAB 
  AS1 (swap,%A0)  CR_TAB 
@@ -3977,20 +4011,27 @@ 
 const char * 
 lshrsi3_out (rtx insn, rtx operands[], int *len) 
 { 
   if (GET_CODE (operands[2]) == CONST_INT) 
 { 
   int k; 
   int *t = len; 

   if (!len) 
len = &k; 
+  
+  /* Test for illegal or not useful shift counts.  */  
+  if ((INTVAL (operands[2]) <= 0) || (INTVAL (operands[2]) > 31)) 
+{  
+  *len = 0; 
+  return ""; 
+}; 

   switch (INTVAL (operands[2])) 
{ 
case 8: 
  { 
int reg0 = true_regnum (operands[0]); 
int reg1 = true_regnum (operands[1]); 
   

[Bug regression/19174] wrong code regression or library problem in gcc-4.0-20041226

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2005-01-19 21:21 
---
Yes, it's certainly possible.  But indeed pr19511 shows that you can't even get
that far with --with-arch=pentium3 at the moment, due to changes that post-date
this report.

After I get a fix for that problem, will you please re-test?  Hopefully I'll 
have magically fixed this problem which was never sufficiently isolated...

-- 
   What|Removed |Added

  BugsThisDependsOn||19511


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

[Bug target/19492] can not build crosscompiler for solaris2.8 (when building libstdc++ - error wcslen...:Link tests are not allowed after GCC_NO_EXECUTABLES)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-19 
19:40 ---
(In reply to comment #6)
> (In reply to comment #5)
> > This config.log:
> > ./i686-pc-solaris2.8/libstdc++-v3/config.log
> 
> Andrew, there is no such file, look at comment #2

I copied and pasted from comment #2 :) so either I did something wrong, or you 
just misunderstood 
me.

-- 


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

[Bug target/19492] can not build crosscompiler for solaris2.8 (when building libstdc++ - error wcslen...:Link tests are not allowed after GCC_NO_EXECUTABLES)

[andreev at comm dot mot dot com]

--- Additional Comments From andreev at comm dot mot dot com  2005-01-19 
19:38 ---
(In reply to comment #5)
> This config.log:
> ./i686-pc-solaris2.8/libstdc++-v3/config.log

Andrew, there is no such file, look at comment #2

-- 


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

[Bug target/19492] can not build crosscompiler for solaris2.8 (when building libstdc++ - error wcslen...:Link tests are not allowed after GCC_NO_EXECUTABLES)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-19 
19:36 ---
This config.log:
./i686-pc-solaris2.8/libstdc++-v3/config.log

-- 


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

[Bug target/19492] can not build crosscompiler for solaris2.8 (when building libstdc++ - error wcslen...:Link tests are not allowed after GCC_NO_EXECUTABLES)

[andreev at comm dot mot dot com]

--- Additional Comments From andreev at comm dot mot dot com  2005-01-19 
19:33 ---
There is no config.log file in libstdc++ directory. And I have 
target's /usr/lib and /usr/include directories in location specified by --with-
sysroot

-- 
   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug java/16885] [4.0 Regression] java/awt/Container.java build failure with parallel make

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-19 
19:32 ---
I just to be able to reproduce this all the time too but lately (in the last 
two months) I have not been 
able to so closing as fixed.

-- 
   What|Removed |Added

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


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

[Bug tree-optimization/18441] Vectorizer: add a command line for simple vectorizer report

[leehod at il dot ibm dot com]

--- Additional Comments From leehod at il dot ibm dot com  2005-01-19 19:28 
---
There is now a patch addressing these issues. 
See: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01247.html


-- 


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

[Bug java/19295] [4.0 regression] Incorrect bytecode produced for bitwise AND

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2005-01-19 
19:24 ---
Mark, can we keep known wrong-code bugs targeted for 4.0 please?  Java/Ada 
or other languages shouldn't make a difference for wrong code bugs.  They 
are the most serious kind we have. 
 

-- 
   What|Removed |Added

 CC||mark at codesourcery dot com


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

[Bug target/19528] [4.0 regression] missing ra.h

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2005-01-19 
18:59 ---
Good.  Ralf, can you post it? 

-- 


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

[Bug java/18190] [4.0 regression] primitive array optimization is gone

[mmitchel at gcc dot gnu dot org]

--- Additional Comments From mmitchel at gcc dot gnu dot org  2005-01-19 
18:52 ---
Ada and Java bugs are not release-critical; therefore, I've removed the target
milsetone.

-- 
   What|Removed |Added

   Target Milestone|4.0.0   |---


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

[Bug java/19295] [4.0 regression] Incorrect bytecode produced for bitwise AND

[mmitchel at gcc dot gnu dot org]

--- Additional Comments From mmitchel at gcc dot gnu dot org  2005-01-19 
18:52 ---
Ada and Java bugs are not release-critical; therefore, I've removed the target
milsetone.

-- 
   What|Removed |Added

   Target Milestone|4.0.0   |---


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

[Bug java/16885] [4.0 Regression] java/awt/Container.java build failure with parallel make

[mmitchel at gcc dot gnu dot org]

--- Additional Comments From mmitchel at gcc dot gnu dot org  2005-01-19 
18:52 ---
Ada and Java bugs are not release-critical; therefore, I've removed the target
milsetone.

-- 
   What|Removed |Added

   Target Milestone|4.0.0   |---


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

[Bug java/18399] [4.0 Regression] Class initialization optimization does not work with the inliner

[mmitchel at gcc dot gnu dot org]

--- Additional Comments From mmitchel at gcc dot gnu dot org  2005-01-19 
18:52 ---
Ada and Java bugs are not release-critical; therefore, I've removed the target
milsetone.

-- 
   What|Removed |Added

   Target Milestone|4.0.0   |---


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

[Bug ada/19456] [4.0 regression] ada bootstrap failure on alpha-linux

[mmitchel at gcc dot gnu dot org]

--- Additional Comments From mmitchel at gcc dot gnu dot org  2005-01-19 
18:51 ---
Ada and Java bugs are not release-critical; therefore, I've removed the target
milsetone.

-- 
   What|Removed |Added

   Target Milestone|4.0.0   |---


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

[Bug java/17574] [meta-bug] gcj and libgcj 4.0 tracking PR

[mmitchel at gcc dot gnu dot org]

--- Additional Comments From mmitchel at gcc dot gnu dot org  2005-01-19 
18:52 ---
Ada and Java bugs are not release-critical; therefore, I've removed the target
milsetone.

-- 
   What|Removed |Added

   Target Milestone|4.0.0   |---


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

[Bug rtl-optimization/18485] [4.0 regression] mmix-knuth-mmixware testsuite failure: g++.dg/lookup/forscope1.C g++.old-deja/g++.niklas/t132.C g++.old-deja/g++.other/singleton.C

[mmitchel at gcc dot gnu dot org]

--- Additional Comments From mmitchel at gcc dot gnu dot org  2005-01-19 
18:47 ---
MMIX is not a primary or secondary platform; removing target milestone.

-- 
   What|Removed |Added

   Target Milestone|4.0.0   |---


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

[Bug target/18335] [3.4/4.0 regression] mmix-knuth-mmixware testsuite failure: gcc.dg/debug/debug-1.c and debug-2 xyzzy

[mmitchel at gcc dot gnu dot org]

--- Additional Comments From mmitchel at gcc dot gnu dot org  2005-01-19 
18:47 ---
MMIX is not a primary or secondary platform; removing target milestone.

-- 
   What|Removed |Added

   Target Milestone|3.4.4   |---


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

[Bug target/18346] [4.0 regression] mmix-knuth-mmixware testsuite failure: gcc.dg/trampoline-1.c

[mmitchel at gcc dot gnu dot org]

--- Additional Comments From mmitchel at gcc dot gnu dot org  2005-01-19 
18:47 ---
MMIX is not a primary or secondary platform; removing target milestone.

-- 
   What|Removed |Added

   Target Milestone|4.0.0   |---


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

[Bug c++/18279] [4.0 regression] missing function bodies from -fdump-translation-unit

[mmitchel at gcc dot gnu dot org]

--- Additional Comments From mmitchel at gcc dot gnu dot org  2005-01-19 
18:45 ---
This option is only designed for use in debugging the compiler.  As it's not
designed for use by end-users, I've removed the target milestone. 

-- 
   What|Removed |Added

   Target Milestone|4.0.0   |---


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

[Bug target/14798] [3.4/4.0 Regression] In case of SH target with -O2 option #pragma interrupt doesn't get resetted.

[mmitchel at gcc dot gnu dot org]

--- Additional Comments From mmitchel at gcc dot gnu dot org  2005-01-19 
18:43 ---
SH is not a primary or secondary target; removing target milestone.

-- 
   What|Removed |Added

   Target Milestone|3.4.4   |---


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

[Bug c++/19367] [4.0 Regression] ICE: tree_check in lookup_local_die with local `using'

[pinskia at gcc dot gnu dot org]

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

-- 
   What|Removed |Added

 CC||micis at gmx dot de


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

[Bug tree-optimization/19536] ICE: tree check: lookup_decl_die, at dwarf2out.c:5415 (boost_1_32_0 utility/current_function_test)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-19 
18:41 ---
This is a dup of bug 19367 which is already reduced.

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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug tree-optimization/19534] ICE in create_tmp_var, at gimplify.c:368 (boost_1_32_0 python/bienstman1)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-19 
18:38 ---
I already reduced this, this is a dup of bug 19299.

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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/19299] [4.0 Regression] ICE with volatile non-PODs pointers

[pinskia at gcc dot gnu dot org]

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

-- 
   What|Removed |Added

 CC||micis at gmx dot de


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

[Bug c/19533] START_PAGE_GENERAL

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-19 
18:38 ---
Not a gcc bug, report this either to cygwin or mygwin as they provide the 
headers.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

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

[mmitchel at gcc dot gnu dot org]

--- Additional Comments From mmitchel at gcc dot gnu dot org  2005-01-19 
18:32 ---
MMIX is not a primary or secondary target; removing target milestone.

-- 
   What|Removed |Added

   Target Milestone|4.0.0   |---


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

[Bug target/18434] [4.0 Regression] Cannot build gnattools on Tru64 UNIX V5.1B

[mmitchel at gcc dot gnu dot org]

--- Additional Comments From mmitchel at gcc dot gnu dot org  2005-01-19 
18:24 ---
Tru64 is not a primary or secondary platform; removing target milestone.

-- 
   What|Removed |Added

   Target Milestone|4.0.0   |---


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

[Bug target/19537] New: tic4x does not build -- ICE in libgcc

[joel at gcc dot gnu dot org]

This does not appear to be the same as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14436.

binutils 2.15, gcc from CVS as or 2005-01-19.

This should be reproducible in any other tic4x target.

./gcc/configure --target=tic4x-rtems4.7 --enable-threads=rtems
--prefix=/opt/rtems-test --with-gnu-as --with-gnu-ld --with-newlib --verbose
--with-system-zlib --disable-nls --enable-version-specific-runtime-libs
--enable-languages=c


/usr3/ftp_archive/gnu/gcc/ss/b-head/b-tic4x-rtems4.7/gcc/xgcc
-B/usr3/ftp_archive/gnu/gcc/ss/b-head/b-tic4x-rtems4.7/gcc/ -nostdinc
-B/usr3/ftp_archive/gnu/gcc/ss/b-head/b-tic4x-rtems4.7/tic4x-rtems4.7/newlib/
-isystem
/usr3/ftp_archive/gnu/gcc/ss/b-head/b-tic4x-rtems4.7/tic4x-rtems4.7/newlib/targ-include
-isystem /usr3/ftp_archive/gnu/gcc/ss/b-head/gcc/newlib/libc/include
-B/opt/rtems-test/tic4x-rtems4.7/bin/ -B/opt/rtems-test/tic4x-rtems4.7/lib/
-isystem /opt/rtems-test/tic4x-rtems4.7/include -isystem
/opt/rtems-test/tic4x-rtems4.7/sys-include -O2
-I../../gcc/gcc/../newlib/libc/sys/rtems/include -DIN_GCC -DCROSS_COMPILE   -W
-Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include  -Dexit=unused_exit -g
-DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I
-I../../gcc/gcc -I../../gcc/gcc/ -I../../gcc/gcc/../include
-I../../gcc/gcc/../libcpp/include  -DL_subvsi3 -c ../../gcc/gcc/libgcc2.c -o
libgcc/./_subvsi3.o
../../gcc/gcc/libgcc2.c: In function '__do_global_ctors':
../../gcc/gcc/libgcc2.c:1674: internal compiler error: in integer_all_onesp, at
tree.c:995
Please submit a full bug report,

-- 
   Summary: tic4x does not build -- ICE in libgcc
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joel at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: tic4x-rtems, tic4x-*


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

[Bug rtl-optimization/19462] generating return insns while current_function_epilogue_delay_list nonempty

[hp at gcc dot gnu dot org]

--- Additional Comments From hp at gcc dot gnu dot org  2005-01-19 17:18 
---
All committed to main trunk.
(May reopen for branches.)

-- 
   What|Removed |Added

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


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

[Bug tree-optimization/19536] ICE: tree check: lookup_decl_die, at dwarf2out.c:5415 (boost_1_32_0 utility/current_function_test)

[micis at gmx dot de]

--- Additional Comments From micis at gmx dot de  2005-01-19 17:11 ---
Created an attachment (id=7994)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7994&action=view)
preprocessed source


-- 


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

[Bug tree-optimization/19536] New: ICE: tree check: lookup_decl_die, at dwarf2out.c:5415 (boost_1_32_0 utility/current_function_test)

[micis at gmx dot de]

I build gcc from the actual snapshot gcc-4.0-20050116.
When I compile boost_1_32_0 I get an ICE when I execute the self tests.
This ICE only occurs if I use the "-g" option.

Michael Cieslinski

g++ -g -c -o current_function_test.o  current_function_test.ii
../libs/utility/test/../current_function_test.cpp: In function 'void message
(const char*, long int, const char*, const char*)':
../libs/utility/test/../current_function_test.cpp:27: internal compiler error: 
tree check: expected class 'declaration', have 'exceptional' (@@dummy) in 
lookup_decl_die, at dwarf2out.c:5415
Please submit a full bug report, with preprocessed source if appropriate.

gcc -v
Using built-in specs.
Configured with: ../gcc40/configure --with-arch=opteron --enable-
languages=c,c++ --enable-checking
Thread model: posix
gcc version 4.0.0 20050116 (experimental)

-- 
   Summary: ICE: tree check: lookup_decl_die, at dwarf2out.c:5415
(boost_1_32_0 utility/current_function_test)
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: micis at gmx dot de
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug debug/19521] [4.0 Regression] omitted stab for gcov initialization function

[stuart at apple dot com]

--- Additional Comments From stuart at apple dot com  2005-01-19 17:08 
---
> So the bug is the end stab without the start stab?

Yes.

> Or do you think that this
> bit of code that corresponds not at all to any user code should have full 
> stabs?

My personal preference is a mild "yes."  But I can forsee that others will
disagree, and I recognize the validity of that position.

> If the later, why?

When I'm grubbing through a broken binary, it's helpful when the debugger tells
me that this function body didn't come from the user's sourcecode.  In general,
"more information is better."

I suppose the counterargument would be that most users don't look at the
assembly code, don't want to know about these functions, and would prefer
smaller debug information for faster linking and development.

I assume that most GCC users are unlike me, this I infer their argument wins.  I
can live with that; this is not a big deal either way.

If the debugger already knows the name of this function, and the stabs are not
adding any useful information, then I agree they're a waste and should be
omitted.  The big deal is that the begin/end stabs should match, both emitted or
both omitted.

-- 


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

[Bug libstdc++/19535] Wrong return types for __pair_get<1>

[peturr02 at ru dot is]

--- Additional Comments From peturr02 at ru dot is  2005-01-19 17:06 ---
Created an attachment (id=7993)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7993&action=view)
Test case

Compiling this fails with:

g++0116 -Wall  -static  1.cc   -o 1
/usr/local/lib/gcc/i686-pc-linux-gnu/4.0.0/include/c++/tr1/utility: In function
‘typename std::tr1::tuple_element<_Int, std::pair<_Tp1, _Tp2> >::type&
std::tr1::get(std::pair<_Tp1, _Tp2>&) [with int _Int = 1, _Tp1 = A, _Tp2 = B]’:

1.cc:9:   instantiated from here
/usr/local/lib/gcc/i686-pc-linux-gnu/4.0.0/include/c++/tr1/utility:80: error:
invalid initialization of reference of type ‘B&’ from expression of type ‘A’
/usr/local/lib/gcc/i686-pc-linux-gnu/4.0.0/include/c++/tr1/utility: In function
‘const typename std::tr1::tuple_element<_Int, std::pair<_Tp1, _Tp2> >::type&
std::tr1::get(const std::pair<_Tp1, _Tp2>&) [with int _Int = 1, _Tp1 = B, _Tp2
= A]’:
1.cc:12:   instantiated from here
/usr/local/lib/gcc/i686-pc-linux-gnu/4.0.0/include/c++/tr1/utility:85: error:
invalid initialization of reference of type ‘const A&’ from expression of type
‘const B’
/usr/local/lib/gcc/i686-pc-linux-gnu/4.0.0/include/c++/tr1/utility: In static
member function ‘static _Tp1& std::tr1::__pair_get<1>::__get(std::pair<_T1,
_T2>&) [with _Tp1 = A, _Tp2 = B]’:
/usr/local/lib/gcc/i686-pc-linux-gnu/4.0.0/include/c++/tr1/utility:80:  
instantiated from ‘typename std::tr1::tuple_element<_Int, std::pair<_Tp1, _Tp2>
>::type& std::tr1::get(std::pair<_Tp1, _Tp2>&) [with int _Int = 1, _Tp1 = A,
_Tp2 = B]’
1.cc:9:   instantiated from here
/usr/local/lib/gcc/i686-pc-linux-gnu/4.0.0/include/c++/tr1/utility:70: error:
invalid initialization of reference of type ‘A&’ from expression of type ‘B’
/usr/local/lib/gcc/i686-pc-linux-gnu/4.0.0/include/c++/tr1/utility: In static
member function ‘static const _Tp1& std::tr1::__pair_get<1>::__const_get(const
std::pair<_T1, _T2>&) [with _Tp1 = B, _Tp2 = A]’:
/usr/local/lib/gcc/i686-pc-linux-gnu/4.0.0/include/c++/tr1/utility:85:  
instantiated from ‘const typename std::tr1::tuple_element<_Int, std::pair<_Tp1,
_Tp2> >::type& std::tr1::get(const std::pair<_Tp1, _Tp2>&) [with int _Int = 1,
_Tp1 = B, _Tp2 = A]’
1.cc:12:   instantiated from here
/usr/local/lib/gcc/i686-pc-linux-gnu/4.0.0/include/c++/tr1/utility:74: error:
invalid initialization of reference of type ‘const B&’ from expression of type
‘const A’
make: *** [1] Error 1


-- 


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

[Bug rtl-optimization/19462] generating return insns while current_function_epilogue_delay_list nonempty

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-01-19 
17:04 ---
Subject: Bug 19462

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-01-19 17:04:25

Modified files:
gcc/testsuite  : ChangeLog 
gcc/testsuite/gcc.dg/torture: pr19462-1.c 

Log message:
PR rtl-optimization/19462
* gcc.dg/torture/pr19462-1.c: Remove token xfail marker.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4910&r2=1.4911
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/torture/pr19462-1.c.diff?cvsroot=gcc&r1=1.1&r2=1.2



-- 


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

[Bug libstdc++/19535] New: Wrong return types for __pair_get<1>

[peturr02 at ru dot is]

In tr1/utility:

  template<>
struct __pair_get<1>
{
  template
  static _Tp1& __get(std::pair<_Tp1, _Tp2>& __pair)
  { return __pair.second; }

  template
  static const _Tp1& __const_get(const std::pair<_Tp1, _Tp2>& __pair)
  { return __pair.second; }
};

These functions should return (const) _Tp2&, since the type of __pair.second
is _Tp2.

-- 
   Summary: Wrong return types for __pair_get<1>
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: peturr02 at ru dot is
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/19448] Different value representation for bitfield width exceeding its type size.

[janis187 at us dot ibm dot com]

--- Additional Comments From janis187 at us dot ibm dot com  2005-01-19 
17:04 ---
Mark, your response addresses the original message but not the later ones, and
not either of the attached test cases.  In those the class is:

class bc {
public:
  char m1 :17;
};

m1 is assigned a value of 1, which certainly fits.

-- 


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