[Bug rtl-optimization/18560] New: better optimalization of EOR/MOV block.
/*
This function reverses the bytes in a word. The method was discovered in
1986 following a competition between ARM programmers; it requires just 4
instructions and 1 work register. A method using only 3 instructions per
word reversed was also found, but it has some set-up overhead and uses
a 2nd register.
*/
unsigned long reverse(unsigned long v)
{
unsigned long t;
t = v ^ ((v 16) | (v 16));// EOR r1,r0,r0,ROR #16[1]
t = ~0xff; // BIC r1,r1,#ff
v = (v 24) | (v 8); // MOV r0,r0,ROR #8
return v ^ (t 8);// EOR r0,r0,r1,LSR #8
}
The gcc-3.4.3 with -O2 produces:
reverse:
mov r3, r0 [2]
mov r0, r0, ror #16 [2]
eor r0, r0, r3 [2]
bic r0, r0, #16711680
mov r3, r3, ror #8
eor r0, r3, r0, lsr #8
mov pc, lr
Itc doesn't seem to produce [2] optimal code [1].
--
Summary: better optimalization of EOR/MOV block.
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at pld-linux dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: pentium3-pld-linux
GCC host triplet: pentium3-pld-linux
GCC target triplet: arm-pld-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18560
[Bug fortran/18561] New: IF (logical ) IF (arith) lab1 , lab 2 lab 3 is unclassifiable
Encountered in LLNL DLSODES.F - execreable stuff, obsolete too, but accepted by other brands. The fix is easy and looks cleaner. IS THIS A BUG OR AN ABOMINATION? program ifif_test integer i , j i = 1 j = 2 if ( i.EQ.1 ) if ( j -2 ) 10 , 20 , 30 10PRINT *, 'thuuunk! j2' stop 20print *, 'Hello 1,2 world' STOP 30 PRINT *, 'uuurkk! j2' end program ifif_test $ /irun/bin/gfortran -x f77 ifif_test.f90 In file ifif_test.f90:5 if ( i.EQ.1 ) if ( j -2 ) 10 , 20 , 30 1 Error: Unclassifiable statement in IF-clause at (1) -- Summary: IF (logical ) IF (arith) lab1 , lab 2 lab 3 is unclassifiable Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: paul dot richard dot thomas at cea dot fr CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18561
[Bug tree-optimization/18562] New: SSE constant vector initialization produces dead constant values on stack
Compiling this testcase with '-O2 -msse' an unoptimal code is produced. 'val1'
is merged into vector at compile time, but it is still loaded onto stack. Gcc
does not detect that 'val1' value on stack is sitting there unused.
#include xmmintrin.h
#include stdio.h
int main(void) {
float val1 = 1.3f;
float result[4];
__m128 A;
A = _mm_load1_ps(val1);
_mm_storeu_ps(result, A);
printf(%f %f %f %f\n, result[0], result[1], result[2], result[3]);
return 0;
}
This code is produced:
...
.LC2: - merged vector
.long 1067869798
.long 0
.long 0
.long 0
.text
.p2align 4,,15
.globl main
.type main, @function
main:
pushl %ebp
movl%esp, %ebp
subl$72, %esp
movss .LC2, %xmm0 - vector is loaded into %xmm0
andl$-16, %esp
subl$16, %esp
movl$0x3fa6, -4(%ebp) - 'val1' is put on stack here
shufps $0, %xmm0, %xmm0
movl$.LC1, (%esp)
movups %xmm0, -20(%ebp)
flds-8(%ebp)
fstpl 28(%esp)
flds-12(%ebp)
fstpl 20(%esp)
flds-16(%ebp)
fstpl 12(%esp)
flds-20(%ebp)
fstpl 4(%esp)
callprintf
xorl%eax, %eax
leave
ret
Even worser situation arises with:
int main(void) {
float val1[4] = {1.3f, 1.4f, 1.5f, 1.6f};
float result[4];
__m128 A;
A = _mm_loadu_ps(val1);
_mm_storeu_ps(result, A);
printf(%f %f %f %f\n, result[0], result[1], result[2], result[3]);
return 0;
Following asm code is produced:
main:
pushl %ebp
movl%esp, %ebp
subl$72, %esp
andl$-16, %esp
movl$0x3fa6, -16(%ebp)
subl$16, %esp
movl$0x3fb3, -12(%ebp)
movl$0x3fc0, -8(%ebp)
movl$0x3fcd, -4(%ebp)
movups -16(%ebp), %xmm0
movups %xmm0, -32(%ebp)
flds-20(%ebp)
fstpl 28(%esp)
flds-24(%ebp)
fstpl 20(%esp)
flds-28(%ebp)
fstpl 12(%esp)
flds-32(%ebp)
fstpl 4(%esp)
movl$.LC4, (%esp)
callprintf
xorl%eax, %eax
leave
ret
The constant values are not merged into vector at compile time, the vector is
built on the stack and then loaded into %xmm register. Value on stack is again
left unused after vector initialization.
Uros.
--
Summary: SSE constant vector initialization produces dead
constant values on stack
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uros at gcc dot gnu 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=18562
GCC bug report
hi there,
I'd like to report a bug with the 'gcc' and its optimizer:
the attached file 'compilerbug.txt' contains the compiler version,
the command line and the compiler output.
find also attached the source '2m_tpl.c' and the preprocessed file
'2m_tpl.i'
Without the optimizer, the file compiles ok.
We have another file in the project that triggers the same intenal error,
while all the (hundred) others are ok.
What these two files have in common is the rather large number of
local variables.
If there's no immediate fix for the compiler, probably you could tell
me a workaround by turning on or off particular compiler option(s) ?
kind regards
Gerhard DonGerry Jacobs
MarconiONDATABacknang Tel. 07191/13- 3083
[EMAIL PROTECTED]Fax 07191/13-63083
One man's error is another man's data
# COMPILER VERSION
Reading specs from
/home_bk6914/shw2bk/usr/local/bin/../lib/gcc-lib/m68k-elf/3.3.3/specs
Configured with: /usr/local/src/uclinux-tools/gcc-3.3-20031222/configure
--enable-languages=c,c++ --target=m68k-elf --enable-multilib
--enable-target-optspace --with-gnu-ld --disable-nls --disable-__cxa_atexit
--disable-c99 --disable-clocale --disable-c-mbchar --disable-long-long
--enable-cxx-flags=-D_ISOC99_SOURCE -D_BSD_SOURCE
Thread model: single
gcc version 3.3.3 20031222 (prerelease)
# COMPILER INVOCATION
/home/shw2bk/usr/local/bin/m68k-elf-gcc -save-temps -c -g -Wall -O2 -m5407
-fno-strict-aliasing -o 2m_tpl.o 2m_tpl.c
# COMPILER OUTPUT
2m_tpl.c: In function `TB2M_Calculate_J1_CRC':
2m_tpl.c:84: error: insn does not satisfy its constraints:
(insn 255 202 130 5 (nil) (set (reg:QI 9 %a1)
(mem:QI (plus:SI (reg/f:SI 14 %a6)
(const_int -7 [0xfff9])) [0 J1_CRC_Byte S1 A8])) 37
{*m68k.md:1060} (nil)
(nil))
2m_tpl.c:84: internal compiler error: in reload_cse_simplify_operands, at
reload1.c:8353
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
2m_tpl.c
Description: Binary data
2m_tpl.i
Description: Binary data
[Bug c++/14513] Friend name injection problem (implicit declaration)
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-11-19 10:09 --- Last part is submitted: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01495.html This one together with earlier parts fix the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14513
[Bug target/18563] New: ICE: output_operand: invalid expression as operand
ICE with -O1 or greater, -O0 does not ICE # avr-rtems4.7-gcc -O4 -o cpuboot.o -c cpuboot.c cpuboot.c: In function `boot_phase_1': cpuboot.c:8: internal compiler error: output_operand: invalid expression as operand Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. # avr-rtems4.7-gcc --version avr-rtems4.7-gcc (GCC) 3.4.4 20041114 (prerelease) This PR has been split out from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18542 -- Summary: ICE: output_operand: invalid expression as operand Product: gcc Version: 3.4.4 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: corsepiu at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: avr-rtems*, avr-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18563
[Bug target/18563] ICE: output_operand: invalid expression as operand
--- Additional Comments From corsepiu at gcc dot gnu dot org 2004-11-19 10:15 --- Created an attachment (id=7567) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7567action=view) Example to reproduce the ICE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18563
[Bug target/18564] New: ICE: output_operand: invalid expression as operand
ICE with -O1 or greater, -O0 does not ICE # h8300-rtems4.7-gcc -O4 -o cpuboot.o -c cpuboot.c cpuboot.c: In function `boot_phase_1': cpuboot.c:8: internal compiler error: output_operand: invalid expression as operand Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. # h8300-rtems4.7-gcc --version avr-rtems4.7-gcc (GCC) 3.4.4 20041114 (prerelease) This PR has been split out from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18542 -- Summary: ICE: output_operand: invalid expression as operand Product: gcc Version: 3.4.4 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: corsepiu at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: h8300-rtems*, h8300-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18564
[Bug target/18564] ICE: output_operand: invalid expression as operand
--- Additional Comments From corsepiu at gcc dot gnu dot org 2004-11-19 10:21 --- Created an attachment (id=7568) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7568action=view) Example code to reproduce the ICE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18564
[Bug target/18542] [3.4 only] ICE: output_operand: invalid expression as operand
--- Additional Comments From corsepiu at gcc dot gnu dot org 2004-11-19 10:22 --- I am filing separate PRs for the avr and the h8300, because I believe this issue to be target-specific. FYI: I have found one target for which compiling the code in the attachment fails with the same symptions with gcc-3.4.0, while gcc-3.4.3 does not fail: An i386-pc-linux (FC3) to i386-freebsd5.2.1 cross gcc-3.4.0 fails the same way, a gcc-3.4.3 does not fail. -- What|Removed |Added GCC target triplet|m68k-*-elf m68k-rtems* avr- |m68k-*-elf m68k-rtems* |rtems* h8300-rtems* | Known to fail||3.4.0 3.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18542
[Bug tree-optimization/18557] Inefficient code generated by -ftree-vectorize on Alpha
--- Additional Comments From giovannibajo at libero dot it 2004-11-19 10:50 --- Can we get some numbers to understand how worse we are behaving? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18557
[Bug tree-optimization/13776] [4.0 Regression] [tree-ssa] Many C++ compile-time regression in 4.0-tree-ssa 040120
--- Additional Comments From kgardas at objectsecurity dot com 2004-11-19 11:14 --- Subject: Re: [4.0 Regression] [tree-ssa] Many C++ compile-time regression in 4.0-tree-ssa 040120 I've tested 3.4.2, 4.0.0 (20041026) and 4.0.0 (20041118) with following results: 3.4.2: c++ -I../include -time -O0 -Wall -DPIC -fPIC -c ir.cc -o ir.pic.o # cc1plus 46.98 0.53 # as 4.62 0.22 peak memory consumed: 99MB 4.0.0 (20041026): c++ -I../include -time -O0 -Wall -DPIC -fPIC -c ir.cc -o ir.pic.o # cc1plus 67.13 2.05 # as 5.98 0.30 peak memory consumed: 243MB 4.0.0 (20041118): c++ -I../include -time -O0 -Wall -DPIC -fPIC -c ir.cc -o ir.pic.o # cc1plus 66.47 1.97 # as 5.84 0.27 peak memory consumed 243MB so there is still both compile-time and memory usage regressions presented on main-line. The reason why do you see speed-up in comparison with 3.1/3.3 is that 3.4.2 is really faster compiler (at least from MICO sources point of view). Cheers, Karel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13776
[Bug tree-optimization/18557] Inefficient code generated by -ftree-vectorize on Alpha
--- Additional Comments From falk at debian dot org 2004-11-19 11:29 --- (In reply to comment #3) Can we get some numbers to understand how worse we are behaving? The code size is inflated by a factor of about 3. Run time difference depends a lot on how many bytes are actually copied, how predictable the branches are etc. If I just run the test case on always the same data, which is about the best possible case, the vectorized code is 5% slower than f2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18557
[Bug fortran/18565] New: gfortran: CONJG: false error message about standard violation
Hi, the following program gives a false error message when compiled with gfortran -std=f95: integer, parameter :: dp = kind (1.d0) complex(dp) :: z1, z2 z1 = (0._dp, 1._dp) z2 = conjg (z1) print *, z1, z2 end I get: In file gfcbug21.f90:4 z2 = conjg (z1) 1 Error: Type of argument 'z' in call to 'conjg' at (1) should be COMPLEX(4), not COMPLEX(8) This is clearly wrong. According to my copy of MetcalfReid, CONJG is a generic elemental function. Cheers, -ha -- Summary: gfortran: CONJG: false error message about standard violation Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: anlauf at hep dot tu-darmstadt dot de CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18565
[Bug target/17735] [4.0 Regression] make stops with initializer for integer value is too complicated while building an avr-cross compiler
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-19 13:12 --- Subject: Bug 17735 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-11-19 13:12:45 Modified files: gcc: ChangeLog varasm.c Log message: PR target/17735 * varasm.c (default_assemble_integer): Allow pointer-sized values. Expand comment. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.6413r2=2.6414 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/varasm.c.diff?cvsroot=gccr1=1.460r2=1.461 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17735
[Bug target/17735] [4.0 Regression] make stops with initializer for integer value is too complicated while building an avr-cross compiler
--- Additional Comments From pbrook at gcc dot gnu dot org 2004-11-19 13:13 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17735
[Bug fortran/18566] New: Can vary constants
Should the value of pi change... The following is very probably illegal code. Still, it would be nice if this could segfault instead of silently doing the Wrong Thing. $ cat variation-constants.f90 module a1 contains subroutine foo(b) real :: b b = 42. end subroutine foo end module a1 program main use a1 real, parameter :: pi = 3.1415926535 call foo(pi) print *,'pi equals ', pi end program main $ gfortran variation-constants.f90 ./a.out pi equals42.0 $ gfortran -v Reading specs from /home/zfkts/lib/gcc/ia64-unknown-linux-gnu/4.0.0/specs Configured with: ../gcc-4.0-20041107/configure --prefix=/home/zfkts --enable-languages=c,c++,f95 Thread model: posix gcc version 4.0.0 20041107 (experimental) -- Summary: Can vary constants Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: enhancement 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=18566
[Bug tree-optimization/18557] Inefficient code generated by -ftree-vectorize on Alpha
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-19 14:21 --- (In reply to comment #2) Subject: Re: Inefficient code generated by -ftree-vectorize on Alpha On Fri, 2004-11-19 at 00:04 +, pinskia at gcc dot gnu dot org wrote: --- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-19 00:04 --- Confirmed. One issue is that we don't fold stuff: D.1061 = 8 - 1; D.1065 = 2 - 1; We correctly rely on CCP to clean it up :) Having every single pass fold every statement it generates isn't necessarily a win when CCP will do it for you :) This is how the vectorizer produced the statement in the first place. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18557
[Bug target/18558] [4.0 Regression] ICE: in gen_lowpart_common, at emit-rtl.c:1078
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-19 14:23 --- Confirmed, target problem, subreg of BLKmode is no longer allowed. See http://gcc.gnu.org/ml/gcc/2004-11/msg00617.html for a way to fix it (this was a patch to rs6000 which fixed the problem there). -- What|Removed |Added Status|UNCONFIRMED |NEW Component|middle-end |target Ever Confirmed||1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2004-11-19 14:23:58 date|| Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18558
[Bug other/18559] apple's gcc-3.3 -fast causes bus error
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-19 14:29 --- Not our bug, report it to Apple. Oh, by the way -fast enables -malign-nature which causes some structs to have different sizes and since libstdc++ is compiled normally that can cause problems. Try -fastcp (or -fastf) for C++ code instead. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18559
[Bug target/18562] SSE constant vector initialization produces dead constant values on stack
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-19 14:44 --- Confirmed. This is either a target bug or an RTL optimization problem. The reason why I say that is because the builtins are not expandded before reaching RTL. -- What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Component|tree-optimization |target Ever Confirmed||1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2004-11-19 14:44:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18562
[Bug rtl-optimization/18560] better optimalization of EOR/MOV block.
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-19 14:50 --- Confirmed, the mainline produces better code already: mov r3, r0 eor r0, r0, r0, ror #16 bic r0, r0, #16711680 mov r0, r0, lsr #8 eor r0, r0, r3, ror #8 @ lr needed for prologue bx lr -- What|Removed |Added Severity|minor |enhancement Status|UNCONFIRMED |NEW Ever Confirmed||1 GCC build triplet|pentium3-pld-linux | GCC host triplet|pentium3-pld-linux | Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2004-11-19 14:50:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18560
[Bug middle-end/17813] [3.4 regression] ada bootstrap failure on i486-linux
-- What|Removed |Added Known to fail||3.4.0 Known to work||4.0.0 3.3.4 Summary|[4.0 regression] ada|[3.4 regression] ada |bootstrap failure on i486- |bootstrap failure on i486- |linux |linux Target Milestone|4.0.0 |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17813
[Bug fortran/18566] Can vary constants
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-19 15:13 --- No it is just undefined on most targets we do seg fault. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18566
[Bug fortran/18561] IF (logical ) IF (arith) lab1 , lab 2 lab 3 is unclassifiable
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-19 15:16 --- *** This bug has been marked as a duplicate of 17229 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18561
[Bug fortran/17229] parser confused by arithmetic if inside an if
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-19 15:17 --- *** Bug 18561 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||paul dot richard dot thomas ||at cea dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17229
[Bug fortran/18565] gfortran: CONJG: false error message about standard violation
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-19 15:19 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||diagnostic, rejects-valid Last reconfirmed|-00-00 00:00:00 |2004-11-19 15:19:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18565
[Bug c++/18567] New: Wrong -O description in manual ?
8
#include iostream
double foo(unsigned nb) {
/* volatile */ double sum = 0.9;
for (unsigned i=0; inb;++i) sum+=0.1;
return sum;
}
int main() {
double old = 1.0;
double diff = old - foo(1);
std::cout diff std::endl;
}
8
g++-3.3.4 foo.cpp
RESULT 0
g++-3.3.4 -O foo.cpp
RESULT -2.77556e-17
http://gcc.gnu.org/onlinedocs/gcc-3.3.4/gcc/Optimize-Options.html#Optimize%20Options
(-O equivalent to 10 or 11 options)
g++-3.3.4 -fdefer-pop -fmerge-constants -fthread-jumps -floop-optimize
-fcrossjumping -fif-conversion -fif-conversion2 -fdelayed-branch
-fguess-branch-probability -fcprop-registers (-fomit-frame-pointer) foo.cpp
RESULT 0
g++-3.4.2 foo.cpp
RESULT 0
g++-3.4.2 -O foo.cpp
RESULT -2.77556e-17
http://gcc.gnu.org/onlinedocs/gcc-3.4.2/gcc/Optimize-Options.html#Optimize-Options
(-O equivalent to 9 or 10 options)
g++-3.4 -fdefer-pop -fmerge-constants -fthread-jumps -floop-optimize
-fif-conversion -fif-conversion2 -fdelayed-branch -fguess-branch-probability
-fcprop-registers (-fomit-frame-pointer) foo.cpp
RESULT 0
With volatile sum or -ffloat-store, RESULT 0.
--
Summary: Wrong -O description in manual ?
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: benoit dot sibaud at rd dot francetelecom dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18567
[Bug c++/18567] Wrong -O description in manual ?
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-19 15:32 --- This is a dup of 323. Also -O enables more than what can be enabled with flags. *** This bug has been marked as a duplicate of 323 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18567
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-19 15:32 --- *** Bug 18567 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||benoit dot sibaud at rd dot ||francetelecom dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug c++/18567] Wrong -O description in manual ?
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-19 15:33 --- This is a dup of 323. Also -O enables more than what can be enabled with flags. Not all optimizations are controlled directly by a flag. Only optimizations that have a flag are listed. *** This bug has been marked as a duplicate of 323 *** *** This bug has been marked as a duplicate of 323 *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18567
[Bug target/18562] SSE constant vector initialization produces dead constant values on stack
--- Additional Comments From uros at gcc dot gnu dot org 2004-11-19 15:41
---
If val1 is moved out of the main() function, produced code is OK:
--cut here--
#include xmmintrin.h
#include stdio.h
float val1[4] = {1.3f, 1.4f, 1.5f, 1.6f};
int main(void) {
float result[4];
__m128 A;
...
--cut here--
val1: - vector is merged this time
.long 1067869798
.long 1068708659
.long 1069547520
.long 1070386381
.section.rodata.str1.1,aMS,@progbits,1
.LC0:
.string %f %f %f %f\n
.text
.p2align 4,,15
.globl main
.type main, @function
main:
pushl %ebp
movl%esp, %ebp
subl$56, %esp
andl$-16, %esp
movups val1, %xmm0 - loaded directy into xmm reg
movups %xmm0, -16(%ebp)
subl$16, %esp
flds-4(%ebp)
...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18562
[Bug fortran/18568] New: pointers in derived data types do not transmit shape of pointed to arrays - bug or non-standard feature?
Source given at end, after comparison of gfortran and digital fortran = first gfortran [EMAIL PROTECTED] /cygdrive/c/df $ /gcc-4.0/bin/gfortran d:\ITC\ITCFOR\size_test.f90 In file d:\ITC\ITCFOR\size_test.f90:22 end program size_test 1 Internal Error at (1): find_array_spec(): Component not found = now Digital Fortran ( Intel ifc is OK too ) $ ./f90 d:\ITC\ITCFOR\size_test.f90 DIGITAL Visual Fortran Optimizing Compiler Version 5.0 (Update D) Copyright (C) 1997,1998 Digital Equipment Corp. All rights reserved. /out:size_test.exe [EMAIL PROTECTED] /cygdrive/c/df $ ./size_test 1 2 3 4 5 6 7 8 9 10 = The source MODULE ints type, PUBLIC :: bar integer, pointer:: th(:) end type bar CONTAINS FUNCTION foo(b) TYPE( bar ),INTENT(IN) :: b integer :: foo( size( b%th ) ) foo = b%th Return end function foo END MODULE ints program size_test use ints type(bar) :: a integer, dimension(10), target :: i1 , i2 integer :: ictr i1 = (/( ictr , ictr =1,10)/) a%th = i1 i2 = foo( a ) print * , i2 end program size_test -- Summary: pointers in derived data types do not transmit shape of pointed to arrays - bug or non-standard feature? Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: paul dot richard dot thomas at cea dot fr CC: gcc-bugs at gcc dot gnu dot org,paulthomas2 at wanadoo dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18568
[Bug other/18559] apple's gcc-3.3 -fast causes bus error
--- Additional Comments From fang at csl dot cornell dot edu 2004-11-19 16:52 --- Subject: Re: apple's gcc-3.3 -fast causes bus error Thanks, found their bug-site, I'll pass it on to them. --- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-19 14:29 --- Not our bug, report it to Apple. Oh, by the way -fast enables -malign-nature which causes some structs to have different sizes and since libstdc++ is compiled normally that can cause problems. Try -fastcp (or -fastf) for C++ code instead. David Fang Computer Systems Laboratory Electrical Computer Engineering Cornell University http://www.csl.cornell.edu/~fang/ -- *gag* work in progress -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18559
[Bug fortran/18568] pointers in derived data types do not transmit shape of pointed to arrays - bug or non-standard feature?
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-19 18:09 --- Confirmed, reduced testcase: MODULE ints type, PUBLIC :: bar integer,pointer :: th(:) end type bar CONTAINS FUNCTION foo(b) TYPE( bar ),INTENT(IN) :: b integer :: foo(size(b%th ) ) end function foo END MODULE ints program size_test use ints end program size_test -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-on-valid-code, rejects- ||valid Last reconfirmed|-00-00 00:00:00 |2004-11-19 18:09:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18568
[Bug tree-optimization/18507] block_defs_stack varrray should not be GC'ed
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-19 18:22 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18507
[Bug rtl-optimization/8361] [3.3/3.4/4.0 regression] C++ compile-time performance regression
-- Bug 8361 depends on bug 18507, which changed state. Bug 18507 Summary: block_defs_stack varrray should not be GC'ed http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18507 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8361
[Bug tree-optimization/18507] block_defs_stack varrray should not be GC'ed
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-19 18:22 --- Subject: Bug 18507 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-11-19 18:22:00 Modified files: gcc: tree-flow.h tree-ssa-dom.c tree-into-ssa.c ChangeLog Log message: 2004-11-19 Andrew Pinski [EMAIL PROTECTED] PR tree-opt/18507 * tree-flow.h (tree2): Typedef because there is already a VEC(tree). Define a VEC(tree2) for head. (register_new_def): Change second argument to be a VEC(tree2). * tree-ssa-dom.c (block_defs_stack): Change to be a VEC(tree2). (tree_ssa_dominator_optimize): Initialize block_defs_stack with the VEC(tree2) function. Also free it before returning. (dom_opt_initialize_block): Use VEC_safe_push instead of VARRAY_PUSH_TREE for block_defs_stack. (restore_currdefs_to_original_value): Use VEC_length instead of VARRAY_ACTIVE_SIZE. VEC_pop instead of VARRAY_TOP_TREE/VARRAY_POP. (dom_opt_finalize_block): Use VEC_safe_push instead of VARRAY_PUSH_TREE for block_defs_stack. * tree-into-ssa.c (block_defs_stack): Change to be a VEC(tree2). (rewrite_initialize_block): Use VEC_safe_push instead of VARRAY_PUSH_TREE for block_defs_stack. (ssa_register_new_def): Likewise. (ssa_rewrite_initialize_block): Likewise. (rewrite_finalize_block): Use VEC_length instead of VARRAY_ACTIVE_SIZE. VEC_pop instead of VARRAY_TOP_TREE/VARRAY_POP. (ssa_rewrite_finalize_block): Likewise. (register_new_def): Change second argument to be a VEC(tree2). Use VEC_safe_push instead of VARRAY_PUSH_TREE. (rewrite_blocks): Initialize block_defs_stack with the VEC(tree2) function. Also free it before returning. (rewrite_ssa_into_ssa): Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-flow.h.diff?cvsroot=gccr1=2.66r2=2.67 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-dom.c.diff?cvsroot=gccr1=2.67r2=2.68 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-into-ssa.c.diff?cvsroot=gccr1=2.30r2=2.31 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.6416r2=2.6417 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18507
[Bug tree-optimization/13776] [4.0 Regression] [tree-ssa] Many C++ compile-time regression in 4.0-tree-ssa 040120
-- Bug 13776 depends on bug 18507, which changed state. Bug 18507 Summary: block_defs_stack varrray should not be GC'ed http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18507 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13776
[Bug tree-optimization/18557] Inefficient code generated by -ftree-vectorize on Alpha
--- Additional Comments From dorit at il dot ibm dot com 2004-11-19 18:24 --- (In reply to comment #5) (In reply to comment #2) Subject: Re: Inefficient code generated by -ftree-vectorize on Alpha On Fri, 2004-11-19 at 00:04 +, pinskia at gcc dot gnu dot org wrote: --- Additional Comments From pinskia at gcc dot gnu dot org 2004-11- 19 00:04 --- Confirmed. One issue is that we don't fold stuff: D.1061 = 8 - 1; D.1065 = 2 - 1; I expect these would go away with this patch: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01512.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18557
[Bug target/11793] [3.3 regression] ICE in extract_insn, at recog.c:2175 (const_vector's)
--- Additional Comments From oliver_stieber at yahoo dot co dot uk 2004-11-19 18:49 --- Still getting error with 3.3.4 compiling glibc. r/tmp/portage/glibc-2.3.4.20041021/work/build-i686-pc-linux-gnu-nptl/math/s_logb .o ) [2 S8 A64]))) -1 (nil) (expr_list:REG_EQUAL (const_double:DF -208943 [0x8375d410] 1.0270676 410069053019924467662349343299865723e+0 [0x0.8375d410a6db48p+1]) (nil))) ../sysdeps/ieee754/dbl-64/s_erf.c:303: internal compiler error: in extract_insn, at recog.c:2175 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11793
[Bug tree-optimization/18181] vectorizer: problem in the peeling mechanism in the presence of loop invariants that are used after the loop
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-19 19:39 --- Subject: Bug 18181 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-11-19 19:39:40 Modified files: gcc: ChangeLog tree-vectorizer.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg/vect: vect-85.c vect-86.c vect-87.c vect-88.c Log message: PR tree-opt/18181 * tree-vectorizer.c (slpeel_tree_peel_loop_to_edge): Peeling scheme changed to suppoer uses-after-loop and to void creating flow paths that shouldn't exist. (slpeel_update_phi_nodes_for_guard): Takes additional two arguments. Modified to fit the new peeling scheme. Avoid quadratic behavior. (slpeel_add_loop_guard): Takes additional argument. (slpeel_verify_cfg_after_peeling): New function. (vect_update_ivs_after_vectorizer): Takes additional argument. Updated documentation. Use 'exit-bb' instead of creating 'new-bb'. (rename_variables_in_bb): Don't update phis for BBs out of loop, to fit the new peeling scheme. (copy_phi_nodes): Function removed. Its functionality moved to update_phis_for_duplicate_loop. (slpeel_update_phis_for_duplicate_loop): Functionality of copy_phi_nodes moved here. Added documentation. Modified to fit the new peeling scheme. (slpeel_make_loop_iterate_ntimes): Setting loop-single_exit not not needed - done in slpeel_tree_peel_loop_to_edge. (slpeel_tree_duplicate_loop_to_edge_cfg): Debug printouts compacted. (vect_do_peeling_for_loop_bound): Add documentation. Call slpeel_verify_cfg_after_peeling. Call vect_update_ivs_after_vectorizer with additional argument. (vect_do_peeling_for_alignment): Call slpeel_verify_cfg_after_peeling. (vect_finish_stmt_generation): Avoid 80 column oveflow. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.6421r2=2.6422 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-vectorizer.c.diff?cvsroot=gccr1=2.34r2=2.35 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4620r2=1.4621 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/vect/vect-85.c.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/vect/vect-86.c.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/vect/vect-87.c.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/vect/vect-88.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18181
[Bug target/18383] [4.0 Regression] Cannot use assert in a dynamic library
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-19 19:43 --- The patch is still slightly wrong, the real way to fix it would be to add -lgcc and make sure that the static libgcc's sources are pritave_extern (aka hidden and like on linux is right now). -- What|Removed |Added Keywords|patch | Last reconfirmed|2004-11-08 21:06:21 |2004-11-19 19:43:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18383
[Bug libgcj/18135] gctest uses the installed libgcc_s on darwin
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-19 19:44 --- Confirmed via a clean tree build two days ago. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-11-19 19:44:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18135
[Bug libgcj/18135] gctest (boehm-gc) uses the installed libgcc_s on darwin
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-19 19:47 --- And the problem is that: TESTS_ENVIRONMENT = LD_LIBRARY_PATH=../../$(MULTIBUILDTOP)gcc only sets LD_LIBRARY_PATH instead of that and DYLD_LIBRARY_PATH but that rule is not quiet right anyways see PR 11412. -- What|Removed |Added BugsThisDependsOn||11412 Summary|gctest uses the installed |gctest (boehm-gc) uses the |libgcc_s on darwin |installed libgcc_s on darwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18135
[Bug target/18349] mmix-knuth-mmixware testsuite failure: gcc.dg/visibility-1.c (actually all) g++.dg/ext/visibility/*
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-19 20:05 --- Fixed by: 2004-11-19 Mark Mitchell [EMAIL PROTECTED] Joseph Myers [EMAIL PROTECTED] * lib/target-supports.exp (check_visibility_available): Really test the compiler. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18349
[Bug tree-optimization/18181] vectorizer: problem in the peeling mechanism in the presence of loop invariants that are used after the loop
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-19 20:14 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18181
[Bug tree-optimization/18557] Inefficient code generated by -ftree-vectorize on Alpha
--- Additional Comments From falk at debian dot org 2004-11-19 20:16 --- (In reply to comment #6) I expect these would go away with this patch: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01512.html Not quite. Code looks like this: f: and $16,4,$1 mov $31,$7 lda $6,64($31) cmpult $31,$1,$1 cmpeq $1,0,$8 lda $8,1($8) zapnot $8,15,$5 beq $5,$L4 mov $31,$3 mov $31,$4 .align 4 $L12: lda $3,1($3) s4addq $4,$16,$2 addl $31,$3,$4 stl $31,0($2) zapnot $4,15,$1 cmpule $5,$1,$1 beq $1,$L12 lda $1,64($31) addl $31,$4,$7 subl $1,$4,$6 $L4: cmpeq $5,64,$1 bne $1,$L15 lda $1,64($31) subq $1,$8,$1 zapnot $1,15,$23 srl $23,1,$1 addl $1,$1,$8 zapnot $8,15,$22 beq $22,$L8 s4addq $5,$16,$2 zapnot $1,15,$4 mov $31,$3 .align 4 $L10: lda $3,1($3) stq $31,0($2) lda $2,8($2) zapnot $3,15,$1 cmpule $4,$1,$1 beq $1,$L10 subl $6,$8,$6 addl $7,$8,$7 $L8: cmpeq $23,$22,$1 bne $1,$L15 mov $31,$2 .align 4 $L14: addl $2,$7,$1 subl $6,1,$6 lda $2,1($2) s4addq $1,$16,$1 stl $31,0($1) bne $6,$L14 $L15: ret The first branch can never be taken, and all sign extensions (sextl) and zero extensions (zapnot 15) are useless. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18557
Subtle MT problem with __gnu_cxx::hash_map
There's a subtle thread safety problem with hash_map that was found in our
testing recently. It's understood that operator[] is a non-const method since
it can insert an element into a container if one is not found with the given index.
In our case we were using operator[] to access a hash_map that had been fully
populated. Each index we were using did have an entry in the hash_map. So we
were accessing elements in the map with operator[] using multiple threads
thinking that this would be a thread safe, const operation. This is implied by
the statement simultaneous read accesses to to shared containers are safe in
the SGI STL user's guide (http://www.sgi.com/tech/stl/thread_safety.html).
This worked for a long time until we tried it on a hash_map with 389 elements.
The program crashed. A search through the source found that 389 is one of the
size values as which a hash_map will expand:
In ext/stl_hashtable.h (for GCC 3.3.4, ext/hashtable.h for GCC 3.4.3):
static const unsigned long __stl_prime_list[__stl_num_primes] =
{
53ul, 97ul, 193ul, 389ul, 769ul,
1543ul, 3079ul, 6151ul, 12289ul, 24593ul,
49157ul, 98317ul, 196613ul,393241ul,786433ul,
1572869ul,3145739ul,6291469ul, 12582917ul, 25165843ul,
50331653ul, 100663319ul, 201326611ul, 402653189ul, 805306457ul,
1610612741ul, 3221225473ul, 4294967291ul
};
Sure enough the problem happens with hash_tables of other sizes in this table.
The find_or_insert() method in stl_hashtable.h seems to call resize() before it
really needs to. The problem could be fixed by moving the call to resize to be
after the first return statement:
template class _Val, class _Key, class _HF, class _Ex, class _Eq, class _All
typename hashtable_Val,_Key,_HF,_Ex,_Eq,_All::reference
hashtable_Val,_Key,_HF,_Ex,_Eq,_All::find_or_insert(const value_type __obj)
{
resize(_M_num_elements + 1); // - FROM HERE
size_type __n = _M_bkt_num(__obj);
_Node* __first = _M_buckets[__n];
for (_Node* __cur = __first; __cur; __cur = __cur-_M_next)
if (_M_equals(_M_get_key(__cur-_M_val), _M_get_key(__obj)))
return __cur-_M_val;
// -- TO HERE
_Node* __tmp = _M_new_node(__obj);
__tmp-_M_next = __first;
_M_buckets[__n] = __tmp;
++_M_num_elements;
return __tmp-_M_val;
}
One could argue that find() should always used to access the hash_map, but using
operator[] is often more succinct and readable in complex code. The problem is
easy to fall into, difficult to diagnose, hard to reproduce (unless you know the
magic prime numbers) and apparently easy to fix (unless I'm missing something).
Could this be changed in the next release of the library? It might fix or
prevent some time bombs out in the field.
Thanks,
Paul Dubuc
[Bug c/18569] New: Call to inline function failed
The following code snippet just does not compile (it did in GCC
3.3.3)
Environment:
System: Linux spartacus 2.6.9 #1 Fri Nov 5 17:15:13 CET 2004 i686 pentium3 i386
GNU/Linux
Architecture: i686
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ../gcc-3.4.2/configure --prefix=/usr --libexecdir=/usr/lib
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --enable-languages=c,c++
How-To-Repeat:
21:20 spartacus:~ cat ts.c
#define INLINE inline __attribute__((always_inline))
static INLINE void blah(void);
int main(void) {
blah();
return 0;
}
static INLINE void blah(void) {
return;
}
21:21 spartacus:~ gcc ts.c -Wall
ts.c: In function
ain':
ts.c:3: sorry, unimplemented: inlining failed in call to 'blah':
function
body not available
ts.c:6: sorry, unimplemented: called from here
--- Additional Comments From jengelh at linux01 dot gwdg dot de 2004-11-19
20:25 ---
Fix:
This can be worked around by placing the function body of blah()
before any call to it.
--
Summary: Call to inline function failed
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jengelh at linux01 dot gwdg dot de
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=18569
Re: Subtle MT problem with __gnu_cxx::hash_map
On Nov 19, 2004, at 12:21 PM, Paul Dubuc wrote: There's a subtle thread safety problem with hash_map that was found in our testing recently. It's understood that operator[] is a non-const method since it can insert an element into a container if one is not found with the given index. In our case we were using operator[] to access a hash_map that had been fully populated. Each index we were using did have an entry in the hash_map. So we were accessing elements in the map with operator[] using multiple threads thinking that this would be a thread safe, const operation. This is implied by the statement simultaneous read accesses to to shared containers are safe in the SGI STL user's guide (http://www.sgi.com/tech/stl/thread_safety.html). But operator[] isn't read access. It's defined to be equivalent to a certain form of insert(). --Matt
[Bug target/18558] [4.0 Regression] ICE: in gen_lowpart_common, at emit-rtl.c:1078
--- Additional Comments From rth at gcc dot gnu dot org 2004-11-19 20:37 --- Mine. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18558
[Bug c/18569] Call to inline function failed
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-19 20:37 --- Invalid as the body is really not available at this point as we are not at unit at a time mode when compiling with -O0. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18569
Re: Subtle MT problem with __gnu_cxx::hash_map
Matt Austern wrote: But operator[] isn't read access. It's defined to be equivalent to a certain form of insert(). Not just insert() but find() too. So it's both read and write access. I think there's enough ambiguity to warrant the simple change I suggested if it's really feasible. -- Paul M. Dubuc Dept. 25 | Rm. 4349B | ext. 2692 http://www.purl.org/dubuc/cas/
[Bug bootstrap/18570] New: gnatmake fails to link on Mac OS X 10.3
I just tried a C and Ada-only bootstrap on Mac OS X 10.3.6 (starting from gcc 3.3, i.e. gcc version 3.3 20030304 (Apple Computer, Inc. build 1666) gcc version 3.3 20040312 (GNAT build 1650) ) for the first time. Linking gnatmake fails like this: ../../xgcc -B../../ -DIN_GCC `echo -O2 -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -fno-common |sed -e 's/-pedantic//g' -e 's/-Wtraditional//g'` -o ../../gnatmake b_gnatm.o a-except.o ctrl_c.o ali.o ali-util.o s-casuti.o alloc.o atree.o binderr.o butil.o casing.o csets.o debug.o elists.o einfo.o erroutc.o errutil.o err_vars.o fmap.o fname.o fname-uf.o fname-sf.o gnatmake.o gnatvsn.o hostparm.o interfac.o i-c.o i-cstrin.o krunch.o lib.o make.o makeusg.o makeutl.o mlib.o mlib-fil.o mlib-prj.o mlib-tgt.o mlib-utl.o namet.o nlists.o opt.o osint.o osint-m.o output.o prj.o prj-attr.o prj-attr-pm.o prj-com.o prj-dect.o prj-env.o prj-err.o prj-ext.o prj-nmsc.o prj-pars.o prj-part.o prj-proc.o prj-strt.o prj-tree.o prj-util.o rident.o s-exctab.o s-secsta.o s-stalib.o s-stoele.o scans.o scng.o sdefault.o sfn_scan.o s-purexc.o s-htable.o sinfo.o sinput.o sinput-c.o sinput-p.o snames.o stand.o stringt.o styleg.o stylesw.o system.o validsw.o switch.o swi! tch-m.o table.o targparm.o tempdir.o tree_io.o types.o uintp.o uname.o urealp.o usage.o widechar.o \ ../rts/libgnat.a ../../prefix.o ../../version.o link.o ../../../libiberty/libiberty.a /usr/bin/ld: Undefined symbols: __Unwind_fallback_frame_state_for collect2: ld returned 1 exit status make[4]: *** [../../gnatmake] Error 1 make[3]: *** [gnattools1] Error 2 make[2]: *** [gnattools-native] Error 2 make[1]: *** [all-target-libada] Error 2 This happens because __Unwind_fallback_frame_state_for is referenced in libgcc_eh.a and defined in libgcc.a, but gnatmake is linked with ../../collect2 -dynamic -arch ppc -weak_reference_mismatches non-weak -o ../../gnatmake -lcrt1.o ../../crt2.o -L../.. b_gnatm.o a-except.o ctrl_c.o ali.o ali-util.o s-casuti.o alloc.o atree.o binderr.o butil.o casing.o csets.o debug.o elists.o einfo.o erroutc.o errutil.o err_vars.o fmap.o fname.o fname-uf.o fname-sf.o gnatmake.o gnatvsn.o hostparm.o interfac.o i-c.o i-cstrin.o krunch.o lib.o make.o makeusg.o makeutl.o mlib.o mlib-fil.o mlib-prj.o mlib-tgt.o mlib-utl.o namet.o nlists.o opt.o osint.o osint-m.o output.o prj.o prj-attr.o prj-attr-pm.o prj-com.o prj-dect.o prj-env.o prj-err.o prj-ext.o prj-nmsc.o prj-pars.o prj-part.o prj-proc.o prj-strt.o prj-tree.o prj-util.o rident.o s-exctab.o s-secsta.o s-stalib.o s-stoele.o scans.o scng.o sdefault.o sfn_scan.o s-purexc.o s-htable.o sinfo.o sinput.o sinput-c.o sinput-p.o snames.o stand.o stringt.o styleg.o stylesw.o system.o validsw.o switch.o switch-m.o table.o targparm.o tempdir.o tree_io.o types.o uintp.o uname.o urealp.! o usage.o widechar.o ../rts/libgnat.a ../../prefix.o ../../version.o link.o ../../../libiberty/libiberty.a -lgcc -lgcc_eh -lSystem -lmx So there's no instance of libgcc.a to satisfy the reference from libgcc_eh.a. Adding -lgcc_eh to the link line allows the link to complete. Environment: System: Darwin nil 7.6.0 Darwin Kernel Version 7.6.0: Sun Oct 10 12:05:27 PDT 2004; root:xnu/xnu-517.9.4.obj~1/RELEASE_PPC Power Macintosh powerpc host: powerpc-apple-darwin7.6.0 build: powerpc-apple-darwin7.6.0 target: powerpc-apple-darwin7.6.0 configured with: /vol/gnu/src/gcc/gcc-dist/configure --prefix=/vol/gcc/obj/gnat/4.0.0/7.6.0 --with-local-prefix=/vol/gcc/obj/gnat/4.0.0/7.6.0 --disable-nls --enable-languages=c,ada How-To-Repeat: Bootstrap as described above. -- Summary: gnatmake fails to link on Mac OS X 10.3 Product: gcc Version: 0.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at techfak dot uni-bielefeld dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: powerpc-apple-darwin7.6.0 GCC host triplet: powerpc-apple-darwin7.6.0 GCC target triplet: powerpc-apple-darwin7.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18570
[Bug libstdc++/18571] New: document wstring/wfilebuf code conversions
Docs in this area nonexistent. Fix. -- Summary: document wstring/wfilebuf code conversions Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bkoz at gcc dot gnu 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=18571
[Bug libstdc++/18571] document wstring/wfilebuf code conversions
--- Additional Comments From bkoz at gcc dot gnu dot org 2004-11-19 21:39 --- Mine, fixing. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org |dot org | Severity|normal |enhancement Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18571
[Bug other/3386] [3.3/3.4/4.0 Regression] Undocumented target macros in 3.0
--- Additional Comments From mmitchel at gcc dot gnu dot org 2004-11-19 22:20 --- I've downgraded the priority and severity of this PR. This PR is certainly not critical severity; it doesn't stop people from using the compiler. It is also not high-priority; there will never be end-user complains about this. I've also once-again removed the target milestone, as we'll never hold up the release for this problem. -- What|Removed |Added Severity|critical|minor Priority|P1 |P3 Target Milestone|4.0.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3386
[Bug target/18329] [4.0 regression] mmix-knuth-mmixware testsuite failure: execute/920501-7.c
--- Additional Comments From mmitchel at gcc dot gnu dot org 2004-11-19 22:25 --- MMIX bugs are low-priority. -- What|Removed |Added Priority|P2 |P3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18329
[Bug libstdc++/17140] Floating point output is slow
--- Additional Comments From bkoz at gcc dot gnu dot org 2004-11-19 22:25 --- This patch applies, and passes regression testing on x86/linux. Now I can start to review it Paolo, any chance you can test this as well? -benjamin -- What|Removed |Added CC||pcarlini at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17140
[Bug rtl-optimization/18325] [4.0 regression] mmix-knuth-mmixware testsuite failure: gcc.c-torture/execute/20020227-1.c (change in behavior)
--- Additional Comments From mmitchel at gcc dot gnu dot org 2004-11-19 22:26 --- MMIX bugs are low-priority. -- What|Removed |Added Bug 18325 depends on bug 18324, which changed state. Bug 18324 Summary: [4.0 regression] mmix-knuth-mmixware testsuite failure: gcc.c-torture/execute/20010518-2.c execution, -O0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18324 What|Old Value |New Value Status|UNCONFIRMED |NEW Status|NEW |RESOLVED Resolution||FIXEDBug 18325 depends on bug 18324, which changed state. Bug 18324 Summary: [4.0 regression] mmix-knuth-mmixware testsuite failure: gcc.c-torture/execute/20010518-2.c execution, -O0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18324 What|Old Value |New Value Status|UNCONFIRMED |NEW Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18325
[Bug bootstrap/18570] gnatmake fails to link on Mac OS X 10.3
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-19 22:25 --- Oh, you have a ppc-darwin machine now, cool but I filed this couple weeks ago: PR 18217. *** This bug has been marked as a duplicate of 18217 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE Version|0.0 |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18570
[Bug ada/18217] [4.0 Regression] Ada Bootstrap failures on powerpc-darwin with undefined symbol (__Unwind_fallback_frame_state_for)
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-19 22:26 --- *** Bug 18570 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||ro at techfak dot uni- ||bielefeld dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18217
[Bug target/18346] [4.0 regression] mmix-knuth-mmixware testsuite failure: gcc.dg/trampoline-1.c
--- Additional Comments From mmitchel at gcc dot gnu dot org 2004-11-19 22:26 --- MMIX bugs are low-priority. -- What|Removed |Added Priority|P2 |P3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18346
[Bug c++/18492] [4.0 regression] mmix-knuth-mmixware testsuite failure: g++.old-deja/g++.other/thunk1.C
--- Additional Comments From mmitchel at gcc dot gnu dot org 2004-11-19 22:26 --- MMIX bugs are low-priority. -- What|Removed |Added Priority|P2 |P3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18492
[Bug rtl-optimization/18485] [4.0 regression] mmix-knuth-mmixware testsuite failure: g++.dg/lookup/forscope1.C g++.old-deja/g++.niklas/t132.C g++.old-deja/g++.other/singleton.C
--- Additional Comments From mmitchel at gcc dot gnu dot org 2004-11-19 22:26 --- MMIX bugs are low-priority. -- What|Removed |Added Priority|P2 |P3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18485
[Bug middle-end/18494] [4.0 regression] mmix-knuth-mmixware testsuite failure: gcc.c-torture/compile/structs.c (et al)
--- Additional Comments From mmitchel at gcc dot gnu dot org 2004-11-19 22:26 --- MMIX bugs are low-priority. -- What|Removed |Added Priority|P2 |P3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18494
[Bug target/18341] [4.0 regression] mmix-knuth-mmixware testsuite failure: gcc.dg/builtins-18.c
--- Additional Comments From mmitchel at gcc dot gnu dot org 2004-11-19 22:26 --- MMIX bugs are low-priority. -- What|Removed |Added Priority|P2 |P3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18341
[Bug target/18342] mmix-knuth-mmixware testsuite failure: gcc.dg/builtins-20.c
--- Additional Comments From mmitchel at gcc dot gnu dot org 2004-11-19 22:26 --- MMIX bugs are low-priority. -- What|Removed |Added Priority|P2 |P3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18342
[Bug rtl-optimization/18331] [4.0 regression] mmix-knuth-mmixware testsuite failure: execute/ieee/fp-cmp-8.c gcc.dg/20040625-1.c
--- Additional Comments From mmitchel at gcc dot gnu dot org 2004-11-19 22:26 --- MMIX bugs are low-priority. -- What|Removed |Added Priority|P2 |P3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18331
[Bug target/18330] [4.0 regression] mmix-knuth-mmixware testsuite failure: execute/comp-goto-2.c
--- Additional Comments From mmitchel at gcc dot gnu dot org 2004-11-19 22:26 --- MMIX bugs are low-priority. -- What|Removed |Added Priority|P2 |P3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18330
[Bug libstdc++/17140] Floating point output is slow
--- Additional Comments From pcarlini at suse dot de 2004-11-19 22:30 --- Sure, and *sorry* for the delay :-( I will do that over the weekend, both on ia64 and x86_64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17140
[Bug ada/18217] [4.0 Regression] Ada Bootstrap failures on powerpc-darwin with undefined symbol (__Unwind_fallback_frame_state_for)
--- Additional Comments From ro at techfak dot uni-bielefeld dot de 2004-11-19 22:33 --- Subject: Re: [4.0 Regression] Ada Bootstrap failures on powerpc-darwin with undefined symbol (__Unwind_fallback_frame_state_for) As a workaround, I've changed all instances of -lgcc -lgcc_eh in the specs file to -lgcc_eh -lgcc -lgcc_eh. With this change, the bootstrap got further along: ../../xgcc -c -I./ -I../rts -I. -I/vol/gnu/src/gcc/gcc-dist/gcc/ada -B../../ -O2 -g -O2 -gnatpg -gnata -I- /vol/gnu/src/gcc/gcc-dist/gcc/ada/makegpr.adb +===GNAT BUG DETECTED==+ | 4.0.0 20041119 (experimental) (powerpc-apple-darwin7.6.0) Bus error | | Error detected at makegpr.adb:4159:23| Program received signal EXC_BAD_ACCESS, Could not access memory. 0x004e9650 in initializer_zerop (init=0x4469dcc0) at /vol/gnu/src/gcc/gcc-dist/gcc/tree.c:5834 (gdb) where #0 0x004e9650 in initializer_zerop (init=0x4469dcc0) at /vol/gnu/src/gcc/gcc-dist/gcc/tree.c:5834 #1 0x004e97dc in initializer_zerop (init=0x4469dcc0) at /vol/gnu/src/gcc/gcc-dist/gcc/tree.c:5870 #2 0x004e97dc in initializer_zerop (init=0x4469dcc0) at /vol/gnu/src/gcc/gcc-dist/gcc/tree.c:5870 #3 0x004fb574 in assemble_variable (decl=0xc659a8, top_level=115, at_end=6317412, dont_output_data=1147788480) at /vol/gnu/src/gcc/gcc-dist/gcc/varasm.c:1706 #4 0x00503118 in rest_of_decl_compilation (decl=0x4469dcc0, top_level=6317412, at_end=12999080) at /vol/gnu/src/gcc/gcc-dist/gcc/passes.c:235 #5 0x00507bfc in expand_one_var (var=0x4469dcc0, toplevel=100 'd') at /vol/gnu/src/gcc/gcc-dist/gcc/cfgexpand.c:559 #6 0x005094ac in tree_expand_cfg () at /vol/gnu/src/gcc/gcc-dist/gcc/cfgexpand.c:791 #7 0x0024896c in execute_pass_list (pass=0x44698210) at /vol/gnu/src/gcc/gcc-dist/gcc/tree-optimize.c:511 #8 0x00248ca8 in tree_rest_of_compilation (fndecl=0x0) at /vol/gnu/src/gcc/gcc-dist/gcc/tree-optimize.c:643 #9 0x005330bc in cgraph_expand_function (node=0x44699880) at /vol/gnu/src/gcc/gcc-dist/gcc/cgraphunit.c:822 #10 0x0053407c in cgraph_optimize () at /vol/gnu/src/gcc/gcc-dist/gcc/cgraphunit.c:1689 #11 0x004d6528 in toplev_main (argc=12717220, argv=0xc265b4) at /vol/gnu/src/gcc/gcc-dist/gcc/toplev.c:985 #12 0x2584 in _start (argc=16, argv=0xb93c, envp=0xb980) at /SourceCache/Csu/Csu-47/crt.c:267 #13 0x8fe1a558 in __dyld__dyld_start () The file compiles without problems at -O0. Is this a known bug, too? Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18217
[Bug target/18342] mmix-knuth-mmixware testsuite failure: gcc.dg/builtins-20.c
-- What|Removed |Added Target Milestone|4.0.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18342
[Bug c++/18556] [4.0 Regression] C++ debug is broken
--- Additional Comments From hjl at lucon dot org 2004-11-19 22:50 ---
Does this patch
--- toplev.c.bar2004-11-16 10:13:18.0 -0800
+++ toplev.c2004-11-19 14:50:09.493493596 -0800
@@ -818,6 +818,13 @@ check_global_declarations (tree *vec, in
for (i = 0; i len; i++)
{
decl = vec[i];
+
+ if (TREE_CODE (decl) == VAR_DECL TREE_STATIC (decl)
+ ! TREE_ASM_WRITTEN (decl))
+ /* Cancel the RTL for this decl so that, if debugging info
+ output for global variables is still to come, this one
+ will be omitted. */
+ DECL_IGNORED_P (decl) = 1;
/* Warn about any function
declared static but not defined.
make any senses? It makes the failed testcase to pass.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18556
[Bug c++/18556] [4.0 Regression] C++ debug is broken
--- Additional Comments From mark at codesourcery dot com 2004-11-19 22:54
---
Subject: Re: [4.0 Regression] C++ debug is broken
hjl at lucon dot org wrote:
--- Additional Comments From hjl at lucon dot org 2004-11-19 22:50
---
Does this patch
--- toplev.c.bar2004-11-16 10:13:18.0 -0800
+++ toplev.c2004-11-19 14:50:09.493493596 -0800
@@ -818,6 +818,13 @@ check_global_declarations (tree *vec, in
for (i = 0; i len; i++)
{
decl = vec[i];
+
+ if (TREE_CODE (decl) == VAR_DECL TREE_STATIC (decl)
+ ! TREE_ASM_WRITTEN (decl))
+ /* Cancel the RTL for this decl so that, if debugging info
+ output for global variables is still to come, this one
+ will be omitted. */
+ DECL_IGNORED_P (decl) = 1;
/* Warn about any function
declared static but not defined.
make any senses? It makes the failed testcase to pass.
It makes much more sense that what was there before, although clearly
the comment is wrong. I've not yet worked out whether this is the right
approach or not, though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18556
[Bug ada/18217] [4.0 Regression] Ada Bootstrap failures on powerpc-darwin with undefined symbol (__Unwind_fallback_frame_state_for)
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-19 23:10 --- Created an attachment (id=7569) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7569action=view) patch which moves darwin-fallback.o to the correct static library Using your hint for -lgcc -lgcc_eh -lgcc, well the patch which would do that not be the correct fix but I figured out what was going on. Oh, by the way the ICE you got is not known yet, please file it seperately. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18217
[Bug ada/18217] [4.0 Regression] Ada Bootstrap failures on powerpc-darwin with undefined symbol (__Unwind_fallback_frame_state_for)
--- Additional Comments From ro at techfak dot uni-bielefeld dot de 2004-11-19 23:12 --- Subject: Re: [4.0 Regression] Ada Bootstrap failures on powerpc-darwin with undefined symbol (__Unwind_fallback_frame_state_for) pinskia at gcc dot gnu dot org writes: Using your hint for -lgcc -lgcc_eh -lgcc, well the patch which would do that not be the correct fix but I figured out what was going on. Fine. I said the change above was a hack, and I wasn't sure whether it is the correct solution. Oh, by the way the ICE you got is not known yet, please file it seperately. Ok, will do. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18217
[Bug ada/17986] [4.0 Regression] Compile error for make.adb breaks bootstrap
--- Additional Comments From ro at gcc dot gnu dot org 2004-11-19 23:17 --- This problems bites me on several platforms (sparc-sun-solaris10, i386-sun-solaris2.10, powerpc-apple-darwin7.6.0). Perhaps you could ping your patch so this gets fixed? Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17986
[Bug target/18217] [4.0 Regression] Ada Bootstrap failures on powerpc-darwin with undefined symbol (__Unwind_fallback_frame_state_for)
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-19 23:19 --- Patch posted here: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01621.html. -- What|Removed |Added Component|ada |target GCC target triplet||ppc-darwin Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18217
[Bug c++/16882] [4.0 Regression] overloading confused by const vector arguments
--- Additional Comments From mmitchel at gcc dot gnu dot org 2004-11-19 23:23 --- Paolo, this patch is OK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16882
[Bug ada/18572] New: Bus error compiling makegpr.adb on Mac OS X 10.3
As already described in PR ada/18217, while building gnattools gnat1 gets a bus error compiling makegpr.adb: $ ../../xgcc -c -I./ -I../rts -I. -I/vol/gnu/src/gcc/gcc-dist/gcc/ada -B../../ -O2 -g -O2 -gnatpg -gnata -I- /vol/gnu/src/gcc/gcc-dist/gcc/ada/makegpr.adb +===GNAT BUG DETECTED==+ | 4.0.0 20041119 (experimental) (powerpc-apple-darwin7.6.0) Bus error | | Error detected at makegpr.adb:4159:23| Program received signal EXC_BAD_ACCESS, Could not access memory. 0x004e9650 in initializer_zerop (init=0x4469dcc0) at /vol/gnu/src/gcc/gcc-dist/gcc/tree.c:5834 (gdb) where #0 0x004e9650 in initializer_zerop (init=0x4469dcc0) at /vol/gnu/src/gcc/gcc-dist/gcc/tree.c:5834 #1 0x004e97dc in initializer_zerop (init=0x4469dcc0) at /vol/gnu/src/gcc/gcc-dist/gcc/tree.c:5870 #2 0x004e97dc in initializer_zerop (init=0x4469dcc0) at /vol/gnu/src/gcc/gcc-dist/gcc/tree.c:5870 #3 0x004fb574 in assemble_variable (decl=0xc659a8, top_level=115, at_end=6317412, dont_output_data=1147788480) at /vol/gnu/src/gcc/gcc-dist/gcc/varasm.c:1706 #4 0x00503118 in rest_of_decl_compilation (decl=0x4469dcc0, top_level=6317412, at_end=12999080) at /vol/gnu/src/gcc/gcc-dist/gcc/passes.c:235 #5 0x00507bfc in expand_one_var (var=0x4469dcc0, toplevel=100 'd') at /vol/gnu/src/gcc/gcc-dist/gcc/cfgexpand.c:559 #6 0x005094ac in tree_expand_cfg () at /vol/gnu/src/gcc/gcc-dist/gcc/cfgexpand.c:791 #7 0x0024896c in execute_pass_list (pass=0x44698210) at /vol/gnu/src/gcc/gcc-dist/gcc/tree-optimize.c:511 #8 0x00248ca8 in tree_rest_of_compilation (fndecl=0x0) at /vol/gnu/src/gcc/gcc-dist/gcc/tree-optimize.c:643 #9 0x005330bc in cgraph_expand_function (node=0x44699880) at /vol/gnu/src/gcc/gcc-dist/gcc/cgraphunit.c:822 #10 0x0053407c in cgraph_optimize () at /vol/gnu/src/gcc/gcc-dist/gcc/cgraphunit.c:1689 #11 0x004d6528 in toplev_main (argc=12717220, argv=0xc265b4) at /vol/gnu/src/gcc/gcc-dist/gcc/toplev.c:985 #12 0x2584 in _start (argc=16, argv=0xb93c, envp=0xb980) at /SourceCache/Csu/Csu-47/crt.c:267 #13 0x8fe1a558 in __dyld__dyld_start () The file compiles without problems at -O0. With this change and the workaround from PR ada/18217, I was able to finish a C and Ada bootstrap. make check currently running. Environment: System: Darwin nil 7.6.0 Darwin Kernel Version 7.6.0: Sun Oct 10 12:05:27 PDT 2004; root:xnu/xnu-517.9.4.obj~1/RELEASE_PPC Power Macintosh powerpc host: powerpc-apple-darwin7.6.0 build: powerpc-apple-darwin7.6.0 target: powerpc-apple-darwin7.6.0 configured with: /vol/gnu/src/gcc/gcc-dist/configure --prefix=/vol/gcc/obj/gnat/4.0.0/7.6.0 --with-local-prefix=/vol/gcc/obj/gnat/4.0.0/7.6.0 --disable-nls --enable-languages=c,ada How-To-Repeat: Bootstrap as described above. -- Summary: Bus error compiling makegpr.adb on Mac OS X 10.3 Product: gcc Version: 0.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at techfak dot uni-bielefeld dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: powerpc-apple-darwin7.6.0 GCC host triplet: powerpc-apple-darwin7.6.0 GCC target triplet: powerpc-apple-darwin7.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18572
[Bug ada/18572] [4.0 Regression] Bus error compiling makegpr.adb on Mac OS X 10.3
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||build, ice-on-valid-code Summary|Bus error compiling |[4.0 Regression] Bus error |makegpr.adb on Mac OS X 10.3|compiling makegpr.adb on Mac ||OS X 10.3 Target Milestone|--- |4.0.0 Version|0.0 |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18572
[Bug ada/18572] [4.0 Regression] Bus error compiling makegpr.adb on Mac OS X 10.3
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-19 23:35 --- Hmm, I did get a different ICE before on this file when I was trying to confirm PR 18237 so it might be the same bug, I will let my build go and see what happens. -- What|Removed |Added BugsThisDependsOn||18237 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18572
[Bug c++/18556] [4.0 Regression] C++ debug is broken
--- Additional Comments From hjl at lucon dot org 2004-11-19 23:39 --- The symptom is that debug information references the symbol which is omittted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18556
[Bug libobjc/18573] New: libobjc abuses posix thread ids
libobjc currently returns the threads id in multiple places, and assumes that it can return NULL as an identifier for no thread but posix thread id's are opqaque, hurd uses a thread id of 0 for the first thread. i'll attach a patch which while still not correct, should show the problem areas, and has worked for linux and hurd. -- Summary: libobjc abuses posix thread ids Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: libobjc AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ratmice at yahoo dot com CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i585-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18573
[Bug libobjc/18573] libobjc abuses posix thread ids
--- Additional Comments From ratmice at yahoo dot com 2004-11-19 23:49 --- Created an attachment (id=7570) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7570action=view) hacky patch which changes No thread identifier from 0 to -1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18573
[Bug libobjc/18573] libobjc abuses posix thread ids
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20 00:02 --- Confirmed. Note this patch does not fix the gthr-* file in the gcc directory which are used when building the compiler and libobjc together. (__gthread_objc_thread_detach is the function in gthr-*) Does anyone know an standard invalid thread id. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-11-20 00:02:09 date|| Version|unknown |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18573
[Bug bootstrap/18574] New: bootstrap comprison failed
With gcc 4.0 from CVS at Sat Nov 20 00:13:50 UTC 2004, I got Bootstrap comparison failure! ./fold-const.o differs cp/decl.o differs make[3]: *** [gnucompare] Error 1 make[3]: Leaving directory `/export/build/gnu/gcc/build-x86_64-linux/gcc' make[2]: *** [bootstrap] Error 2 The differences are in debug sections. -- Summary: bootstrap comprison failed Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18574
[Bug libobjc/18575] New: objc_class subclass_list and sibling_class not filled out after dlopen
after dlopen on a shared library with objc classes __objc_resolve_class_links() isn't called until an object is sent a message for the first time or a class poses as another class. i currently call this private function after loading them, but not sure if it could be done in the ctor (if there is a way to do this without traversing the class list twice?) -- Summary: objc_class subclass_list and sibling_class not filled out after dlopen Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: libobjc AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ratmice at yahoo dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18575
[Bug libobjc/18575] objc_class subclass_list and sibling_class not filled out after dlopen
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20 01:25 --- Confirmed (I had the testcase for this before). -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-11-20 01:25:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18575
[Bug driver/7516] Ambiguous driver behaviour with -shared -static cmd line options combination
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20 01:28 --- I and some others think this should be rejected and the documentation changed. -- What|Removed |Added Last reconfirmed|2004-08-21 02:14:35 |2004-11-20 01:28:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7516
[Bug ada/18572] [4.0 Regression] Bus error compiling makegpr.adb on Mac OS X 10.3
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20 03:12 --- I cannot even get even passed stage1 anymore: gcc -c -g -no-cpp-precomp -DHAVE_DESIGNATED_INITIALIZERS=0 -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -gnatpg -gnata -I- -I. -Iada -I/Users/pinskia/src/local2/gcc/gcc/ ada /Users/pinskia/src/local2/gcc/gcc/ada/stylesw.adb -o ada/stylesw.o /Users/pinskia/src/local2/gcc/gcc/ada/stylesw.adb:53:07: Style_Check_Subprogram_Order is undefined (more references follow) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18572
[Bug preprocessor/18102] darwin framework header search depends on order of options
--- Additional Comments From ratmice at yahoo dot com 2004-11-20 04:16 --- posted a patch here http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01637.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18102
[Bug tree-optimization/18576] New: missing jump threading because of type changes
struct loop
{
int depth;
struct loop **pred;
};
static __inline__ unsigned char
flow_loop_nested_p (const struct loop *outer, const struct loop *loop)
{
return (loop-depth outer-depth
loop-pred[outer-depth] == outer);
}
unsigned char
flow_bb_inside_loop_p (const struct loop *loop, const struct loop *source_loop)
{
return loop == source_loop || flow_loop_nested_p (loop, source_loop);
}
In .64.final_cleanup:
L2:;
iftmp.0 = 1;
goto bb 5 (L14);
L4:;
iftmp.0 = 0;
L14:;
if ((unsigned char) (int) (unsigned char) iftmp.0 != 0) goto L8; else goto
L7;
See miss this jump threading (in fact we miss it on the RTL level also).
We do get better code already on the tree-cleanup-branch but that is because of
my rewrite of PHI-OPT
for that branch we get:
L12:;
iftmp.0 = 0;
goto bb 5 (L4);
L1:;
iftmp.0 = (int) !(loop != *(source_loop-pred + (struct loop * *) ((unsigned
int) D.1160 * 4)));
L4:;
iftmp.1 = (int) ((unsigned char) (int) (unsigned char) iftmp.0 != 0);
--
Summary: missing jump threading because of type changes
Product: gcc
Version: 4.0.0
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
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18576
[Bug tree-optimization/18576] missing jump threading because of type changes
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20 06:37 --- The corresponding asm for the tcb: cmpw cr7,r3,r4 mr r11,r3 li r10,0 li r3,1 beqlr- cr7 lwz r0,0(r11) lwz r2,0(r4) slwi r9,r0,2 cmpw cr7,r2,r0 ble- cr7,L7 lwz r2,4(r4) lwzx r0,r9,r2 xor r10,r11,r0 subfic r2,r10,0 adde r10,r2,r10 L7: mr r3,r10 blr the mainline (which is much worse): cmpw cr7,r3,r4 li r10,0 beq- cr7,L2 lwz r0,0(r3) li r11,1 lwz r2,0(r4) slwi r9,r0,2 cmpw cr7,r2,r0 bgt- cr7,L12 L4: li r11,0 L7: cmpwi cr7,r11,0 bne- cr7,L2 mr r3,r10 blr L12: lwz r2,4(r4) lwzx r0,r9,r2 cmpw cr7,r3,r0 bne+ cr7,L4 b L7 L2: li r10,1 mr r3,r10 blr -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18576
[Bug tree-optimization/18576] missing jump threading because of type changes
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20 06:43 --- Oh, even though the asm is fixed on the tcb we are still missing it on the tree level. By the way I noticed this while trying to speedup flow_bb_inside_loop_p in the first place. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18576
RFC822/M400 Mail Network -- Delivery Report
Not delivered to: [EMAIL PROTECTED] bad address Original-Envelope-Id: in*vsnl*rfc987;419ee9ca43a5000mimey2k X400-Content-Identifier: 041120122258+053 Reporting-MTA: x400; /ADMD=VSNL/C=IN DSN-Gateway: smtp; terminator1.vsnl.net.in Final-Recipient: rfc822; [EMAIL PROTECTED] Action: failed Diagnostic-Code: x400; 1 0 Status: 5.1.1 Last-Attempted-Date: 20 Nov 2004 12:09 +0530
