RE: bug in /usr/include/c++/3.4/bits/fstream.tcc

[Jacob Schmidt Madsen]

please ignore the previous message. i was my mistake, since i had
include some work from another guy, who had "using namespace std" and
also defined a "min" and "max" - it causes a conflict.

sorry about the trouble!

-Oprindelig meddelelse-
Fra: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sendt: 9. december 2004 22:21
Til: Jacob Schmidt Madsen
Cc: [EMAIL PROTECTED]
Emne: Re: bug in /usr/include/c++/3.4/bits/fstream.tcc


"Jacob Schmidt Madsen" <[EMAIL PROTECTED]> writes:

| error:
| /usr/include/c++/3.4/bits/fstream.tcc: In member function `virtual
| typename std::basic_filebuf<_CharT, _Traits>::int_type
| std::basic_filebuf<_CharT, _Traits>::underflow()':
| /usr/include/c++/3.4/bits/fstream.tcc:277: error: expected
| unqualified-id before '(' token
| /usr/include/c++/3.4/bits/fstream.tcc: In member function `virtual
| std::streamsize std::basic_filebuf<_CharT, _Traits>::xsputn(const
| _CharT*, std::streamsize)':
| /usr/include/c++/3.4/bits/fstream.tcc:518: error: expected
| unqualified-id before '(' token
| 
| solution found at:
| http://gcc.gnu.org/ml/gcc-bugs/2004-07/msg02128.html
| 
| fix:
| change line 277 in /usr/include/c++/3.4/bits/fstream.tcc
| from: __ilen = std::min(__avail, __buflen);
| to: __ilen = min(__avail, __buflen);

I cannot see any reason why that would be a fix.

-- Gaby

[Bug bootstrap/18125] bootstrap fails in libstdc++'s configure script, ICE on every C++ conftest.

[debian-gcc at lists dot debian dot org]

--- Additional Comments From debian-gcc at lists dot debian dot org  
2004-12-10 08:27 ---
not reproducible anymore with 2004-12-04

  Matthias

-- 
   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED


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

[Bug fortran/16511] Test 19990905-0.f fails with gfortran

[paulthomas2 at wanadoo dot fr]

--- Additional Comments From paulthomas2 at wanadoo dot fr  2004-12-10 
08:56 ---
(In reply to comment #7)

The COMMON block has nothing to do with the problem:

subroutine sub(a)
  integer :: m=2,n=2
  real a(m,n)
end subroutine sub

Fails to compile too, with the same message.

-- 


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

[Bug c/18919] New: print_address_operand produces segmentation fault

[bastian42 at monlynx dot de]

The fprintf() on mingw gets to many parameters and thus produces a segmentation 
fault.
config/rs6000/rs6000.c:9595
Original line:
   fprintf (file, HOST_WIDE_INT_PRINT_DEC "(%s)",
   INTVAL (XEXP (x, 1)), reg_names[ REGNO (XEXP (x, 0)) ]);
The compiled code passes an additional parameter between INTVAL and reg_names.

workaround, splitting into separate fprintfS:
  fprintf(file,HOST_WIDE_INT_PRINT_DEC,INTVAL (XEXP (x,1)));
fprintf(file,"(%s)",reg_names[ REGNO (XEXP (x,0)) ]);

Note: It is very likely a bug in the mingw32 implementation.

-- 
   Summary: print_address_operand produces segmentation fault
   Product: gcc
   Version: 3.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bastian42 at monlynx dot de
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: mingw32
GCC target triplet: powerpc-elf


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

[Bug target/18665] [3.4/4.0 Regression] -ftrapv borks up simple integer arithmetic

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-12-10 
09:53 ---
This fails on all 64-bit targets.


-- 
   What|Removed |Added

  GCC build triplet|x86_64-unknown-linux-gnu|*-*-*
   GCC host triplet|x86_64-unknown-linux-gnu|*-*-*
 GCC target triplet|x86_64-unknown-linux-gnu|*-*-*
  Known to fail|4.0.0   |3.4.3 4.0.0


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

[Bug fortran/12366] array assignment fails

[paulthomas2 at wanadoo dot fr]

--- Additional Comments From paulthomas2 at wanadoo dot fr  2004-12-10 
09:54 ---
For what it is worth:

program testg
real, dimension(5) :: a=(/ 1.5,2.1,3.2,4.6,5.3 /)
integer,dimension(3) :: i
i=(/ 2,3,1 /)
print *, a((/ 2,3,1 /))   ! ICEs
! print *, a(i)   !works fine
end

-- 


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

[Bug target/18459] [4.0 Regression] gcj no longer works on win32

[dannysmith at users dot sourceforge dot net]

--- Additional Comments From dannysmith at users dot sourceforge dot net  
2004-12-10 10:09 ---
Rutger,
Did you do a clean rebuild of libgcj.a after applying these patches?
Either works for me after native bootstrap on mingw32 host.  The second patch, 
however, does require CVS bunutils to get weak linkage to work correctly.

Danny



-- 


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

[Bug target/18665] [3.4/4.0 Regression] -ftrapv borks up simple integer arithmetic

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-12-10 
10:11 ---
OK, I understand what happens: the 5 symbols __absvdi2, __addvdi3, __subvdi3,
__mulvdi3 and __negvdi2 are not #defined in libgcc2.h, hence not tweaked based
on the word size.  They are, therefore, double-word symbols everywhere, which
doesn't work on 64-bit targets.

The fix is straightforward, however there is a hitch: on 64-bit targets, libgcc
will contain 5 new symbols (__absvti2, __addvti3, __mulvti3, __negvti2,
__subvti3)  and will not contain (__absvsi2, __addvsi3, __mulvsi3, __negvsi2,
__subvsi3) anymore.  While the former is OK, the latter is probably not so we
might need to provide stubs that will redirect them to the equivalent mode-sized
routines for backwards compatibility.

Richard, does that sound plausible?


-- 


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

[Bug rtl-optimization/16968] [3.4 Regression] loop optimizer miscompilation

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-12-10 
10:29 ---
Investigating, RTX_UNCHANGING_P was my preferred RTL flag. ;-)


-- 
   What|Removed |Added

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


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

[Bug libfortran/18879] ? not supported in namelist input

[Thomas dot Koenig at online dot de]

-- 
   What|Removed |Added

   Severity|normal  |enhancement
 Status|WAITING |NEW
 Ever Confirmed||1
   Priority|P2  |P3


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

[Bug tree-optimization/18888] [4.0 regression] loops miscompiled

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2004-12-10 
11:05 ---
The patch identified in comment #7 really can't have caused this,
at worst it uncovered a latent bug because the order of edges is
changed after this patch - but no pass should depend on the edges
being in any specific order so the bug is elsewhere.


-- 


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

[Bug tree-optimization/18921] New: [4.0 Regression] wrong code with operator "?"

[belyshev at lubercy dot com]

this program aborts if compiled with any options:

extern void abort (void);

int foo (int k)
{
  unsigned char j = 0;
  (k ? 0 : j++) == -1;
  return j;
}

int main ()
{
  if (!foo (0))
abort ();
  return 0;
}


-- 
   Summary: [4.0 Regression] wrong code with operator "?"
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: critical
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: belyshev at lubercy dot com
CC: gcc-bugs at gcc dot gnu dot org


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

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

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2004-12-10 
11:18 ---
Backtrace from amd64 (Prescott) at -O0

#0  fancy_abort (file=0x95711e "../../mainline/gcc/recog.c", line=2020,
function=0x957139 "extract_insn") at diagnostic.c:556
#1  0x00766d08 in _fatal_insn (msgid=0x95e5fb "unrecognizable insn:",
insn=0x2a95895cd0, file=0x95711e "../../mainline/gcc/recog.c", line=2020,
function=0x957139 "extract_insn") at rtl-error.c:120
#2  0x00766d45 in _fatal_insn_not_found (insn=0x2a95895cd0,
file=0x95711e "../../mainline/gcc/recog.c", line=2020,
function=0x957139 "extract_insn") at rtl-error.c:128
#3  0x0072d290 in extract_insn (insn=0x2a95895cd0) at recog.c:2020
#4  0x00737b58 in scan_one_insn (insn=0x2a95895cd0, pass=0) at
regclass.c:1048
#5  0x00738225 in regclass (f=0x2a959ee3c0, nregs=66, dump=0x0)
at regclass.c:1253
#6  0x0079ef0c in rest_of_handle_old_regalloc () at passes.c:491
#7  0x007a0dc6 in rest_of_compilation () at passes.c:1718

t.c: In function 'test1':
t.c:11: error: unrecognizable insn:
(insn 21 19 22 2 (set (reg/f:DI 58 [ D.1469 ])
(const:DI (plus:DI (symbol_ref:DI ("foo") [flags 0x22] )
(const_int 16 [0x10] -1 (nil)
(nil))


-- 
   What|Removed |Added

  GCC build triplet|pentium3-pld-linux  |
   GCC host triplet|pentium3-pld-linux  |
 GCC target triplet|pentium3-pld-linux  |
Summary|[4.0 Regression] ice with - |[4.0 Regression]
   |O2 / works fine with -O0.   |unrecognisable insn in
   ||regclass on x86/amd64


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

[Bug tree-optimization/18921] [4.0 Regression] wrong code with operator "?"

[belyshev at lubercy dot com]

-- 
   What|Removed |Added

  Known to fail||4.0.0
  Known to work||3.3.5 3.4.4
   Target Milestone|--- |4.0.0


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

[Bug c++/18922] New: ICE in tree_low_cst, at tree.c:3315

[a dot kral at sh dot cvut dot cz]

I get ICE when trying to compile wmkbd, it works with gcc 3.2 but not with 3.3.5
nor 3.4.4

Reading specs from /usr/lib/gcc/i486-linux/3.4.4/specs
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr
--libexecdir=/usr/lib --with-gxx-include-dir=/usr/include/c++/3.4
--enable-shared --with-system-zlib --enable-nls --without-included-gettext
--program-suffix=-3.4 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt
--enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm
--enable-java-awt=gtk --disable-werror i486-linux
Thread model: posix
gcc version 3.4.4 20041128 (prerelease) (Debian 3.4.3-3)

g++-3.4 -Wall -g -DXLIB_ILLEGAL_ACCESS -O2 -save-temps -I/usr/openwin/include
-I/usr/local/include `glib-config --cflags` `gnome-config gnomeui --cflags`
`gtk-config --cflags` app.c -c -o app.o
In file included from app.c:76:
keysyms.c:921: internal compiler error: in tree_low_cst, at tree.c:3315
Please submit a full bug report,
with preprocessed source if appropriate.

-- 
   Summary: ICE  in tree_low_cst, at tree.c:3315
   Product: gcc
   Version: 3.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: a dot kral at sh dot cvut dot cz
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/18922] ICE in tree_low_cst, at tree.c:3315

[a dot kral at sh dot cvut dot cz]

--- Additional Comments From a dot kral at sh dot cvut dot cz  2004-12-10 
11:25 ---
Created an attachment (id=7718)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7718&action=view)
Preprocessed source


-- 


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

[Bug c++/18922] [3.4/4.0 Regression] ICE in tree_low_cst, at tree.c:3315

[belyshev at lubercy dot com]

--- Additional Comments From belyshev at lubercy dot com  2004-12-10 11:35 
---
// "minimized" testcase:

char *hebrewdb[0][2] = {};


-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
  Known to fail||3.3.5 3.4.4
  Known to work||4.0.0
   Last reconfirmed|-00-00 00:00:00 |2004-12-10 11:35:02
   date||
Summary|ICE  in tree_low_cst, at|[3.4/4.0 Regression] ICE  in
   |tree.c:3315 |tree_low_cst, at tree.c:3315
   Target Milestone|--- |3.4.4


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

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

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2004-12-10 
11:35 ---
Not the same but maybe related:

1   static __thread void *foo [2];
2  
   
3   test1 ()
4   {
5 void **D, **ivtmp12;
6   L0:;
7 D = &foo[2];
8 if (D != ivtmp12) goto L0;
9   }

$ ./cc1 f.c
 test1
 
f.c: In function 'test1':
f.c:9: error: impossible constraint in 'asm'

What asm...?


-- 


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

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

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2004-12-10 
11:44 ---
Minimal test case:
$ cat t.c
static __thread void *foo[2];
test1 ()
{
  void **ivtmp12;
  while (&foo[1] != ivtmp12);
}

$ ../cc1 t.c -fdump-rtl-expand-details
 test1
 
t.c: In function 'test1':
t.c:6: error: unrecognizable insn:
(insn 9 7 10 1 (set (reg/f:DI 58 [ D.1471 ])
(const:DI (plus:DI (symbol_ref:DI ("foo") [flags 0x22] )
(const_int 8 [0x8] -1 (nil)
(nil))
t.c:6: internal compiler error: in extract_insn, at recog.c:2020


Removing __thread makes the ICE go away.  It definitely looks related to
the error from comment #6, the insn that causes the ICE is precisely the
statement that is rejected when I feed the gimplified test case to the
compiler:

;; D.1471 = &foo[1]
(insn 9 7 0 (set (reg:DI 58 [ D.1471 ])
(const:DI (plus:DI (symbol_ref:DI ("foo") [flags 0x22] )
(const_int 8 [0x8] -1 (nil)
(nil))


-- 


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

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

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2004-12-10 
11:47 ---
Without __thread, insn 9 is almost identical except for the flags (this is
with -m32 fwiw):

 ;; D.1123 = &foo[1]
 (insn 9 7 0 (set (reg:SI 58 [ D.1123 ])
-(const:SI (plus:SI (symbol_ref:SI ("foo") [flags 0x2] )
+(const:SI (plus:SI (symbol_ref:SI ("foo") [flags 0x22] )
 (const_int 4 [0x4] -1 (nil)
 (nil))


-- 


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

[Bug tree-optimization/18888] [4.0 regression] loops miscompiled

[schwab at suse dot de]

--- Additional Comments From schwab at suse dot de  2004-12-10 12:00 ---
The patch did not help. -fno-tree-dominator-opts is a workaround. 

-- 


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

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

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2004-12-10 
12:04 ---
GCC 3.3.5 (SUSE 9.2) produces this RTL for the ICEing statement:

(insn 11 10 12 (nil) (set (reg:DI 61)
(symbol_ref:DI ("foo"))) -1 (nil)
(nil))
   
  
(insn 12 11 13 (nil) (parallel [
(set (reg:DI 60)
(plus:DI (reg:DI 61)
(const_int 8 [0x8])))
(clobber (reg:CC 17 flags))
]) -1 (nil)
(nil))



-- 


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

[Bug fortran/18923] New: segfault after subroutine name confusion

[Thomas dot Koenig at online dot de]

The code below is invalid, but it's not that
bad that a segfault is called for :-)

$ cat sel_int_kind.f90
program foo
contains
  subroutine foo(i)
integer :: i
character(len=selected_int_kind(i)) :: c
  end subroutine bar
end program foo
$ gfortran sel_int_kind.f90
 In file sel_int_kind.f90:3

  subroutine foo(i)
   1
Error: PROGRAM attribute conflicts with PROCEDURE attribute at (1)
 In file sel_int_kind.f90:4

integer :: i
   1
Error: Unexpected data declaration statement in CONTAINS section at (1)
 In file sel_int_kind.f90:5

character(len=selected_int_kind(i)) :: c
   1
Error: Unexpected data declaration statement in CONTAINS section at (1)
 In file sel_int_kind.f90:6

  end subroutine bar
1
Error: Expecting END PROGRAM statement at (1)
sel_int_kind.f90:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
$ gfortran -v
Reading specs from /home/zfkts/lib/gcc/ia64-unknown-linux-gnu/4.0.0/specs
Configured with: ../gcc-4.0-20041205/configure --prefix=/home/zfkts
--enable-languages=c,c++,f95 --disable-shared
Thread model: posix
gcc version 4.0.0 20041205 (experimental)

Here's a backtrace:

$ gdb ~/libexec/gcc/ia64-unknown-linux-gnu/4.0.0/f951
GNU gdb Red Hat Linux (6.1post-1.20040607.17rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "ia64-redhat-linux-gnu"...Using host libthread_db
library "/lib/tls/libthread_db.so.1".

(gdb) r sel_int_kind.f90
Starting program: /home/zfkts/libexec/gcc/ia64-unknown-linux-gnu/4.0.0/f951
sel_int_kind.f90
 In file sel_int_kind.f90:3

  subroutine foo(i)
   1
Error: PROGRAM attribute conflicts with PROCEDURE attribute at (1)
 In file sel_int_kind.f90:4

integer :: i
   1
Error: Unexpected data declaration statement in CONTAINS section at (1)
 In file sel_int_kind.f90:5

character(len=selected_int_kind(i)) :: c
   1
Error: Unexpected data declaration statement in CONTAINS section at (1)
 In file sel_int_kind.f90:6

  end subroutine bar
1
Error: Expecting END PROGRAM statement at (1)

Program received signal SIGSEGV, Segmentation fault.
gfc_resolve_expr (e=0x600e7200)
at ../../gcc-4.0-20041205/gcc/fortran/resolve.c:2084
2084  if (sym->attr.flavor == FL_PROCEDURE && !sym->attr.function)
(gdb) bt
#0  gfc_resolve_expr (e=0x600e7200)
at ../../gcc-4.0-20041205/gcc/fortran/resolve.c:2084
#1  0x40085fb0 in resolve_actual_arglist (arg=0x600e6f10)
at ../../gcc-4.0-20041205/gcc/fortran/resolve.c:604
#2  0x40083f60 in gfc_resolve_expr (e=0x600e6de0)
at ../../gcc-4.0-20041205/gcc/fortran/resolve.c:942
#3  0x4008e090 in gfc_resolve (ns=0x600e67f0)
at ../../gcc-4.0-20041205/gcc/fortran/resolve.c:4666
#4  0x4008dff0 in gfc_resolve (ns=0x600e5bd0)
at ../../gcc-4.0-20041205/gcc/fortran/resolve.c:4658
#5  0x4007a520 in gfc_parse_file ()
at ../../gcc-4.0-20041205/gcc/fortran/parse.c:2612
#6  0x400adcb0 in gfc_be_parse_file (set_yydebug=-19536)
at ../../gcc-4.0-20041205/gcc/fortran/f95-lang.c:266
#7  0x4063d760 in toplev_main (argc=Variable "argc" is not available.
)
at ../../gcc-4.0-20041205/gcc/toplev.c:992
#8  0x40106220 in main (argc=2, argv=0x6fffb838)
at ../../gcc-4.0-20041205/gcc/main.c:35

-- 
   Summary: segfault after subroutine name confusion
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug fortran/16898] Aliasing problem with array descriptors

[pbrook at gcc dot gnu dot org]

--- Additional Comments From pbrook at gcc dot gnu dot org  2004-12-10 
13:21 ---
This is not fixed. 
It still fails for me at -O2 in i686-linux. 

-- 


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

[Bug c++/18922] [3.3/3.4 Regression] ICE in tree_low_cst, at tree.c:3315

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-10 
13:27 ---


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

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/18384] [3.3/3.4/4.0 Regression] ICE on zero-length array with empty initializer...

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-10 
13:27 ---
*** Bug 18922 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||a dot kral at sh dot cvut
   ||dot cz


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

[Bug target/16932] Compilation error for sh-coff-gcc little endian target

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-10 
13:39 ---
So lets close it as fixed for 4.0.0 then.

-- 
   What|Removed |Added

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


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

[Bug target/18919] print_address_operand produces segmentation fault

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-10 
13:44 ---
Fixed in 4.0.0 by changing the definition of HOST_LONG_LONG_FORMAT to be 
correct for mingw32.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|c   |target
 Resolution||FIXED
   Target Milestone|--- |4.0.0


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

[Bug libfortran/18924] New: segfault in dot_product with missing interface information

[Thomas dot Koenig at online dot de]

This one is a bit tricky.  It passes two arrays
to a subroutine, where they are passed on to the
intrinsic function dot_product.  However, they
are passed old-style, without interface information.
dot_product expects to receive only new-style arrays,
and generates a segfault in the executed program.

This one can't be caught at compile time (at least not
without inter-procedural analysis) because it's
the caller who determines wether to pass an old-style
or a new-style array.

$ cat dot_product.f90
program main
  implicit none
  real, dimension(2) :: a, b
  real :: c
  a = 1.
  b = -2.3
  call foo(a,b,c)
  print *,c
end program main

subroutine foo(a,b,c)
  real, dimension(:), intent(in) :: a, b
  real, intent(out) :: c
  c = dot_product(a,b)
end subroutine foo
$ gfortran dot_product.f90 && ./a.out
Segmentation fault
$ gfortran -v
Reading specs from /home/zfkts/lib/gcc/ia64-unknown-linux-gnu/4.0.0/specs
Configured with: ../gcc-4.0-20041205/configure --prefix=/home/zfkts
--enable-languages=c,c++,f95 --disable-shared
Thread model: posix
gcc version 4.0.0 20041205 (experimental)

-- 
   Summary: segfault in dot_product with missing interface
information
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/18920] internal compiler error: Segmentation fault

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-10 
13:47 ---
Fixed in 3.4.0 and later:
pr18920.cc:16: error: template argument required for 'struct print_matrix'
pr18920.cc:16: error: types may not be defined in parameter types
pr18920.cc:20: error: two or more data types in declaration of 'parameter'
pr18920.cc:20: error: 'class std::vector >, std::
allocator > > >' is not a valid type 
for a template constant 
parameter
pr18920.cc:20: error: expected `>' before ';' token
pr18920.cc:26: error: expected unqualified-id at end of input

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Keywords||ice-on-invalid-code
 Resolution||FIXED
   Target Milestone|--- |3.4.0


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

[Bug fortran/17175] set_exponent breaks with integer*8 exponent

[Tobias dot Schlueter at physik dot uni-muenchen dot de]

--- Additional Comments From Tobias dot Schlueter at physik dot 
uni-muenchen dot de  2004-12-10 13:48 ---
Subject: Re:  set_exponent breaks with integer*8 exponent

paulthomas2 at wanadoo dot fr wrote:
> --- Additional Comments From paulthomas2 at wanadoo dot fr  2004-12-10 
> 13:35 ---
> You have fixed this one, haven't you? cvs 20041205 runs it fine.

I don't think so, maybe it's got hidden by another change.

> However, in testing, I found another nasty:
> 
> y = 1/2 + 1/8
> !y= 0.125 + 0.5 !!works OK

1/2 .EQ. 0 in Fortran, same for 1/8, this is integer division :-)

- Tobi


-- 


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

[Bug c++/18731] [3.3/3.4/4.0 regression] ICE on invalid template declaration

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-10 
13:50 ---
Patch here: .

-- 
   What|Removed |Added

   Keywords||patch


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

[Bug target/18925] New: Invalid gprel relocation in PIC

[schwab at suse dot de]

$ cat gprel.cc 
class __attribute__ ((visibility("default"))) Type 
{ 
 private: 
  static long _staticTypeCount; 
 public: 
  Type() { _staticTypeCount++; } 
  ~Type(); 
}; 
 
long Type::_staticTypeCount = 0; 
 
Type::~Type() 
{ 
 _staticTypeCount--; 
} 
$ gcc -fPIC -fvisibility=hidden -S gprel.cc 
$ grep _staticTypeCount gprel.s 
.global _ZN4Type16_staticTypeCountE# 
.type   _ZN4Type16_staticTypeCountE#, @object 
.size   _ZN4Type16_staticTypeCountE#, 8 
_ZN4Type16_staticTypeCountE: 
addl r14 = @gprel(_ZN4Type16_staticTypeCountE#), gp 
addl r14 = @gprel(_ZN4Type16_staticTypeCountE#), gp 
addl r14 = @gprel(_ZN4Type16_staticTypeCountE#), gp 
addl r14 = @gprel(_ZN4Type16_staticTypeCountE#), gp

-- 
   Summary: Invalid gprel relocation in PIC
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schwab at suse dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: ia64-*-linux


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

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

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-10 
14:14 ---
Note the date for C++ is different:
: Search converges between 2004-08-30-trunk (#529) and 2004-08-31-trunk (#530).

-- 


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

[Bug target/18896] addressing split complex parm

[amodra at bigpond dot net dot au]

--- Additional Comments From amodra at bigpond dot net dot au  2004-12-10 
14:14 ---
http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00682.html

-- 
   What|Removed |Added

   Keywords||ABI, ice-on-valid-code,
   ||patch, wrong-code


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

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

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-10 
14:18 ---
(In reply to comment #9)
> The fail dates from comment #3 probably refer to this change
> 
> 2004-10-17  Andrew Pinski  <[EMAIL PROTECTED]>
>   
>   
> * c-typeck.c (default_function_array_conversion): Always create
> &a[0] for array types.
> (build_unary_op): Do not fold &a[x] into a + x.
> 
> which was reverted again on the same day.  Can someone try with the reghunter
> to see if it failed before October 17 also?

What this tells me it is a latent bug in x86/x86_64 back-end as my change 
should not change what RTL 
is produced as it is the back-end's job to reject addressing modes.

-- 


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

[Bug libfortran/17597] list directed read has error

[paulthomas2 at wanadoo dot fr]

--- Additional Comments From paulthomas2 at wanadoo dot fr  2004-12-10 
14:24 ---
This runs correctly when read(10,*)I,X,P,Z,G is broken up into
read(10,*)I,X
read(10,*)P,Z,G



(In reply to comment #0)
> here is the list directed read example from the F2003 draft standard:
> $ cat a.f
> ! taken from F2003 standard
>integer I
>real X(8)
>data X / 8*0.0/
>character*20 P
>complex z
>logical g
>open(UNIT=10)
>write(10,'(A)') '12345,12345,,2*1.5,4*'
>write(10,'(A)') "ISN'T_BOB'S,(123,0),.TEXAS$"
>rewind(10)
>read(10,*)I,X,P,Z,G
>print*,I,X,P,Z,G
>end
>  
> $ gfc a.f
> $ ./a.out
> At line 12 of file a.f
> Fortran runtime error: Bad complex value in item 11 of list input
> $ g77 a.f
> $ ./a.out
>  12345  12345.  0.  1.5  1.5  0.  0.  0.  0.ISN'T_BOB'S  (123.,0.) T



-- 


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

[Bug fortran/17175] set_exponent breaks with integer*8 exponent

[tobi at gcc dot gnu dot org]

--- Additional Comments From tobi at gcc dot gnu dot org  2004-12-10 14:53 
---
BTW Paul, this depends on the endianess of your target, the error won't show up
on i686.  I'm currently testing a patch which should really fix this.

-- 


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

[Bug target/18925] [4.0 regression] Invalid gprel relocation in PIC

[schwab at suse dot de]

-- 
   What|Removed |Added

Summary|Invalid gprel relocation in |[4.0 regression] Invalid
   |PIC |gprel relocation in PIC


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

[Bug target/17767] [4.0 Regression] MMX intrinsics cause internal compiler error

[uros at kss-loka dot si]

--- Additional Comments From uros at kss-loka dot si  2004-12-10 15:34 
---
This patch will fix the mainline, but more investigation is needed.

Index: cse.c
===
RCS file: /cvs/gcc/gcc/gcc/cse.c,v
retrieving revision 1.327
diff -u -r1.327 cse.c
--- cse.c   26 Nov 2004 15:42:36 - 1.327
+++ cse.c   10 Dec 2004 15:30:34 -
@@ -3860,6 +3860,9 @@
 
 case RTX_COMPARE:
 case RTX_COMM_COMPARE:
+  if (VECTOR_MODE_P (mode))
+   break;
+
   /* See what items are actually being compared and set FOLDED_ARG[01]
 to those values and CODE to the actual comparison code.  If any are
 constant, set CONST_ARG0 and CONST_ARG1 appropriately.  We needn't

Uros.

-- 


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

[Bug c++/18926] New: internal compiler error: in tree_low_cst, at tree.c:3255

[gcc-bugzilla at gcc dot gnu dot org]

[EMAIL PROTECTED]:/tmp/s$ g++ -c foo.c
foo.c:16: internal compiler error: in tree_low_cst, at tree.c:3255
when compiling following code:

 8< [cut here] ---
typedef struct {
char *str;
int n;
char *(f[]);
char *(l[]);
int *a;
} t_moja;


t_moja x={
"foobar",
4,
{"imie","nazwisko","telefon","email"},
{"Imiê","Nazwisko","Telefon","E-mail"},
{0,1,2,3},
};


t_moja y={
"baz",
2,
{"dupa","blada"},
{"Pan","Kowalski"},
{8,9}
};

 8< [cut here] ---

Environment:
System: Linux blabluga.hell.pl 2.6.7bl #1 Sun Jul 4 17:47:48 CEST 2004 i686 
GNU/Linux
Architecture: i686


host: i486-pc-linux-gnu
build: i486-pc-linux-gnu
target: i486-pc-linux-gnu
configured with: ../src/configure -v 
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr 
--mandir=/usr/share/man --infodir=/usr/share/info 
--with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --with-system-zlib 
--enable-nls --without-included-gettext --enable-__cxa_atexit 
--enable-clocale=gnu --enable-debug --enable-java-gc=boehm 
--enable-java-awt=xlib --enable-objc-gc i486-linux

How-To-Repeat:
Save above snippet into file and run:
g++ -c filename

-- 
   Summary: internal compiler error: in tree_low_cst, at tree.c:3255
   Product: gcc
   Version: 3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: arturcz at blabluga dot hell dot pl
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i486-pc-linux-gnu
  GCC host triplet: i486-pc-linux-gnu
GCC target triplet: i486-pc-linux-gnu


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

[Bug target/18927] New: O(n^2) compile time with -O0 (n= number of basic blocks) in global alloc

[heinrich dot brand at fujitsu-siemens dot com]

Some C-Code is (with Option -O0) processed by an algorithm with O(n^2) time.
This simple code scheme shows that the compile time grows fast with
the number of basic blocks in a function. If the number of 
basic blocks is doubled the compile time is almost quadrupled.
The output of -ftime-report shows that global alloc uses most of the time.  
But C-Code with a small difference has roughly O(n) compile time.
expensive code:
  if(*i0){int a; a=(*i1);*i2=(a/3+a/7);} : roughly O(n*n) compile time
  if(*i0){int a; a=(*i1);*i2=(a/3+(*i2)/7);} : roughly O(n*n) compile time
cheap code:
  if(*i0){int a; a=(*i1);*i2=(a*3+a*7);} : roughly  O(n)  compile time
  if(*i0){int a; a=(*i1);*i2=(a*3+(*i2)*7);} : roughly  O(n)  compile time

Used Code Scheme:

void test(int *i0,int *i1,int *i2){
  if(*i0){int a; a=(*i1);*i2=(a/3+a/7);}
  ... copies of the last statement
return;}

The body of the test function consists of a number of copies of 
the following Statement:
if(*i0){int a; a=(*i1);*i2=(a/3+a/7);}
Each statement produces 2 basic blocks.

Content of the following table:

BBs : number of basic blocks in if-statements
user: user time from /usr/bin/time gcc 
global_alloc : from output of -ftime-report 
lines of assembler code : lines of gcc output
(Intel Pentium 700Mhz or an old SPARC-Computer)

Table relating number of basic block to compile time for gcc 3.4.3 intel

BBs  user   global_alloclines of assembler code
---
100  0.22   0.12(55%)   1468
200  0.54   0.30(56%)   2918
400  1.36   0.91(67%)   5818
800  4.09   3.15(77%)   11618
1600 15.52  13.67   (88%)   23218
3200 76.63  72.87   (95%)   46418
6400 277.25 269.49  (97%)   92818
128001072.581057.20 (99%)   185618


Table relating number of basic block to compile time for gcc 3.2 intel
==
BBs  user   global_alloclines of assembler code
---
100  0.170.07(41%)   1369
200  0.370.15(42%)   2719
400  0.760.36(48%)   5419
800  1.530.76(50%)   10819
1600 3.501.80(52%)   21619
3200 8.134.59(56%)   43219
6400 21.59   14.33   (66%)   86419
1280062.03   45.75   (74%)   172819




Table relating number of basic block to compile time for gcc 3.4.3 sparc
=
BBs  user   global_alloclines of assembler code
---
100  0.320.05(16%)   1218
200  0.490.07(15%)   2418
400  0.870.16(19%)   4818
800  1.490.30(20%)   9618
1600 3.100.67(22%)   19218
3200 6.721.51(23%)   38418
6400 14.95   4.45(30%)   76818
1280054.73   32.43   (59%)   153618

Table relating number of basic block to compile time for gcc 2.95.2 sparc
=
BBs  user   global_alloclines of assembler code
---
100  0.111173
200  0.172323
400  0.304623
800  0.629223
1600 1.3518423
3200 2.9036823
6400 6.1973623
1280014.97   147223


Table relating number of basic block to compile time for gcc 3.4.3 intel
for this Code: if(*i0){int a; a=(*i1);*i2=(a*3+a*7);}
=
BBs  user   global_alloclines of assembler code
---
100  0.110.01(10%)   713
200  0.160.03(20%)   1413
400  0.350.07(21%)   2813
800  0.650.14(22%)   5613
1600 1.330.28(21%)   11213
3200 2.930.58(20%)   22413
6400 5.801.15(20%)   44813
1280012.09   2.68(22%)   89613


Shellscripts:
---
for x in  50 100 200 400 800 1600 3200 6400 
do
echo " $x"
run $x
done


---
[[ -z $1 ]] && exit 1
N=$1

echo 'void test(int *i0,int *i1,int *i2){' >z.c

IF="if(*i0){int a; a=(*i1);*i2=(a/3+(*i2)/7);}"

((i=$N))
while((i>0))
do
echo "  $IF" >>z.c
((i=i-1))
done
echo 'return;}' >>z.c

wc z.c
echo "$IF"
/usr/bin/time -p gcc -S -O0 -ftime-report z.c
((BB=N+N))
echo "### BB $BB"
wc z.s

-
gawk '
  $1=="g

[Bug c++/17868] [3.3 regression] RDIV_EXPR not supported by dump_expr

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2004-12-10 
15:48 ---
Gaby, is this trivial patch OK for the 3.3 branch?


-- 


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

[Bug c++/18731] [3.3/3.4/4.0 regression] ICE on invalid template declaration

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-10 
16:04 ---
Subject: Bug 18731

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-12-10 16:04:22

Modified files:
gcc/cp : ChangeLog parser.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/g++.dg/parse: struct-1.C struct-2.C struct-3.C 

Log message:
PR c++/18731
* parser.c (cp_parser_class_head): Reject typedef-name in class head.

* g++.dg/parser/struct-1.C: New test.
* g++.dg/parser/struct-2.C: New test.
* g++.dg/parser/struct-3.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4527&r2=1.4528
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gcc&r1=1.292&r2=1.293
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4734&r2=1.4735
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/struct-1.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/struct-2.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/struct-3.C.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug c++/18926] internal compiler error: in tree_low_cst, at tree.c:3255

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-10 
16:08 ---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE
Version|3.3 |3.3.5


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

[Bug c++/18327] [3.3/3.4/4.0 Regression] ICE while compiling valid c code with g++

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-10 
16:08 ---
*** Bug 18926 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||arturcz at hell dot pl


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

[Bug target/18925] [4.0 regression] Invalid gprel relocation in PIC

[schwab at suse dot de]

--- Additional Comments From schwab at suse dot de  2004-12-10 16:23 ---
Broken by 
 
2004-08-03  Mark Mitchell  <[EMAIL PROTECTED]> 
 
* class.c (build_vtable): Do not set DECL_VISIBILITY here. 
(check_field_decls): Or here. 
(check_methods): Or here. 
(initialize_array): Don't mess with DECL_CONTEXT. 
* cp-tree.h (start_decl): Adjust prototype. 
(determine_visibility): New function. 
* decl.c (duplicate_decls): Remove checks for hidden "operator 
new". 
(build_library_fn_1): Give all library functions default 
visibility. 
(start_decl): Add pop_scope_p parameter.  Tidy. 
(cp_finish_decl): Do not pop scopes here.  Call 
determine_visibility for variable definitions. 
(start_preparsed_function): Call determine_visibility. 
* decl2.c (determine_visibility): New function. 
* method.c (use_thunk): Fix formatting. 
* parser.c (cp_parser_condition): Adjust calls to start_decl. 
(cp_parser_init_declarator): Likewise. 
* pt.c (instantiate_decl): Always call pop_nested_class. 
* rtti.c (get_tinfo_decl): Do not set DECL_VISIBILITY. 
(tinfo_base_init): Likewise. 
 

-- 
   What|Removed |Added

 CC||mark at codesourcery dot com


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

[Bug target/18459] [4.0 Regression] gcj no longer works on win32

[ovidr at users dot sourceforge dot net]

--- Additional Comments From ovidr at users dot sourceforge dot net  
2004-12-10 16:35 ---
It was a completely fresh checkout to an empty dir (both times). I build a
linux->win32 cross. (building on win32 takes way too long due to fork()).

For the dwarf2 patch, I had used the one line patch from:
"http://sources.redhat.com/ml/binutils/2004-11/msg00249.html";
on the binutils-2.15.91-20040904-1-src.tar.gz from mingw.org.  If I don't need
any further patches(?), I will try to use binutils directly from cvs and build
it again.







-- 


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

[Bug c++/17868] [3.3 regression] RDIV_EXPR not supported by dump_expr

[gdr at integrable-solutions dot net]

--- Additional Comments From gdr at integrable-solutions dot net  
2004-12-10 16:53 ---
Subject: Re:  [3.3 regression] RDIV_EXPR not supported by dump_expr

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

| Gaby, is this trivial patch OK for the 3.3 branch?

Yes, thanks.

-- Gaby


-- 


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

[Bug middle-end/18928] ice on valid code with -O2 -fPIC

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|other   |middle-end
   Keywords||ice-on-valid-code
Summary|ice on valid code.  |ice on valid code with -O2 -
   ||fPIC


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

[Bug bootstrap/15212] [3.4/4.0 Regression] bootstrap fails on interix3

[neroden at gcc dot gnu dot org]

-- 
   What|Removed |Added

 Status|WAITING |ASSIGNED
   Last reconfirmed|2004-04-29 21:27:43 |2004-12-10 16:59:27
   date||


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

[Bug target/18019] [4.0 Regression] -march=pentium4 generates word fetch instead of byte fetch

[neroden at gcc dot gnu dot org]

--- Additional Comments From neroden at gcc dot gnu dot org  2004-12-10 
17:09 ---
Oh, cool.  :-)  Did you get the patch linked up? 

-- 


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

[Bug target/18153] [3.4/4.0 Regression] -static-libgcc links in libunwind.so.7

[hjl at lucon dot org]

--- Additional Comments From hjl at lucon dot org  2004-12-10 17:11 ---
An updated patch is posted at

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

-- 


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

[Bug rtl-optimization/16536] [3.3 regression] Incorrect __restrict__ optimization in -O2

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2004-12-10 
17:26 ---
Fixed.


-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug libfortran/18891] write with no open causes core dump

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-10 
17:44 ---
Patch here: .

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||patch
   Last reconfirmed|-00-00 00:00:00 |2004-12-10 17:44:02
   date||


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

[Bug middle-end/18928] ice on valid code with -O2 -fPIC

[bangerth at dealii dot org]

--- Additional Comments From bangerth at dealii dot org  2004-12-10 18:01 
---
This used to work with my somewhat outdated version 20041015; it must 
be a regression since then. 
 
W. 

-- 


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

[Bug libfortran/17597] list directed read has error

[sgk at troutmask dot apl dot washington dot edu]

--- Additional Comments From sgk at troutmask dot apl dot washington dot 
edu  2004-12-10 18:03 ---
The patch included here

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

fixes this problem.

-- 
steve

-- 


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

[Bug middle-end/18928] [4.0 regression] ice on valid code with -O2 -fPIC

[bangerth at dealii dot org]

--- Additional Comments From bangerth at dealii dot org  2004-12-10 18:04 
---
I can, however, confirm the segfault on top-of-mainline. No reduced 
testcase, however. 
 
W. 

-- 
   What|Removed |Added

  Known to fail||4.0.0
Summary|ice on valid code with -O2 -|[4.0 regression] ice on
   |fPIC|valid code with -O2 -fPIC
   Target Milestone|--- |4.0.0


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

[Bug tree-optimization/18694] [4.0 regression] loop miscompilation at -O1 (-ftree-ch)

[law at redhat dot com]

--- Additional Comments From law at redhat dot com  2004-12-10 18:11 ---
Subject: Re:  [4.0 regression] loop
miscompilation at -O1 (-ftree-ch)

On Thu, 2004-12-09 at 05:24 +, kazu at cs dot umass dot edu wrote:
> --- Additional Comments From kazu at cs dot umass dot edu  2004-12-09 
> 05:24 ---
> Updated the testcase like so:
> 
> /* PR tree-optimization/18694
> 
>The dominator optimization didn't take the PHI evaluation order
>into account when threading an edge.  */
> 
> extern void abort (void) __attribute__((noreturn));
> extern void exit (int) __attribute__((noreturn));
> 
> void __attribute__((noinline))
> foo (int i)
> {
>   int next_n = 1;
>   int j = 0;
> 
>   for (; i != 0; i--)
> {
>   int n;
> 
>   for (n = next_n; j < n; j++)
>   next_n++;
> 
>   if (j != n)
>   abort ();
> }
> }
> 
> int
> main (void)
> {
>   foo (2);
>   exit (0);
> }
> 
> 
Can you go ahead and install this into the testsuite?  No need to xfail
since we ought to have a patch installed for the problem soon.

jeff




-- 


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

[Bug middle-end/18928] [4.0 regression] ice on valid code with -O2 -fPIC

[bangerth at dealii dot org]

--- Additional Comments From bangerth at dealii dot org  2004-12-10 18:13 
---
Here's a small testcase: 
-- 
const char *toHex( unsigned short u ) 
{ 
  static char hexVal[5]; 
  int i = 3; 
  while ( i >= 0 ) { 
unsigned short hex = (u & 0x000f); 
if ( hex < 0x0a ) 
  hexVal[i] = '0'+hex; 
else 
  hexVal[i] = 'A'+(hex-0x0a); 
i--; 
  } 
  hexVal[4] = '\0'; 
  return hexVal; 
} 
--- 
sandbox/tt> ../../build-gcc/gcc-install/bin/c++ -O2 -fPIC -c x.cc  
c++: Internal error: Segmentation fault (program cc1plus) 
Please submit a full bug report. 
See http://gcc.gnu.org/bugs.html> for instructions. 
 
W. 

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-12-10 18:13:02
   date||


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

[Bug middle-end/18928] [4.0 regression] ice on valid code with -O2 -fPIC

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-10 
18:14 ---
: Search converges between 2004-11-03-014001-trunk (#612) and 
2004-11-03-161001-trunk 
(#613).


-- 


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

[Bug c/18929] New: Profiling optimized code causes segfaults on ARM due to missing frames

[opensource at artnaseef dot com]

When compiling with the arm-linux compiler with optimization enabled, the 
compiler removes frame pointers from functions even when they are profiled.  
This leads to a segmentation fault with the glibc version of mcount when it 
attempts to determine the caller of a function from the current stack because 
mcount assumes the frame pointer is there.

It seems that optimized functions, on this platform, should not drop their 
frame 
pointers when profiling is enabled.

-- 
   Summary: Profiling optimized code causes segfaults on ARM due to
missing frames
   Product: gcc
   Version: 3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: opensource at artnaseef dot com
CC: gcc-bugs at gcc dot gnu dot org,opensource at artnaseef
dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-linux


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

[Bug c/18929] Profiling optimized code causes segfaults on ARM due to missing frames

[opensource at artnaseef dot com]

--- Additional Comments From opensource at artnaseef dot com  2004-12-10 
18:19 ---
Created an attachment (id=7720)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7720&action=view)
recommended fix

This patch fixes the problem by forcing functions to keep their frame pointers
when compiled with profiling.  It maintains portability by using a macro, and
only defining it for the ARM architecture, that indicates when mcount requires
the frame pointer.


-- 


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

[Bug target/18929] Profiling optimized code causes segfaults on ARM due to missing frames

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-10 
18:20 ---
Does this work in 3.4.?

-- 
   What|Removed |Added

  Component|c   |target


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

[Bug tree-optimization/18694] [4.0 regression] loop miscompilation at -O1 (-ftree-ch)

[law at redhat dot com]

--- Additional Comments From law at redhat dot com  2004-12-10 18:24 ---
Subject: Re:  [4.0 regression] loop
miscompilation at -O1 (-ftree-ch)

On Fri, 2004-12-10 at 00:28 +, kazu at cs dot umass dot edu wrote:
> --- Additional Comments From kazu at cs dot umass dot edu  2004-12-10 
> 00:28 ---
> Subject: Re:  [4.0 regression] loop
>  miscompilation at -O1 (-ftree-ch)
> 
> Hi Jeff,
> 
> > I believe your fast-path check is effectively equivalent to
> > 
> > if ((e->flags & EDGE_DFS_BACK) == 0)
> 
> I see that we call mark_dfs_back_edges at the beginning of
> tree_ssa_dominator_optimize.  Now, after we call cleanup_tree_cfg, can
> we trust EDGE_DFS_BACK?
> 
> No pass in cleanup_tree_cfg really adds an edge.  All we do is either
> remove or redirect edges, so the real question is "Do we ever get a
> new back edge without a EDGE_DFS_BACK mark as a result of edge
> redirection?"  If we have a forwarder block BB flowing into the loop
> header, BB's sole successor edge may be marked with a EDGE_DFS_BACK,
> but its incoming edges may not be.  When we call
> cleanup_forwarder_blocks, the edges that will survive are BB's
> incoming edges, not the edge going out of BB, so we may end up with a
> back edge without a EDGE_DFS_BACK mark.
Hmm, I think you're right.


> I think we should call mark_dfs_back_edges at the beginning of every
> iteration
That might be advisable -- we use EDGE_DFS_BACK to avoid creating
irreducible loops as a result of jump threading IIRC.


>  or simply use dominated_by_p, which is not too expensive -
> only a couple of "if" statements, assuming the dominator infomatino is
> available.
EDGE_DFS_BACK would have been more efficient.  But I don't think it's
100% safe right now.

Jeff




-- 


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

[Bug c/18930] New: name clash in C?

[jacob at engelbrecht dot dk]

On several different version of gcc (2.95, 3.3 and 3.4)
(gcc-3.4 --version reports: gcc-3.4 (GCC) 3.4.2 (Debian 3.4.2-2))
When I compile a.c I get errors:

a.c:6: error: parse error before "c"
etc

but b.c compiles without errors. As I understand the ANSI-C standard,
type names and variable names should be separate namespaces - and both
programs should compile (borland turbo C 2.01 compiles both programs).

==> a.c <==
#include 

typedef int i;
typedef char c;

i main (i c, c ** v)
{
  i i=1;
  printf("%d\n",c+i);
  return 0;
}

==> b.c <==
#include 

typedef int i;
typedef char c;

i main (i C, c ** v)
{
  i i=1;
  printf("%d\n" C+i);
  return 0;
}

-- 
   Summary: name clash in C?
   Product: gcc
   Version: 3.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jacob at engelbrecht dot dk
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug tree-optimization/18694] [4.0 regression] loop miscompilation at -O1 (-ftree-ch)

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

--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni 
dot cz  2004-12-10 18:38 ---
Subject: Re:  [4.0 regression] loop miscompilation at -O1 (-ftree-ch)

> >  or simply use dominated_by_p, which is not too expensive -
> > only a couple of "if" statements, assuming the dominator infomatino is
> > available.
> EDGE_DFS_BACK would have been more efficient.  But I don't think it's
> 100% safe right now.

not that much.  Since you do not change cfg in the progress of dominator
optimizations, you should have fast query structure for dominators
up-to-date; i.e.  testing whether a basic block dominates other takes only
two comparisons of integers.


-- 


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

[Bug target/18929] Profiling optimized code causes segfaults on ARM due to missing frames

[opensource at artnaseef dot com]

--- Additional Comments From opensource at artnaseef dot com  2004-12-10 
18:40 ---
Subject: Re:  Profiling optimized code causes segfaults
on ARM due to missing frames

I have not tested it, but I don't see why not.  The patch is fairly short and 
straight-forward, I believe.

-- Original Message -
Subject: [Bug target/18929] Profiling optimized code causes segfaults on ARM 
due to missing frames
Date: 10 Dec 2004 18:20:04 -
From: "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]



--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-10 
18:20 ---
Does this work in 3.4.?

-- 
   What|Removed |Added

  Component|c   |target


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

--- You are receiving this mail because: ---
You reported the bug, or are watching the reporter.
You are on the CC list for the bug, or are watching someone who is.





-- 


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

[Bug rtl-optimization/18928] [4.0 regression] ice on valid code with -O2 -fPIC

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-10 
18:40 ---
simplify_plus_minus is where the problem is.

-- 
   What|Removed |Added

  Component|middle-end  |rtl-optimization


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

[Bug tree-optimization/18694] [4.0 regression] loop miscompilation at -O1 (-ftree-ch)

[kazu at cs dot umass dot edu]

--- Additional Comments From kazu at cs dot umass dot edu  2004-12-10 18:53 
---
Subject: Re:  [4.0 regression] loop
 miscompilation at -O1 (-ftree-ch)

Hi Zdenek,

> > >  or simply use dominated_by_p, which is not too expensive -
> > > only a couple of "if" statements, assuming the dominator infomatino is
> > > available.
> > EDGE_DFS_BACK would have been more efficient.  But I don't think it's
> > 100% safe right now.
> 
> not that much.  Since you do not change cfg in the progress of dominator
> optimizations, you should have fast query structure for dominators
> up-to-date; i.e.  testing whether a basic block dominates other takes only
> two comparisons of integers.

Right.  If we have dominator information available,
mark_dfs_back_edges does nothing but duplicates a part of what the
dominator information has to offer.  (It's not that
mark_dfs_back_edges is very flow, but )

Kazu Hirata


-- 


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

[Bug other/18665] [3.4/4.0 Regression] -ftrapv borks up simple integer arithmetic

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2004-12-10 18:58 
---
I'm not sure redirecting __addvsi3 to __addvdi3 is correct.  If we provide that
symbol at all, I think it should do what it advertises.

Just so I'm clear, are we invoking __addvsi3 right now, or is it just that
__addvdi3 has the wrong implementation?

-- 
   What|Removed |Added

  GCC build triplet|*-*-*   |
   GCC host triplet|*-*-*   |
 GCC target triplet|*-*-*   |


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

[Bug tree-optimization/18694] [4.0 regression] loop miscompilation at -O1 (-ftree-ch)

[law at redhat dot com]

--- Additional Comments From law at redhat dot com  2004-12-10 19:18 ---
Subject: Re:  [4.0 regression] loop
miscompilation at -O1 (-ftree-ch)

On Fri, 2004-12-10 at 19:08 +, kazu at cs dot umass dot edu wrote:

> I think so. :-)
I don't.  :(  I think it'll record tmp_1 = next_2, which is actually
wrong, even though it doesn't actually cause problems with this
testcase.


> What thread_across_edge is really trying to do is "What would these
> statements in E->dest look like if they appeared at the end of
> E->src?"  Then the question is reduced to whether each statement in
> E->dest is translated correctly.  To do the translation, we use
> SSA_NAME_VALUE, but note that we don't use it iteratively.  In other
> words, given a SSA_NAME variable VAR, we don't do this
> 
>   while (TREE_CODE (var) == SSA_NAME
>&& SSA_NAME_VALUE (var) != NULL_TREE)
> var = SSA_NAME_VALUE (var);
And the reason we don't do that is we can actually get into a loop
due to equivalences created by equality tests.


> p.s.
> By the way, I am now wondering how many times we succeed in threading
> a back edge.
It does happen, but I don't know how often.
jeff




-- 


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

[Bug c/18282] PR c/17384 patch causes regression from 3.4.2

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-10 
19:23 ---
Subject: Bug 18282

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED]   2004-12-10 19:23:25

Modified files:
gcc: ChangeLog attribs.c c-common.c 
Added files:
gcc/testsuite/gcc.dg: attr-mode-2.c 

Log message:
PR c/18282
* attribs.c (decl_attributes): Clear DECL_ALIGN when relaying out decl.
* c-common.c (handle_mode_attribute): Handle enumeral types.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.2326.2.726&r2=2.2326.2.727
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/attribs.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.28&r2=1.28.10.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-common.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.476.4.10&r2=1.476.4.11
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/attr-mode-2.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.2.1



-- 


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

[Bug c/18282] PR c/17384 patch causes regression from 3.4.2

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2004-12-10 19:24 
---
Fixed.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug other/18665] [3.4/4.0 Regression] -ftrapv borks up simple integer arithmetic

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-12-10 
19:24 ---
> I'm not sure redirecting __addvsi3 to __addvdi3 is correct.  If we provide 
> that
> symbol at all, I think it should do what it advertises.

But what we export now as __addvsi3 will be exported as __addvdi3 after the fix.

> Just so I'm clear, are we invoking __addvsi3 right now, or is it just that
> __addvdi3 has the wrong implementation?

The latter.  __addvdi3 uses double words everywhere, so is actually __addvti3 on
64-bit targets.


-- 


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

[Bug middle-end/18903] [4.0 Regression] ice in bsi_after_labels

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-10 
19:32 ---
Subject: Bug 18903

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-12-10 19:32:14

Modified files:
gcc: ChangeLog tree-cfg.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.c-torture/compile: pr18903.c 

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

PR middle-end/18903
* gcc.c-torture/compile/pr18903.c: New test.

2004-12-10  Andrew Pinski  <[EMAIL PROTECTED]>

PR middle-end/18903
* tree-cfg.c (remove_bb): Put the moved label at the beginning
of the basic block.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6773&r2=2.6774
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-cfg.c.diff?cvsroot=gcc&r1=2.133&r2=2.134
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4736&r2=1.4737
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/pr18903.c.diff?cvsroot=gcc&r1=NONE&r2=1.1


--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-10 
19:32 ---
Fixed.

-- 


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

[Bug middle-end/18931] jar -> .so optimization problem

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-10 
19:41 ---
What target is this on? i686-pc-linux?
I cannot reproduce this on 20041204 on powerpc-darwin.

-- 
   What|Removed |Added

  Component|java|middle-end
   Keywords||ice-on-valid-code


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

[Bug middle-end/18931] jar -> .so optimization problem

[overholt at redhat dot com]

--- Additional Comments From overholt at redhat dot com  2004-12-10 19:43 
---
Yes, this is i686-linux.  I'll update to a more recent snapshot and see if I can
reproduce.

-- 


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

[Bug tree-optimization/18694] [4.0 regression] loop miscompilation at -O1 (-ftree-ch)

[law at redhat dot com]

--- Additional Comments From law at redhat dot com  2004-12-10 19:44 ---
Subject: Re:  [4.0 regression] loop
miscompilation at -O1 (-ftree-ch)

On Fri, 2004-12-10 at 19:08 +, kazu at cs dot umass dot edu wrote:

> By the way, I am now wondering how many times we succeed in threading
> a back edge.
I just put in some instrumentation.  It happens relatively often.

jeff





-- 


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

[Bug tree-optimization/18694] [4.0 regression] loop miscompilation at -O1 (-ftree-ch)

[law at redhat dot com]

--- Additional Comments From law at redhat dot com  2004-12-10 20:00 ---
Subject: Re:  [4.0 regression] loop
miscompilation at -O1 (-ftree-ch)

On Fri, 2004-12-10 at 19:08 +, kazu at cs dot umass dot edu wrote:
> --- Additional Comments From kazu at cs dot umass dot edu  2004-12-10 
> 19:08 ---
> Subject: Re:  [4.0 regression] loop
>  miscompilation at -O1 (-ftree-ch)
> 
> Hi Jeff,
> 
> > Note that recording tmp_1 = next_2 isn't particularly good either since 
> > tmp_1 really isn't equivalent to next_2.  It's equivalent to the
> > previous valueof n next_2, which was next_3.  ugh.  Anyway, I'll verify
> > that Kazu's patch handles this correctly.
> 
> I think so. :-)
> 
> What thread_across_edge is really trying to do is "What would these
> statements in E->dest look like if they appeared at the end of
> E->src?"  Then the question is reduced to whether each statement in
> E->dest is translated correctly.  To do the translation, we use
> SSA_NAME_VALUE, but note that we don't use it iteratively.  In other
> words, given a SSA_NAME variable VAR, we don't do this
> 
>   while (TREE_CODE (var) == SSA_NAME
>&& SSA_NAME_VALUE (var) != NULL_TREE)
> var = SSA_NAME_VALUE (var);
> 
> because SSA_NAME_VALUE is supposed to be closed so that you won't need
> to iterate.  So when we follow "copy-of" relation from tmp_1 to next_2
> using SSA_NAME_VALUE, we don't follow next_2 to something else.
> 
> Note also that lookup_avail_expr does not translate the expression in
> hash table using SSA_NAME_VALUE.  What we translate is the expression
> that we look up.
BTW, I may have a nice clean way to deal with this problem which doesn't
depend on us not walking the SSA_NAME_VALUE chain.

I'm looking into it now...

jeff




-- 


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

[Bug other/18665] [3.4/4.0 Regression] -ftrapv borks up simple integer arithmetic

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-12-10 
20:04 ---
> If addvsi3 actually performs addvdi3, that will be most surprising to
> everyone.  I think that's a very bad idea.  Since we are not invoking 
> addvsi3, 
> and I suspect it's impossible to convince the compiler to do so,

After your patch, that's indeed the case.

> I think there's no reason to provide the backward compatibility function at
> all; the symbol was unused and unusable.

Except that, before your patch, the 64-bit compiler was emitting addvsi3 (see
comment #6 by Steven).  So I think we need to provide the symbol.  The question
would then be: should we provide real SImode addition or word_mode addition as
currently?  Strict backwards compatibility would imply the latter.


-- 


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

[Bug tree-optimization/18694] [4.0 regression] loop miscompilation at -O1 (-ftree-ch)

[law at redhat dot com]

--- Additional Comments From law at redhat dot com  2004-12-10 20:12 ---
Subject: Re:  [4.0 regression] loop
miscompilation at -O1 (-ftree-ch)

On Fri, 2004-12-10 at 19:57 +, kazu at cs dot umass dot edu wrote:
> --- Additional Comments From kazu at cs dot umass dot edu  2004-12-10 
> 19:57 ---
> Subject: Re:  [4.0 regression] loop
>  miscompilation at -O1 (-ftree-ch)
> 
> Hi Jeff,
> 
> > > I think so. :-)
> > I don't.  :(  I think it'll record tmp_1 = next_2, which is actually
> > wrong, even though it doesn't actually cause problems with this
> > testcase.
> 
> IMHO, you should really think of it as tmp_1 -> next_2 or "tmp_1 is a
> copy-of next_2".  It is a one-way relation, not an equivalence because
> it is not symmetric.
Err, no.  You're totally warping how the the equivalency code is meant
to work.  It's a symmetric relationship and it's your patch that is
making it asymmetric.


> Let me also think hard to see if I can prove my patch is correct or
> come up with a counterexample.  I certainly don't intend to push my
> patch blindly.
Don't bother.  The patch is wrong.There's a couple of very simple
ways to fix this problem that I'm evaluating.

Jeff



-- 


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

[Bug other/18665] [3.4/4.0 Regression] -ftrapv borks up simple integer arithmetic

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2004-12-10 20:17 
---
Since the symbol exists in 3.3 (which I'd forgotten), we have to keep it.
But I don't see any reason we can't fix the bug in its implementation.
So let's do proper simode arithmetic.

-- 


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

[Bug target/18932] New: [3.4 regression] -march=pentium4 -O2 causes ICE

[hjl at lucon dot org]

This patch

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

causes a regression on i386.

-- 
   Summary: [3.4 regression]  -march=pentium4 -O2 causes ICE
   Product: gcc
   Version: 3.4.4
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: target
AssignedTo: rth at redhat dot com
ReportedBy: hjl at lucon dot org
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=18932

[Bug target/18932] [3.4 regression] -march=pentium4 -O2 causes ICE

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2004-12-10 20:25 
---
Do not assign prs to people unless they request it.  Assignment implies
actively working on the problem.  Use cc for advisory.

-- 
   What|Removed |Added

 AssignedTo|rth at redhat dot com   |rth at gcc dot gnu dot org
 Status|UNCONFIRMED |ASSIGNED


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

[Bug c++/18933] New: pointer-to-member called on incomplete type generates bad code

[efrias at syncad dot com]

When presented with the attached code, gcc (taken from CVS on Dec. 6 2004)
generates bad code for the function callpmf().  The code it generates never
calls the member function, so the exit status of this program is garbage (I get
39).  No diagnostic is issued when compiling.

If you replace the declaration of A with a trivial definition ("class A{};"), it
generates the correct code.

gcc-3.4.2 and earlier generated the correct code regardless of whether A was an
incomplete type.  


class A;

class B {
public:
int memfn() { return 1; }
};

int callpmf(A* a_ptr, int (A::*memfn_ptr)()) {
return (a_ptr->*memfn_ptr)();
}

int main() {
B b;
return callpmf((A*)&b, (int (A::*)())&B::memfn);
}

This bug looks related to 15684, which seems to be debating whether this is a
legal thing to do or not.  If it is decided that this is illegal, a diagnostic
would be helpful.

-- 
   Summary: pointer-to-member called on incomplete type generates
bad code
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: efrias at syncad dot com
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: i686-pc-linux-gnu


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

[Bug c++/18933] pointer-to-member called on incomplete type generates bad code

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-10 
21:09 ---
Yes this invalid code and here is the werid part we have a error_mark_node.
So this is a dup of bug 15684.

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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug tree-optimization/18694] [4.0 regression] loop miscompilation at -O1 (-ftree-ch)

[kazu at cs dot umass dot edu]

--- Additional Comments From kazu at cs dot umass dot edu  2004-12-10 21:31 
---
Subject: Re:  [4.0 regression] loop
 miscompilation at -O1 (-ftree-ch)

Hi Jeff,

> Err, no.  You're totally warping how the the equivalency code is meant
> to work.  It's a symmetric relationship and it's your patch that is
> making it asymmetric.

I thought SSA_NAME_VALUE gets me a gimple min invariant or the
earliest SSA_NAME that has the same value.

> Don't bother.  The patch is wrong.

Can you come up with a hypothetical scenario?

Kazu Hirata


-- 


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

[Bug tree-optimization/18694] [4.0 regression] loop miscompilation at -O1 (-ftree-ch)

[law at redhat dot com]

--- Additional Comments From law at redhat dot com  2004-12-10 21:42 ---
Subject: Re:  [4.0 regression] loop
miscompilation at -O1 (-ftree-ch)

On Fri, 2004-12-10 at 21:31 +, kazu at cs dot umass dot edu wrote:

> Can you come up with a hypothetical scenario?
No need.  It's fundamentally broken in that it's recording
an invalid equivalence.  It's recording that tmp_1 = next_2
which is totally bogus.

The only reason it works is because we don't walk through
all the SSA_NAME_VALUEs back to the oldest.  

jeff




-- 


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

[Bug c++/18933] pointer-to-member called on incomplete type generates bad code

[bangerth at dealii dot org]

--- Additional Comments From bangerth at dealii dot org  2004-12-10 21:53 
---
The fact that we don't issue any errors is a duplicate of PR 15684. However, 
the code is fundamentally broken in that you cast a pointer to B into a 
pointer to A and use it to do something with it. This violates aliasing 
constraints, and you shouldn't be surprised that your code does weird 
things. 
 
W. 

-- 


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

[Bug rtl-optimization/16613] [3.4 Regression] compile time regression, when adding cerr usage

[andre maute]

Once more i couldn't upload an attachment
with the bugzilla upload form, so i send it here.

I'll refer to it later.

Regards Andre


compiletimetest2.cc.gz
Description: GNU Zip compressed data

[Bug tree-optimization/18694] [4.0 regression] loop miscompilation at -O1 (-ftree-ch)

[kazu at cs dot umass dot edu]

--- Additional Comments From kazu at cs dot umass dot edu  2004-12-10 22:25 
---
Subject: Re:  [4.0 regression] loop
 miscompilation at -O1 (-ftree-ch)

Hi Jeff,

> > Can you come up with a hypothetical scenario?
> No need.  It's fundamentally broken in that it's recording
> an invalid equivalence.  It's recording that tmp_1 = next_2
> which is totally bogus.
> 
> The only reason it works is because we don't walk through
> all the SSA_NAME_VALUEs back to the oldest.  

Yes, I was relying on that fact.

Ah, now I see that we have two different definitions of
SSA_NAME_VALUE.  Rather than pushing what I think is the right
definition, let's get a correct definition from the author of
tree-ssa-dom.c. :-) Is the following more or less correct?

  SSA_NAME_VALUE(X) gives you a gimple min invariant or an SSA_NAME
  that has the same value as X.  If we do not find a gimple min
  invariant for X, we make every effort to make SSA_NAME_VALUE(X)
  evaluate to the oldest SSA_NAME that has the same value as X (via
  record_const_or_copy, etc), but that is not guaranteed.  For the
  best result, you may have to walk SSA_NAME_VALUE, but it's
  questionable how profitable that is.

The only comment I can find for SSA_NAME_VALUE is this:

/* Get the value of this SSA_NAME, if available.  */
#define SSA_NAME_VALUE(N) \
   SSA_NAME_CHECK (N)->ssa_name.value_handle

I think it would be helpful to expand the comment for a future
reference.  To be honest, given that tree-ssa-dom.c never walks
SSA_NAME_VALUE and that record_const_or_copy makes a transitive
closure of "copy-of" relations, I was under the impression that
SSA_NAME_VALUE gives you the oldest value.

Kazu Hirata


-- 


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

[Bug rtl-optimization/16613] [3.4 Regression] compile time regression, when adding cerr usage

[andre dot maute at gmx dot de]

--- Additional Comments From andre dot maute at gmx dot de  2004-12-10 
22:36 ---
I don't think the compile time regression is solved in the actual g++-4.0. 
I made some run time measurements with the attached file compiletimetest2.cc 
on a PIII 550. The __DEBUG__ tests only enable  and some cerr lines. 
 
> g++ -v 
Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.1/specs 
Configured with: ../gcc-3.2.1/configure --prefix=/usr --enable-shared 
--enable-languages=c,c++ --enable-threads=posix --with-slibdir=/lib 
--enable-__cxa_atexit--enable-clocale=gnu 
Thread model: posix 
gcc version 3.2.1 
 
> g++-3.3.5 -v 
Reading specs from /opt/gcc-3.3.5/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/specs 
Configured with: ../gcc-3.3.5/configure --prefix=/opt/gcc-3.3.5 
--enable-shared--enable-languages=c,c++ --enable-threads=posix 
--enable-__cxa_atexit --enable-clocale=gnu --program-suffix=-3.3.5 
--with-cpu=pentium3 
Thread model: posix 
gcc version 3.3.5 
 
> g++-3.4.3 -v 
Reading specs from /opt/gcc-3.4.3/lib/gcc/i686-pc-linux-gnu/3.4.3/specs 
Configured with: ../gcc-3.4.3/configure --prefix=/opt/gcc-3.4.3 
--enable-shared--enable-languages=c,c++ --enable-threads=posix 
--enable-__cxa_atexit --enable-clocale=gnu --program-suffix=-3.4.3 
--with-arch=pentium3 
Thread model: posix 
gcc version 3.4.3 
 
g++-4.0-20041205 -v 
Reading specs from /opt/gcc-4.0-20041205/lib/gcc/i686-pc-linux-gnu/4.0.0/specs 
Configured with: ../gcc-4.0-20041205/configure --prefix=/opt/gcc-4.0-20041205 
--enable-shared --enable-languages=c,c++ --enable-threads=posix 
--enable-__cxa_atexit --enable-clocale=gnu --disable-nls 
--program-suffix=-4.0-20041205 --with-arch=pentium3 
Thread model: posix 
gcc version 4.0.0 20041205 (experimental) 
 
 
> time g++ -c -O3 -D __NDEBUG__ compiletimetest2.cc 
real 0m9.957suser 0m9.910ssys  0m0.090s 
 
> time g++ -c -O3 -D __DEBUG__ compiletimetest2.cc 
real0m13.544suser0m13.270ssys  0m0.170s 
 
> time g++-3.3.5 -c -O3 -D __NDEBUG__ compiletimetest2.cc 
real 0m9.881suser 0m9.740ssys  0m0.130s 
 
> time g++-3.3.5 -c -O3 -D __NDEBUG__ compiletimetest2.cc 
real 0m9.881suser 0m9.740ssys  0m0.130s  
 
> time g++-3.4.3 -c -O3 -D __NDEBUG__ compiletimetest2.cc 
real0m18.614suser0m18.240ssys  0m0.310s 
 
> time g++-3.4.3 -c -O3 -D __DEBUG__ compiletimetest2.cc 
real0m21.563suser0m21.050ssys  0m0.510s 
 
> time g++-4.0-20041205 -c -O3 -D __NDEBUG__ compiletimetest2.cc 
real0m24.983suser0m24.740ssys  0m0.160s 
 
> time g++-4.0-20041205 -c -O3 -D __DEBUG__ compiletimetest2.cc 
real0m31.269suser0m30.230ssys 0m0.240s 
 
 
Regards Andre 

-- 


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

[Bug target/18459] [4.0 Regression] gcj no longer works on win32

[dannysmith at users dot sourceforge dot net]

--- Additional Comments From dannysmith at users dot sourceforge dot net  
2004-12-10 23:11 ---
Ugh, I see what is wrong with the patch I posted at:
http://gcc.gnu.org/ml/gcc-patches/2004-11/msg02192.html

* config/i386/cygming.h (TARGET_USE_JCR_SECTION): Overide
default.

Index: gcc/gcc/config/i386/cygming.h
===
RCS file: /cvs/gcc/gcc/gcc/config/i386/cygming.h,v
retrieving revision 1.23
diff -c -3 -p -r1.23 cygming.h
*** gcc/gcc/config/i386/cygming.h   6 Nov 2004 04:28:06 -   1.23
--- gcc/gcc/config/i386/cygming.h   25 Nov 2004 21:25:17 -
*** extern int i386_pe_dllimport_name_p (con
*** 408,413 
--- 410,420 
while (0)
  #endif /* HAVE_GAS_WEAK */
  
+ /* FIXME: SUPPORTS_WEAK && TARGET_HAVE_NAMED_SECTIONS is true,
+but for .jcr section to work we also need crtbegin and crtend
+objects  as well as linker supoort. */
+ #define USE_JCR_SECTION 0 <<
+ 
  /* Decide whether it is safe to use a local alias for a virtual function
 when constructing thunks.  */
  #undef TARGET_USE_LOCAL_THUNK_ALIAS_P

That should be   
#define TARGET_USE_JCR_SECTION 0

Sorry, I'll retest with clean CVS co and resubmit patch.

Danny


-- 


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

[Bug rtl-optimization/16613] [3.4 Regression] compile time regression, when adding cerr usage

[dberlin at gcc dot gnu dot org]

--- Additional Comments From dberlin at gcc dot gnu dot org  2004-12-10 
23:12 ---
(In reply to comment #9)
>  g++-4.0-20041205 -v 
> Reading specs from 
> /opt/gcc-4.0-20041205/lib/gcc/i686-pc-linux-gnu/4.0.0/specs 
> Configured with: ../gcc-4.0-20041205/configure --prefix=/opt/gcc-4.0-20041205 
> --enable-shared --enable-languages=c,c++ --enable-threads=posix 
> --enable-__cxa_atexit --enable-clocale=gnu --disable-nls 
> --program-suffix=-4.0-20041205 --with-arch=pentium3 
> Thread model: posix 
> gcc version 4.0.0 20041205 (experimental) 

You need to add --disable-checking to your configure flags in order to compare
against a development branch.
When release branches are made, checking gets turned off by default by
configure, but it's on in non-release branches.

The compiler is a *lot* slower with checking


-- 


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

[Bug rtl-optimization/16613] [3.4 Regression] compile time regression, when adding cerr usage

[andre dot maute at gmx dot de]

--- Additional Comments From andre dot maute at gmx dot de  2004-12-10 
22:42 ---
sorry missed the following two lines 
 
> time g++-3.3.5 -c -O3 -D __DEBUG__ compiletimetest2.cc 
real0m12.454suser0m12.210ssys 0m0.230s 
 
so g++-3.3.5 is really good, 
and I don't hope that we will see  40 s  for  g++-4.1 ;-) 
 
Regards Andre 
 
 

-- 


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

[Bug c++/18934] Spurious Uninitialized Variable Warning

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-10 
23:20 ---
Fixed in 4.0.0 by moving the uninitializing warning to the tree level where the 
exceptions have not been 
lowered to setjmp/longjmp which is what is causing the warning.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 GCC target triplet||i686-pc-cygwin
 Resolution||FIXED
   Target Milestone|--- |4.0.0


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

Re: [Bug rtl-optimization/16613] [3.4 Regression] compile time regression, when adding cerr usage

[Daniel Berlin]

On Fri, 10 Dec 2004, andre maute wrote:
Once more i couldn't upload an attachment
with the bugzilla upload form, so i send it here.
You can email it to [EMAIL PROTECTED] with a subject of "Bug 16613" 
(or whatever the bug number is), and it'll auto-add it to the bug for you.

[Bug driver/18732] Compiler will not compile two source files if first has error or is unreadable

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-11 
00:02 ---
Subject: Bug 18732

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-12-11 00:02:00

Modified files:
gcc: ChangeLog gcc.c 

Log message:
PR 18732
* gcc.c (main): Do not break out of loop when error is reported while
processing one source file.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6777&r2=2.6778
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gcc.c.diff?cvsroot=gcc&r1=1.440&r2=1.441



-- 


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

[Bug c/18935] New: Error on reference of 'extern' variable in block scope.

[sorie at sorie dot net]

This problem occurs in both mode c89 and c99.

I will try to describe it with a simple example.

- code.c --

#include 

int main(void)
{
extern int a;

printf("a: %d\n", a);

int a = 20; /* internal compiler error */

return 0;
}

-

If you compile this code, you'll get follwing error message.

$ gcc -Wall -std=c89 code.c
code.c: In function `main':
code.c:7: internal compiler error: in make_decl_rtl, at varasm.c:752

Inside a block scope, the codes are executed sequently.
So I think, when there is a variable declaration with 'extern', that the
compiler should either let occur an error of double variable-declaration or show
warning only and just give the local variable priority.

Thank you for reading.

-- 
   Summary: Error on reference of 'extern' variable in block scope.
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sorie at sorie dot net
CC: gcc-bugs at gcc dot gnu dot org


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