[Bug tree-optimization/18438] vectorizer failed for vector matrix multiplication
--- Comment #3 from irar at il dot ibm dot com 2006-09-19 07:10 --- t.c:20: note: not vectorized: mixed data-types t.c:20: note: can't determine vectorization factor. Removing flags[i] = true; Multiple data-types vectorization is already supported in the autovect branch, and the patches for mainline (starting from http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00941.html) will be committed as soon as 4.3 is open. we get: t.c:20: note: not consecutive access t.c:20: note: not vectorized: complicated access pattern. Vectorization of strided accesses is also already implemented in the autovect branch (and will be committed to the mainline 4.3). However, this case contains stores with gaps (stores to opoints[i][0], opoints[i][1], and opoints[i][2], without a store to opoints[i][3]), and only loads with gaps are currently supported. Therefore, this loop will be vectorizable in the autovect branch (and soon in the mainline 4.3) if a store to opoints[i][3] is added. Ira -- irar at il dot ibm dot com changed: What|Removed |Added CC||irar at il dot ibm dot com Last reconfirmed|2005-12-21 03:49:03 |2006-09-19 07:10:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18438
[Bug tree-optimization/19049] not vectorizing a fortran loop
--- Comment #7 from irar at il dot ibm dot com 2006-09-19 07:29 --- Even though vectorization of strided accesses is already implemented in the autovect branch (and will be committed to the mainline 4.3), this case contains a store with a gap (store to a[i] without a store to a[i-1]), and such stores are not supported (the current implementation supports only loads with gaps). Note, however, that adding a store to a[i-1] will create a data dependence in the loop. Ira -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19049
[Bug c++/29016] [4.2 Regression] tree check: expected class 'expression', have 'exceptional' (baselink) in get_base_var, at ipa-utils.c:224
--- Comment #8 from micis at gmx dot de 2006-09-19 08:17 --- The patch in comment #5 fixes the testcases but a make bootstrap ; make check (with only C/C++) results in two new regressions: WARNING: program timed out. FAIL: g++.dg/opt/pr24665.C (test for excess errors) FAIL: gcc.c-torture/execute/20050929-1.c compilation, -O1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29016
[Bug ada/28953] Ada: Documentation for gprmake is missing
--- Comment #2 from charlet at gcc dot gnu dot org 2006-09-19 08:47 --- gprmake was a beta tool never documented, which probably should not have been put in the first place, so instead I'll likely remove it at some point, since in any case, gprmake does not really belong in the ada directory since it's a multi-language tool. Arno -- charlet at gcc dot gnu dot org changed: What|Removed |Added CC|charlet at adacore dot com | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28953
[Bug c++/29136] New: using declaration misinterpreted in classes
The following program should return 1 when executed:
struct A {
virtual int f() {return 1;}
};
struct B : virtual A {
virtual int f() {return 0;}
};
struct C : B , virtual A {
using A::f;
};
int
main () {
C c;
return c.f () + c.C::f ();
}
It actually returns 2.
The C++ standard section 10.3 shows the example which somewhat matches the code
above. The 'c.f()' is supposed to call 'B::f' and the 'c.C::f()' is supposed
to call 'A::f'. In fact, both call 'A::f'.
--
Summary: using declaration misinterpreted in classes
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andrew dot stubbs at st dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29136
[Bug c++/29136] using declaration misinterpreted in classes
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-19 09:41 --- This is a dup of bug 11750, it was not hard to find that bug. Anyways the problem here is that we still use mostly the old ARM style using semantics instead of the standard defined ones. *** This bug has been marked as a duplicate of 11750 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29136
[Bug c++/11750] Incorrect virtual method invoked for class hierarchy w/ virtual bases
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-19 09:41 --- *** Bug 29136 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||andrew dot stubbs at st dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11750
[Bug fortran/29097] !$ include 'omp_lib.h' does not work
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||09/msg00795.html Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-19 10:27:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29097
[Bug c++/29138] New: access declarations don't work for classes
class A
{
public:
int i;
class A1
{
int j;
};
};
class B : private A
{
public:
A::i;
A::A1;
};
void
f ()
{
B b;
b.i = 1;
B::A1 a1;
}
The above program does not compile with the following messages:
t.cpp:15: error: declaration does not declare anything
t.cpp: In function void f():
t.cpp:6: error: class A::A1 is inaccessible
t.cpp:23: error: within this context
The C++ standard section 11.3 talks about access declarators. It does not
explicitly say that inner classes can be used this way, but nor does it say
they cannot. Note that the integer `i' works fine with the same idiom.
--
Summary: access declarations don't work for classes
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andrew dot stubbs at st dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29138
[Bug fortran/29101] Memory leak in gfortran
--- Comment #9 from pault at gcc dot gnu dot org 2006-09-19 11:05 --- Subject: Bug 29101 Author: pault Date: Tue Sep 19 11:04:55 2006 New Revision: 117053 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117053 Log: 2006-09-19 Paul Thomas [EMAIL PROTECTED] Steven Bosscher [EMAIL PROTECTED] PR fortran/29101 * trans-stmt.c (gfc_trans_character_select): Store the label from select_string and then clean up any temporaries from the conversion of the select expression, before branching to the selected case. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-stmt.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29101
[Bug c/29129] [4.2 Regression] Strictly conforming code rejected
--- Comment #2 from joseph at codesourcery dot com 2006-09-19 11:10 --- Subject: Re: New: Strictly conforming code rejected On Mon, 18 Sep 2006, neil at gcc dot gnu dot org wrote: Compile the following with -std=c99 -pedantic-errors void f(unsigned int [*]); foo.c:1: error: '[*]' not allowed in other than a declaration As the diagnostic indicates, unsigned int [*] is not a declaration with function prototype scope but a type name. Feel free to submit a DR regarding the exact meaning of can only be used in declarations with function prototype scope. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29129
[Bug ada/29127] gnatchop-gcc: installation problem, executable not found
--- Comment #5 from schwab at suse dot de 2006-09-19 11:19 --- Doesn't change anything either. I don't think this function is ever called anyway. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29127
[Bug fortran/29101] Memory leak in gfortran
--- Comment #10 from pault at gcc dot gnu dot org 2006-09-19 11:24 --- Subject: Bug 29101 Author: pault Date: Tue Sep 19 11:24:44 2006 New Revision: 117054 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117054 Log: 2006-09-19 Paul Thomas [EMAIL PROTECTED] Steven Bosscher [EMAIL PROTECTED] PR fortran/29101 * trans-stmt.c (gfc_trans_character_select): Store the label from select_string and then clean up any temporaries from the conversion of the select expression, before branching to the selected case. Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/trans-stmt.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29101
[Bug fortran/29101] Memory leak in gfortran
--- Comment #11 from pault at gcc dot gnu dot org 2006-09-19 11:26 --- Thanks to Steven's intervention, I can declare this bug well and truly closed. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29101
[Bug target/28946] assembler shifts set the flag ZF, no need to re-test to zero
--- Comment #14 from uros at kss-loka dot si 2006-09-19 11:31 --- Fixed everywhere. -- uros at kss-loka dot si changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.0.0 3.0.4 3.2.3 3.3.3 |3.0.4 3.2.3 3.3.3 Known to work|2.95.3 4.2.0 4.1.2 |2.95.3 4.2.0 4.1.2 4.0.4 Resolution||FIXED Summary|[4.0 Only] assembler shifts |assembler shifts set the |set the flag ZF, no need to |flag ZF, no need to re-test |re-test to zero |to zero http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28946
[Bug c++/29139] New: GCC produces wrong code with SSE / inline functions
Output of gcc -v: Using built-in specs. Target: i686-pc-cygwin Configured with: ../../source/gcc-4.1.1/configure --enable-threads=posix --enable-languages=c,c++ --disable-win32-registry Thread model: posix gcc version 4.1.1 I wrote a Vector class that I wanted to optimize by using some inline assembly with SSE instructions. I noticed that with certain optimizations on, GCC version 4.1.1 produces wrong code. The source code consists of my Vector class and some test code. When I compile this with the following command line I get the error: g++ -Wall -O2 -msse -finline-functions gccbug.cpp -o gccbug Output of the program: Start FAILED: expected (1.5;3;4.5) but value is (1;3;4.5): bug in operator* FAILED: expected (1.5;3;4.5) but value is (1;3;4.5): bug in operator* FAILED: expected (0.5;1;1.5) but value is (1;1;1.5): bug in operator/ FAILED: expected (1.5;3;4.5) but value is (1;3;4.5): bug in operator* FAILED: expected (1.5;3;4.5) but value is (1;3;4.5): bug in operator* FAILED: expected (0.5;1;1.5) but value is (1;1;1.5): bug in operator/ Finished in 14338932 ticks Ther are some computations with vectors, and when I compile it with these settings, there are errors in the compilation. Note that the first element of the result vector is 1 instead of 1.5 (for the multiplication) or 0.5 (for the division). When I compile this code with different options, for example: 1. Without -msse: g++ -Wall -O2 -finline-functions gccbug.cpp -o gccbug 2. Without -finline-functions: g++ -Wall -O2 -msse gccbug.cpp -o gccbug Then the program works correctly! Conclusion: GCC produces wrong code with this combination of optimization options. -- Summary: GCC produces wrong code with SSE / inline functions Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jespdj at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29139
[Bug c++/29139] GCC produces wrong code with SSE / inline functions
--- Comment #1 from jespdj at hotmail dot com 2006-09-19 11:33 --- Created an attachment (id=12294) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12294action=view) Source code that demonstrates the bug This is the source code that demonstrates bug 29139. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29139
[Bug c++/29139] GCC produces wrong code with SSE / inline functions
--- Comment #2 from jespdj at hotmail dot com 2006-09-19 11:34 --- Created an attachment (id=12295) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12295action=view) Precompiled source (*.ii) Precompiled code for gccbug.cpp of bug 29139. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29139
[Bug fortran/29101] Memory leak in gfortran
--- Comment #12 from paulthomas2 at wanadoo dot fr 2006-09-19 11:56 --- Subject: Re: Memory leak in gfortran steven at gcc dot gnu dot org wrote: --- Comment #8 from steven at gcc dot gnu dot org 2006-09-18 22:35 --- Not fixed just yet. Steven, I put it to rights this time. Thanks for your help. Can I lean on you in future, please? I have been talking to myself of late. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29101
[Bug ada/28716] Ada: Bind_Socket doesn't bind to specified address
--- Comment #3 from msimonides at power dot com dot pl 2006-09-19 12:11 --- That's the solution we have applied. I've recompiled gnat-gpl-3.4.6 with your patch and it works as expected. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28716
[Bug c/29140] New: optimization -O2/-O3/-Os generate wrong instruction order
Hello,
I'm using gcc-4.1.1, built into an EABI tool chain with glibc-2.4 and
binutils-2.16.92.
I have a Fixed-to-Float transition program shown as below. But it can only work
with -O1 option. -O2/-O3/-Os are all failed.
% cat CTL_Math.c
typedef float CTLFLOAT;
typedef int CTLFIXED;
typedef int CTLI32;
typedef unsigned int CTLU32;
inline CTLFLOAT _CTL_Fixed2Float( CTLFIXED In )
{
CTLI32 lm = In;
CTLI32 tm = lm;
CTLI32 le;
CTLU32 bits;
CTLI32 man;
if (0 == In) return 0;
if (tm 0)
tm = -tm;
// determine shift necessary to move radix to the 22-bit position
le = CTL_FASTFLOAT_MANTISSA_LEADINGZEROS - (CTLI32)(CLZ(tm));
if (le = 0)
lm = le;
else
lm = -le;
// le = le + (CTL_FASTFLOAT_MANTISSA_BITS-17);
le += 5;
if (0==lm) le = 0;
bits = ((CTLI32)(le + 127) 0x00FF) 23;
man = lm;
if (lm 0)
{
man = -man;
bits |= 0x8000;
}
man = man CTL_FASTFLOAT_IEEE_BITDIF_MANTISSA;
bits |= man 0x007F;
return *(CTLFLOAT*)bits;
}
I compiled it with following command.
% arm-iwmmxt-linux-gnueabi-gcc -O1 -Wall -mcpu=xscale -mtune=xscale
-mabi=aapcs-linux -c CTL_Math.c -o CTL_Math.o1
% arm-iwmmxt-linux-gnueabi-gcc -O2 -Wall -mcpu=xscale -mtune=xscale
-mabi=aapcs-linux -c CTL_Math.c -o CTL_Math.o2
I disassembled the object file and found the instruction order was different
between -O1 and -O2. With -O2 option, it seems GCC pull in 'ldr r0, [sp,
#4]', which will only get an obsolete r0. So the return value is incorrect. The
disassembly result is as below.
% arm-iwmmxt-linux-gnueabi-objdump -d CTL_Math.o1 o1
% arm-iwmmxt-linux-gnueabi-objdump -d CTL_Math.o2 o2
% vimdiff o1 o2
0564 _CTL_Fixed2Float: |0560
_CTL_Fixed2Float:
564: e92d4010stmdb sp!, {r4, lr} | 560:
e92d4010stmdb sp!, {r4, lr}
568: e24dd008sub sp, sp, #8 ; 0x8 | 564:
e2504000subsr4, r0, #0 ; 0x0
56c: e2504000subsr4, r0, #0 ; 0x0 | 568:
e24dd008sub sp, sp, #8 ; 0x8
570: 03a0moveq r0, #0 ; 0x0 | 56c:
03a02000moveq r2, #0 ; 0x0
574: 0a19beq 5e0 _CTL_Fixed2Float+0x7c | 570:
1a02bne 580 _CTL_Fixed2Float+0x20
578: e0240fc4eor r0, r4, r4, asr #31 | 574:
e1a2mov r0, r2
57c: e0400fc4sub r0, r0, r4, asr #31 | 578:
e28dd008add sp, sp, #8 ; 0x8
580: ebfebl 0 E3D_CLZ | 57c:
e8bd8010ldmia sp!, {r4, pc}
584: e270200arsbsr2, r0, #10 ; 0xa | 580:
e0240fc4eor r0, r4, r4, asr #31
588: 51a00254movpl r0, r4, asr r2 | 584:
e0400fc4sub r0, r0, r4, asr #31
58c: 42623000rsbmi r3, r2, #0 ; 0x0 | 588:
ebfebl 0 E3D_CLZ
590: 41a00314movmi r0, r4, lsl r3 | 58c:
e270200arsbsr2, r0, #10 ; 0xa
594: e350cmp r0, #0 ; 0x0 | 590:
42623000rsbmi r3, r2, #0 ; 0x0
598: 03a035femoveq r3, #1065353216 ; 0x3f80| 594:
41a00314movmi r0, r4, lsl r3
59c: 058d3004streq r3, [sp, #4]| 598:
51a00254movpl r0, r4, asr r2
5a0: 03a0moveq r0, #0 ; 0x0 | 59c:
e350cmp r0, #0 ; 0x0
5a4: 0a06beq 5c4 _CTL_Fixed2Float+0x60 | 5a0:
03a035femoveq r3, #1065353216 ; 0x3f80
5a8: e2823084add r3, r2, #132; 0x84 | 5a4:
058d3004streq r3, [sp, #4]
5ac: e20330ffand r3, r3, #255; 0xff | 5a8:
0a0cbeq 5e0 _CTL_Fixed2Float+0x80
5b0: e1a03b83mov r3, r3, lsl #23 | 5ac:
e2823084add r3, r2, #132; 0x84
5b4: e58d3004str r3, [sp, #4]| 5b0:
e20330ffand r3, r3, #255; 0xff
5b8: b260rsblt r0, r0, #0 ; 0x0 | 5b4:
e1a02b83mov r2, r3, lsl #23
5bc: b3833102orrlt r3, r3, #-2147483648; 0x| 5b8:
b2603000rsblt r3, r0, #0 ; 0x0
5c0: b58d3004strlt r3, [sp, #4]| 5bc:
a1a03100movge r3, r0, lsl #2
5c4: e3a02502mov
[Bug c/29140] optimization -O2/-O3/-Os generate wrong instruction order
--- Comment #1 from mingqiao dot wu at gmail dot com 2006-09-19 12:26 --- Created an attachment (id=12296) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12296action=view) compare the disassembly result clearly -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29140
[Bug c/29129] [4.2 Regression] Strictly conforming code rejected
--- Comment #3 from neil at daikokuya dot co dot uk 2006-09-19 13:04 --- Subject: Re: [4.2 Regression] Strictly conforming code rejected joseph at codesourcery dot com wrote:- foo.c:1: error: '[*]' not allowed in other than a declaration As the diagnostic indicates, unsigned int [*] is not a declaration with function prototype scope but a type name. Feel free to submit a DR regarding the exact meaning of can only be used in declarations with function prototype scope. I'm quite happy my reading is correct, thanks, but don't let me stop you. I'd be interested in why you believe an alternative reading is justified despite its explicit inclusion in the grammar of 6.7.6, plus examples. DR 295 is an example of continuing imprecise wording that is far more gratuitous. Neil. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29129
[Bug other/28230] -O2 -fwrapv miscompiles gcc, binutils, gzip.
--- Comment #7 from pluto at agmk dot net 2006-09-19 13:08 --- and one more misscompiled program - gzip-1.3.5. this time 4.1.2 with -O2 -fwrapv produces wrong code. $ dd if=/dev/zero of=foo count=10 $ gzip foo $ gzip -d foo.gz $ gzip: foo.gz: invalid compressed data--format violated -- pluto at agmk dot net changed: What|Removed |Added Known to fail|4.2.0 |4.2.0 4.1.2 Known to work|4.1.2 | Summary|ICE during bootstrap / |-O2 -fwrapv miscompiles gcc, |binutils miscompilation (-O2|binutils, gzip. |-fwrapv issue) | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28230
[Bug target/28516] [4.2 regression] arm_unwind_emit_set, at config/arm/arm.c:15419 with -fexceptions
--- Comment #15 from pbrook at gcc dot gnu dot org 2006-09-19 13:18 --- Subject: Bug 28516 Author: pbrook Date: Tue Sep 19 13:18:27 2006 New Revision: 117055 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117055 Log: 2006-09-19 Paul Brook [EMAIL PROTECTED] PR target/28516 gcc/ * config/arm/arm.c (arm_unwind_emit_set): Handle reg = sp + const. gcc/testsuite/ * gcc.dg/nested-func-5.c: New test. Added: branches/csl/sourcerygxx-4_1/gcc/testsuite/gcc.dg/nested-func-5.c Modified: branches/csl/sourcerygxx-4_1/ChangeLog.csl branches/csl/sourcerygxx-4_1/gcc/config/arm/arm.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28516
[Bug target/28516] [4.2 regression] arm_unwind_emit_set, at config/arm/arm.c:15419 with -fexceptions
--- Comment #16 from pbrook at gcc dot gnu dot org 2006-09-19 13:19 --- Subject: Bug 28516 Author: pbrook Date: Tue Sep 19 13:19:24 2006 New Revision: 117056 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117056 Log: 2006-09-19 Paul Brook [EMAIL PROTECTED] PR target/28516 gcc/ * config/arm/arm.c (arm_unwind_emit_set): Handle reg = sp + const. gcc/testsuite/ * gcc.dg/nested-func-5.c: New test. Added: trunk/gcc/testsuite/gcc.dg/nested-func-5.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28516
[Bug target/28516] [4.2 regression] arm_unwind_emit_set, at config/arm/arm.c:15419 with -fexceptions
--- Comment #17 from pbrook at gcc dot gnu dot org 2006-09-19 13:26 --- Fixed. -- pbrook at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28516
[Bug c++/29141] static constructors beyond 64k fail
--- Comment #1 from joerg dot diederich at graffiti dot net 2006-09-19 13:28 --- Created an attachment (id=12297) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12297action=view) example source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29141
[Bug c++/29141] New: static constructors beyond 64k fail
Contruction of global static objects fails while using flash adresses over 0x, e.g. for bootloader purposes. avr mcu hangs completly before main or even the called constructor itself. minimal gcc call: avr-c++ -c -mmcu=at90can128 -I. -I. -g -O0 -Wall -Wextra -Wshadow -Wpointer-arith -Wcast-align -Wsign-compare -Waggregate-return -Wunused -fno-exceptions a_test.cpp -o a_test.o linked with the following options -Wl,-Map=a_test.map,--cref,--section-start=.text=0x1F000 short example code in attachment. -- Summary: static constructors beyond 64k fail Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: joerg dot diederich at graffiti dot net GCC host triplet: Linux 2.6.16-1.2111_FC4 i686 athlon i386 GNU/Linux GCC target triplet: avr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29141
[Bug c++/29141] static constructors beyond 64k fail
--- Comment #2 from joerg dot diederich at graffiti dot net 2006-09-19 13:36 --- thanks to joerg wunsch, additional information is already available. #ifdef L_ctors .section .init6,ax,@progbits .global __do_global_ctors __do_global_ctors: ldi r17, hi8(__ctors_start) ldi r28, lo8(__ctors_end) ldi r29, hi8(__ctors_end) rjmp.do_global_ctors_start .do_global_ctors_loop: sbiwr28, 2 mov_h r31, r29 mov_l r30, r28 XCALL __tablejump__ .do_global_ctors_start: cpi r28, lo8(__ctors_start) cpc r29, r17 brne.do_global_ctors_loop #endif /* L_ctors */ using r28/r29 only works for data 64k. r30/r31 are filled with wrong data in return, in detail 64k less than intended. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29141
[Bug target/15445] spurious dependency-violation warnings
--- Comment #4 from tbm at cyrius dot com 2006-09-19 14:36 --- (In reply to comment #3) This is partly a compiler problem, and partly a binutils problem. This bug exists to document the fact that gcc/gas don't handle dependency violation issues correctly in all instances. I don't plan to work on this immediately, but at least assigning it to me makes it clear who to ask if there are questions about this bug. Do you have any plans to work on this in the near future? Would it help it have some testcases? I noticed a number of such warnings while compiling the Debian archive with gcc 4.2. Some appear to be regressions from 3.4. -- tbm at cyrius dot com changed: What|Removed |Added CC||tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15445
[Bug c/29140] optimization -O2/-O3/-Os generate wrong instruction order
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-09-19 14:42 --- You are violating C aliasing rules here (try -Wstrict-aliasing): return *(CTLFLOAT*)bits; -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29140
[Bug fortran/29142] New: gfortran - incorrectly flags error on allocatable variable in TYPE declaration
The other compilers are happy with this TYPE declaration - so I guess that it is ok - [dranta:~/tests/gfortran-D] dir% g95 -c struct02.f90 [dranta:~/tests/gfortran-D] dir% f90 -c struct02.f90 [dranta:~/tests/gfortran-D] dir% xlf95 -qsuffix=f=f90 -c struct02.f90 ** plot_hdf === End of Compilation 1 === 1501-510 Compilation successful for file struct02.f90. [dranta:~/tests/gfortran-D] dir% gfortran -c struct02.f90 In file struct02.f90:5 real,dimension(:), allocatable :: data 1 Error: Attribute at (1) is not allowed in a TYPE definition In file struct02.f90:6 end type SDS2Dout 1 Error: Derived type definition at (1) has no components [dranta:~/tests/gfortran-D] dir% cat struct02.f90 module plot_hdf implicit none save type, public :: SDS2Dout real,dimension(:), allocatable :: data end type SDS2Dout end module plot_hdf [dranta:~/tests/gfortran-D] dir% gfortran --v Using built-in specs. Target: powerpc-apple-darwin8.7.0 Configured with: ../gcc/configure --prefix=/usr/local/gfortran --enable-languages=c,f95 Thread model: posix gcc version 4.2.0 20060919 (experimental) -- Summary: gfortran - incorrectly flags error on allocatable variable in TYPE declaration Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dir at lanl dot gov GCC host triplet: Darwin 8.7.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29142
[Bug c++/29143] New: address-of overloaded function does not work in function call
void f(int,int);
void f(int,int,int);
void
g ()
{
(f)(1,2,3);
}
gives:
t.cpp: In function void g():
t.cpp:7: error: address of overloaded function with no contextual type
information
The C++ standard clause 13.3.1.1 says that '(f)(...)' is the same as
'(f)(...)',
but the latter works and the former does not.
--
Summary: address-of overloaded function does not work in function
call
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andrew dot stubbs at st dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29143
[Bug c/29144] New: Missing if-conversion. If-conversion dependent on operand order. Inconsistent if-conversion.
Four ways of coding a conditional assignment yields 1 conditional move using
gcc 3.4.5 20051201 (Red Hat 3.4.5-2). gcc 4.0.2 20051130 (Red Hat 4.0.2-14.EL4)
produces none. IMHO, four cmov's should have been produced. I further expect
all four functions to generates the exact same code.
All recent new commercial compilers tested generates four cmov's:
- intel 8.1, 9.0, and 9.1
- pgi 5.2, 6.0, 6.1, and 6.2
- pathscale 2.1, 2.2, 2.3, 2.4
Version-Release number of selected component (if applicable):
How reproducible:
allways
Steps to Reproduce:
gcc -O2 -S if_conversion.c;egrep cmov\|^[a-d]: if_conversion.s
Actual results:
a:
b:
c:
d:
cmove %ecx, %esi
Expected results:
One cmovX per function, four in total.
Here is the source code:
-
/* if construct, near obvious cse */
int a(int c, int a, int b, int o) {
int r;
if (c) {
r = a - b;
} else {
r = a + o - b;
}
return r;
}
/* if construct, absolute obvious cse */
int b(int c, int a, int b, int o) {
int r;
if (c) {
r = a - b;
} else {
r = a - b + o;
}
return r;
}
/* conditional assignment, near obvious cse */
int c(int c, int a, int b, int o) {
int r;
r = (c) ? a - b : a + o - b;
return r;
}
/* conditional assignment, absolute obvious cse */
int d(int c, int a, int b, int o) {
int r;
r = (c) ? a - b : a - b + o;
return r;
}
-
--
Summary: Missing if-conversion. If-conversion dependent on
operand order. Inconsistent if-conversion.
Product: gcc
Version: 3.4.5
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Hakon dot Bugge at scali dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29144
[Bug tree-optimization/29145] New: unsafe use of restrict qualifier
In the test case below, GCC doesn't observe a non-restrict-qualified
pointer being based on a restrict-qualified pointer. On i686-pc-linux-gnu,
this program aborts when compiled with
-O2 -msse -ftree-vectorize
because the loop in function with_restrict is vectorized based on an unsafe
alias assumption.
void abort(void);
void exit(int);
void with_restrict(int * __restrict p)
{
int i;
int *q = p - 2;
for (i = 0; i 1000; ++i) {
p[i] = q[i];
}
}
void without_restrict(int * p)
{
int i;
int *q = p - 2;
for (i = 0; i 1000; ++i) {
p[i] = q[i];
}
}
int main(void)
{
int i;
int a[1002];
int b[1002];
for (i = 0; i 1002; ++i) {
a[i] = b[i] = i;
}
with_restrict(a + 2);
without_restrict(b + 2);
for (i = 0; i 1002; ++i) {
if (a[i] != b[i])
abort();
}
exit(0);
}
--
Summary: unsafe use of restrict qualifier
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: djg at cray dot com
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=29145
[Bug target/28490] [4.0/4.1 regression] ICE in ia64_expand_move, at config/ia64/ia64.c:1088
--- Comment #19 from sje at gcc dot gnu dot org 2006-09-19 16:09 --- Subject: Bug 28490 Author: sje Date: Tue Sep 19 16:09:48 2006 New Revision: 117057 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117057 Log: PR 28490 * config/ia64/ia64.c (ia64_legitimate_constant_p): Allow function pointers as legitimate constants. Modified: trunk/gcc/ChangeLog trunk/gcc/config/ia64/ia64.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28490
[Bug target/26792] [4.2 Regression] need to use autoconf when using newly-added libgcc functions
--- Comment #21 from howarth at nitro dot med dot uc dot edu 2006-09-19 16:11 --- Steve has checked in the changes to config/unwind_ipinfo.m4, so I believe all we need now is... Index: libjava/configure.ac === --- libjava/configure.ac(revision 117056) +++ libjava/configure.ac(working copy) @@ -1480,6 +1480,9 @@ # See if we support thread-local storage. GCC_CHECK_TLS +# For _Unwind_GetIPInfo. +GCC_CHECK_UNWIND_GETIPINFO + # Check if linker supports static linking on a per library basis LD_START_STATIC_SPEC= LD_FINISH_STATIC_SPEC= I'll test that with tonight's gcc trunk build using MACOSX_DEPLOYMENT_TARGET unset which should create both a libstdc++ and libgcj with the _Unwind_GetIPInfo symbols. This should complete the fix for this PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26792
[Bug fortran/29142] gfortran - incorrectly flags error on allocatable variable in TYPE declaration
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-19 16:41 --- This is an extension to both Fortran 90 and Fortran 95. It is part of Fortran 2003 though. Anyways this is a dup of bug 20541. *** This bug has been marked as a duplicate of 20541 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29142
[Bug fortran/20541] TR 15581: ALLOCATABLE components
--- Comment #20 from pinskia at gcc dot gnu dot org 2006-09-19 16:41 --- *** Bug 29142 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||dir at lanl dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541
[Bug tree-optimization/29145] unsafe use of restrict qualifier
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-19 16:43 --- Actually restrict is weird and you might be violating one of the rules for restrict, I always forget those rules and don't really understand them that well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29145
[Bug bootstrap/25009] Bootstrap: Failure to build doc/gcc.info
--- Comment #11 from falk at debian dot org 2006-09-19 17:38 --- No feedback for a long time, let's just close it. -- falk at debian dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25009
[Bug ada/28716] Ada: Bind_Socket doesn't bind to specified address
--- Comment #4 from laurent at guerby dot net 2006-09-19 19:38 --- Patch posted. -- laurent at guerby dot net changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||09/msg00837.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28716
[Bug middle-end/21990] Wrong code for 4.0 and head: Reload clobbers the frame pointer by using it as spill register without recognizing the clobbering
--- Comment #12 from eweddington at cso dot atmel dot com 2006-09-19 19:41 --- (In reply to comment #11) I just realized that the patch posted here had just posted had a = where should have been a for two comparisons. The patch on [EMAIL PROTECTED] is already correct. Bjoern, 1. Is this patch already applied? 2. If yes, what versions is it applied to? 3. If no, can you post the link to the patch on gcc-patches? Or can you attach the corrected patch to this bug report? Thanks -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21990
[Bug ada/28733] GNAT crash while compiling Ada-2005 code
--- Comment #5 from laurent at guerby dot net 2006-09-19 19:44 --- With gcc version 4.2.0 20060915 (experimental) $ gcc -c -gnat05 ada_3d-file_io-step_reader.adb ada_3d-file_io-step_reader.ads:84:04: this instantiation requires Ada_3d.System.Containers.Single_List (body) ada_3d-file_io-step_reader.ads:84:04: but file ada_3d-system-containers-single_list.adb was not found compilation abandoned Could you provide the missing file? thanks -- laurent at guerby dot net changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28733
[Bug ada/28394] Ada: Ambiguous call not detected when using dotted notation
--- Comment #2 from laurent at guerby dot net 2006-09-19 20:00 --- Confirmed with gcc version 4.2.0 20060915 (experimental I think your analysis is correct, the compiler should issue an error on the first line. If it's not correct, I don't see how the compiler could generate a call to pkg.setup so it would be wrong-code. -- laurent at guerby dot net changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||accepts-invalid Last reconfirmed|-00-00 00:00:00 |2006-09-19 20:00:17 date|| Summary|Ambiguous call not detected |Ada: Ambiguous call not |when using dotted notation |detected when using dotted ||notation http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28394
[Bug middle-end/21990] Wrong code for 4.0 and head: Reload clobbers the frame pointer by using it as spill register without recognizing the clobbering
--- Comment #13 from bjoern dot m dot haase at web dot de 2006-09-19 20:16 --- Hello Eric, IIRC, the bug never was really resolved. The true place to fix the issue was, IMO, the most dreaded source file of the entire GCC source tree: reload. My now quite old patch tried to fix the immediate problem without touching reload and it used a fairly crude method by denying gcc to make use of Y in many situations. My test case generated code that was very difficult to handle by the register allocator. This code triggered the bug. Later on some change in some of the passes just before the 4.0.0 release removed the immediate problem. With 4.0 and afterwards I no longer succeeded to reproduce the bug: The reason might be, that the original reload bug was fixed. The reason might as well be that the reload bug is still there, but that it's no longer exposed due to some other modification in the compiler. The message is: There stand good chances that this bug is resolved, but I cannot prove it. In any case, I'd like to suggest *NOT* to make use of my old crude patch. IMO it's better to just hope that the problem is fixed. Until now, I never again stepped over this bug, so I have good confidence. HTH, Bjoern -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21990
[Bug middle-end/21990] Wrong code for 4.0 and head: Reload clobbers the frame pointer by using it as spill register without recognizing the clobbering
--- Comment #14 from eweddington at cso dot atmel dot com 2006-09-19 20:25 --- Thanks, Bjoern, for responding in detail. If this bug cannot be reproduced, can we go ahead and close this bug report? Eric -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21990
[Bug rtl-optimization/21299] [4.0/4.1/4.2 Regression] internal error on invalid asm statement
--- Comment #9 from steven at gcc dot gnu dot org 2006-09-19 21:22 --- Subject: Bug 21299 Author: steven Date: Tue Sep 19 21:22:31 2006 New Revision: 117061 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117061 Log: PR rtl-optimization/21299 * reload1.c (reload): Purge invalid ASMs in the final pass. Modified: trunk/gcc/ChangeLog trunk/gcc/reload1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21299
[Bug rtl-optimization/21299] [4.0/4.1 Regression] internal error on invalid asm statement
--- Comment #10 from steven at gcc dot gnu dot org 2006-09-19 21:23 --- Fixed on trunk for GCC 4.2. -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW Known to fail|3.0.4 4.0.0 4.1.0 4.2.0 |3.0.4 4.0.0 4.1.0 Known to work|2.95.3 |2.95.3 4.2.0 Summary|[4.0/4.1/4.2 Regression]|[4.0/4.1 Regression] |internal error on invalid |internal error on invalid |asm statement |asm statement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21299
[Bug middle-end/4520] cselib.c hash_rtx incorrectly hashes based on rtx address
--- Comment #12 from sayle at gcc dot gnu dot org 2006-09-19 21:25 --- Subject: Bug 4520 Author: sayle Date: Tue Sep 19 21:25:28 2006 New Revision: 117062 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117062 Log: PR middle-end/4520 Backport from mainline * cselib.c (cselib_hash_rtx): Avoid hashing on the address of labels and symbols. Instead use the implementation from cse.c's hash_rtx. Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/cselib.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4520
[Bug middle-end/29135] internal compiler error at cfgexpand.c:515
--- Comment #3 from de at cs dot brown dot edu 2006-09-19 21:49 --- Subject: Re: internal compiler error at cfgexpand.c:515 It seems to still be a problem with 4.1.1 (released 20060511). Maybe this is a slightly different problem? If not, what version has fixed this? Or, how can I change my code to avoid the stack overflow? Thanks, David /usr/bin/gcc-4.1 -Wall -pedantic -g -c -o desh.o desh.c -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,java,fortran,objc,obj-c++,ada,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/jre --enable-mpfr --with-tune=i686 --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.1.1 20060511 (prerelease) (Debian 4.1.0-4) /usr/lib/gcc/i486-linux-gnu/4.1.1/cc1 -quiet -v desh.c -quiet -dumpbase desh.c -mtune=i686 -auxbase-strip desh.o -g -Wall -pedantic -version -o /tmp/ccBamZow.s ignoring nonexistent directory /usr/local/include/i486-linux-gnu ignoring nonexistent directory /usr/include/i486-linux-gnu #include ... search starts here: #include ... search starts here: /usr/local/include /usr/lib/gcc/i486-linux-gnu/4.1.1/include /usr/include End of search list. GNU C version 4.1.1 20060511 (prerelease) (Debian 4.1.0-4) (i486-linux-gnu) compiled by GNU C version 4.1.1 20060511 (prerelease) (Debian 4.1.0-4). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 0094fb0542a7fdae5375a0ba89472de3 desh.c: In function 'main': desh.c:256: internal compiler error: in expand_one_stack_var_at, at cfgexpand.c:515 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. For Debian GNU/Linux specific bug reporting instructions, see URL:file:///usr/share/doc/gcc-4.1/README.Bugs. pinskia at gcc dot gnu dot org wrote: --- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-19 04:19 --- char input[((size_t)~0 1)]; hehehehehehehe. Anyways this has been fixed for 4.1.0 by rejecting this code saying there is a stack (32bit) overflow. *** This bug has been marked as a duplicate of 21107 *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29135
[Bug ada/28394] Ada: Ambiguous call not detected when using dotted notation
--- Comment #3 from laurent at guerby dot net 2006-09-19 21:52 --- Note: confirmed by an Ada 2005 expert, and this has been fixed by AdaCore so the patch will probably land in the FSF tree soon. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28394
[Bug target/19087] Overflowed address in dwarf debug line information
--- Comment #23 from eweddington at cso dot atmel dot com 2006-09-19 21:54 --- (In reply to comment #20) I suggest that this change should be accompanied by another indication in the output that tells the ELF/DWARF-2 consumer about the changed pointer size. Otherwise the consumer will experience funny behaviour. While there are many ELF fields available that are otherwise unused on this architecture (like the OS or ABI fields), there doesn't seem to exist any practical way to modify their contents through the assembler/linker interface. Thus, and after checking other GCC code like the section .note.GNU-stack suggested at the end of varasm.c, I think adding something like named_section_flags (.note.DWARF2-32, SECTION_DEBUG); to function avr_file_end() in gcc/config/avr/avr.c appears to be a suitable way to me to flag this information to the potential consumer. Joerg, I've been trying this, but something strange is going on. On the linker command line, I specify for it to create a map file. I can correctly see the new section, .note.DWARF2-32, in the map file. However, when I use avr-objdump on the resulting ELF file, the section looks like it is not there. So can the linker show the section when it generates the map file, but then remove the section, because the section is empty, when it does the final generation of the ELF file? Thanks Eric -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087
[Bug middle-end/4520] cselib.c hash_rtx incorrectly hashes based on rtx address
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.1.1 4.0.3 Known to work||4.1.2 4.0.4 4.2.0 Target Milestone|4.1.2 |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4520
[Bug target/19087] Overflowed address in dwarf debug line information
--- Comment #24 from dberlin at gcc dot gnu dot org 2006-09-20 00:00 --- You guys should be aware that dwarf2/3 has a field in the header of each dwarf compilation unit labeled address size that tells what the address size for that compilation unit is. If this is set to 4, you should be able to use 4 byte addresses and any conforming dwarf2 reader will understand it and use it to determine how many bytes the address forms (DW_FORM_addr, etc) use. See section 7.5.1 of the DWARF3 standard. This is the way the consumer is supposed to know what the address size in a dwarf2 is (there is also a way to tell the consumer what the offset size should be for file offsets, in case you want to have really large debug info on a machine with 8 byte *addresses*), i'm not sure why you think you need an extra note. See the rest of the DWARF2/3 specification for more details. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087
[Bug c/29140] optimization -O2/-O3/-Os generate wrong instruction order
--- Comment #3 from mingqiao dot wu at gmail dot com 2006-09-20 01:22
---
(In reply to comment #2)
You are violating C aliasing rules here (try -Wstrict-aliasing):
return *(CTLFLOAT*)bits;
Yes, -O2 turns on -fstrict-aliasing, and I saw many warnings like warning:
dereferencing type-punned pointer will break strict-aliasing rules without
specifying -Wstrict-aliasing explicitly because -Wall include it. I added
-Wstrict-aliasing to CFLAGS. The disassembly result is different but still not
correct. At 5e8 line, r3 is the latest value to return, but 574 line regard r2
is the return value. I noticed this warning did not appear in gcc-3.4.3. How
should I re-write such code to use -O2 correctly with gcc-4.1.1? Thanks.
0560 _CTL_Fixed2Float:
560: e92d4010stmdb sp!, {r4, lr}
564: e2504000subsr4, r0, #0 ; 0x0
568: e24dd008sub sp, sp, #8 ; 0x8
56c: 03a02000moveq r2, #0 ; 0x0
570: 1a02bne 580 _CTL_Fixed2Float+0x20
574: e1a2mov r0, r2
578: e28dd008add sp, sp, #8 ; 0x8
57c: e8bd8010ldmia sp!, {r4, pc}
580: e0240fc4eor r0, r4, r4, asr #31
584: e0400fc4sub r0, r0, r4, asr #31
588: ebfebl 0 E3D_CLZ
58c: e270200arsbsr2, r0, #10 ; 0xa
590: 42623000rsbmi r3, r2, #0 ; 0x0
594: 41a00314movmi r0, r4, lsl r3
598: 51a00254movpl r0, r4, asr r2
59c: e350cmp r0, #0 ; 0x0
5a0: 03a035femoveq r3, #1065353216 ; 0x3f80
5a4: 058d3004streq r3, [sp, #4]
5a8: 0a0cbeq 5e0 _CTL_Fixed2Float+0x80
5ac: e2823084add r3, r2, #132; 0x84
5b0: e20330ffand r3, r3, #255; 0xff
5b4: e1a02b83mov r2, r3, lsl #23
5b8: b2603000rsblt r3, r0, #0 ; 0x0
5bc: a1a03100movge r3, r0, lsl #2
5c0: b1a03103movlt r3, r3, lsl #2
5c4: e58d2004str r2, [sp, #4]
5c8: a3c304ffbicge r0, r3, #-16777216 ; 0xff00
5cc: b3822102orrlt r2, r2, #-2147483648; 0x8000
5d0: b3c304ffbiclt r0, r3, #-16777216 ; 0xff00
5d4: a3c00502bicge r0, r0, #8388608; 0x80
5d8: b58d2004strlt r2, [sp, #4]
5dc: b3c00502biclt r0, r0, #8388608; 0x80
5e0: e59d3004ldr r3, [sp, #4]
5e4: e59d2004ldr r2, [sp, #4]
5e8: e1833000orr r3, r3, r0
5ec: e58d3004str r3, [sp, #4]
5f0: eadfb 574 _CTL_Fixed2Float+0x14
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29140
[Bug fortran/19260] not required when splitting a token in continuation
--- Comment #5 from patchapp at dberlin dot org 2006-09-20 02:45 --- Subject: Bug number PR19260 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00854.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19260
[Bug middle-end/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2006-09-20 03:16 --- Subject: Re: [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites The patch which I am thinking might had caused this is: 2006-09-13 Andreas Krebbel [EMAIL PROTECTED] * flow.c (calculate_global_regs_live): Invalidate eh registers on eh edges. Renamed invalidated_by_call to invalidated_by_eh_edge. (propagate_block): Handle eh registers as if they were set at basic block start. * except.c (dw2_build_landing_pads): Don't emit clobbers for eh registers. * global.c (global_conflicts): Make eh registers to conflict with pseudos live at basic block begin. * basic_block.h (bb_has_eh_pred): New function. While I could see that this might be the cause, it looks like 116942 introduced the failure. See http://gcc.gnu.org/ml/gcc-testresults/2006-09/msg00983.html and http://gcc.gnu.org/ml/gcc-testresults/2006-09/msg01047.html. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118
[Bug middle-end/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2006-09-20 03:19 --- Subject: Re: Timeouts in libstdc++, libjava and libgomp testsuites Does hppa-linux-gnu use dwarf2 eh info? It uses the dwarf2 unwind info. So, does hpux which doesn't appear affected. The same exception_receiver code is generated for both. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118
[Bug target/19087] Overflowed address in dwarf debug line information
--- Comment #25 from eweddington at cso dot atmel dot com 2006-09-20 03:38 --- (In reply to comment #24) i'm not sure why you think you need an extra note. Because we weren't aware of the information that you thoughtfully laid out and put in this bug report? :-) Thank you very much for doing this! See the rest of the DWARF2/3 specification for more details. Torleif can you take a look at this new info and see if it will work for you? Thanks Eric Weddington -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087
[Bug fortran/19654] compilation crashes when variable is too large instead of showing error
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2006-09-20 03:48 --- I think this is fixed. If I increase the size of the parameter I get the expected error message. program kk implicit none integer, parameter :: N=65535, M=N/2-1 real, dimension(N,N):: input call random_number(input) end program kk [EMAIL PROTECTED] pr19654]$ gfc pr19654.f90 pr19654.f90: In function MAIN__: pr19654.f90:4: error: size of variable input is too large I think this is fixed. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19654
[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-20 04:40 --- http://gcc.gnu.org/viewcvs?view=revrevision=116942 This is why I mentioned some of the libstdc++ changes should not be going in. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||bkoz at gcc dot gnu dot org Severity|normal |blocker Component|middle-end |libstdc++ Keywords|EH | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118
[Bug libfortran/29121] CPU_TIME subroutine missing for REAL(kind=10) argument
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2006-09-20 04:47 --- Confirmed -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-20 04:47:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29121
[Bug c/29140] optimization -O2/-O3/-Os generate wrong instruction order
--- Comment #4 from mingqiao dot wu at gmail dot com 2006-09-20 04:48 --- After checking gcc manual, I found union can be used to do this conversion. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29140
[Bug c/29140] optimization -O2/-O3/-Os generate wrong instruction order
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-20 04:49 --- (In reply to comment #4) After checking gcc manual, I found union can be used to do this conversion. You can also use memcpy which is slightly more portable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29140
[Bug middle-end/29135] internal compiler error at cfgexpand.c:515
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-20 04:56 --- [EMAIL PROTECTED] ~]$ ~/gcc-4.1/bin/gcc t.i -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /home/pinskia/src/gcc/gcc-4.1/gcc/configure --prefix=/home/pinskia/gcc-4.1/ Thread model: posix gcc version 4.1.2 20060917 (prerelease) /home/pinskia/gcc-4.1/bin/../libexec/gcc/i686-pc-linux-gnu/4.1.2/cc1 -fpreprocessed t.i -quiet -dumpbase t.i -mtune=pentiumpro -auxbase t -version -o /tmp/cc4wbv0b.s GNU C version 4.1.2 20060917 (prerelease) (i686-pc-linux-gnu) compiled by GNU C version 4.1.2 20060917 (prerelease). GGC heuristics: --param ggc-min-expand=94 --param ggc-min-heapsize=121165 Compiler executable checksum: 3ccc0164c9173719947ca913043b7105 desh.c: In function main: desh.c:256: error: total size of local objects too large It is fixed for me. Well for one replace the size on input to be something more resonable because ((size_t)-1)2 is half the memory which is really invalid for the stack. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29135
[Bug fortran/19261] continuation character illegal as first non-blank character in statement
-- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-12-30 18:58:38 |2006-09-20 05:19:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19261
[Bug fortran/19262] more than thirty-nine continuation lines should issue a std-warn
-- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-12-30 18:58:51 |2006-09-20 05:20:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19262
[Bug debug/29146] New: Gcc generates DWARF3 DW_FORM_ref_addr in DWARF2 info
DW_FORM_ref_addr uses address size in DWARF2, but uses offset size in DWARF3. The current linker can only handle DWARF2 info. It looks like gcc generates DWARF3 DW_FORM_ref_addr while marking debug info as DWARF2. See http://sourceware.org/bugzilla/show_bug.cgi?id=3191 -- Summary: Gcc generates DWARF3 DW_FORM_ref_addr in DWARF2 info Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29146
[Bug debug/29146] Gcc generates DWARF3 DW_FORM_ref_addr in DWARF2 info
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-20 05:48 --- http://www.sourceware.org/ml/gdb/2001-06/msg00111.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29146
[Bug debug/29146] Gcc generates DWARF3 DW_FORM_ref_addr in DWARF2 info
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-20 05:51 --- http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00030.html Hmm -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29146
[Bug debug/29146] Gcc generates DWARF3 DW_FORM_ref_addr in DWARF2 info
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-20 05:56 --- (In reply to comment #0) DW_FORM_ref_addr uses address size in DWARF2, but uses offset size in DWARF3. The current linker can only handle DWARF2 info. It looks like gcc generates DWARF3 DW_FORM_ref_addr while marking debug info as DWARF2. Yes and those sizes are the same on 90% of the targets (only a few are different) so I think the linker is still making a mistake. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29146
