[Bug bootstrap/24562] makebootstrap failed: make[3]: *** No rule to make target `../zlib/libz.a'

[luongductruong at gmail dot com]

--- Comment #8 from luongductruong at gmail dot com  2005-10-28 08:24 
---
(In reply to comment #7)
> > Following your way, I download zlib at http://www.zlib.net, gunzip and untar
> > it at GCC'src directory.
> 
> Don't do that, everything should be included in the GCC archive.
> 
> What GCC archive do you use and where does it come from?  What does 'make -v'
> print?
> 
I download GCC 4.0.2 from http://gcc.gnu.org. When I untar that source in many
times, It always notices : the directory checksum error. I try another FTP
server, download again but that error doesn't fix. 

 bash-2.03# make -v
 GNU Make 3.80
 Copyright (C) 2002  Free Software Foundation, Inc.
 This is free software; see the source for copying conditions.
 There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
 PARTICULAR PURPOSE.


-- 


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

[Bug middle-end/24556] gcc can't inline functions using setjmp

[samuel dot thibault at ens-lyon dot org]

--- Comment #8 from samuel dot thibault at ens-lyon dot org  2005-10-28 
08:27 ---
Subject: Re:  gcc can't inline functions using setjmp

pinskia at gcc dot gnu dot org, le Fri 28 Oct 2005 01:39:59 -, a écrit :
> So this is not a bug.

Yes this is a bug. The docs for setjmp are really clear about the fact
automatic variables of the callee might be thrashed, but that doesn't
entail that the callee can't be inlined. Gcc doesn't implement anything
for getting semantic right, but it is feasible, I explained how. So it
is a bug.

But you don't want to fix it. Too bad for us.
I thought that "An Inline Function is As Fast As a Macro". It is not.



-- 


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

[Bug bootstrap/24562] makebootstrap failed: make[3]: *** No rule to make target `../zlib/libz.a'

[ebotcazou at gcc dot gnu dot org]

--- Comment #9 from ebotcazou at gcc dot gnu dot org  2005-10-28 08:31 
---
> I download GCC 4.0.2 from http://gcc.gnu.org. When I untar that source in many
> times, It always notices : the directory checksum error. I try another FTP
> server, download again but that error doesn't fix. 

You must use GNU tar.


-- 


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

[Bug fortran/24554] internal compiler error

[eedelman at gcc dot gnu dot org]

--- Comment #5 from eedelman at gcc dot gnu dot org  2005-10-28 11:18 
---
(In reply to comment #4)
> I don't understand what is the exact solution to my problem. 

Nobody has said there is a solution at the moment.  When Richard Guenther
marked this PR as RESOLVED, DUPLICATE, it didn't mean that the bug was solved,
only that he thought it looked the same as another PR.

>??? What I have to do to? :(

Send us the code that triggers that "internal compiler error"-message. Without
the code there is not much else we can do than try to guess what the problem
might be (like assuming it's the same as in some other PR).  A testcase reduced
to as few code lines as possible is prefered, but even the full code is better
than nothing.


-- 


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

[Bug fortran/17905] allocated arrays not visible with gdb

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2005-10-28 12:04 ---
(In reply to comment #5)
> "set lang c" didn't give me that output.  What is your configuration, gdb ,
> gfortran version and so on?  
Oh, I did a "p array" since whatis is the same as ptype.


-- 


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

[Bug middle-end/24563] getting internal error

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2005-10-28 12:06 ---
Can you attach the preprocessed source, also if you run it again do you hit it
still?


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Severity|critical|normal
 Status|UNCONFIRMED |WAITING
  Component|c   |middle-end


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

[Bug regression/24565] facerec performance regression

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2005-10-28 12:10 ---
(In reply to comment #0)
> I could revert the change (only second part) with the new patch unless there 
> is
> a reason (which for the moment I'm not able to understand) for removing the
> call to mark_array_ref_addressable().

It causes a performance regression in crafty which was why it was removed.


-- 


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

[Bug middle-end/24556] gcc can't inline functions using setjmp

[pinskia at gcc dot gnu dot org]

--- Comment #9 from pinskia at gcc dot gnu dot org  2005-10-28 14:18 ---
(In reply to comment #8)
> Yes this is a bug. The docs for setjmp are really clear about the fact
> automatic variables of the callee might be thrashed, but that doesn't
> entail that the callee can't be inlined. Gcc doesn't implement anything
> for getting semantic right, but it is feasible, I explained how. So it
> is a bug.

Actually there is no easy way to implement that as the information about what
function is inlined where is lost very early on.


-- 


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

[Bug middle-end/24362] [4.0/4.1 Regression] internal compiler error: in extract_component, at tree-complex.c:68

[pinskia at gcc dot gnu dot org]

--- Comment #11 from pinskia at gcc dot gnu dot org  2005-10-28 14:26 
---
Subject: Bug 24362

Author: pinskia
Date: Fri Oct 28 14:26:36 2005
New Revision: 105930

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=105930
Log:
2005-10-28  Andrew Pinski  <[EMAIL PROTECTED]>

PR middle-end/24362
* g++.dg/opt/complex4.C: New test.
2005-10-28  Andrew Pinski  <[EMAIL PROTECTED]>

PR middle-end/24362
* tree-complex.c (extract_component): Treat RESULT_DECL
like the rest of the decls.



Added:
trunk/gcc/testsuite/g++.dg/opt/complex4.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-complex.c


-- 


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

[Bug middle-end/21786] Segmentation fault under FreeBSD 5.3-RELEASE-p15

[postmaster at t-hosting dot hu]

--- Comment #4 from postmaster at t-hosting dot hu  2005-10-28 14:31 ---
(In reply to comment #3)
> Seems fixed in "3.4.5 20050809".  Can you try a newer 3.4.5?
> 

It's okay now, but there's a build error. I susoect the code is not for gcc
3.4.5. I got this:

CC='/usr/local/bin/gcc34' mkdep -f .depend -a -DCRT_BEGIN   -DIN_GCC
-DHAVE_LD_EH_FRAME_HDR -I/usr/src/gnu/lib/csu/../../../contrib/gcc/config
-I/usr/src/gnu/lib/csu/../../../contrib/gcc -I.
-I/usr/src/gnu/lib/csu/../../usr.bin/cc/cc_tools
/usr/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c
/usr/local/bin/gcc34 -s -Os -pipe -march=athlon64  -DIN_GCC
-DHAVE_LD_EH_FRAME_HDR -finhibit-size-directive -fno-inline-functions 
-fno-exceptions -fno-zero-initialized-in-bss  -fno-omit-frame-pointer
-fno-unit-at-a-time -I/usr/src/gnu/lib/csu/../../../contrib/gcc/config
-I/usr/src/gnu/lib/csu/../../../contrib/gcc -I. 
-I/usr/src/gnu/lib/csu/../../usr.bin/cc/cc_tools  -g0 -DCRT_BEGIN  -c -o
crtbegin.o /usr/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c
/usr/local/bin/gcc34 -s -Os -pipe -march=athlon64  -DIN_GCC
-DHAVE_LD_EH_FRAME_HDR -finhibit-size-directive -fno-inline-functions 
-fno-exceptions -fno-zero-initialized-in-bss  -fno-omit-frame-pointer
-fno-unit-at-a-time -I/usr/src/gnu/lib/csu/../../../contrib/gcc/config
-I/usr/src/gnu/lib/csu/../../../contrib/gcc -I. 
-I/usr/src/gnu/lib/csu/../../usr.bin/cc/cc_tools  -g0 -DCRT_END  -c -o crtend.o
/usr/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c
/usr/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c:451: error: mode `SI'
applied to inappropriate type
*** Error code 1


-- 

postmaster at t-hosting dot hu changed:

   What|Removed |Added

 Status|WAITING |NEW


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

[Bug middle-end/24362] [4.0/4.1 Regression] internal compiler error: in extract_component, at tree-complex.c:68

[pinskia at gcc dot gnu dot org]

--- Comment #12 from pinskia at gcc dot gnu dot org  2005-10-28 14:32 
---
Subject: Bug 24362

Author: pinskia
Date: Fri Oct 28 14:26:36 2005
New Revision: 105930

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=105930
Log:
2005-10-28  Andrew Pinski  <[EMAIL PROTECTED]>

PR middle-end/24362
* g++.dg/opt/complex4.C: New test.
2005-10-28  Andrew Pinski  <[EMAIL PROTECTED]>

PR middle-end/24362
* tree-complex.c (extract_component): Treat RESULT_DECL
like the rest of the decls.



Added:
trunk/gcc/testsuite/g++.dg/opt/complex4.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-complex.c


-- 


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

[Bug middle-end/24362] [4.0/4.1 Regression] internal compiler error: in extract_component, at tree-complex.c:68

[pinskia at gcc dot gnu dot org]

--- Comment #13 from pinskia at gcc dot gnu dot org  2005-10-28 14:40 
---
Subject: Bug 24362

Author: pinskia
Date: Fri Oct 28 14:39:57 2005
New Revision: 105931

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=105931
Log:
2005-10-28  Andrew Pinski  <[EMAIL PROTECTED]>

PR middle-end/24362
* g++.dg/opt/complex4.C: New test.
2005-10-28  Andrew Pinski  <[EMAIL PROTECTED]>

PR middle-end/24362
* tree-complex.c (extract_component): Treat RESULT_DECL
like the rest of the decls.



Added:
branches/gcc-4_0-branch/gcc/testsuite/g++.dg/opt/complex4.C
Modified:
branches/gcc-4_0-branch/gcc/ChangeLog
branches/gcc-4_0-branch/gcc/testsuite/ChangeLog
branches/gcc-4_0-branch/gcc/tree-complex.c


-- 


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

[Bug middle-end/24362] [4.0/4.1 Regression] internal compiler error: in extract_component, at tree-complex.c:68

[pinskia at gcc dot gnu dot org]

--- Comment #14 from pinskia at gcc dot gnu dot org  2005-10-28 14:41 
---
Fixed. only 4.1 still have issues with this code but that is PR 24365.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/23426] [4.0/4.1 Regression] Too large array problem gives two error message

[pinskia at gcc dot gnu dot org]

--- Comment #16 from pinskia at gcc dot gnu dot org  2005-10-28 14:50 
---
Subject: Bug 23426

Author: pinskia
Date: Fri Oct 28 14:50:53 2005
New Revision: 105934

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=105934
Log:
2005-10-28  Andrew Pinski  <[EMAIL PROTECTED]>

PR C++/23426
* decl.c (start_decl): Check that the decl is an
error_mark_node before getting the type.
Remove the check for the decl's type being an
error_mark_node.  

2005-10-28  Andrew Pinski  <[EMAIL PROTECTED]>

PR C++/23426
* g++.dg/other/large-size-array.C: New test.


Added:
branches/gcc-4_0-branch/gcc/testsuite/g++.dg/other/large-size-array.C
Modified:
branches/gcc-4_0-branch/gcc/ChangeLog
branches/gcc-4_0-branch/gcc/cp/decl.c
branches/gcc-4_0-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/23426] [4.0/4.1 Regression] Too large array problem gives two error message

[pinskia at gcc dot gnu dot org]

--- Comment #17 from pinskia at gcc dot gnu dot org  2005-10-28 14:57 
---
Subject: Bug 23426

Author: pinskia
Date: Fri Oct 28 14:57:30 2005
New Revision: 105936

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=105936
Log:
2005-10-28  Andrew Pinski  <[EMAIL PROTECTED]>

PR C++/23426
* decl.c (start_decl): Check that the decl is an
error_mark_node before getting the type.
Remove the check for the decl's type being an
error_mark_node.  

2005-10-28  Andrew Pinski  <[EMAIL PROTECTED]>

PR C++/23426
* g++.dg/other/large-size-array.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/other/large-size-array.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/23426] [4.0/4.1 Regression] Too large array problem gives two error message

[pinskia at gcc dot gnu dot org]

--- Comment #18 from pinskia at gcc dot gnu dot org  2005-10-28 14:57 
---
Fixed in 4.0.3.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/24567] New: poor diagnostics

[igodard at pacbell dot net]

int operator-(foo a, foo b) {}

struct bar {
int operator-(foo a, foo b) {}
};

gets you:

~/ootbc/members/src$ g++ foo.cc
foo.cc:1: error: declaration of `operator-' as non-function
foo.cc:1: error: `foo' was not declared in this scope
foo.cc:1: error: `foo' was not declared in this scope
foo.cc:1: error: expected `,' or `;' before '{' token
foo.cc:4: error: declaration of `operator-' as non-function
foo.cc:4: error: expected `;' before '(' token
foo.cc:5: error: expected `;' before '}' token


The undeclared names are not reported in the member function, and both produce
cascaded diagnostics.


-- 
   Summary: poor diagnostics
   Product: gcc
   Version: 3.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net


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

[Bug c++/24567] poor diagnostics

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2005-10-28 15:17 ---
Fixed in 4.0.0 and above at least:
t.cc:1: error: declaration of ‘operator-’ as non-function
t.cc:1: error: ‘foo’ was not declared in this scope
t.cc:1: error: ‘foo’ was not declared in this scope
t.cc:4: error: ‘foo’ has not been declared
t.cc:4: error: ‘foo’ has not been declared
t.cc:4: error: ‘int bar::operator-(int, int)’ must take either zero or one
argument


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug target/24230] [4.1 Regression] ICE in extract_insn with altivec

[steven at gcc dot gnu dot org]

--- Comment #13 from steven at gcc dot gnu dot org  2005-10-28 15:58 ---
Smaller test case:

// Compile with -O2 -maltivec
//
// Works with GCC 3.3.5 and GCC 4.0.2
// ICEs with GCC 4.1 from today's CVS
#include 
#define REGLIST  \
 "77",  "78",  "79",  "80",  "81",  "82",  "83",  "84",  "85",  "86",\
 "87",  "88",  "89",  "90",  "91",  "92",  "93",  "94",  "95",  "96",\
 "97",  "98",  "99", "100", "101", "102", "103", "104", "105", "106",\
"107", "108"


void
foo (int H)
{
  volatile __attribute__ ((altivec (vector__))) unsigned char tmp;
  while (H-- > 0)
{
  asm ("" : : : REGLIST);

  tmp =
( __attribute__ ((altivec (vector__))) unsigned
 char) (( __attribute__ ((altivec (vector__))) unsigned short)
vec_splat_s16 (((5;
}
}

Note that this is really a register allocation problem that we fail on because
our register allocator doesn't know about liveness inside blocks, only at the
start and end of a block.  But the situation is easily reproducible as long as
you pump the register pressure up far enough.

The problem seems to be in reload const-to-mem.  We start with this:

(insn:HI 26 22 56 2 (set (mem/v/c/i:V16QI (plus:SI (reg/f:SI 113 sfp)
(const_int 16 [0x10])) [0 tmp+0 S16 A128])
(subreg:V16QI (reg:V8HI 128) 0)) 467 {altivec_stvx_v16qi}
(insn_list:REG_DEP_TRUE 22 (nil))
(expr_list:REG_EQUAL (const_vector:V16QI [
(const_int 0 [0x0])
(const_int 5 [0x5])
(const_int 0 [0x0])
(const_int 5 [0x5])
(const_int 0 [0x0])
(const_int 5 [0x5])
(const_int 0 [0x0])
(const_int 5 [0x5])
(const_int 0 [0x0])
(const_int 5 [0x5])
(const_int 0 [0x0])
(const_int 5 [0x5])
(const_int 0 [0x0])
(const_int 5 [0x5])
(const_int 0 [0x0])
(const_int 5 [0x5])
])
(nil)))


and we end with this (were we ICE on insn 65):

(insn 65 22 64 2 (set (reg:V16QI 77 0)
(mem/u/c/i:V16QI (symbol_ref/u:SI ("*.LC0") [flags 0x2]) [0 S16 A128]))
-1 (nil)
(nil))

(insn 64 65 26 2 (set (reg:SI 9 9)
(plus:SI (reg/f:SI 1 1)
(const_int 16 [0x10]))) 31 {*addsi3_internal1} (nil)
(nil))

(insn:HI 26 64 56 2 (set (mem/v/c/i:V16QI (reg:SI 9 9) [0 tmp+0 S16 A128])
(reg:V16QI 77 0)) 467 {altivec_stvx_v16qi} (insn_list:REG_DEP_TRUE 22
(nil))
(expr_list:REG_EQUAL (const_vector:V16QI [
(const_int 0 [0x0])
(const_int 5 [0x5])
(const_int 0 [0x0])
(const_int 5 [0x5])
(const_int 0 [0x0])
(const_int 5 [0x5])
(const_int 0 [0x0])
(const_int 5 [0x5])
(const_int 0 [0x0])
(const_int 5 [0x5])
(const_int 0 [0x0])
(const_int 5 [0x5])
(const_int 0 [0x0])
(const_int 5 [0x5])
(const_int 0 [0x0])
(const_int 5 [0x5])
])
(nil)))


-- 


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

[Bug tree-optimization/24568] New: Missed optimization: trivialization of silly code

[tobi at gcc dot gnu dot org]

xgcc (GCC) 4.1.0 20051020 (experimental)
can't optimize the following code (from ):

int convertToMinutes(long milliDiff)
{
  int negative = 0;
  int minutesDiff = -1;

  if (milliDiff < 0)
  {
negative = 1;
milliDiff = -milliDiff; // Make positive (is easier)
  }

  if (milliDiff == 0) // Watch out for exceptional value 0
minutesDiff = 0;
  else
minutesDiff = (int) (milliDiff / 1000) / 60;

  if (negative) minutesDiff = -minutesDiff; // Make it negative again

  return minutesDiff;
}

The code should simplify to
int convertToMinutes (long i)
{
   return i / 6;
}

But the final tree dump contains the complete logic even in the case of high
optimization levels.

An interesting peculiarity from the assembly:
.file   "milli.c"
.text
.p2align 4,,15
.globl convertToMinutes
.type   convertToMinutes, @function
convertToMinutes:
pushl   %ebp
movl%esp, %ebp
subl$8, %esp
movl%esi, 4(%esp)
movl8(%ebp), %esi
movl%ebx, (%esp)
xorl%ebx, %ebx
testl   %esi, %esi
js  .L12  ; jump from here
.L4:
xorl%ecx, %ecx
testl   %esi, %esi
je  .L7
movl$1172812403, %eax
imull   %esi
movl%esi, %eax
sarl$31, %eax
movl%edx, %ecx
sarl$14, %ecx
subl%eax, %ecx
.L7:
testl   %ebx, %ebx
je  .L8
negl%ecx
.L8:
movl(%esp), %ebx
movl%ecx, %eax
movl4(%esp), %esi
movl%ebp, %esp
popl%ebp
ret
.p2align 4,,7
.L12:;;; all the way down here, probably out of the prefetch buffer
negl%esi
movl$1, %ebx
jmp .L4
.size   convertToMinutes, .-convertToMinutes
.ident  "GCC: (GNU) 4.1.0 20051020 (experimental)"
.section.note.GNU-stack,"",@progbits


-- 
   Summary: Missed optimization: trivialization of silly code
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobi at gcc dot gnu dot org
GCC target triplet: i686-pc-linux


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

[Bug debug/24569] New: [4.1 regression] ICE in add_AT_specification, at dwarf2out.c:4966

[bangerth at dealii dot org]

Attached file shows a fairly new ICE on x86_64. Compile with -g to get

base> c++ geometry_info.ii -g
source/geometry_info.cc:354: internal compiler error: in add_AT_specification,
at dwarf2out.c:4966
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.


W.


-- 
   Summary: [4.1 regression] ICE in add_AT_specification, at
dwarf2out.c:4966
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: critical
  Priority: P2
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at dealii dot org


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

[Bug debug/24569] [4.1 regression] ICE in add_AT_specification, at dwarf2out.c:4966

[bangerth at dealii dot org]

--- Comment #1 from bangerth at dealii dot org  2005-10-28 16:19 ---
Created an attachment (id=10076)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10076&action=view)
Preprocessed sources


-- 


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

[Bug target/24230] [4.1 Regression] ICE in extract_insn with altivec

[steven at gcc dot gnu dot org]

--- Comment #14 from steven at gcc dot gnu dot org  2005-10-28 16:22 ---
More background:
Starting program: /abuild/stevenb/build/gcc/cc1 -O2 -maltivec t.c -da
 foo
Analyzing compilation unitPerforming intraprocedural optimizations
Assembling functions:
 foo
Breakpoint 8, find_reloads (insn=0x401069c0, replace=0, ind_levels=0,
live_known=1,
reload_reg_p=0x10a65334) at reload.c:2541
2541  int no_input_reloads = 0, no_output_reloads = 0;
(gdb) disab 8
(gdb) enab 10
(gdb) cont
Continuing.

Breakpoint 10, emit_insn (x=0x40110680) at emit-rtl.c:4430
4430  rtx last = last_insn;
(gdb) cont
Continuing.

Breakpoint 10, emit_insn (x=0x401106c0) at emit-rtl.c:4430
4430  rtx last = last_insn;
(gdb) p debug_rtx(x)
(set (reg:V16QI 77 0)
(mem/u/c/i:V16QI (symbol_ref/u:SI ("*.LC0") [flags 0x2]) [0 S16 A128]))
$52 = void
(gdb) up
#1  0x1069fe58 in rs6000_emit_move (dest=0x4010e7f8, source=0x40110670,
mode=V16QImode)
at rs6000.c:4058
4058  emit_insn (gen_rtx_SET (VOIDmode, operands[0], operands[1]));
(gdb) bt
#0  emit_insn (x=0x401106c0) at emit-rtl.c:4430
#1  0x1069fe58 in rs6000_emit_move (dest=0x4010e7f8, source=0x40110670,
mode=V16QImode)
at rs6000.c:4058
#2  0x10487fd8 in gen_movv16qi (operand0=0x4010e7f8, operand1=0x40110670) at
altivec.md:171
#3  0x1033360c in emit_move_insn_1 (x=0x4010e7f8, y=0x40110670) at expr.c:3107
#4  0x10510fa8 in gen_move_insn (x=0x4010e7f8, y=0x40110670) at optabs.c:4214
#5  0x10594ac4 in gen_reload (out=0x4010e7f8, in=0x40110670, opnum=1,
type=RELOAD_FOR_INPUT)
at reload1.c:7606
#6  0x1058fef8 in emit_input_reload_insns (chain=0x10aa3da0, rl=0x10a5f99c,
old=0x40110670, j=3)
at reload1.c:6635
#7  0x10590c30 in do_input_reload (chain=0x10aa3da0, rl=0x10a5f99c, j=3) at
reload1.c:6880
#8  0x10591c00 in emit_reload_insns (chain=0x10aa3da0) at reload1.c:7053
#9  0x10585898 in reload_as_needed (live_known=1) at reload1.c:3902
#10 0x1057bdec in reload (first=0x400351b8, global=1) at reload1.c:1067
#11 0x107b452c in global_alloc (file=0x10aacc40) at global.c:628


-- 


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

[Bug middle-end/24556] gcc can't inline functions using setjmp

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2005-10-28 16:22 
---
I'll re-open this issue as we might indeed follow users advice if he declared
the function inline.  We only should avoid inlining functions calling setjmp
that are not declared inline.  I'll be putting this on my list of things to
look at.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|WONTFIX |


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

[Bug middle-end/24556] gcc can't inline functions using setjmp

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
   Severity|normal  |enhancement
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2005-10-28 16:23:23
   date||


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

[Bug debug/24569] [4.1 regression] ICE in add_AT_specification, at dwarf2out.c:4966

[bangerth at dealii dot org]

--- Comment #2 from bangerth at dealii dot org  2005-10-28 16:26 ---
And here's the minimal testcase:
-
template 
struct S
{
static const int u = 2 * dim;
static const int p[u];
static int f();
};

template <>
inline int S<3>::f () { return 1; }

template  const int S::u;

template class S<3>;
---

base> c++ -c x.cc -g
x.cc:13: internal compiler error: in add_AT_specification, at dwarf2out.c:4966
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

W.


-- 


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

[Bug gcov/profile/24487] [3.4/4.0/4.1 Regression] Basic block frequencies inaccurate

[hubicka at gcc dot gnu dot org]

--- Comment #2 from hubicka at gcc dot gnu dot org  2005-10-28 16:32 ---
I've benchmarked the change reducing maximum number of iterations predicted for
loop with constant bounds to 100 and 10 respectively.  100 makes no actual
change to x86-64 SPEC run, 10 seems to result in small degradation:
   164.gzip  1400 1171193* 1400 1171195*
   175.vpr   1400 166 845* 1400 166 844*
   176.gcc   1100 1071031* 1100 1061035*
   181.mcf   1800 335 537* 1800 333 541*
   186.crafty1000  49.8  2010* 1000  49.7  2012*
   197.parser1800 232 777* 1800 230 783*
   252.eon   1300  71.3  1823* 1300  75.4  1724*
   253.perlbmk   1800 1251440* 1800 1241446*
   254.gap   1100  95.3  1154* 1100  96.0  1146*
   255.vortex1900 1121689* 1900 1131689*
   256.bzip2 1500 1491005* 1500 1491005*
   300.twolf 3000 353 850* 3000 353 851*
   Est. SPECint_base2000 1118
   Est. SPECint20001114
(specFP still in progress).  I will also try the idea of increasing estimated
number of iterations for loops without contatn bounds when some high limit is
known for loop with constant bound within function, but actually I don't like
that idea much anymore as it would result in profile to be artifically steep on
wrong places, most probably :(
Does the missprediction manifest somehow on PPC?


-- 

hubicka at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |hubicka at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2005-10-23 20:11:24 |2005-10-28 16:32:22
   date||


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

[Bug c++/24569] [4.1 regression] ICE in add_AT_specification, at dwarf2out.c:4966

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|debug   |c++
   Target Milestone|--- |4.1.0


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

[Bug c++/24569] [4.0/4.1 regression] ICE in add_AT_specification, at dwarf2out.c:4966

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.0.3
Summary|[4.1 regression] ICE in |[4.0/4.1 regression] ICE in
   |add_AT_specification, at|add_AT_specification, at
   |dwarf2out.c:4966|dwarf2out.c:4966
   Target Milestone|4.1.0   |4.0.3


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

[Bug c++/24569] [4.0/4.1 regression] ICE in add_AT_specification, at dwarf2out.c:4966

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2005-10-28 16:43 ---
Confirmed, I think this was caused by one of Mark's constant value patches (but
I don't know for sure).


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||mmitchel at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to fail|4.0.3   |4.0.3 4.1.0
  Known to work||4.0.0
   Last reconfirmed|-00-00 00:00:00 |2005-10-28 16:43:20
   date||


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

[Bug web/14561] some cvsweb entries missing for branches

[kcook at gcc dot gnu dot org]

--- Comment #2 from kcook at gcc dot gnu dot org  2005-10-28 16:44 ---
I'm closing this bug as the subversion-pushed move to viewcvs has made the
problem go away.

http://gcc.gnu.org/viewcvs/branches/gcc-3_4-branch/gcc/configure?view=log


-- 

kcook at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||11335
 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug web/11335] cvsweb shows incomplete logs for some files

[kcook at gcc dot gnu dot org]

--- Comment #2 from kcook at gcc dot gnu dot org  2005-10-28 16:46 ---
I think we can close this as the subversion push move from cvsweb to viewcvs
seems to have just made it go away.

http://gcc.gnu.org/viewcvs/trunk/gcc/Makefile.in?view=log


-- 

kcook at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c/24570] New: unit-at-a-time: debug info not emitted for unused global variables

[tomas dot vanek at fbl dot cz]

Both

Target: i686-pc-linux-gnu
Configured with: ../configure --disable-nls --with-dwarf2
Thread model: posix
gcc version 4.0.2

and

Target: avr
Configured with: ../configure --prefix=/usr/local/avr --target=avr
--disable-nls --with-dwarf2 --enable-languages=c 
Thread model: single
gcc version 4.0.2

do not emit stabs or emit incomplete dwarf debug info for an unused global
variable when compiled unit-at-a-time (-O2 or -Os).

var.c:
int used_variable;
int unused_variable __attribute__((unused));

int use_one(void)
{
return used_variable;
}

gcc -S var.c -gstabs
and avr-gcc -S -mmcu=atmega8 var.c -gstabs 

works good and generates stabs for both variables

.Lscope0:
.comm   used_variable,4,4
.comm   unused_variable,4,4
.stabs  "used_variable:G(0,1)",32,0,0,0
.stabs  "unused_variable:G(0,1)",32,0,0,0
.stabs  "",100,0,0,.Letext0
.Letext0:


gcc -S var.c -gstabs -funit-at-a-time
or avr-gcc -S -mmcu=atmega8 var.c -gstabs -funit-at-a-time

As soon as unit-at-a-time is active, stabs for unused var is gone

.Lscope0:
.stabs  "used_variable:G(0,1)",32,0,0,0
.comm   unused_variable,4,4
.comm   used_variable,4,4
.stabs  "",100,0,0,.Letext0
.Letext0:



gcc -S var.c -gdwarf-2 -dA -funit-at-a-time
or avr-gcc -S -mmcu=atmega8 var.c -gdwarf-2 -dA -funit-at-a-time

With dwarf, the unused variable is emited without location as if it was
external.

.uleb128 0x4# (DIE (0x63) DW_TAG_variable)
.ascii "used_variable\0"# DW_AT_name
.byte   0x1 # DW_AT_decl_file
.byte   0x1 # DW_AT_decl_line
.long   0x5c# DW_AT_type
.byte   0x1 # DW_AT_external
.byte   0x5 # DW_AT_location
.byte   0x3 # DW_OP_addr
.long   used_variable
.uleb128 0x5# (DIE (0x7f) DW_TAG_variable)
.ascii "unused_variable\0"  # DW_AT_name
.byte   0x1 # DW_AT_decl_file
.byte   0x2 # DW_AT_decl_line
.long   0x5c# DW_AT_type
.byte   0x1 # DW_AT_external
.byte   0x0 # end of children of DIE 0xb
.section.debug_abbrev


The problem is caused by calling c_write_global_declarations_2 () before
cgraph_varpool_assemble_pending_decls (), which generates rtx for unused
variables.

I tried a dirty hack: insert an extra call of
cgraph_varpool_assemble_pending_decls () into
procedure c_write_global_declarations() in c-decl.c just before the last block
 if - for - c_write_global_declarations_2
and it solved the problem. Of course I don't know what it breaks...


-- 
   Summary: unit-at-a-time: debug info not emitted for unused global
variables
   Product: gcc
   Version: 4.0.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tomas dot vanek at fbl dot cz


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

[Bug middle-end/24570] unit-at-a-time: debug info not emitted for unused global variables

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2005-10-28 16:50 ---
I don't think this is a bug as the unused global variables are removed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c   |middle-end
Summary|unit-at-a-time: debug info  |unit-at-a-time: debug info
   |not emitted for unused  |not emitted for unused
   |global variables|global variables


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

[Bug c/24571] New: "error: pthread.h: No such file or directory" while building core gcc for cross-compiler

[rpjday at mindspring dot com]

In using "crosstool" to build a cross-compiler for the SH3, I get the following
error in building the early bootstrap gcc:

/home/rpjday/results/edge/build-tools/build-gcc-core/./gcc/xgcc
-B/home/rpjday/results/edge/build-tools/build-gcc-core/./gcc/
-B/home/rpjday/results/edge/build-tools/gcc-core-prefix/sh3-unknown-linux-gnu/bin/
-B/home/rpjday/results/edge/build-tools/gcc-core-prefix/sh3-unknown-linux-gnu/lib/
-isystem
/home/rpjday/results/edge/build-tools/gcc-core-prefix/sh3-unknown-linux-gnu/include
-isystem
/home/rpjday/results/edge/build-tools/gcc-core-prefix/sh3-unknown-linux-gnu/sys-include
-O2  -O2 -g -O2  -DIN_GCC -DCROSS_COMPILE   -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include  -fpic -DNO_FPSCR_VALUES -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I.
-I/home/rpjday/results/edge/build-tools/gcc-4.1-20051022/gcc
-I/home/rpjday/results/edge/build-tools/gcc-4.1-20051022/gcc/.
-I/home/rpjday/results/edge/build-tools/gcc-4.1-20051022/gcc/../include
-I/home/rpjday/results/edge/build-tools/gcc-4.1-20051022/gcc/../libcpp/include 
-fexceptions  -c
/home/rpjday/results/edge/build-tools/gcc-4.1-20051022/gcc/unwind-dw2.c -o
libgcc/./unwind-dw2.o
In file included from ./gthr-default.h:1,
 from
/home/rpjday/results/edge/build-tools/gcc-4.1-20051022/gcc/gthr.h:114,
 from
/home/rpjday/results/edge/build-tools/gcc-4.1-20051022/gcc/unwind-dw2.c:42:
/home/rpjday/results/edge/build-tools/gcc-4.1-20051022/gcc/gthr-posix.h:43:21:
error: pthread.h: No such file or directory


  I'll shortly attach a script that isolates the error by compiling that single
file.


-- 
   Summary: "error: pthread.h: No such file or directory" while
building core gcc for cross-compiler
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rpjday at mindspring dot com
  GCC host triplet: i686-unknown-linux
GCC target triplet: sh3-unknown-linux


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

[Bug target/24230] [4.1 Regression] ICE in extract_insn with altivec

[steven at gcc dot gnu dot org]

--- Comment #15 from steven at gcc dot gnu dot org  2005-10-28 16:59 ---
The trouble appears to come from this:

case V16QImode:
case V8HImode:
case V4SFmode:
case V4SImode:
case V4HImode:
case V2SFmode:
case V2SImode:
case V1DImode:
  if (CONSTANT_P (operands[1])
  && !easy_vector_constant (operands[1], mode))
operands[1] = force_const_mem (mode, operands[1]);
  break;

We get here with:
Breakpoint 14, rs6000_emit_move (dest=0x4010e7f8, source=0x40110670,
mode=V16QImode)
at rs6000.c:3867
3867  if (CONSTANT_P (operands[1])
(gdb) p debug_rtx(dest)
(reg:V16QI 77 0)
$3 = void
(gdb) p debug_rtx(source)
(const_vector:V16QI [
(const_int 0 [0x0])
(const_int 5 [0x5])
(const_int 0 [0x0])
(const_int 5 [0x5])
(const_int 0 [0x0])
(const_int 5 [0x5])
(const_int 0 [0x0])
(const_int 5 [0x5])
(const_int 0 [0x0])
(const_int 5 [0x5])
(const_int 0 [0x0])
(const_int 5 [0x5])
(const_int 0 [0x0])
(const_int 5 [0x5])
(const_int 0 [0x0])
(const_int 5 [0x5])
])
$4 = void
(gdb)   


And we go to emit_set with:
(gdb) p debug_rtx (operands[0])
(reg:V16QI 77 0)
$5 = void
(gdb) p debug_rtx (operands[1])
(mem/u/c/i:V16QI (symbol_ref/u:SI ("*.LC0") [flags 0x2]) [0 S16 A128])
$6 = void
(gdb)   


-- 


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

[Bug c/24571] "error: pthread.h: No such file or directory" while building core gcc for cross-compiler

[rpjday at mindspring dot com]

--- Comment #1 from rpjday at mindspring dot com  2005-10-28 17:00 ---
Created an attachment (id=10078)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10078&action=view)
A script that generates the error described by this bug.


-- 


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

[Bug target/24230] [4.1 Regression] ICE in extract_insn with altivec

[steven at gcc dot gnu dot org]

--- Comment #16 from steven at gcc dot gnu dot org  2005-10-28 17:01 ---
On IRC it was suggested that we just need to get a version of
easy_vector_constant which does the right thing in any mode.


-- 


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

[Bug c/24571] "error: pthread.h: No such file or directory" while building core gcc for cross-compiler

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2005-10-28 17:01 ---
This is not a bug as you need to install glibc's headers.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug java/24572] New: [4.0 regression] ICE in gimplify_expr, at gimplify.c:3983

[debian-gcc at lists dot debian dot org]

seen with 4.0 CVS 20051023, compiling antlr 2.7.5.

/usr/bin/gcj-4.0 -shared --classpath= -fassume-compiled -I./src -I.
-I/usr/share/java/antlr.jar -I. -g -O2 -c -o antlr.so /usr/share/java/antlr.jar
antlr/StringUtils.java: In class 'antlr.StringUtils':
antlr/StringUtils.java: In method
'antlr.StringUtils.stripBack(java.lang.String,java.lang.String)':
antlr/StringUtils.java:24: internal compiler error: in gimplify_expr, at
gimplify.c:3983
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

copy of the jar file at http://people.debian.org/~doko/tmp/antlr.jar


-- 
   Summary: [4.0 regression] ICE in gimplify_expr, at
gimplify.c:3983
   Product: gcc
   Version: 4.0.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org


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

[Bug middle-end/24570] unit-at-a-time: debug info not emitted for unused global variables

[tomas dot vanek at fbl dot cz]

--- Comment #2 from tomas dot vanek at fbl dot cz  2005-10-28 17:14 ---
I'm sure it is. I have to declare variables in other segment than .data
for my AVR project and if they are declared in one module and __used__ in some
others, they cannot be showed in gdb and AVRstudio (however they definitelly
are there!!)
Just to simplify the example, I left vars in common, where they probably gets
removed.


-- 


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

[Bug middle-end/24570] unit-at-a-time: debug info not emitted for unused global variables

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2005-10-28 17:18 ---
never mind, I read unused and I thought unused static variables.


-- 


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

[Bug middle-end/24570] [4.0 Regression] unit-at-a-time: debug info not emitted for unused global variables

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2005-10-28 17:23 ---
Confirmed, only on the 4.0 branch.  It works in 3.4.x and also on the mainline.
 This is on x86_64-linux-gnu too.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||wrong-debug
   Last reconfirmed|-00-00 00:00:00 |2005-10-28 17:23:06
   date||
Summary|unit-at-a-time: debug info  |[4.0 Regression] unit-at-a-
   |not emitted for unused  |time: debug info not emitted
   |global variables|for unused global variables
   Target Milestone|--- |4.0.3


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

[Bug middle-end/24570] [4.0 Regression] unit-at-a-time: debug info not emitted for unused global variables

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2005-10-28 17:24 ---
That is the mainline and 3.4.x give:
.ascii "unused_variable\0"  # DW_AT_name
.byte   0x1 # DW_AT_decl_file
.byte   0x2 # DW_AT_decl_line
.long   0x7c# DW_AT_type
.byte   0x1 # DW_AT_external
.byte   0x9 # DW_AT_location
.byte   0x3 # DW_OP_addr
.quad   unused_variable
.byte   0x0 # end of children of DIE 0xb


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.0.3
  Known to work||3.4.5 4.1.0


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

[Bug c++/24573] New: g++: Internal error message while building openh323

[qijcqj8lcwka56m at jetable dot com]

*  the exact version of GCC;
g++ (GCC) 3.3.5 (Debian 1:3.3.5-13)

* the system type;
Linux 2.6.8 #1 SMP Tue Oct 4 13:15:08 CEST 2005 i686 GNU/Linux
Intel(R) Pentium(R) 4 CPU 2.80GHz hyperthreading

* the options given when GCC was configured/built;
GCC got from debian packages (testing)

* the complete command line that triggers the bug;

g++ -I/usr/lib/pwlib/libavcodec/ -DP_USE_PRAGMA -D_REENTRANT -Wall  -fPIC
-DPTRACING -I/home/dave/gm/openh323-1.15.6/include -DHAS_OSS
-I/usr/share/pwlib//include -Os  -DH323_RFC2190_AVCODEC=1 -DP_EXPAT=1
-DP_HAS_QOS=1 -g -DMEDIANET_PATCH=1 -D_DEBUG=1 -save-temps -felide-constructors
-x c++ -c h323.cxx -o /home/dave/gm/openh323-1.15.6/lib/obj_linux_x86_r/h323.o

* the compiler output:
make[2]: Entering directory `/home/dave/gm/openh323-1.15.6/src'
g++ -I/usr/lib/pwlib/libavcodec/ -DP_USE_PRAGMA -D_REENTRANT -Wall  -fPIC
-DPTRACING -I/home/dave/gm/openh323-1.15.6/include -DHAS_OSS
-I/usr/share/pwlib//include -Os  -DH323_RFC2190_AVCODEC=1 -DP_EXPAT=1
-DP_HAS_QOS=1 -g -DMEDIANET_PATCH=1 -D_DEBUG=1 -save-temps -felide-constructors
-x c++ -c h323.cxx -o /home/dave/gm/openh323-1.15.6/lib/obj_linux_x86_r/h323.o
g++: Internal error: Terminated (program cc1plus)
Please submit a full bug report.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see .


* the preprocessed file (*.i*) that triggers the bug, 
Don't know how can to attach it ?


-- 
   Summary: g++: Internal error message while building openh323
   Product: gcc
   Version: 3.3.5
Status: UNCONFIRMED
  Severity: blocker
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: qijcqj8lcwka56m at jetable dot com
 GCC build triplet: linux 2.6.8 SMP i686
  GCC host triplet: linux 2.6.8 SMP i686
GCC target triplet: linux 2.6.8 SMP i686


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

[Bug gcov/profile/24487] [3.4/4.0/4.1 Regression] Basic block frequencies inaccurate

[dje at gcc dot gnu dot org]

--- Comment #3 from dje at gcc dot gnu dot org  2005-10-28 17:30 ---
The misprediction causes (or at least contributes to) compute_alignments in
final.c not aligning the critical loop in longest_match.  The recent changes to
bb-reorder.c moved the start of the loop from an ideal alignment to the worst
alignment, causing a 8-10% performance drop due to instruction fetch problems. 
Without the explicit alignment directives omitted because of misprediction, the
alignment of the loop is random.


-- 

dje at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dberlin at gcc dot gnu dot
   ||org


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

[Bug c++/24573] g++: Internal error message while building openh323

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|blocker |normal
   Keywords||memory-hog


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

[Bug c++/24573] g++: Internal error message while building openh323

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2005-10-28 17:35 ---
(In reply to comment #0)
> * the preprocessed file (*.i*) that triggers the bug, 
> Don't know how can to attach it ?

You attach it afterwards.


-- 


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

[Bug c++/24573] g++: Internal error message while building openh323

[qijcqj8lcwka56m at jetable dot com]

--- Comment #2 from qijcqj8lcwka56m at jetable dot com  2005-10-28 17:40 
---
Created an attachment (id=10079)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10079&action=view)
gcc temporary .ii file compressed


-- 


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

[Bug libstdc++/24559] Incorrect definition of wcspbrk in cwchar

[pcarlini at suse dot de]

--- Comment #3 from pcarlini at suse dot de  2005-10-28 17:45 ---
Fixed for 4.0.3.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

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


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

[Bug c++/24573] g++: Internal error message while building openh323

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2005-10-28 17:51 ---
This works for me in 3.3.3.
How much memory do you have?


-- 


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

[Bug c++/22153] [3.4/4.0/4.1 regression] ICE on invalid template specialization

[jconner at gcc dot gnu dot org]

--- Comment #3 from jconner at gcc dot gnu dot org  2005-10-28 17:59 ---
Subject: Bug 22153

Author: jconner
Date: Fri Oct 28 17:58:59 2005
New Revision: 105944

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=105944
Log:
PR c++/22153
* cp/parser.c (cp_parser_member_declaration): Detect and handle
a template specialization.
* testsuite/g++.dg/template/crash38.C: New test.
* testsuite/g++.dg/parse/explicit1.C: Change expected errors.


Added:
trunk/gcc/testsuite/g++.dg/crash38.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/parse/explicit1.C


-- 


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

[Bug tree-optimization/24568] Missed optimization: trivialization of silly code

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2005-10-28 18:01 ---
There is a couple of different bugs in the is code snipit really.  Let me file
new bugs for each of them.


-- 


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

[Bug tree-optimization/24574] New: a!=0?0:a/10 is not reduced to a/10

[pinskia at gcc dot gnu dot org]

Reduced from PR 24568:
the followin three fucntions should be equivalent:
int f(int i)
{
  if (i == 0) return 0;
  return i/10;
}
int f1(int i)
{
  return i?i/10:0;
}
int f2(int i)
{
  return i/10;
}


-- 
   Summary: a!=0?0:a/10 is not reduced to a/10
   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: pinskia at gcc dot gnu dot org


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

[Bug tree-optimization/24568] Missed optimization: trivialization of silly code

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2005-10-28 18:05 ---
(In reply to comment #1)
> There is a couple of different bugs in the is code snipit really.  Let me file
> new bugs for each of them.

PR 24574 is the first issue which seems like it could happen in really code
(though not as much as one thinks).


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||24574


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

[Bug c++/22153] [3.4/4.0/4.1 regression] ICE on invalid template specialization

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2005-10-28 18:09 ---
Fixed.  Thanks Josh.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/24568] Missed optimization: trivialization of silly code

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement


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

[Bug tree-optimization/24568] Missed optimization: trivialization of silly code

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2005-10-28 18:11 ---
(In reply to comment #2)
> PR 24574 is the first issue which seems like it could happen in really code
> (though not as much as one thinks).

That was for the inner if.

I have to see how to reduce the outer ones.


-- 


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

[Bug tree-optimization/24575] New: -(-i / 10) is not foldded to i/10

[pinskia at gcc dot gnu dot org]

Another reduced testcase from PR 24568:
Note this is only valid for overflow is undefined or for
unsafe_math_transformations.
nt f(int i)
{
  return -((-i)/10);
}
int f2(int i)
{
  return i/10;
}


-- 
   Summary: -(-i / 10) is not foldded to i/10
   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: pinskia at gcc dot gnu dot org


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

[Bug tree-optimization/24568] Missed optimization: trivialization of silly code

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2005-10-28 18:15 ---
Another issue is PR 24575:
-(-a/10) is not converted into a/10.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||24575


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

[Bug tree-optimization/24568] Missed optimization: trivialization of silly code

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2005-10-28 18:18 ---
Last but not least is:
int f(int i)
{
  if (i < 0) return i/10;
  return i/10;
}


int f2(int i)
{
  return i/10;
}

Which is converted at the rtl level but not at the tree level (I think there is
a bug about this already).


-- 


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

[Bug tree-optimization/24568] [meta-bugs] Missed optimization: trivialization of silly code

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2005-10-28 18:19 ---
Confirmed, I am changing this into a meta-bug because there are three different
issues that this bug depends on now.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2005-10-28 18:19:55
   date||


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

[Bug tree-optimization/24568] [meta-bugs] Missed optimization: trivialization of silly code

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2005-10-28 18:21 ---
Oh, for PR 24575 to do anything useful in this case, we need to a tree based
combiner.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||15459


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

[Bug c++/20912] C++ FE emitting assignments to read-only global symbols

[pinskia at gcc dot gnu dot org]

--- Comment #11 from pinskia at gcc dot gnu dot org  2005-10-28 18:25 
---
Right now after fixing this and PR 23777 should become fixed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO||23777
  nThis||


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

[Bug tree-optimization/23286] missed fully redundant expression

[pinskia at gcc dot gnu dot org]

--- Comment #10 from pinskia at gcc dot gnu dot org  2005-10-28 18:43 
---
Here is another example which comes from PR 24568 (which really comes from
thedailywtf):
int f(int i)
{
  if (i < 0) return i/10+ i;
  return i/10 + i;
}
int f2(int i)
{
  return i/10 + i;
}


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO||24568
  nThis||


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

[Bug c++/22153] [3.4/4.0/4.1 regression] ICE on invalid template specialization

[jconner at gcc dot gnu dot org]

--- Comment #5 from jconner at gcc dot gnu dot org  2005-10-28 18:47 ---
Subject: Bug 22153

Author: jconner
Date: Fri Oct 28 18:47:28 2005
New Revision: 105946

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=105946
Log:
Merged from mainline change #105944:

PR c++/22153
* cp/parser.c (cp_parser_member_declaration): Detect and handle
a template specialization.
* testsuite/g++.dg/template/crash38.C: New test.
* testsuite/g++.dg/parse/explicit1.C: Change expected errors.


Added:
branches/gcc-3_4-branch/gcc/testsuite/g++.dg/crash38.C
  - copied unchanged from r105944, trunk/gcc/testsuite/g++.dg/crash38.C
Modified:
branches/gcc-3_4-branch/gcc/cp/ChangeLog
branches/gcc-3_4-branch/gcc/cp/parser.c
branches/gcc-3_4-branch/gcc/testsuite/ChangeLog
branches/gcc-3_4-branch/gcc/testsuite/g++.dg/parse/explicit1.C


-- 


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

[Bug c++/22153] [3.4/4.0/4.1 regression] ICE on invalid template specialization

[jconner at gcc dot gnu dot org]

--- Comment #6 from jconner at gcc dot gnu dot org  2005-10-28 18:57 ---
Subject: Bug 22153

Author: jconner
Date: Fri Oct 28 18:57:33 2005
New Revision: 105947

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=105947
Log:
Merged from mainline change #105944:

PR c++/22153
* cp/parser.c (cp_parser_member_declaration): Detect and handle
a template specialization.
* testsuite/g++.dg/template/crash38.C: New test.
* testsuite/g++.dg/parse/explicit1.C: Change expected errors.


Added:
branches/gcc-4_0-branch/gcc/testsuite/g++.dg/crash38.C
  - copied unchanged from r105944, trunk/gcc/testsuite/g++.dg/crash38.C
Modified:
branches/gcc-4_0-branch/gcc/cp/ChangeLog
branches/gcc-4_0-branch/gcc/cp/parser.c
branches/gcc-4_0-branch/gcc/testsuite/ChangeLog
branches/gcc-4_0-branch/gcc/testsuite/g++.dg/parse/explicit1.C


-- 


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

[Bug c++/22153] [3.4/4.0/4.1 regression] ICE on invalid template specialization

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2005-10-28 18:58 ---
Fixed in all open branches.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail|3.4.0 4.0.0 4.1.0   |3.4.0 4.0.0
  Known to work|3.3.3   |3.3.3 3.4.5 4.0.3 4.1.0
   Target Milestone|4.1.0   |3.4.5


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

[Bug target/24230] [4.1 Regression] ICE in extract_insn with altivec

[paolo dot bonzini at lu dot unisi dot ch]

--- Comment #17 from paolo dot bonzini at lu dot unisi dot ch  2005-10-28 
19:16 ---
Subject: Re:  [4.1 Regression] ICE in extract_insn with
 altivec


>On IRC it was suggested that we just need to get a version of
>easy_vector_constant which does the right thing in any mode.
>
Yes, it looks like the bug is that the constant is declared "easy" until 
it is in V8HI mode, but not when the reload is done in V16QI mode.

It may make sense to assert !reload_in_progress && !reload_completed 
before force_const_mem is called.

Paolo


-- 


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

[Bug fortran/24545] gfortran bug regarding interface block with named END INTERFACE statements

[kargl at gcc dot gnu dot org]

--- Comment #3 from kargl at gcc dot gnu dot org  2005-10-28 20:06 ---
Subject: Bug 24545

Author: kargl
Date: Fri Oct 28 20:05:56 2005
New Revision: 105953

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=105953
Log:
PR fortran/24545
* interface.c (gfc_match_end_interface): Fix typo in INTERFACE_USER_OP case.



Added:
trunk/gcc/testsuite/gfortran.dg/interface_2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/interface.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/24545] gfortran bug regarding interface block with named END INTERFACE statements

[sgk at troutmask dot apl dot washington dot edu]

--- Comment #4 from sgk at troutmask dot apl dot washington dot edu  
2005-10-28 20:07 ---
Subject: Re:  gfortran bug regarding interface block with named END INTERFACE
statements

On Wed, Oct 26, 2005 at 06:54:10PM -, steven at gcc dot gnu dot org wrote:
> 
> Index: interface.c
> ===
> RCS file: /cvs/gcc/gcc/gcc/fortran/interface.c,v
> retrieving revision 1.21
> diff -u -3 -p -r1.21 interface.c
> --- interface.c 21 Oct 2005 18:50:52 -  1.21
> +++ interface.c 26 Oct 2005 18:53:39 -
> @@ -295,7 +295,7 @@ gfc_match_end_interface (void)
>/* Comparing the symbol node names is OK because only use-associated
>   symbols can be renamed.  */
>if (type != current_interface.type
> - || strcmp (current_interface.sym->name, name) != 0)
> + || strcmp (current_interface.uop->name, name) != 0)
> {
>   gfc_error ("Expecting 'END INTERFACE OPERATOR (.%s.)' at %C",
>  current_interface.sym->name);
> 

Bootstrapped and regression tested  on amd64-*-freebsd.
I've committed the patch.


-- 


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

[Bug c++/24511] [4.0/4.1 Regression] explicit instantiation/extern template unsats on symbols defined later

[jason at gcc dot gnu dot org]

--- Comment #2 from jason at gcc dot gnu dot org  2005-10-28 20:25 ---
This is not a bug.  All member templates must be defined before an explicit
instantiation of the class.  The existing standard requires an error on this
case, but a future DR will change the standard to match the g++ behavior.

It's desirable to not require all member templates to be defined in the case of
private copy constructors declared only to prevent copying the class.




-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID


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

[Bug c++/23229] [4.0/4.1 Regression] g++ gives incorrect error message with void main() and a void function

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2005-10-28 20:26 ---
Subject: Bug 23229

Author: pinskia
Date: Fri Oct 28 20:25:55 2005
New Revision: 105960

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=105960
Log:
2005-10-28  Andrew Pinski  <[EMAIL PROTECTED]>

PR C++/23229
* decl.c (grokfndecl): Create a new function type
after erroring out about main not returning int.
2005-10-28  Andrew Pinski  <[EMAIL PROTECTED]>

PR C++/23229
* g++.dg/warn/main-2.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/warn/main-2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/24511] [4.0/4.1 Regression] explicit instantiation/extern template unsats on symbols defined later

[sebor at roguewave dot com]

--- Comment #3 from sebor at roguewave dot com  2005-10-28 20:34 ---
Jason, I respectfully disagree. In bug 22263 I explained why I believe gcc is
wrong. Do you see a problem with my reasoning there? If not, you must surely
agree that this is just another example of the same bug.


-- 

sebor at roguewave dot com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |


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

[Bug c++/23229] [4.0/4.1 Regression] g++ gives incorrect error message with void main() and a void function

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2005-10-28 20:52 ---
Subject: Bug 23229

Author: pinskia
Date: Fri Oct 28 20:52:44 2005
New Revision: 105961

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=105961
Log:
2005-10-28  Andrew Pinski  <[EMAIL PROTECTED]>

PR C++/23229
* decl.c (grokfndecl): Create a new function type
after erroring out about main not returning int.
2005-10-28  Andrew Pinski  <[EMAIL PROTECTED]>

PR C++/23229
* g++.dg/warn/main-2.C: New test.


Added:
branches/gcc-4_0-branch/gcc/testsuite/g++.dg/warn/main-2.C
  - copied unchanged from r105960, trunk/gcc/testsuite/g++.dg/warn/main-2.C
Modified:
branches/gcc-4_0-branch/gcc/cp/ChangeLog
branches/gcc-4_0-branch/gcc/cp/decl.c
branches/gcc-4_0-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/24545] gfortran bug regarding interface block with named END INTERFACE statements

[kargl at gcc dot gnu dot org]

--- Comment #5 from kargl at gcc dot gnu dot org  2005-10-28 20:57 ---
Subject: Bug 24545

Author: kargl
Date: Fri Oct 28 20:57:17 2005
New Revision: 105962

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=105962
Log:
PR fortran/24545
* interface.c (gfc_match_end_interface): Fix typo in INTERFACE_USER_OP case.


Added:
branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/interface_2.f90
Modified:
branches/gcc-4_0-branch/gcc/fortran/ChangeLog
branches/gcc-4_0-branch/gcc/fortran/interface.c
branches/gcc-4_0-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/24545] gfortran bug regarding interface block with named END INTERFACE statements

[kargl at gcc dot gnu dot org]

--- Comment #6 from kargl at gcc dot gnu dot org  2005-10-28 20:58 ---
Fixed.


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug fortran/24545] gfortran bug regarding interface block with named END INTERFACE statements

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.1.0   |4.0.3


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

[Bug c++/23229] [4.0/4.1 Regression] g++ gives incorrect error message with void main() and a void function

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2005-10-28 21:02 ---
Fixed in 4.0.3.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/24569] [4.0/4.1 regression] ICE in add_AT_specification, at dwarf2out.c:4966

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2005-10-28 16:43:20 |2005-10-28 21:05:38
   date||


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

[Bug c++/24511] [4.0/4.1 Regression] explicit instantiation/extern template unsats on symbols defined later

[jason at gcc dot gnu dot org]

--- Comment #4 from jason at gcc dot gnu dot org  2005-10-28 21:19 ---
I do disagree with your reasoning on the other bug.  This DR clarifies 14.7.2:

  http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#470

If indeed all other compilers accept this code, then perhaps the DR is not what
we want, but you should bring that up with Core.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|REOPENED|SUSPENDED


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

[Bug fortran/24576] New: Fortran I/O to same unit number in main program and in a shared library

[iwan at irs dot phy dot nrc dot ca]

A fortran main program and a fortran shared library dlopen'ed from the main
program use the same unit number to report results to two different files 
(explicitely opened in the main program and in the library, see example below)

With GCC 3.x when one links with libg2c.a to produce the shared library 
(i.e. 
g77 -shared -fPIC -Wl,-Bsymbolic -o libtest.so test.f /usr/lib64/libg2c.a
) 
output goes to the two files as intended.

With gfortran 4.0.2 and also snapshot 4.1.0 20051022 the attempt to write 
to the file in the shared library fails with 
Fortran runtime error: End of record
In this case I have used 
gfortran -fPIC -shared -Wl,-Bsymbolic -o libtest.so test.f
/usr/lib64/libgfortran.a
gcc -c testx.c
gfortran main.f testx.o -ldl
to produce the executable and the shared library.

When the shared library is built without libgfortran.a, 
once unit 1 is opened in the shared library, all output goes 
to this file, not the file connected to unit 1 in the main program.

I'm not sure if this is a bug or intended behavior. 

c--- test.f
  subroutine test
  open(1,file='junk_shared')
  write(1,*) 'In subroutine test'
  return
  end

/*- testx.c
#include 
#include 

typedef void (*MyFunc)();

void testx_() {
void *h; MyFunc func;
h = dlopen("./libtest.so",RTLD_LAZY);
if( !h ) {
printf("Failed to open libtest: %s\n",dlerror());
return;
}
func = (MyFunc) dlsym(h,"test_");
if( !func ) {
printf("Failed to resolve test: %s\n",dlerror());
return;
}
func();
}

c-- main.f
  program io_test
  open(1,file='junk_main')
  write(1,*) 'In main program, calling testx'
  call testx
  write(1,*) 'Back in main program after call to testx: '
  end


-- 
   Summary: Fortran I/O to same unit number in main program and in a
shared library
   Product: gcc
   Version: 4.0.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: iwan at irs dot phy dot nrc dot ca
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug awt/16741] Toolkit.loadSystemColor unimplemented

[sven at physto dot se]

--- Comment #2 from sven at physto dot se  2005-10-28 21:27 ---
Can we close this?


-- 


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

[Bug gcov/profile/24487] [3.4/4.0/4.1 Regression] Basic block frequencies inaccurate

[hubicka at ucw dot cz]

--- Comment #4 from hubicka at ucw dot cz  2005-10-28 21:29 ---
Subject: Re: [Bug gcov/profile/24487] [3.4/4.0/4.1 Regression] Basic block
frequencies inaccurate

> 
> 
> --- Comment #3 from dje at gcc dot gnu dot org  2005-10-28 17:30 ---
> The misprediction causes (or at least contributes to) compute_alignments in
> final.c not aligning the critical loop in longest_match.  The recent changes 
> to
> bb-reorder.c moved the start of the loop from an ideal alignment to the worst
> alignment, causing a 8-10% performance drop due to instruction fetch 
> problems. 
> Without the explicit alignment directives omitted because of misprediction, 
> the
> alignment of the loop is random.

I see, Athlon is less sensitive to alignment that might explain it.  I
will try to fix my SPEC testing setup on PPC after SVN revamp and
benchmark it there too...

Honza

> 
> 
> -- 
> 
> dje at gcc dot gnu dot org changed:
> 
>What|Removed |Added
> 
>  CC||dberlin at gcc dot gnu dot
>||org
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24487
> 
> --- You are receiving this mail because: ---
> You are on the CC list for the bug, or are watching someone who is.
> You are the assignee for the bug, or are watching the assignee.


-- 


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

[Bug c++/24511] explicit instantiation/extern template unsats on symbols defined later

[jason at gcc dot gnu dot org]

--- Comment #5 from jason at gcc dot gnu dot org  2005-10-28 21:34 ---
Actually, I'm sympathetic to the behavior you would like to see, so I'm
reopening the bug.  But I think the current behavior is clearly correct under
the DR, so I'm changing the severity to enhancement.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|critical|enhancement
 Status|SUSPENDED   |NEW
   Last reconfirmed|2005-10-25 01:00:51 |2005-10-28 21:34:24
   date||
Summary|[4.0/4.1 Regression]|explicit
   |explicit|instantiation/extern
   |instantiation/extern|template unsats on symbols
   |template unsats on symbols  |defined later
   |defined later   |


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

[Bug libfortran/24576] Fortran I/O to same unit number in main program and in a shared library

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2005-10-28 21:40 ---
Why are you not linking against the shared library version of libgfortran?
What you are doing seems wrong and unsupported.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|fortran |libfortran


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

[Bug c++/24511] explicit instantiation/extern template unsats on symbols defined later

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.0.3   |---


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

[Bug libfortran/24576] Fortran I/O to same unit number in main program and in a shared library

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2005-10-28 21:43 ---
Anyways I think this is really a dup of bug 22298.
Also note the static library really needs to be compiled with -fPIC if you are
linking it in a shared library (by default it is not).


-- 


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

[Bug target/24230] [4.1 Regression] ICE in extract_insn with altivec

[pinskia at gcc dot gnu dot org]

--- Comment #18 from pinskia at gcc dot gnu dot org  2005-10-28 21:47 
---
Aldy,
  Can you look into this bug?


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu dot org


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

[Bug middle-end/24573] g++: Internal error message while building openh323

[qijcqj8lcwka56m at jetable dot com]

--- Comment #4 from qijcqj8lcwka56m at jetable dot com  2005-10-28 22:13 
---
(In reply to comment #3)
> This works for me in 3.3.3.
> How much memory do you have?
> 

I have 248 Mb of memory



-- 


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

[Bug c++/24577] New: diagnostic informative note labelled "error"

[igodard at pacbell dot net]

void foo(){ int a = b; }

gets you:

foo.cc: In function `void foo()':
foo.cc:1: error: `b' undeclared (first use this function)
foo.cc:1: error: (Each undeclared identifier is reported only once for each
function it appears in.)

Other informative notes are labeled "note:". Because this is labelled "error",
scripts that scan generated compiler output to count errors get wrong counts.

Ivan


-- 
   Summary: diagnostic informative note labelled "error"
   Product: gcc
   Version: 3.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net


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

[Bug libfortran/24576] Fortran I/O to same unit number in main program and in a shared library

[iwan at irs dot phy dot nrc dot ca]

--- Comment #3 from iwan at irs dot phy dot nrc dot ca  2005-10-28 23:22 
---
Subject: Re:  Fortran I/O to same unit number in main program and in a shared
library

>--- Comment #1 from pinskia at gcc dot gnu dot org  2005-10-28 21:40  
>Why are you not linking against the shared library version of libgfortran?
>What you are doing seems wrong and unsupported.
>
If I do that, after the shared library has opened unit 1, all output  
from the main program goes there and this is not what I want.
With the Intel and PGI compilers linking the shared library 
with -Wl,-Bsymbolic is sufficient to make the main program and 
the shared library to have independent I/O. With the GCC 3.x 
compilers one needed to link against the static g2c. This no longer 
works with GCC 4.x.

Both the shared library and the main program are huge packages 
using tens of different I/O units => It i not easy to simply find and 
replace I/O units everywhere. 

> --- Comment #2 from pinskia at gcc dot gnu dot org  2005-10-28 21:43
> --- Anyways I think this is really a dup of bug 22298.
> Also note the static library really needs to be compiled with -fPIC if you
> are linking it in a shared library (by default it is not).
>
The static gfortran library is made with -fPIC (otherwise the linker refuses 
to create a shared library on x86_64 when linking against it) 


-- 


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

[Bug c++/24569] [4.0/4.1 regression] ICE in add_AT_specification, at dwarf2out.c:4966

[jason at gcc dot gnu dot org]

--- Comment #4 from jason at gcc dot gnu dot org  2005-10-28 23:38 ---
Yes, this was introduced by

2005-10-10  Mark Mitchell  <[EMAIL PROTECTED]>

PR c++/24277
* pt.c (instantiate_decl): Call finish_static_data_member_decl for
static data members.

After this change, we call that function twice for static data members, once
when instantiating the class and again when instantiating the member itself. 
As a result, the member gets added to pending_statics twice.

I think we only want to call finish_static_data_member_decl once per static
data member.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|jason at gcc dot gnu dot org|mmitchel at gcc dot gnu dot
   ||org


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

[Bug c/24577] diagnostic informative note labelled "error"

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2005-10-28 23:44 ---
This is only a C bug now:
t.c:1: error: 'b' undeclared (first use in this function)
t.c:1: error: (Each undeclared identifier is reported only once
t.c:1: error: for each function it appears in.)

Confirmed, the C++ front-end now gives
t.c: In function 'void foo()':
t.c:1: error: 'b' was not declared in this scope


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|c++ |c
 Ever Confirmed|0   |1
   Keywords||diagnostic
   Last reconfirmed|-00-00 00:00:00 |2005-10-28 23:44:06
   date||


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

[Bug c/24577] diagnostic informative note labelled "error"

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |trivial


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

[Bug c++/11987] [3.4/4.0/4.1 regression] Accepts-invalid with inherited nested type

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |minor


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

[Bug libfortran/24576] Fortran I/O to same unit number in main program and in a shared library

[kargl at gcc dot gnu dot org]

--- Comment #4 from kargl at gcc dot gnu dot org  2005-10-29 00:14 ---
Intel and PGI are wrong according to the standard.  Gfortran is 
doing the right thing.  See section 9.4 File Connection.  In 
particular "The external unit identified by a particular value of
a scalar-int-expr is the same external unit in all program units of
the program."  Also, read Note 9.13.   I'm here referencing 
material from the Final Committee Draft for the Fortran 2003 
standard.

You'll also find

Section 9.4.3  Connection of a file to a unit
An external unit has a property of being connected or not connected. If
connected, it refers to an external file.  An external unit may become
connected by preconnection or by the execution of an OPEN statement. The
property of connection is symmetric; the unit is connected to a file if
and only if the file is connected to the unit.

In short, if you want to different files, then you need to have unique
unit numbers.


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu dot org


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

[Bug c/24578] New: compiler emits call to floorf() instead of floor()

[ds at schleef dot org]

Compiling the following code on MIPS emits a function call to floorf (not
floor).  This is a problem when one's libc does not contain a floorf function.

void func (float *dest, float *src)
{
*dest = floor (*src);
}

Compile using 'mipsel-linux-uclibc-gcc -O2 -save-temps -c it.c'.


-- 
   Summary: compiler emits call to floorf() instead of floor()
   Product: gcc
   Version: 3.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ds at schleef dot org


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

[Bug target/24578] compiler emits call to floorf() instead of floor()

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2005-10-29 00:52 ---
First this is a target bug and second floorf is a C99 function and really
uclibc should have it.  If you want to declare this a gcc bug, you first need
to add an uclibc target and make it so it does not declare that you have C99
math functions.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c   |target
 GCC target triplet||mipsel-linux-uclibc


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

[Bug tree-optimization/23346] [4.1 Regression] FRE before DCE makes a mess of loads or need to sink loads

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |minor


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