[Bug c++/20710] New: g++ should warn when hiding non-virtual method in base class

[loose at astron dot nl]

I was wondering whether it is possible to have GCC produce a warning
whenever a non-virtual method in the base class is hidden by a method in the
derived class. I know this is possible for virtual methods by using
the -Woverload-virtual switch, but I haven't been able to find the
equivalent for non-virtual methods.

For example, I would like GCC to produce a warning about the following code.

$ cat tHide.cc
class A
{
public:
  void f() {}
};

class B : public A
{
public:
  void f(int) {}
};

int main()
{
  A a;
  B b;
  b.f(10);
  a.f();
}

Something like: warning: void A::f() was hidden by void B::f(int)

$ g++ -v -save-temps -Wall -Wextra tHide.cc
Reading specs from /usr/local/gcc343/lib/gcc/i686-pc-linux-gnu/3.4.3/specs
Configured with: ../gcc-3.4.3/configure --prefix=/usr/local/gcc343 --enable-
threads=posix
Thread model: posix
gcc version 3.4.3
 /usr/local/gcc343/libexec/gcc/i686-pc-linux-gnu/3.4.3/cc1plus -E -quiet -v -
D_GNU_SOURCE tHide.cc -mtune=pentiumpro -Wall -Wextra -o tHide.ii
ignoring nonexistent directory "/usr/local/gcc343/lib/gcc/i686-pc-linux-
gnu/3.4.3/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/gcc343/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../include/c++/3.4.3
 /usr/local/gcc343/lib/gcc/i686-pc-linux-
gnu/3.4.3/../../../../include/c++/3.4.3/i686-pc-linux-gnu
 /usr/local/gcc343/lib/gcc/i686-pc-linux-
gnu/3.4.3/../../../../include/c++/3.4.3/backward
 /usr/local/include
 /usr/local/gcc343/include
 /usr/local/gcc343/lib/gcc/i686-pc-linux-gnu/3.4.3/include
 /usr/include
End of search list.
 /usr/local/gcc343/libexec/gcc/i686-pc-linux-gnu/3.4.3/cc1plus -fpreprocessed 
tHide.ii -quiet -dumpbase tHide.cc -mtune=pentiumpro -auxbase tHide -Wall -
Wextra -version -o tHide.s
GNU C++ version 3.4.3 (i686-pc-linux-gnu)
compiled by GNU C version 3.4.3.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
 as -V -Qy -o tHide.o tHide.s
GNU assembler version 2.13.90.0.18 (i386-redhat-linux) using BFD version 
2.13.90.0.18 20030206
 /usr/local/gcc343/libexec/gcc/i686-pc-linux-gnu/3.4.3/collect2 --eh-frame-hdr -
m elf_i386 -dynamic-linker /lib/ld-
linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o /usr/local/gcc343/lib/gcc/i686-pc-
linux-gnu/3.4.3/crtbegin.o -L/usr/local/gcc343/lib/gcc/i686-pc-linux-gnu/3.4.3 -
L/usr/local/gcc343/lib/gcc/i686-pc-linux-gnu/3.4.3/../../.. tHide.o -lstdc++ -
lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/local/gcc343/lib/gcc/i686-pc-linux-
gnu/3.4.3/crtend.o /usr/lib/crtn.o

-- 
   Summary: g++ should warn when hiding non-virtual method in base
class
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: loose at astron dot nl
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug rtl-optimization/20600] [4.1 regression] failure for pass.c on x86_64-pc-linux-gnu

[bonzini at gcc dot gnu dot org]

--- Additional Comments From bonzini at gcc dot gnu dot org  2005-04-01 
08:25 ---
Committed fix at http://gcc.gnu.org/ml/gcc-cvs/2005-04/msg00019.html

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/19454] [4.0 Regression] bad code generated with gcc.c-torture/execute/bf64-1.c at -O1

[bonzini at gcc dot gnu dot org]

-- 
Bug 19454 depends on bug 20600, which changed state.

Bug 20600 Summary: [4.1 regression] failure for pass.c on x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20600

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

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

[Bug c++/20629] internal compiler error: in cp_tree_equal, at cp/tree.c:1552

[steven at gcc dot gnu dot org]

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-04-01 10:40:37
   date||


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

[Bug c++/20629] internal compiler error: in cp_tree_equal, at cp/tree.c:1552

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2005-04-01 
10:43 ---
Seen in wxGTK on i386:
../../../../contrib/src/ogl/drawn.cpp:1019: internal compiler error: in
cp_tree_equal, at cp/tree.c:1552
../../../../contrib/src/ogl/mfutils.cpp:157: internal compiler error: in
cp_tree_equal, at cp/tree.c:1552



-- 


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

[Bug c++/20711] New: accept-invalid definition not in enclosing namespace

[smcpeak at cs dot berkeley dot edu]

In the C++ standard, section 9.3 paragraph 2:

  "A member function definition that appears outside of the class definition
   shall appear in a namespace scope enclosing the class definition."

This is similar to 7.3.1.2p2 except for class members.

Therefore, the following code should be rejected:

  namespace NS1 {
struct S {
  int foo();
};
  }

  namespace NS2 {
int NS1::S::foo() { return 0; }
  }

but g++-3.4.3 does not reject it, and issues no warnings with -Wall.

Intel C++ 8.1 properly rejects it.

-- 
   Summary: accept-invalid definition not in enclosing namespace
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: minor
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: smcpeak at cs dot berkeley dot edu
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=20711

[Bug middle-end/19454] [4.0 Regression] bad code generated with gcc.c-torture/execute/bf64-1.c at -O1

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-01 
11:23 ---
Subject: Bug 19454

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-04-01 11:23:08

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

Log message:
2005-04-01  Paolo Bonzini  <[EMAIL PROTECTED]>

PR middle-end/19454
PR rtl-optimization/20600

* combine.c (gen_binary): Remove.
(known_cond, simplify_shift_const, find_split_point,
combine_simplify_rtx, simplify_if_then_else, simplify_set,
simplify_logical, expand_field_assignment, extract_left_shift,
force_to_mode, if_then_else_cond, apply_distributive_law,
simplify_and_const_int, simplify_shift_const, gen_lowpart_for_combine,
simplify_comparison, reversed_comparison): Replace with
simplify_gen_binary, simplify_gen_relational or
distribute_and_simplify_rtx.
(distribute_and_simplify_rtx): New function.

* config/i386/i386.c (ix86_decompose_address): Look inside SUBREGs
to fix addresses involving EBP and ESP.
(aligned_operand, legitimate_address_p, ix86_address_cost): Be prepared
for SUBREGed registers.
(legitimate_address_p): Accept SUBREGed registers.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.107&r2=2.7592.2.108
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/combine.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.475.4.1&r2=1.475.4.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.795.6.1&r2=1.795.6.2



-- 


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

[Bug rtl-optimization/20600] [4.1 regression] failure for pass.c on x86_64-pc-linux-gnu

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-01 
11:23 ---
Subject: Bug 20600

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-04-01 11:23:08

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

Log message:
2005-04-01  Paolo Bonzini  <[EMAIL PROTECTED]>

PR middle-end/19454
PR rtl-optimization/20600

* combine.c (gen_binary): Remove.
(known_cond, simplify_shift_const, find_split_point,
combine_simplify_rtx, simplify_if_then_else, simplify_set,
simplify_logical, expand_field_assignment, extract_left_shift,
force_to_mode, if_then_else_cond, apply_distributive_law,
simplify_and_const_int, simplify_shift_const, gen_lowpart_for_combine,
simplify_comparison, reversed_comparison): Replace with
simplify_gen_binary, simplify_gen_relational or
distribute_and_simplify_rtx.
(distribute_and_simplify_rtx): New function.

* config/i386/i386.c (ix86_decompose_address): Look inside SUBREGs
to fix addresses involving EBP and ESP.
(aligned_operand, legitimate_address_p, ix86_address_cost): Be prepared
for SUBREGed registers.
(legitimate_address_p): Accept SUBREGed registers.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.107&r2=2.7592.2.108
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/combine.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.475.4.1&r2=1.475.4.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.795.6.1&r2=1.795.6.2



-- 


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

[Bug middle-end/15700] [4.0 Regression] [unit-at-a-time] Inlining problem leads to miscompilation of glibc

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-01 
11:39 ---
Subject: Bug 15700

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-04-01 11:38:53

Modified files:
gcc/testsuite  : ChangeLog 

Log message:
Add missing entry from yesterday:
2005-03-31  J"orn Rennecke <[EMAIL PROTECTED]>

Fix fallout from PR middle-end/15700:
* gcc.c-torture/compile/2009-1.c: Take
__USER_LABEL_PREFIX__ into account.
* gcc.c-torture/compile/2009-2.c: Likewise.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5259&r2=1.5260



-- 


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

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

[pcarlini at suse dot de]

-- 
   What|Removed |Added

   Severity|normal  |enhancement


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

[Bug inline-asm/20712] New: asm code depends on position of function in the source

[y_s_r at list dot ru]

The following 3 equvalent variants of the same primitive program should lead to
the same code, but they don't:

1. C source:

static inline int f1();
static inline int f2();

int main() { f1(); }
static inline int f1() { f2(); }
static inline int f2() { return 1; }

Its assembler output:

.file   "main_1.c"
.version"01.01"
gcc2_compiled.:
.text
.align 4
.globl main
.typemain,@function
main:
pushl   %ebp
movl%esp, %ebp
pushl   %eax
pushl   %eax
leave
jmp f1
.Lfe1:
.sizemain,.Lfe1-main
.align 4
.typef1,@function
f1:
pushl   %ebp
movl%esp, %ebp
pushl   %edx
pushl   %edx
leave
jmp f2
.Lfe2:
.sizef1,.Lfe2-f1
.align 4
.typef2,@function
f2:
pushl   %ebp
movl$1, %eax
movl%esp, %ebp
popl%ebp
ret
.Lfe3:
.sizef2,.Lfe3-f2
.ident  "GCC: (GNU) 2.96 2731 (Red Hat Linux 7.3 2.96-110)"

2. C source:

static inline int f1();
static inline int f2();

int main() { f1(); }
static inline int f2() { return 1; }
static inline int f1() { f2(); }

Its assembler output:

.file   "main_2.c"
.version"01.01"
gcc2_compiled.:
.text
.align 4
.globl main
.typemain,@function
main:
pushl   %ebp
movl%esp, %ebp
pushl   %eax
pushl   %eax
leave
jmp f1
.Lfe1:
.sizemain,.Lfe1-main
.align 4
.typef1,@function
f1:
pushl   %ebp
movl%esp, %ebp
popl%ebp
ret
.Lfe2:
.sizef1,.Lfe2-f1
.ident  "GCC: (GNU) 2.96 2731 (Red Hat Linux 7.3 2.96-110)"

3. C source:

static inline int f1();
static inline int f2();

static inline int f2() { return 1; }
static inline int f1() { f2(); }
int main() { f1(); }

Its assembler output:

.file   "main_3.c"
.version"01.01"
gcc2_compiled.:
.text
.align 4
.globl main
.typemain,@function
main:
pushl   %ebp
movl%esp, %ebp
popl%ebp
ret
.Lfe1:
.sizemain,.Lfe1-main
.ident  "GCC: (GNU) 2.96 2731 (Red Hat Linux 7.3 2.96-110)"

In the C code automatically generated by the nesC compiler such a situation
leads to significant missing of optimization for size.

-- 
   Summary: asm code depends on position of function in the source
   Product: gcc
   Version: 2.96
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P2
 Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: y_s_r at list dot ru
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux
  GCC host triplet: i686-pc-linux
GCC target triplet: i686-pc-linux


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

[Bug fortran/18481] [g77 regression] ICE with assigned integer variable format

[Thomas dot Koenig at online dot de]

--- Additional Comments From Thomas dot Koenig at online dot de  2005-04-01 
11:45 ---
No write or print statement is necessary:

$ cat assign.f90
  program main
  assign 1000 to i
 1000 format (A)
  end
$ gfortran assign.f90
$ gfortran -fdump-parse-tree assign.f90
 In file assign.f90:2

  assign 1000 to i
 1
Warning: Obsolete: ASSIGN statement at (1)

Namespace: A-H: (REAL 4) I-N: (INTEGER 4) O-Z: (REAL 4)
symtree: i  Ambig 0
symbol i (INTEGER 4)(VARIABLE UNKNOWN-INTENT UNKNOWN-ACCESS UNKNOWN-PROC
IMPLICIT-TYPE)

symtree: main  Ambig 0
symbol main (UNKNOWN 0)(PROGRAM UNKNOWN-INTENT UNKNOWN-ACCESS 
UNKNOWN-PROC)


  LABEL ASSIGN i 1000

assign.f90: In function 'MAIN__':
assign.f90:2: internal compiler error: in gfc_add_modify_expr, at
fortran/trans.c:152
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
$
$ gfortran -v
Using built-in specs.
Target: ia64-unknown-linux-gnu
Configured with: ../gcc-4.1-20050327/configure --prefix=/home/zfkts
--enable-languages=c,f95
Thread model: posix
gcc version 4.1.0 20050327 (experimental)


-- 


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

[Bug middle-end/20635] [4.0 Regression] ICE in cgraph_mark_reachable_node

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-01 
12:41 ---
Subject: Bug 20635

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-04-01 12:41:19

Modified files:
gcc: ChangeLog varasm.c 

Log message:
PR middle-end/20635
* varasm.c (mark_decl_referenced): Do not mark extern inline functions
as needed.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.108&r2=2.7592.2.109
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/varasm.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.477.6.6&r2=1.477.6.7



-- 


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

[Bug tree-optimization/20712] asm code depends on position of function in the source

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-01 
12:54 ---
Fixed in 3.4.0 and above with unit-at-a-time.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|inline-asm  |tree-optimization
   Keywords||missed-optimization
 Resolution||FIXED
   Target Milestone|--- |3.4.0


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

[Bug fortran/20713] New: Don't pad parameter strings.

[fengwang at gcc dot gnu dot org]

character(len = 10),parameter:: a = 'hello'
print *, a, "world"
end

the output:
helloworld.

-- 
   Summary: Don't pad parameter strings.
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: fengwang at gcc dot gnu dot org
ReportedBy: fengwang at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: i686-pc-linux


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

[Bug c++/20711] accept-invalid definition not in enclosing namespace

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-01 
13:08 ---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/13140] declaration in global namespace, definition inside named or anon namespace

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-01 
13:08 ---
*** Bug 20711 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||smcpeak at cs dot berkeley
   ||dot edu


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

[Bug middle-end/20635] [4.0 Regression] ICE in cgraph_mark_reachable_node

[pinskia at gcc dot gnu dot org]

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

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/20225] [4.0/4.1 regression] ICE during GC

[pinskia at gcc dot gnu dot org]

-- 
Bug 20225 depends on bug 20635, which changed state.

Bug 20635 Summary: [4.0 Regression] ICE in cgraph_mark_reachable_node
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20635

   What|Old Value   |New Value

 Status|NEW |WAITING
 Status|WAITING |NEW
 Status|NEW |ASSIGNED
 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

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

[Bug fortran/20713] Not pad parameter strings.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-01 
13:17 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2005-04-01 13:17:55
   date||
Summary|Don't pad parameter strings.|Not pad parameter strings.


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

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

[ncm at cantrip dot org]

--- Additional Comments From ncm at cantrip dot org  2005-04-01 13:24 
---
Subject: Re:  basic_string::_M_rep() can produce an unnaturally aligned pointer 
to _Rep

On Fri, Apr 01, 2005 at 11:42:27AM -, pcarlini at suse dot de wrote:
>What|Removed |Added
> 
>Severity|normal  |enhancement
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19495

I don't see how this (or 8670, or the other one) is an enhancement 
request.  Users are absolutely allowed to make allocators that 
enforce only the alignment of the type they are instantiated on, 
and string is certainly using the wrong kind of allocator.

It's a fairly minor bug, but seems to me clearly a bug.

N


-- 


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

[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-04-01 13:31 
---
Ok, my change was only dictated by consistency, and the original idea of using
"enhancement" is not mine ;) Let's remove "enhancement" from both. By the way,
I really noticed yesterday for the first time that basic_string, which often has
requirements very similar to the other STL containers, differs in that, at
variance with the other STL containers, its allocator can have a value_type !=
CharT (in case, I would suggest not further discussing this side remark here)


-- 
   What|Removed |Added

   Severity|enhancement |normal


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

[Bug libstdc++/8670] Alignment problem in std::basic_string

[pcarlini at suse dot de]

-- 
   What|Removed |Added

   Severity|enhancement |normal


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

[Bug libfortran/20661] End of record not detected

[Thomas dot Koenig at online dot de]

--- Additional Comments From Thomas dot Koenig at online dot de  2005-04-01 
13:34 ---
This patch fixes the test case.  It also includes my
EOR patch for advancing I/O.

This is regression-tested on mainline.  I'll submit a proper
patch when I have finished regression-testing it on 4.0.

--- transfer.c.orig 2005-03-25 14:35:29.0 +0100
+++ transfer.c  2005-04-01 15:34:19.0 +0200
@@ -150,7 +150,12 @@ read_sf (int *length)
   else
 p = base = data;

-  memset(base,'\0',*length);
+  memset(base,' ',*length);
+
+  /* If we have seen an eor previously, return blanks.  */
+
+  if (sf_seen_eor)
+return base;

   current_unit->bytes_left = options.default_recl;
   readlen = 1;
@@ -179,12 +184,6 @@ read_sf (int *length)

   if (readlen < 1 || *q == '\n' || *q == '\r')
{
- /* ??? What is this for?  */
-  if (current_unit->unit_number == options.stdin_unit)
-{
-  if (n <= 0)
-continue;
-}
  /* Unexpected end of line.  */
  if (current_unit->flags.pad == PAD_NO)
{
@@ -193,8 +192,13 @@ read_sf (int *length)
}

  current_unit->bytes_left = 0;
- *length = n;
   sf_seen_eor = 1;
+
+ if (advance_status == ADVANCE_NO)
+   ioparm.library_return = LIBRARY_EOR;
+ else
+   *length = n;
+
  break;
}

@@ -748,6 +752,9 @@ formatted_transfer (bt type, void *p, in
  internal_error ("Bad format node");
}

+  if (ioparm.library_return == LIBRARY_EOR)
+   generate_error (ERROR_EOR, NULL);
+
   /* Free a buffer that we had to allocate during a sequential
 formatted read of a block that was larger than the static
 buffer.  */
@@ -1223,7 +1230,10 @@ next_record_r (int done)
   length = 1;
   /* sf_read has already terminated input because of an '\n'  */
   if (sf_seen_eor)
- break;
+   {
+ sf_seen_eor=0;
+ break;
+   }

   do
 {


-- 


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

[Bug middle-end/20714] New: emit_no_conflict_block does invalid reordering

[amylaar at gcc dot gnu dot org]

When emit_no_conflict_block is handed these insns:

(insn 597 0 598 (set (reg:SI 405)
(mem/i:SI (reg/f:SI 154 virtual-stack-vars) [0 x+0 S4 A32])) -1 (nil)
(nil))

(insn 598 597 599 (parallel [
(set (reg:SI 404)
(ashift:SI (reg:SI 405)
(const_int 1 [0x1])))
(clobber (reg:SI 147 t))
]) -1 (nil)
(nil))

(insn 599 598 600 (set (reg:SI 406)
(mem/i:SI (plus:SI (reg/f:SI 154 virtual-stack-vars)
(const_int 4 [0x4])) [0 x+4 S4 A32])) -1 (nil)
(nil))

(insn 600 599 601 (parallel [
(set (subreg:SI (reg:DI 403) 4)
(lshiftrt:SI (reg:SI 406)
(const_int 31 [0x1f])))
(clobber (reg:SI 147 t))
]) -1 (nil)
(nil))

(insn 601 600 602 (set (subreg:SI (reg:DI 403) 4)
(ior:SI (subreg:SI (reg:DI 403) 4)
(reg:SI 404))) -1 (nil)
(nil))

(insn 602 601 603 (set (reg:SI 407)
(mem/i:SI (reg/f:SI 154 virtual-stack-vars) [0 x+0 S4 A32])) -1 (nil)
(nil))

(insn 603 602 604 (set (reg:SI 408)
(const_int 0 [0x0])) -1 (nil)
(nil))

(insn 604 603 605 (set (reg:SI 147 t)
(gt:SI (reg:SI 408)
(reg:SI 407))) -1 (nil)
(nil))

(insn 605 604 0 (set (subreg:SI (reg:DI 403) 0)
(neg:SI (reg:SI 147 t))) -1 (nil)
(expr_list:REG_EQUAL (ashiftrt:SI (reg:SI 407)
(const_int 31 [0x1f]))
(nil)))

What it emits is this:

(insn 597 595 598 (set (reg:SI 405)
(mem/i:SI (reg/f:SI 154 virtual-stack-vars) [0 x+0 S4 A32])) -1 (nil)
(nil))

(insn 598 597 599 (parallel [
(set (reg:SI 404)
(ashift:SI (reg:SI 405)
(const_int 1 [0x1])))
(clobber (reg:SI 147 t))
]) -1 (nil)
(nil))

(insn 599 598 602 (set (reg:SI 406)
(mem/i:SI (plus:SI (reg/f:SI 154 virtual-stack-vars)
(const_int 4 [0x4])) [0 x+4 S4 A32])) -1 (nil)
(nil))

(insn 602 599 603 (set (reg:SI 407)
(mem/i:SI (reg/f:SI 154 virtual-stack-vars) [0 x+0 S4 A32])) -1 (nil)
(nil))

(insn 603 602 604 (set (reg:SI 408)
(const_int 0 [0x0])) -1 (nil)
(nil))

(insn 604 603 606 (set (reg:SI 147 t)
(gt:SI (reg:SI 408)
(reg:SI 407))) -1 (nil)
(nil))

(insn 606 604 600 (clobber (reg:DI 403)) -1 (nil)
(insn_list:REG_LIBCALL 607 (nil)))

(insn 600 606 601 (parallel [
(set (subreg:SI (reg:DI 403) 4)
(lshiftrt:SI (reg:SI 406)
(const_int 31 [0x1f])))
(clobber (reg:SI 147 t))
]) -1 (nil)
(nil))

(insn 601 600 605 (set (subreg:SI (reg:DI 403) 4)
(ior:SI (subreg:SI (reg:DI 403) 4)
(reg:SI 404))) -1 (nil)
(nil))

(insn 605 601 607 (set (subreg:SI (reg:DI 403) 0)
(neg:SI (reg:SI 147 t))) -1 (nil)
(expr_list:REG_EQUAL (ashiftrt:SI (reg:SI 407)
(const_int 31 [0x1f]))
(nil)))

(insn 607 605 0 (set (reg:DI 403)
(reg:DI 403)) -1 (nil)
(insn_list:REG_RETVAL 606 (expr_list:REG_EQUAL (ashiftrt:DI (mem/i:DI
(reg/f:SI 154 virtual-stack-vars) [0 x+0 S8 A32])
(const_int 31 [0x1f]))
(nil

Note that insn 600 clobbers the fixed register T that had been set by insn
604 and is needed in insn 605.

FWIW, 600 has been generated by lshrsi3, and 603-605 has been generated by
ashrsi3.

-- 
   Summary: emit_no_conflict_block does invalid reordering
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P2
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug libstdc++/20534] Erroneous #include of

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-04-01 14:26 
---
> I think it is not OK to include  or .

I agree. Actually, probably we have already briefly discussed that (privately)
with Benjamin. Is there something wrong with just using if () abort() instead?!?
(in case we can wrap it in a tiny macro to avoid writing the complete 
conditional
every time)



-- 


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

[Bug libstdc++/19995] libstdc++ fails to build correctly on AIX 5.2

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-04-01 14:34 
---
I think we can safely close this one.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug libgcj/20715] New: gcj link error

[jack dot rong at cloakware dot com]

When I tried to compile and link java application into an exacutable using GCJ 
v3.4.3 in Linux Red Hat 3.4.3-9.EL4, it produces error messages:

[EMAIL PROTECTED]:~/testarea/build$ ./gcjbuild
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.3/specs
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.3/libgcj.spec
rename spec lib to liborig
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 --disable-libunwind-
exceptions --enable-java-awt=gtk --host=i386-redhat-linux
Thread model: posix
gcc version 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)
 /usr/libexec/gcc/i386-redhat-linux/3.4.3/jc1 /tmp/ccDKDmFrjx -fhash-
synchronization -fno-use-divide-subroutine -fuse-boehm-gc -fnon-call-
exceptions -fkeep-inline-functions -quiet -dumpbase ccDKDmFrjx -auxbase 
ccDKDmFrjx -g1 -version -fjni -
fclasspath=/opt/cloakware/cspmclient_thirdparty/java/jre/lib:/opt/cloakware/csp
mclient_thirdparty/java/jre/lib/jsse.jar:/opt/cloakware/cspmclient_thirdparty/j
etty/lib/javax.servlet.jar:/opt/cloakware/cspmclient_thirdparty/jetty/ext/xmlPa
rserAPIs-2.5.jar -ffilelist-file -o /tmp/ccKdJ5dJ.s
GNU Java version 3.4.3 20041212 (Red Hat 3.4.3-9.EL4) (i386-redhat-linux)
compiled by GNU C version 3.4.3 20041212 (Red Hat 3.4.3-9.EL4).
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=129199
Class path starts here:
/opt/cloakware/cspmclient_thirdparty/java/jre/lib/
/opt/cloakware/cspmclient_thirdparty/java/jre/lib/jsse.jar/ (zip)
/opt/cloakware/cspmclient_thirdparty/jetty/lib/javax.servlet.jar/ (zip)
/opt/cloakware/cspmclient_thirdparty/jetty/ext/xmlParserAPIs-2.5.jar/ (zip)
/usr/share/java/libgcj-3.4.3.jar/ (system) (zip)
java/awt/Component.java: In class `java.awt.Component':
java/awt/Component.java: In method `java.awt.Component.eventTypeEnabled(int)':
java/awt/Component.java:4709: error: expected type 'int' but stack 
contains 'void'
java/awt/Component.java:4709: error: verification error at PC=327
java/awt/Component.java:4709: error: types could not be merged
java/io/BufferedReader.java:0: confused by earlier errors, bailing out



Looks like one of our jars linked is using the java.awt.* package, which cause 
the problem.

By the way, all our JAVA applications work very well if we don't compile and 
link it into an executable.

Thanks a lot in advance.

Jack rong

-- 
   Summary: gcj link error
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jack dot rong at cloakware dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org


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

[Bug java/20715] gcj link error

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Severity|critical|normal
  Component|libgcj  |java


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

[Bug java/20715] gcj link error

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-01 
14:52 ---
You might want to try a snapshot of 4.0.0 which has AWT support builtin.
Also this is not a link error, this is at compile time still.
This error usually shows up if you try to compile a .jar and a .java file at 
the same time.  This is known 
to be broken, there are a couple of bugs for this.

-- 


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

[Bug tree-optimization/20641] Missed optimization on the tree level (malloc attribute)

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-04-01 14:57:31
   date||


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

[Bug java/20715] gcj link error

[jack dot rong at cloakware dot com]

--- Additional Comments From jack dot rong at cloakware dot com  2005-04-01 
14:58 ---
Subject: RE:  gcj link error

It is a compilation error. Thanks.

Jack

-Original Message-
From: pinskia at gcc dot gnu dot org [mailto:[EMAIL PROTECTED]
Sent: Friday, April 01, 2005 9:52 AM
To: [EMAIL PROTECTED]
Subject: [Bug java/20715] gcj link error



--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-01
14:52 ---
You might want to try a snapshot of 4.0.0 which has AWT support builtin.
Also this is not a link error, this is at compile time still.
This error usually shows up if you try to compile a .jar and a .java file at
the same time.  This is known
to be broken, there are a couple of bugs for this.

--


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

--- You are receiving this mail because: ---
You reported the bug, or are watching the reporter.



-- 


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

[Bug java/20715] gcj compilation error

[jack dot rong at cloakware dot com]

-- 
   What|Removed |Added

Summary|gcj link error  |gcj compilation error


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

[Bug treelang/20604] treelang does not get passed -fPIC by default on *-darwin

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-01 
15:01 ---
Subject: Bug 20604

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-04-01 15:01:31

Modified files:
gcc/treelang   : ChangeLog lang-specs.h 

Log message:
2005-04-01  Andrew Pinski  <[EMAIL PROTECTED]>

PR treelang/20604
* lang-spec.c: Simplify @treelang to what the other
languages do.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/treelang/ChangeLog.diff?cvsroot=gcc&r1=1.120&r2=1.121
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/treelang/lang-specs.h.diff?cvsroot=gcc&r1=1.3&r2=1.4



-- 


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

[Bug treelang/20604] treelang does not get passed -fPIC by default on *-darwin

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-01 
15:01 ---
Fixed.

-- 
   What|Removed |Added

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


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

[Bug middle-end/20714] emit_no_conflict_block does invalid reordering

[amylaar at gcc dot gnu dot org]

--- Additional Comments From amylaar at gcc dot gnu dot org  2005-04-01 
15:20 ---
Created an attachment (id=8507)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8507&action=view)
proposed patch

This implements a similar dependency check as in emit_libcall_block,
except that we might have to consider multiple sets / clobbers.
This also fixes the bogosity of checking only the first set for
setting part of target, and looking at the SET_DEST of USEs and CLOBBERs.

-- 


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

[Bug middle-end/20714] emit_no_conflict_block does invalid reordering

[amylaar at gcc dot gnu dot org]

-- 
   What|Removed |Added

OtherBugsDependingO||20695
  nThis||


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

[Bug target/20695] sh64-*-* port deos not handle 32 / 64 bit conversions properly

[amylaar at gcc dot gnu dot org]

-- 
   What|Removed |Added

  BugsThisDependsOn||20714


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

[Bug libfortran/20471] Segmentation fault on read after backspace and rewind

[fxcoudert at gcc dot gnu dot org]

--- Additional Comments From fxcoudert at gcc dot gnu dot org  2005-04-01 
15:28 ---
Forget comment #4. The problem is in the testsuite file (I corrected it, this
test now FAILs, but will be fixed soon by Dale's patch).

-- 
   What|Removed |Added

   Last reconfirmed|2005-03-31 20:32:36 |2005-04-01 15:28:32
   date||


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

[Bug fortran/20716] New: Error gfortran and in "gfortran.fortran-torture/execute/backspace.f90"

[dir at lanl dot gov]

The fortran testsuite routine 
"/gfortran/gcc/gcc/testsuite/gfortran.fortran-torture/execute/backspace.f90" is
actually incorrect - C should actually be 'a' not 'b' - gfortran incorrectly
returns 'b' and passes the bad test.


[dranta:~/tests/gfortran] dir% gfortran -o backspace backspace.f90
[dranta:~/tests/gfortran] dir% backspace
[dranta:~/tests/gfortran] dir% cat backspace.f90
! pr 15755
implicit none
character*1 C
open(10)
write(10,*)'a'
write(10,*)'b'
write(10,*)'c'
rewind(10)
read(10,*)C
backspace(10) 
read(10,*) C
if (C.ne.'b') call abort
close(10,STATUS='DELETE')
end

-- 
   Summary: Error gfortran and in "gfortran.fortran-
torture/execute/backspace.f90"
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dir at lanl dot gov
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: powerpc-apple-darwin7.8.0


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

[Bug fortran/20716] Error gfortran and in "gfortran.fortran-torture/execute/backspace.f90"

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-01 
15:34 ---
This was just fixed by " François-Xavier Coudert":
* gfortran.fortran-torture/execute/backspace.f90: Check
after backspace and read was incorrect.



-- 
   What|Removed |Added

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


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

[Bug tree-optimization/20702] [tcb] ASSERT_EXPRs are not inserted when a certain "if" statement is present.

[kazu at cs dot umass dot edu]

--- Additional Comments From kazu at cs dot umass dot edu  2005-04-01 16:23 
---
Let me replace the testcase as follows so that
I can remove dependence on PR 20701.

extern void bar (int);

int
foo (int *p, int b)
{
  int a;

  if (b)
bar (123);
  else
bar (321);

  a = *p;
  if (p == 0)
return 0;

  return a;
}

Note that "p == 0" in the second "if" statement is always false,
but VRP does not fold it.


-- 
   What|Removed |Added

  BugsThisDependsOn|20701   |


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

[Bug target/20717] New: [4.1 Regression] Many C++ testsuite failures on ia64-hpux

[jsm28 at gcc dot gnu dot org]

Many g++ and libstdc++ testcases started failing on mainline on ia64-hpux on
20050331.  The failures are of the form:

ld: (Warning) Unsatisfied symbol "std::basic_stringbuf, std::allocator >::~basic_stringbuf()" in file
/scratch/gcc/nightly-2005-03-31-mainline/ia64-hp-hpux11.23/build_gcc/build/ia64-hp-hpux11.23/./libstdc++-v3/src/.libs/libstdc++.so

Suspicious patches are

2005-03-31  Jan Hubicka  <[EMAIL PROTECTED]>

 * decl2.c (finish_objects): Mark ctor as needed.
 (cp_finish_file): Output variables only in nonunit-at-a-time.

(known to be wrong because C++ is always unit-at-a-time)

and

2005-03-31  Jan Hubicka  <[EMAIL PROTECTED]>

 2004-11-02  Jan Hubicka  <[EMAIL PROTECTED]>

 * cgraph.c (cgraph_varpool_node_name): New function.
 (dump_cgraph_varpool_node): New function.
 (dump_varpool): New function.
 * cgraphunit.c (cgraph_optimize): Dump varpool.

 ...

This could also be related to ,
bootstrap failure on ia64-linux.

-- 
   Summary: [4.1 Regression] Many C++ testsuite failures on ia64-
hpux
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jsm28 at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,jh at suse dot cz,mark
at codesourcery dot com
GCC target triplet: ia64-*-hpux11.*


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

[Bug inline-asm/20718] New: "+r" constraint with uninitialized value

[jakub at gcc dot gnu dot org]

unsigned long foo (unsigned long *a, unsigned long *b,
   unsigned long *c, int d)
{
  unsigned long e, f;

  if (d <= 0) return 0;
  asm ("# registers %0 %1 %2 %3 %4 %5"
   : "+a" (e),"+c" (d), "+r" (f)
   : "r" (a), "r" (b), "r" (c));
  return e;
}

at -O2 results in
# registers %rax %ecx %rdx %rdi %rsi %rdx
Note %2 and %5 being the same register, %rdx.
If f (and e) are initialized, both older GCCs and GCC4+ assign different
registers, but with unitialized values older GCCs seem to act as if "+r"
was instead "=&r" while GCC4+ treat it as "=r".

The library that used this (openssl) has been fixed to use "=&r" and "=&a"
instead, but I'd like to understand what is the desirable GCC behaviour
in this case.  If it is undefined behaviour, so be it, but perhaps that
should be documented.  Similarly if "r" (unitialized_var) among inputs means
GCC should allocate a unique register for that input or it doesn't have to.

-- 
   Summary: "+r" constraint with uninitialized value
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,rth at gcc dot gnu dot
org
GCC target triplet: x86_64-*-linux


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

[Bug tree-optimization/20703] [tcb] FRE does not remove a fully redundant load.

[kazu at cs dot umass dot edu]

--- Additional Comments From kazu at cs dot umass dot edu  2005-04-01 16:47 
---
Before FRE.  (That is, the result of copyprop)

foo (array)
{
  int D.1134;
  int D.1133;
  int * D.1132;

:
  D.1132_3 = array_2 + 4B;
  #   VUSE ;
  D.1133_4 = *D.1132_3;
  if (D.1133_4 != 0) goto ; else goto ;

:;
  D.1132_7 = array_2 + 4B;
  #   VUSE ;
  D.1134_8 = *D.1132_7;
  goto  ();

:;
  D.1134_6 = 0;

  # D.1134_1 = PHI ;
:;
  return D.1134_1;

}

After FRE.

foo (array)
{
  int D.1134;
  int D.1133;
  int * D.1132;

:
  D.1132_3 = array_2 + 4B;
  #   VUSE ;
  D.1133_4 = *D.1132_3;
  if (D.1133_4 != 0) goto ; else goto ;

:;
  D.1132_7 = D.1132_3;
  #   VUSE ;
  D.1134_8 = *D.1132_7;
  goto  ();

:;
  D.1134_6 = 0;

  # D.1134_1 = PHI ;
:;
  return D.1134_1;

}


-- 


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

[Bug bootstrap/20719] New: [4.1 Regression] ICE in default_no_named_section, at varasm.c:4828

[jsm28 at gcc dot gnu dot org]

Bootstrap on mainline on hppa2.0w-hpux has started failing on 20050401 in the
build of libgcc with the stage1 compiler.

/home/gcc/nightlies/gcc-mainline-2005-04-01/gcc/libgcc2.c: In function 
'__muldi3':
/home/gcc/nightlies/gcc-mainline-2005-04-01/gcc/libgcc2.c:533: internal compiler
error: in default_no_named_section, at varasm.c:4828
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

The most recent big changes to varasm.c seem to be from

2005-03-31  Caroline Tice  <[EMAIL PROTECTED]>

* Makefile.in (varasm.o): Add basic-block.h to list of requirements.
(bb-reorder.o): Add errors.h to list of requirements.
(STAGEFEEDBACK_FLAGS_TO_PASS): Add -freorder-blocks-and-partition to
profiledbootstrap flags.
[...]

(but it doesn't touch that particular function).  I'll attach preprocessed
source for the relevant file (no special compilation options needed to reproduce
the ICE).

-- 
   Summary: [4.1 Regression] ICE in default_no_named_section, at
varasm.c:4828
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jsm28 at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: hppa2.0w-*-hpux11.*


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

[Bug bootstrap/20719] [4.1 Regression] ICE in default_no_named_section, at varasm.c:4828

[jsm28 at gcc dot gnu dot org]

--- Additional Comments From jsm28 at gcc dot gnu dot org  2005-04-01 16:56 
---
Created an attachment (id=8508)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8508&action=view)
File which ICEs


-- 


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

[Bug AWT/20720] New: crash when pressing laptop arrow keys

[fitzsim at redhat dot com]

AWT applications crash when processing certain key events because the
keysym-to-keycode mapping is wrong.  The crash is preceded by this warning:

** (:7916): WARNING **: No keyval found for hardware keycode 233
*** glibc detected *** free(): invalid pointer: 0x085819a0 ***

-- 
   Summary: crash when pressing laptop arrow keys
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: AWT
AssignedTo: fitzsim at redhat dot com
ReportedBy: fitzsim at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org


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

[Bug c++/20721] New: [regression from 3.4.2 to 3.4.3] crossing of a initialization left undetected on goto

[nefercheprure at gmail dot com]

the error ``crosses initialization of `...''' is wrongly omited

-- 
   Summary: [regression from 3.4.2 to 3.4.3] crossing of a
initialization left undetected on goto
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nefercheprure at gmail dot com
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=20721

[Bug inline-asm/20718] "+r" constraint with uninitialized value

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-01 
19:19 ---
This is not a regression and here is an example (compile on 3.2.3 with -O2 -
fomit-frame-pointer on i686-pc-linux-gnu and you get the same behavior as 
pointed out here):
unsigned long foo (unsigned long *a, unsigned long *b,
   unsigned long *c, int d)
{
  unsigned long e, f,g,h;
 // e = 0;f = 0;


  if (d <= 0) return 0;
  asm ("# registers %0 %1 %2 %3 %4 %5 %6 %7"
   : "+a" (e),"+c" (d), "+r" (f), "+r"(g)
   : "r" (a), "r" (b), "r" (c), "r"(h));
  return e;
}


-- asm 
#APP
# registers %eax %ecx %edx %ebp %edi %esi %ebx %edx
#NO_APP

Notice how edx are used for both input and output registers.

-- 


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

[Bug c++/20721] [regression from 3.4.2 to 3.4.3] crossing of a initialization left undetected on goto

[nefercheprure at gmail dot com]

--- Additional Comments From nefercheprure at gmail dot com  2005-04-01 
19:22 ---
Created an attachment (id=8509)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8509&action=view)
the preprocessed file that demonstrates the regression

g++ -v -c logger.cc produces this message:

Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/specs
Configured with: /var/tmp/portage/gcc-3.4.3/work/gcc-3.4.3/configure
--enable-version-specific-runtime-libs --prefix=/usr
--bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.4.3
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/include/g++-v3
--host=i686-pc-linux-gnu --disable-altivec --enable-nls
--without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu
--with-system-zlib --disable-checking --disable-werror
--disable-libunwind-exceptions --enable-shared --enable-threads=posix
--disable-multilib --disable-libgcj --enable-languages=c,c++,f77
Thread model: posix
gcc version 3.4.3  (Gentoo Linux 3.4.3, ssp-3.4.3-0, pie-8.7.6.6)
 /usr/libexec/gcc/i686-pc-linux-gnu/3.4.3/cc1plus -quiet -v -D_GNU_SOURCE
logger.cc -mno-sse2 -quiet-dumpbase logger.cc -mtune=pentiumpro -auxbase logger
-version -o /tmp/cc6VhQ7m.s
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/include/g++-v3
 /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/include/g++-v3/i686-pc-linux-gnu
 /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/include/g++-v3/backward
 /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/include
 /usr/include
End of search list.
GNU C++ version 3.4.3  (Gentoo Linux 3.4.3, ssp-3.4.3-0, pie-8.7.6.6)
(i686-pc-linux-gnu)
compiled by GNU C version 3.4.3  (Gentoo Linux 3.4.3, ssp-3.4.3-0,
pie-8.7.6.6).
GGC heuristics: --param ggc-min-expand=63 --param ggc-min-heapsize=63198
 /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../i686-pc-linux-gnu/bin/as -V
-Qy -o logger.o /tmp/cc6VhQ7m.s
GNU assembler version 2.15.90.0.1.1 (i686-pc-linux-gnu) using BFD version
2.15.90.0.1.1 20040303

it should report crossing of initialization of certain bool variables

-- 


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

[Bug c++/20721] [regression from 3.4.2 to 3.4.3] crossing of a initialization left undetected on goto

[nefercheprure at gmail dot com]

-- 
   What|Removed |Added

   Keywords||accepts-invalid
  Known to fail||3.4.3
  Known to work||3.4.2


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

[Bug c++/20721] [regression from 3.4.2 to 3.4.3] crossing of a initialization left undetected on goto

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-01 
19:42 ---
There is at least an ICE on the mainline.

-- 
   What|Removed |Added

   Keywords|accepts-invalid |
  Known to fail|3.4.3   |
  Known to work|3.4.2   |


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

[Bug c/20655] Attempt to use undefined structure tag triggers no diagnostic

[jozef dot behran at krs dot sk]

--- Additional Comments From jozef dot behran at krs dot sk  2005-04-01 
19:49 ---
> This is still valid code because the struct could be defined below still. 
 
But if the struct is not defined anywhere (not even below its use), a warning 
should 
occur. If you send the first declaration to the compiler without sending the 
second 
one, you should see a warning about an undeclared structure. However if you 
send your example to the compiler as you mentioned it, no warnings should 
appear. This warning should at least indicate the users that there may be 
something wrong with their code and that they should check for typos or so. 
Note that the code is valid, but unusual. If you see a structure tag used 
somewhere without being declared, most likely it is a bug in the code. 
Otherwise 
the compiler may give the user very strange error/warning messages that may 
confuse him seriously (a structure type seeming not to be compatible with 
itself). 

-- 
   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug other/20722] New: select_section invoked with argument "unlikely"

[dje at gcc dot gnu dot org]

In varasm.c, function_section() and current_function_section() invoke target 
hook select_section with boolean "unlikely" as the second argument.  The 
second argument is suppose to specify if the decl contains relocations, not if 
it should be placed in the unlikely section.

-- 
   Summary: select_section invoked with argument "unlikely"
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P1
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dje at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: *-*-*
  GCC host triplet: *-*-*
GCC target triplet: *-*-*


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

[Bug target/20625] [4.0/4.1 regression] ivopts produces code that generates "unaligned access exception"

[rakdver at gcc dot gnu dot org]

--- Additional Comments From rakdver at gcc dot gnu dot org  2005-04-01 
20:00 ---
http://gcc.gnu.org/ml/gcc-patches/2005-04/msg00097.html

-- 
   What|Removed |Added

   Keywords||patch


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

[Bug libstdc++/20534] Erroneous #include of

[pcarlini at suse dot de]

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pcarlini at suse dot de
   |dot org |
 Status|WAITING |ASSIGNED


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

[Bug c/20655] Attempt to use undefined structure tag triggers no diagnostic

[joseph at codesourcery dot com]

--- Additional Comments From joseph at codesourcery dot com  2005-04-01 
20:19 ---
Subject: Re:  Attempt to use undefined structure tag triggers
 no diagnostic

On Fri, 1 Apr 2005, jozef dot behran at krs dot sk wrote:

> Note that the code is valid, but unusual. If you see a structure tag used 
> somewhere without being declared, most likely it is a bug in the code. 
> Otherwise 

No, if a tag is used without the structure or union contents being defined 
then most likely it is being used as an opaque type and the definition is 
in a separate internal header for e.g. the library implementation but does 
not form part of the public interface.



-- 


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

[Bug c/20655] Attempt to use undefined structure tag triggers no diagnostic

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-01 
20:58 ---
If you deference or do an assignment like:

TType *a, *b;

b->Pointer = a;

You will either get an error or a warning saying the code is invalid.

Also as mentioned by JSM, it is a way to provide opaque type pointers.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug debug/19345] [4.0/4.1 Regression] Segmentation fault with VLA and inlining and dwarf2

[mark at codesourcery dot com]

--- Additional Comments From mark at codesourcery dot com  2005-04-01 21:17 
---
Subject: Re: [PR debug/19345] remap TYPE_STUB_DECL during inlining

Alexandre Oliva wrote:
> TYPE_STUB_DECL was NULL in the testcase given in the bug report
> because tree inlining failed to remap TYPE_STUB_DECL.  This patch
> reverts the patch that hides the problem, that AFAICT was checked in
> by accident, and installs a proper (IMHO :-) fix.  Bootstrapping on
> amd64-linux-gnu.  Ok to install if it passes regtesting?

Yes!  This looks very sensible.

Thanks,



-- 


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

[Bug bootstrap/20719] [4.1 Regression] ICE in default_no_named_section, at varasm.c:4828

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-01 
21:25 ---
Also reproducable on i686-pc-openbsd3.1.

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Keywords||ice-on-valid-code
   Target Milestone|--- |4.1.0


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

[Bug bootstrap/20719] [4.1 Regression] ICE in default_no_named_section, at varasm.c:4828

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Keywords||build


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

[Bug c++/20647] Wrong typeid for incomplete types

[frederic dot riss at gmail dot com]

--- Additional Comments From frederic dot riss at gmail dot com  2005-04-01 
21:45 ---
Andrew, I don't fully get what you mean and seeing no activity on this bug makes
me wonder if you expect some feedback from me... Experimenting based on your
comment I tried using -fno-weak, but it doesn't work nor seems recommended. So I
wonder if what I see is a real bug, me misusing C++ or maybe a bug in the
packages I use.

-- 


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

[Bug libstdc++/20647] Wrong typeid for incomplete types

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-01 
21:48 ---
(In reply to comment #2)
> Andrew, I don't fully get what you mean and seeing no activity on this bug 
> makes
> me wonder if you expect some feedback from me... Experimenting based on your
> comment I tried using -fno-weak, but it doesn't work nor seems recommended. 
> So I
> wonder if what I see is a real bug, me misusing C++ or maybe a bug in the
> packages I use.

No I mean this works on targets without weak symbol support like say openbsd or 
older versions of gcc 
on darwin (Mac OS X).

I don't know the C++ rules to say this is correct or not.

-- 
   What|Removed |Added

  Component|c++ |libstdc++


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

[Bug c++/20721] [3.4/4.0/4.1 Regression] crossing of a initialization left undetected on goto

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-01 
21:57 ---
Reduced testcase for the accepts invalid, I will then reduce the ICE on the 
mainline soon (note you have 
some other invalid code in there):
bool f();
void g(int i)
{
  if (i) goto bad;
  bool a = f();
  bad:
  ;
}

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||accepts-invalid
  Known to fail||3.4.3 4.0.0
  Known to work||3.4.0 3.4.2
   Last reconfirmed|-00-00 00:00:00 |2005-04-01 21:57:11
   date||
Summary|[regression from 3.4.2 to   |[3.4/4.0/4.1 Regression]
   |3.4.3] crossing of a|crossing of a initialization
   |initialization left |left undetected on goto
   |undetected on goto  |
   Target Milestone|--- |3.4.4


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

[Bug c++/20721] [3.4/4.0/4.1 Regression] crossing of a initialization left undetected on goto

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-01 
21:57 ---
: Search converges between 2004-10-26-161001-trunk (#611) and 
2004-11-03-014001-trunk 
(#612).
: Search converges between 2004-10-28-004002-3.4 (#106) and 
2004-11-01-004001-3.4 (#107).

-- 


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

[Bug tree-optimization/20703] [tcb] FRE does not remove a fully redundant load.

[dberlin at gcc dot gnu dot org]

--- Additional Comments From dberlin at gcc dot gnu dot org  2005-04-01 
22:16 ---
I have a patch for this that solves it.
Waiting for TCB merge to post

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dberlin at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2005-04-01 00:41:16 |2005-04-01 22:16:50
   date||


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

[Bug c++/20723] New: [4.1 Regression] ICE in more_specialized_fn, more than one user-defined conversion "srp" to "ptr"

[pinskia at gcc dot gnu dot org]

The following code now ICEs on the mainline:
template  class srp;
template  struct ptr
{
  template  ptr(const srp &other);
};
template  struct srp
{
  template  operator ptr(void) const;  
};
ptr parent_get()
{
  srp parent;
  return parent;
}


Note we did reject this before even though it is invalid code.

-- 
   Summary: [4.1 Regression] ICE in more_specialized_fn, more than
one user-defined conversion "srp" to "ptr"
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P2
 Component: c++
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


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

[Bug libstdc++/20534] Erroneous #include of

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-04-01 22:54 
---
Humpf! A problem with the trivial fix using abort() is that doesn't emit 
diagnostic about the failure point. This is relevant for , which
uses _GLIBCXX_DEBUG_ASSERT/PEDASSERT directly.

-- 


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

[Bug c++/20723] [4.1 Regression] ICE in more_specialized_fn, more than one user-defined conversion "srp" to "ptr"

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-01 
22:55 ---
I think the ICE was caused by:
2005-03-31  Nathan Sidwell  <[EMAIL PROTECTED]>

PR c++/19203, implement DR 214
* call.c (joust): Use more_specialized_fn.
* cp-tree.h (DEDUCE_ORDER): Remove.
(more_specialized): Replace with ...
(more_specialized_fn): ... this.
* pt.c (maybe_adjust_types_for_deduction): Remove DEDUCE_ORDER
case.
(type_unification_real): Remove DEDUCE_ORDER case.
(more_specialized): Replace with ...
(more_specialized_fn): ... this.  Implement DR 214.
(most_specialized_instantiation): Use get_bindings_real directly.


-- 
   What|Removed |Added

 CC||nathan at codesourcery dot
   ||com
   Target Milestone|--- |4.1.0


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

[Bug libstdc++/20534] Erroneous #include of

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-04-01 23:02 
---
...and also elsewhere (there are more uses besides ).

-- 
   What|Removed |Added

 AssignedTo|pcarlini at suse dot de |unassigned at gcc dot gnu
   ||dot org
 Status|ASSIGNED|NEW


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

[Bug target/20717] [4.1 Regression] Many C++ testsuite failures on ia64-hpux

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |4.1.0


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

[Bug c/20709] strict aliasing warning with float pointer pointing to int pointer

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Severity|critical|normal
   Keywords||diagnostic


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

[Bug c/20709] strict aliasing warning with float pointer pointing to int pointer

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-02 
00:09 ---
Because we only warn if you take the address and then cast so if you have a 
tempary variable 
inbetween, we don't warn.

Note really strict aliasing warnings are hard to produce as it is only a bug if 
you access via those two 
types.
Aka this is valid and defined (even though we warn):
float a(float b)
{
  int i;
  *(float*)&i = b;
  return *(float*)&i;
}

-- 


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

[Bug tree-optimization/19049] not vectorizing a fortran loop

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-02 
00:16 ---
pr19049.f:10: note: not vectorized: can't determine dependence between: 
(*a_38)[D.722_49] and 
(*a_38)[D.721_51]
pr19049.f:10: note: bad data dependence.

-- 
   What|Removed |Added

Summary|not vectorizing fortran |not vectorizing a fortran
   |loops because not moving|loop
   |user lables on the tree |
   |level   |


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

[Bug libgcj/20693] javax-imageio.lo failed to build

[hjl at lucon dot org]

--- Additional Comments From hjl at lucon dot org  2005-04-02 00:28 ---
It is getting worse. Both libtool and java testsuite try to outsmart
each other. Each tries to put `\' in front `$' for file name.

-- 


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

[Bug c++/20724] New: function overload resolution fails when any template is declared

[kjd at duda dot org]

Consider this program;


namespace N {
   int function( char * ) { return 200; }

   // uncomment the next line to see a surprising error:
   //template< typename T > int function();
   
   // The error is:
   // foo.cpp: In function `int main()':
   // foo.cpp:15: error: cannot convert `Enum' to `char*' for argument `1' to
`int N::function(char*)'
};
enum Enum { enum1 };
int function( Enum const & ) { return 100; }
int main() {
   using N::function;
   function( enum1 );
}
=

I would expect this program to compile and for function(enum1) to return 100,
regardless of the "template" declaration on line 5.  However, if you uncomment
the declaration, gcc gets confused and can't find the overload in the main
namespace (::function(Enum)).  It's like the presence of the template
declaration is a little honeypot that gets the overload searcher stuck in the
wrong namespace.  Oddly, the call to "function(Enum)" and the Enum itself have
to be in the *same* namespace to trigger this bug; i.e., if you move the Enum
into a namespace separate from main(), the problem goes away.

I'd appreciate any feedback here, particularly in the form of "you're crazy" or
"this is fixed in gcc version X".

Thanks,
-Ken

-- 
   Summary: function overload resolution fails when any template is
declared
   Product: gcc
   Version: 3.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kjd at duda dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i386-redhat-linux
  GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux


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

[Bug c++/20724] function overload resolution fails when any template is declared

[kjd at duda dot org]

-- 
   What|Removed |Added

 CC||kjd at duda dot org


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

[Bug tree-optimization/19794] [meta-bug] Jump threading related bugs

[law at redhat dot com]

--- Additional Comments From law at redhat dot com  2005-04-02 01:31 ---
Some notes on recent poking and prodding.

The big perl speedup is consistent on my P4 -- but perl shows no significant
change on my AMD box.  Perl spends ~50% of its time in one routine (regexec)
and, surprise, that's the routine where profiling shows the great improvements.

Unfortunately, the profiling data hasn't pinpointed _why_ that routine is
running so much faster.  If one is to believe the oprofile data, the
huge reduction in cycles actually occurs in the function's header block.
But it's not substantially different between the version compiled with
and without the threading updates.  And it does not appear that threading has
turned any of the recursive calls into simple loops.  Looking at the profile
results from different P4 counters hasn't provided any additional insight
yet.  Sigh.

Anyway, I'll continue poking at Perl -- I'd really like to understand the 
huge improvements before installing the patch. 

-- 


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

[Bug java/20526] gij -X reports no options are recognized, while -Xmx and -Xms seem to be

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-02 
02:27 ---
Subject: Bug 20526

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-04-02 02:26:52

Modified files:
gcc/java   : ChangeLog gcj.texi 
libjava: ChangeLog configure configure.ac gij.cc 
 prims.cc 
libjava/gcj: cni.h 
libjava/include: config.h.in java-props.h jvm.h 
libjava/java/lang: natRuntime.cc 

Log message:
2005-04-01  Thomas Fitzsimmons  <[EMAIL PROTECTED]>

* gcj.texi (Invoking gij): Add descriptions of new -X options.
Mention recognized-and-ignored compatibility options.
(Memory allocation): Add descriptions of JvMalloc, JvRealloc and
JvFree.
(About CNI): Add Memory allocation section.

2005-04-01  Thomas Fitzsimmons  <[EMAIL PROTECTED]>

PR libgcj/20090, PR libgcj/20526
* gij.cc (nonstandard_opts_help): New function.
(add_option): New function.
(main): Support java options.  Set java.class.path.  Don't set
_Jv_Jar_Class_Path.
* prims.cc (parse_x_arg): New function.
(parse_init_args): Call parse_x_arg for -X and _ options, when
ignoreUnrecognized is true.
(new _Jv_RunMain): New vm_args variant.
(old _Jv_RunMain): Call new vm_args _Jv_RunMain.
(_Jv_Jar_Class_Path): Remove variable.
* include/java-props.h: Likewise.
* include/cni.h (JvRealloc): New function.
* include/jvm.h (_Jv_RunMain): Declare vm_args variant.
* java/lang/natRuntime.cc (insertSystemProperties): Remove
_Jv_Jar_Class_Path logic.  Use JV_VERSION and JV_API_VERSION
macros.
* configure.ac (JV_VERSION): Define.
(JV_API_VERSION): Likewise.
* configure: Regenerate.
* include/config.h.in: Regenerate.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gcc&r1=1.1584&r2=1.1585
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/gcj.texi.diff?cvsroot=gcc&r1=1.77&r2=1.78
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&r1=1.3449&r2=1.3450
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/configure.diff?cvsroot=gcc&r1=1.258&r2=1.259
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/configure.ac.diff?cvsroot=gcc&r1=1.24&r2=1.25
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/gij.cc.diff?cvsroot=gcc&r1=1.25&r2=1.26
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/prims.cc.diff?cvsroot=gcc&r1=1.107&r2=1.108
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/gcj/cni.h.diff?cvsroot=gcc&r1=1.15&r2=1.16
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/include/config.h.in.diff?cvsroot=gcc&r1=1.59&r2=1.60
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/include/java-props.h.diff?cvsroot=gcc&r1=1.8&r2=1.9
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/include/jvm.h.diff?cvsroot=gcc&r1=1.81&r2=1.82
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/lang/natRuntime.cc.diff?cvsroot=gcc&r1=1.52&r2=1.53



-- 


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

[Bug libgcj/20090] gij should be implemented in Java

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-02 
02:27 ---
Subject: Bug 20090

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-04-02 02:26:52

Modified files:
gcc/java   : ChangeLog gcj.texi 
libjava: ChangeLog configure configure.ac gij.cc 
 prims.cc 
libjava/gcj: cni.h 
libjava/include: config.h.in java-props.h jvm.h 
libjava/java/lang: natRuntime.cc 

Log message:
2005-04-01  Thomas Fitzsimmons  <[EMAIL PROTECTED]>

* gcj.texi (Invoking gij): Add descriptions of new -X options.
Mention recognized-and-ignored compatibility options.
(Memory allocation): Add descriptions of JvMalloc, JvRealloc and
JvFree.
(About CNI): Add Memory allocation section.

2005-04-01  Thomas Fitzsimmons  <[EMAIL PROTECTED]>

PR libgcj/20090, PR libgcj/20526
* gij.cc (nonstandard_opts_help): New function.
(add_option): New function.
(main): Support java options.  Set java.class.path.  Don't set
_Jv_Jar_Class_Path.
* prims.cc (parse_x_arg): New function.
(parse_init_args): Call parse_x_arg for -X and _ options, when
ignoreUnrecognized is true.
(new _Jv_RunMain): New vm_args variant.
(old _Jv_RunMain): Call new vm_args _Jv_RunMain.
(_Jv_Jar_Class_Path): Remove variable.
* include/java-props.h: Likewise.
* include/cni.h (JvRealloc): New function.
* include/jvm.h (_Jv_RunMain): Declare vm_args variant.
* java/lang/natRuntime.cc (insertSystemProperties): Remove
_Jv_Jar_Class_Path logic.  Use JV_VERSION and JV_API_VERSION
macros.
* configure.ac (JV_VERSION): Define.
(JV_API_VERSION): Likewise.
* configure: Regenerate.
* include/config.h.in: Regenerate.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gcc&r1=1.1584&r2=1.1585
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/gcj.texi.diff?cvsroot=gcc&r1=1.77&r2=1.78
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&r1=1.3449&r2=1.3450
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/configure.diff?cvsroot=gcc&r1=1.258&r2=1.259
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/configure.ac.diff?cvsroot=gcc&r1=1.24&r2=1.25
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/gij.cc.diff?cvsroot=gcc&r1=1.25&r2=1.26
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/prims.cc.diff?cvsroot=gcc&r1=1.107&r2=1.108
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/gcj/cni.h.diff?cvsroot=gcc&r1=1.15&r2=1.16
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/include/config.h.in.diff?cvsroot=gcc&r1=1.59&r2=1.60
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/include/java-props.h.diff?cvsroot=gcc&r1=1.8&r2=1.9
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/include/jvm.h.diff?cvsroot=gcc&r1=1.81&r2=1.82
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/lang/natRuntime.cc.diff?cvsroot=gcc&r1=1.52&r2=1.53



-- 


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

[Bug java/20526] gij -X reports no options are recognized, while -Xmx and -Xms seem to be

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-02 
02:30 ---
Subject: Bug 20526

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-04-02 02:30:41

Modified files:
gcc/java   : ChangeLog gcj.texi 
libjava: ChangeLog configure configure.ac gij.cc 
 prims.cc 
libjava/gcj: cni.h 
libjava/include: config.h.in java-props.h jvm.h 
libjava/java/lang: natRuntime.cc 

Log message:
2005-04-01  Thomas Fitzsimmons  <[EMAIL PROTECTED]>

* gcj.texi (Invoking gij): Add descriptions of new -X options.
Mention recognized-and-ignored compatibility options.
(Memory allocation): Add descriptions of JvMalloc, JvRealloc and
JvFree.
(About CNI): Add Memory allocation section.

2005-04-01  Thomas Fitzsimmons  <[EMAIL PROTECTED]>

PR libgcj/20090, PR libgcj/20526
* gij.cc (nonstandard_opts_help): New function.
(add_option): New function.
(main): Support java options.  Set java.class.path.  Don't set
_Jv_Jar_Class_Path.
* prims.cc (parse_x_arg): New function.
(parse_init_args): Call parse_x_arg for -X and _ options, when
ignoreUnrecognized is true.
(new _Jv_RunMain): New vm_args variant.
(old _Jv_RunMain): Call new vm_args _Jv_RunMain.
(_Jv_Jar_Class_Path): Remove variable.
* include/java-props.h: Likewise.
* include/cni.h (JvRealloc): New function.
* include/jvm.h (_Jv_RunMain): Declare vm_args variant.
* java/lang/natRuntime.cc (insertSystemProperties): Remove
_Jv_Jar_Class_Path logic.  Use JV_VERSION and JV_API_VERSION
macros.
* configure.ac (JV_VERSION): Define.
(JV_API_VERSION): Likewise.
* configure: Regenerate.
* include/config.h.in: Regenerate.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.1556.2.9&r2=1.1556.2.10
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/gcj.texi.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.73.2.3&r2=1.73.2.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.3391.2.34&r2=1.3391.2.35
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/configure.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.253&r2=1.253.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/configure.ac.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.19&r2=1.19.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/gij.cc.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.25&r2=1.25.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/prims.cc.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.104&r2=1.104.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/gcj/cni.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.15&r2=1.15.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/include/config.h.in.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.59&r2=1.59.10.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/include/java-props.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.8&r2=1.8.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/include/jvm.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.77.2.2&r2=1.77.2.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/lang/natRuntime.cc.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.47.2.2&r2=1.47.2.3



-- 


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

[Bug libgcj/20090] gij should be implemented in Java

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-02 
02:30 ---
Subject: Bug 20090

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-04-02 02:30:41

Modified files:
gcc/java   : ChangeLog gcj.texi 
libjava: ChangeLog configure configure.ac gij.cc 
 prims.cc 
libjava/gcj: cni.h 
libjava/include: config.h.in java-props.h jvm.h 
libjava/java/lang: natRuntime.cc 

Log message:
2005-04-01  Thomas Fitzsimmons  <[EMAIL PROTECTED]>

* gcj.texi (Invoking gij): Add descriptions of new -X options.
Mention recognized-and-ignored compatibility options.
(Memory allocation): Add descriptions of JvMalloc, JvRealloc and
JvFree.
(About CNI): Add Memory allocation section.

2005-04-01  Thomas Fitzsimmons  <[EMAIL PROTECTED]>

PR libgcj/20090, PR libgcj/20526
* gij.cc (nonstandard_opts_help): New function.
(add_option): New function.
(main): Support java options.  Set java.class.path.  Don't set
_Jv_Jar_Class_Path.
* prims.cc (parse_x_arg): New function.
(parse_init_args): Call parse_x_arg for -X and _ options, when
ignoreUnrecognized is true.
(new _Jv_RunMain): New vm_args variant.
(old _Jv_RunMain): Call new vm_args _Jv_RunMain.
(_Jv_Jar_Class_Path): Remove variable.
* include/java-props.h: Likewise.
* include/cni.h (JvRealloc): New function.
* include/jvm.h (_Jv_RunMain): Declare vm_args variant.
* java/lang/natRuntime.cc (insertSystemProperties): Remove
_Jv_Jar_Class_Path logic.  Use JV_VERSION and JV_API_VERSION
macros.
* configure.ac (JV_VERSION): Define.
(JV_API_VERSION): Likewise.
* configure: Regenerate.
* include/config.h.in: Regenerate.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.1556.2.9&r2=1.1556.2.10
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/gcj.texi.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.73.2.3&r2=1.73.2.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.3391.2.34&r2=1.3391.2.35
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/configure.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.253&r2=1.253.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/configure.ac.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.19&r2=1.19.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/gij.cc.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.25&r2=1.25.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/prims.cc.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.104&r2=1.104.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/gcj/cni.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.15&r2=1.15.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/include/config.h.in.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.59&r2=1.59.10.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/include/java-props.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.8&r2=1.8.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/include/jvm.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.77.2.2&r2=1.77.2.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/lang/natRuntime.cc.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.47.2.2&r2=1.47.2.3



-- 


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

[Bug libgcj/20699] gij -ms segfaults

[vektor at dumbterm dot net]

-- 
   What|Removed |Added

 CC||vektor at dumbterm dot net


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

[Bug bootstrap/20719] [4.1 Regression] ICE in default_no_named_section, at varasm.c:4828

[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=20719

[Bug tree-optimization/20725] New: [tcb] FRE does not remove a fully redundant load.

[kazu at cs dot umass dot edu]

Consider:

struct s {
  int *n;
};

int
foo (unsigned int i, struct s *array)
{
  int *p = array[i].n;
  if (p)
{
  int *q = array[i].n;
  if (p != q)
return 1;
}
  return 0;
}

Note that the second load is unnecessary, but FRE does not remove it.

Here is the dump before FRE.

foo (i, array)
{
  int * q;
  int * p;
  int D.1142;
  struct s * D.1141;
  struct s * D.1140;
  unsigned int D.1139;

:
  D.1139_3 = i_2 * 4;
  D.1140_4 = (struct s *) D.1139_3;
  D.1141_6 = D.1140_4 + array_5;
  #   VUSE ;
  p_7 = D.1141_6->n;
  if (p_7 != 0B) goto ; else goto ;

:;
  D.1139_10 = i_2 * 4;
  D.1140_11 = (struct s *) D.1139_10;
  D.1141_12 = array_5 + D.1140_11;
  #   VUSE ;
  q_13 = D.1141_12->n;
  if (p_7 != q_13) goto ; else goto ;

:;
  D.1142_14 = 1;
  goto  ();

:;
  D.1142_9 = 0;

  # D.1142_1 = PHI <1(2), 0(3)>;
:;
  return D.1142_1;

}

After FRE:

foo (i, array)
{
  int * q;
  int * p;
  int D.1142;
  struct s * D.1141;
  struct s * D.1140;
  unsigned int D.1139;

:
  D.1139_3 = i_2 * 4;
  D.1140_4 = (struct s *) D.1139_3;
  D.1141_6 = D.1140_4 + array_5;
  #   VUSE ;
  p_7 = D.1141_6->n;
  if (p_7 != 0B) goto ; else goto ;

:;
  D.1139_10 = D.1139_3;
  D.1140_11 = D.1140_4;
  D.1141_12 = D.1141_6;
  #   VUSE ;
  q_13 = D.1141_12->n;
  if (p_7 != q_13) goto ; else goto ;

:;
  D.1142_14 = 1;
  goto  ();

:;
  D.1142_9 = 0;

  # D.1142_1 = PHI <1(2), 0(3)>;
:;
  return D.1142_1;

}

-- 
   Summary: [tcb] FRE does not remove a fully redundant load.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug tree-optimization/20725] [tcb] FRE does not remove a fully redundant load.

[kazu at cs dot umass dot edu]

--- Additional Comments From kazu at cs dot umass dot edu  2005-04-02 04:41 
---
Danny, could you take a look?

This occurs even with your patch to tree-ssa-pre.c to fix PR 20703.


-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dberlin at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED


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

[Bug c++/20724] function overload resolution fails when any template is declared

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Keywords||rejects-valid


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