[Bug fortran/39253] A bug with interface in gfortran
--- Comment #1 from burnus at gcc dot gnu dot org 2009-02-20 07:00 --- Thanks for the report. However, GCC/gfortran 4.1.0 is quite old. (GCC 4.0.0 was the first version which contained gfortran, which was at that time very buggy. Version 4.1.x was quite usable, but still contained a few bugs (especially 4.1.0).) Could you update to a newer version? 4.2.x is much better than 4.1.x, but the recommended version is either 4.3.3 (latest stable version) or 4.4 (latest developer version, which should be soon released). You might try a build at http://gcc.gnu.org/wiki/GFortranBinaries -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39253
[Bug c++/39055] [4.2/4.3/4.4 regression] ICE with questionable default parameter of a member function
--- Comment #3 from jason at gcc dot gnu dot org 2009-02-20 05:38 --- Yes, "i" is bound to "this->i", which I believe is perfectly valid. The section of the standard that says that default arguments can't refer to "this" means that default arguments of member functions can't refer to their own "this" parameter; usage in this form is fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39055
[Bug c++/39225] [4.3 Regression] ICE if destructor doen't match class name
--- Comment #10 from hjl dot tools at gmail dot com 2009-02-20 05:37 --- I think 4.3 branch is still broken. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Known to fail|4.3.4 4.4.0 |4.3.4 Known to work|4.3.2 |4.3.2 4.4.0 Resolution|FIXED | Summary|[4.3/4.4 Regression] ICE if |[4.3 Regression] ICE if |destructor doen't match |destructor doen't match |class name |class name http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39225
[Bug c++/38880] [4.4 Regression] g++.dg/init/const7.C XFAILed
--- Comment #10 from jason at gcc dot gnu dot org 2009-02-20 05:35 --- Er, not that one, this one: http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00882.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38880
[Bug c++/38880] [4.4 Regression] g++.dg/init/const7.C XFAILed
--- Comment #9 from jason at gcc dot gnu dot org 2009-02-20 05:34 --- New patch at http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01309.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38880
[Bug c++/39225] [4.3/4.4 Regression] ICE if destructor doen't match class name
--- Comment #9 from jason at gcc dot gnu dot org 2009-02-20 05:33 --- Fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39225
[Bug c++/39225] [4.3/4.4 Regression] ICE if destructor doen't match class name
--- Comment #8 from jason at gcc dot gnu dot org 2009-02-20 05:32 --- Subject: Bug 39225 Author: jason Date: Fri Feb 20 05:32:40 2009 New Revision: 144314 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144314 Log: PR c++/39225 * decl.c (grokdeclarator): Handle ~identifier. Added: trunk/gcc/testsuite/g++.dg/parse/dtor15.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39225
[Bug fortran/39253] New: A bug with interface in gfortran
This is my first report at gcc Bugzilla... I tried to compile a fortran program that invokes QD library (multiprecision arithmetic, available at http://www.cs.berkeley.edu/~yozo/software/qd-2.3.7.tar.gz). When I use Intel compiler suite, everything is fine. If I switch to gcc (the performance of QD is much better when it is compiled with g++ rather than Intel C++) then I get the following error message: In file f_main.f90:17 call random_number(s) 1 Error: There is no specific subroutine for the generic 'random_number' at (1) make: *** [f_main.o] Error 1 I have investigated the issue a little it and came to the conclusion that there is something wrong with interfacing in gfortran. The QD library has fortran modules called ddmod.f90 and qdmod.f90 which contain the following: interface random_number module procedure ddrand end interface interface random_number module procedure qdrand end interface random_number is interfaced to allow it to be called with the types or real numbers implemented in QD [type(qd_real) and type(dd_real)]. But in my code I want to call random_number with standard real(8) type. Intel fortran has no problems with it, the compilation goes fine and the program runs as expected. So there must be a bug in gfortran. In order to make things work I simply removed those interfaces from qdmod.f90 and ddmod.f90 (I don't need random_number with type(qd_real) and type(dd_real) anyway). After doing that everything goes fine. -- Summary: A bug with interface in gfortran Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bubin at qcri dot or dot jp http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39253
[Bug c/39252] Request new feature __builtin_not_reached();
--- Comment #7 from hpa at zytor dot com 2009-02-20 04:34 --- A "noreturn" clobber would work just as well, obviously. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39252
[Bug target/39232] apparent bizarre miscompilation on AVR
--- Comment #3 from regehr at cs dot utah dot edu 2009-02-20 03:44 ---
Created an attachment (id=17335)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17335&action=view)
diff between broken and working assembly
This is a diff between the attachment compiled at -O0 and the same program but
with the declaration and initialization of l_46 commented out. The first
problem (I claim) produces incorrect output, the second correct. So this diff
has to show the problem.
The change is to turn func_43() to this:
int32_t func_43 (int64_t p_44)
{
int16_t l_45 = 1;
//int16_t l_46 = 1;
return l_45;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39232
[Bug target/39232] apparent bizarre miscompilation on AVR
--- Comment #2 from regehr at cs dot utah dot edu 2009-02-20 03:32 --- Created an attachment (id=17334) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17334&action=view) failure-inducing C program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39232
[Bug rtl-optimization/39241] [4.4 Regression] ICE in subreg_get_info, at rtlanal.c:3104
--- Comment #4 from hjl dot tools at gmail dot com 2009-02-20 01:58 --- The updated patch is at http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00939.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- |http://gcc.gnu.org/ml/gcc- |patches/2009- |patches/2009- |02/msg00937.html|02/msg00939.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39241
[Bug rtl-optimization/39241] [4.4 Regression] ICE in subreg_get_info, at rtlanal.c:3104
--- Comment #3 from hjl dot tools at gmail dot com 2009-02-20 01:21 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00937.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||02/msg00937.html Component|target |rtl-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39241
[Bug inline-asm/39048] gcc 4.4.0 20090131 - Extra underscore hides libgcc's soft-fp functions from Testsuite causing FAILs + naming error in libgcc
--- Comment #10 from rob1weld at aol dot com 2009-02-20 01:13 --- (In reply to comment #9) > (In reply to comment #8) > > using Sun's Linker (and GNU assembler version 2.19). > > After this patch is tested, approved, applied to trunk, and re-tested, then > > this Bug will be fixed. > Adding DEPENDS and trying to test the 'Booted 64-Bit Mode" after fixing: 39150 This is not yet working on _both_ Sun and GNU's Linkers. Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39048
[Bug libgcj/39161] gcc 4.4.0 20090210 - The 'copy-vmresources.sh' script can't find the 'mkinstalldirs' script.
--- Comment #3 from rob1weld at aol dot com 2009-02-20 01:02 --- A workaround is to copy '../gcc_trunk/libjava/classpath/mkinstalldirs' into the same directory as 'copy-vmresources.sh' so it can find it. Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39161
[Bug libstdc++/39238] trunk revision 144279 - cfenv:54: error: �::fenv_t� has not been declared
--- Comment #4 from rob1weld at aol dot com 2009-02-20 00:57 --- (In reply to comment #3) > Even though I ./configured using "--with-gnu-ld --with-ld=/usr/local/bin/ld" > the scripts seemed to have decided to use the "gcc-used-for-build"'s choice > of 'ld' instead of the main ./configure scripts settings ... > The second Bug in this Report (about the Linker) is filed here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39111 Comment #0 is the only remaining Bug in this thread. Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39238
[Bug c/39252] Request new feature __builtin_not_reached();
--- Comment #6 from jakub at gcc dot gnu dot org 2009-02-19 23:02 --- Wouldn't be a special "noreturn" clobber in inline asm better suited for this then? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39252
[Bug fortran/39239] Reject SAVEd variables EQUIVALENCEd to a COMMON
--- Comment #2 from burnus at gcc dot gnu dot org 2009-02-19 22:29 --- Glan found the relevant part (see link above for more): In 5.5.2.1: "Data objects associated with an entity in a common block are considered to be in that common block." * * * BIND(C) in equivalence is wrong in general (see C576); there is currently a warning printed, but the message is misleading: module m integer :: i1, i2 bind(C) :: i2 ! common /block/ i1 equivalence(i1,i2) end module m With COMMON, the warning (!) is the following; note that /BLOCK/ is not bind(C) contrary to the message: "Warning: Variable 'i1' in common block 'block' at (1) may not be a C interoperable kind though common block 'block' is BIND(C) Without COMMON, the warning (!) is also misleading: "Warning: Variable 'i2' at (1) may not be a C interoperable kind but it is bind(c)" * * * Protected is already handled (cf. C584): "Error: Either all or none of the objects in the EQUIVALENCE set at (1) shall have the PROTECTED attribute" * * * Volatile is not handled, though it [probably] should (cf. NOTE 5.22) integer :: i1, i2 VOLATILE :: i2 equivalence(i1,i2) end * * * Asynchronous: Not yet supported in gfortran. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39239
[Bug c/39252] Request new feature __builtin_not_reached();
--- Comment #5 from hpa at zytor dot com 2009-02-19 22:21 --- Let me respectfully disagree, and explain why. *You* can just create a builtin, but for us (the Linux kernel community) we stare a multi-year pipeline in the face whenever we have to request a gcc change. This feature would allow us to do arbitrary trapping constructs via the existing generic asm feature, without having to do wait for this pipeline to flush every time we want to do something new. In theory, ALL asm() constructs could be turned into builtins, and on some level, that would be the right thing to do. However, I think you can see why this is completely unrealistic, at least with anything less than us forking gcc and have an ad hoc compiler for the kernel. Yes, this feature can be abused. So can *any* use of asm(). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39252
[Bug c/39252] Request new feature __builtin_not_reached();
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-02-19 22:14 --- Still you can make a builtin that does that. Even if it is a target builtin. I think of having a target builtin is better than creating a generic __builtin_not_reached. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39252
[Bug testsuite/38164] gcc.target/i386/amd64-abi-3.c fails at -m64 on i686-apple-darwin9
--- Comment #2 from ubizjak at gmail dot com 2009-02-19 22:13 --- Just add -fomit-frame-pointer to dg-options. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38164
[Bug c/39252] Request new feature __builtin_not_reached();
-- hpa at zytor dot com changed: What|Removed |Added Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39252
[Bug c/39252] Request new feature __builtin_not_reached();
--- Comment #3 from hpa at zytor dot com 2009-02-19 21:58 ---
Two reasons:
1. We have no control over what instruction __builtin_trap() will generate.
2. We require the address of the faulting instruction.
In particular, we currently have a construct which looks like:
#ifdef CONFIG_X86_32
# define __BUG_C0 "2:\t.long 1b, %c0\n"
#else
# define __BUG_C0 "2:\t.long 1b - 2b, %c0 - 2b\n"
#endif
#define BUG() \
do {\
asm volatile("1:\tud2\n"\
".pushsection __bug_table,\"a\"\n" \
__BUG_C0 \
"\t.word %c1, 0\n" \
"\t.org 2b+%c2\n" \
".popsection" \
: : "i" (__FILE__), "i" (__LINE__),\
"i" (sizeof(struct bug_entry))); \
for (;;) ; \
} while (0)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39252
[Bug c/39252] Request new feature __builtin_not_reached();
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-02-19 21:50 --- Why again is __builtin_trap not useful for this purpose? You mention about "assembly constructs" but why not instead implement those as builtins instead of providing something which really can be abused? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Target Milestone|4.5.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39252
[Bug target/38182] stddef.h assumes machinee/ansi.h defines _ANSI_H_
--- Comment #3 from aran at 100acres dot us 2009-02-19 21:46 --- Created an attachment (id=17333) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17333&action=view) Removes gcc's version of both stddef.h and sys/types.h This patch removes gcc's version of stddef.h and the "fixed" version of sys/types.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38182
[Bug target/39175] ICE while compiling qt-4.5.0-rc1
--- Comment #5 from jakub at gcc dot gnu dot org 2009-02-19 21:16 --- Fixed on the trunk so far. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.3.3 Known to work||4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39175
[Bug target/39175] ICE while compiling qt-4.5.0-rc1
--- Comment #4 from jakub at gcc dot gnu dot org 2009-02-19 21:15 --- Subject: Bug 39175 Author: jakub Date: Thu Feb 19 21:15:12 2009 New Revision: 144305 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144305 Log: PR target/39175 * c-common.c (c_determine_visibility): If visibility changed and DECL_RTL has been already set, call make_decl_rtl to update symbol flags. * decl2.c (determine_visibility): If visibility changed and DECL_RTL has been already set, call make_decl_rtl to update symbol flags. * gcc.dg/visibility-20.c: New test. * g++.dg/ext/visibility/visibility-11.C: New test. Added: trunk/gcc/testsuite/g++.dg/ext/visibility/visibility-11.C trunk/gcc/testsuite/gcc.dg/visibility-20.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-common.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl2.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39175
[Bug target/39247] FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE
--- Comment #1 from joseph at codesourcery dot com 2009-02-19 21:11 --- Subject: Re: New: FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE The ARM constant pool code needs to handle a NOTE_INSN_SWITCH_TEXT_SECTIONS note in some way as indicating insns on one side mustn't use constant pool entries on the other side. One possible approach would be treating such a note as an insn of length 4100, but there might be a cleaner way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39247
[Bug c/39252] Request new feature __builtin_not_reached();
--- Comment #1 from hjl dot tools at gmail dot com 2009-02-19 20:51 --- So __builtin_not_reached is just __builtin_trap which doesn't generate any insn. It shouldn't be too hard to implement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39252
[Bug c/39252] Request new feature __builtin_not_reached();
-- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com Target Milestone|--- |4.5.0 Version|unknown |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39252
[Bug c/39252] New: Request new feature __builtin_not_reached();
In the Linux kernel, we use assembly constructs (asm volatile) which trap or otherwise terminate execution. gcc doesn't know about this, so it doesn't terminate its flow analysis. These assembly constructs are more complex than a simple __builtin_trap(); will permit -- we have tried using assembly constructs in conjunction with __builtin_trap(); but that relies too much on undefined behaviour. A much better solution would be to give us __builtin_not_reached(); which is simply an annotation truncating the flow of control at that point. You can think of it from an implementation perspective as __builtin_trap(); that doesn't actually generate any code. This allows any arbitrary assembly that truncates the flow of control to be annotated as such, without the overhead of a compiler-generated catch loop which is never actually reached. -- Summary: Request new feature __builtin_not_reached(); Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hpa at zytor dot com GCC build triplet: All GCC host triplet: All GCC target triplet: All http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39252
[Bug middle-end/39210] g++ 4.3 takes hours to compile greycstoration
--- Comment #8 from steven at gcc dot gnu dot org 2009-02-19 19:57 --- Indeed the same issue. *** This bug has been marked as a duplicate of 36439 *** -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39210
[Bug tree-optimization/36439] [4.3 Regression] very long compile-time in PRE building gimp-plugin-registry
--- Comment #9 from steven at gcc dot gnu dot org 2009-02-19 19:57 --- *** Bug 39210 has been marked as a duplicate of this bug. *** -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||kurt at garloff dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36439
[Bug target/39250] unsigned char times 64U produces long slow loop
-- aesok at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-02-19 18:37:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39250
[Bug tree-optimization/39251] FAIL: g++.dg/tree-ssa/new1.C scan-tree-dump-not forwprop1 "= .* \+ -"
--- Comment #1 from dave at hiauly1 dot hia dot nrc dot ca 2009-02-19 18:28 --- Subject: Re: New: FAIL: g++.dg/tree-ssa/new1.C scan-tree-dump-not forwprop1 "= .* \+ -" Attached new1.C.028t.forwprop1. Dave --- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2009-02-19 18:28 --- Created an attachment (id=17332) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17332&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39251
[Bug c++/39188] G++ doesn't handle static anonymous union right
--- Comment #5 from hjl dot tools at gmail dot com 2009-02-19 18:25 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39188
[Bug tree-optimization/39251] New: FAIL: g++.dg/tree-ssa/new1.C scan-tree-dump-not forwprop1 "= .* \+ -"
Executing on host: /home/dave/gnu/gcc/objdir/gcc/testsuite/g++/../../g++ -B/home /dave/gnu/gcc/objdir/gcc/testsuite/g++/../../ /home/dave/gnu/gcc/gcc/gcc/testsui te/g++.dg/tree-ssa/new1.C -nostdinc++ -I/home/dave/gnu/gcc/objdir/arm-none-linu x-gnueabi/libstdc++-v3/include/arm-none-linux-gnueabi -I/home/dave/gnu/gcc/objdi r/arm-none-linux-gnueabi/libstdc++-v3/include -I/home/dave/gnu/gcc/gcc/libstdc++ -v3/libsupc++ -I/home/dave/gnu/gcc/gcc/libstdc++-v3/include/backward -I/home/dav e/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -O2 -Wall -fdump-t ree-forwprop1 -S -o new1.s(timeout = 300) PASS: g++.dg/tree-ssa/new1.C (test for excess errors) FAIL: g++.dg/tree-ssa/new1.C scan-tree-dump-not forwprop1 "= .* \+ -" -- Summary: FAIL: g++.dg/tree-ssa/new1.C scan-tree-dump-not forwprop1 "= .* \+ -" Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: arm-none-linux-gnueabi GCC host triplet: arm-none-linux-gnueabi GCC target triplet: arm-none-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39251
[Bug tree-optimization/39249] FAIL: g++.dg/ipa/iinline-1.C scan-ipa-dump inline "String::funcOne[^\n]*inline copy in int main"
--- Comment #1 from dave at hiauly1 dot hia dot nrc dot ca 2009-02-19 18:19 --- Subject: Re: New: FAIL: g++.dg/ipa/iinline-1.C scan-ipa-dump inline "String::funcOne[^\n]*inline copy in int main" Attached iinline-1.C.042i.inline. Dave --- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2009-02-19 18:19 --- Created an attachment (id=17331) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17331&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39249
[Bug c/39250] New: unsigned char times 64U produces long slow loop
Multiplying an unsigned char by 64U produces bigger slower code than necessary.
avr-gcc (WinAVR 20081205) 4.3.2
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Windows XP
avr-gcc -c -mmcu=atmega168 -save-temps -Wall -std=gnu99 -Os ../64.c
No terminal output.
64.i:
# 1 "../64.c"
# 1 ""
# 1 ""
# 1 "../64.c"
unsigned mult(unsigned char arg)
{
return arg*64U;
}
compiled into this:
Code:
mov r18,r24
ldi r19,lo8(0)
ldi r24,6
1: lsl r18
rol r19
dec r24
brne 1b
movw r24,r18
ret
Not this:
Code:
mov r19,r24
ldi r18,0
lsr r19
ror r18
lsr r19
ror r18
movw r24,r18
ret
or this
Code:
mov r25,r24
ldi r24,0
lsr r25
ror r24
lsr r25
ror r24
ret
Each example is faster than the previous.
If R0 and R1 had been deemed available,
using MUL would have been even faster,
but MUL doesn't get used even in that case.
--
Summary: unsigned char times 64U produces long slow loop
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hennebry at web dot cs dot ndsu dot nodak dot edu
GCC build triplet: avr-gcc (WinAVR 20081205) 4.3.2?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39250
[Bug tree-optimization/39249] New: FAIL: g++.dg/ipa/iinline-1.C scan-ipa-dump inline "String::funcOne[^\n]*inline copy in int main"
Executing on host: /home/dave/gnu/gcc/objdir/gcc/testsuite/g++/../../g++ -B/home /dave/gnu/gcc/objdir/gcc/testsuite/g++/../../ /home/dave/gnu/gcc/gcc/gcc/testsui te/g++.dg/ipa/iinline-1.C -nostdinc++ -I/home/dave/gnu/gcc/objdir/arm-none-linu x-gnueabi/libstdc++-v3/include/arm-none-linux-gnueabi -I/home/dave/gnu/gcc/objdi r/arm-none-linux-gnueabi/libstdc++-v3/include -I/home/dave/gnu/gcc/gcc/libstdc++ -v3/libsupc++ -I/home/dave/gnu/gcc/gcc/libstdc++-v3/include/backward -I/home/dav e/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -O3 -fdump-ipa-inl ine -fno-early-inlining -S -o iinline-1.s(timeout = 300) PASS: g++.dg/ipa/iinline-1.C (test for excess errors) FAIL: g++.dg/ipa/iinline-1.C scan-ipa-dump inline "String::funcOne[^\n]*inline copy in int main" -- Summary: FAIL: g++.dg/ipa/iinline-1.C scan-ipa-dump inline "String::funcOne[^\n]*inline copy in int main" Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: arm-none-linux-gnueabi GCC host triplet: arm-none-linux-gnueabi GCC target triplet: arm-none-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39249
[Bug c++/39242] [4.4 Regression] Inconsistent reject / accept of code
--- Comment #12 from jason at gcc dot gnu dot org 2009-02-19 17:39 --- (In reply to comment #10) > What that means is that we *must not* implicitly instantiate things > declared "extern template" unless they are DECL_DECLARED_INLINE_P. As a > consequence, at -O3, we cannot implicitly instantiate non-inline "extern > template" functions. I'm not entirely sure that's what we want it to say, but it does seem like a reasonable expectation for users to have. Beyond this issue, what is the compile speed impact of the earlier change to use possibly_inlined_p? It seems like it might be making us speculatively instantiate a lot more functions for potential inlining even at -O1, which I would expect to cause memory bloat and slower compilation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39242
[Bug tree-optimization/39248] FAIL: gcc.dg/vect/vect-complex-1.c
--- Comment #3 from danglin at gcc dot gnu dot org 2009-02-19 17:37 --- gcc.dg/vect/slp-7.c has a similar failure: Executing on host: /home/dave/gnu/gcc/objdir/gcc/xgcc -B/home/dave/gnu/gcc/objdi r/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/vect/slp-7.c -ftree-vectori ze -fno-vect-cost-model -mfpu=neon -mfloat-abi=softfp -O2 -fdump-tree-vect-detai ls -S -o slp-7.s(timeout = 300) PASS: gcc.dg/vect/slp-7.c (test for excess errors) FAIL: gcc.dg/vect/slp-7.c scan-tree-dump-times vect "vectorized 2 loops" 1 FAIL: gcc.dg/vect/slp-7.c scan-tree-dump-times vect "vectorizing stmts using SLP" 2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39248
[Bug tree-optimization/39248] FAIL: gcc.dg/vect/vect-complex-1.c
--- Comment #1 from dave at hiauly1 dot hia dot nrc dot ca 2009-02-19 17:19 --- Subject: Re: New: FAIL: gcc.dg/vect/vect-complex-1.c Attached vect-complex-1.c.101t.vect. Dave --- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2009-02-19 17:19 --- Created an attachment (id=17330) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17330&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39248
[Bug c++/39242] [4.4 Regression] Inconsistent reject / accept of code
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-02-19 16:59:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39242
[Bug tree-optimization/39248] New: FAIL: gcc.dg/vect/vect-complex-1.c
Executing on host: /home/dave/gnu/gcc/objdir/gcc/xgcc -B/home/dave/gnu/gcc/objdi r/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/vect/vect-complex-1.c -ftre e-vectorize -fno-vect-cost-model -mfpu=neon -mfloat-abi=softfp -O2 -fdump-tree-v ect-details -S -o vect-complex-1.s(timeout = 300) PASS: gcc.dg/vect/vect-complex-1.c (test for excess errors) FAIL: gcc.dg/vect/vect-complex-1.c scan-tree-dump-times vect "vectorized 1 loops" 1 FAIL: gcc.dg/vect/vect-complex-1.c scan-tree-dump-times vect "vectorizing stmts using SLP" 1 -- Summary: FAIL: gcc.dg/vect/vect-complex-1.c Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: arm-none-linux-gnueabi GCC host triplet: arm-none-linux-gnueabi GCC target triplet: arm-none-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39248
[Bug c++/39242] [4.4 Regression] Inconsistent reject / accept of code
--- Comment #11 from rguenther at suse dot de 2009-02-19 16:54 --- Subject: Re: [4.4 Regression] Inconsistent reject / accept of code On Thu, 19 Feb 2009, mark at codesourcery dot com wrote: > --- Comment #10 from mark at codesourcery dot com 2009-02-19 16:41 > --- > Subject: Re: [4.4 Regression] Inconsistent reject / accept > of code > > rguenth at gcc dot gnu dot org wrote: > > > The ultimate question is of course if the standard allows (or even requires) > > an error here. > > The (someone old) C++ WP I have is pretty clear: > > "An explicit instantiation declaration that names a class template > specialization has no effect on the class template specialization > itself (except for perhaps resulting in its implicit instantiation). > Except for inline functions, other explicit > instantiation declarations have the effect of suppressing the implicit > instantiation of the entity to which they refer. [ Note: > The intent is that an inline function that is the subject of an explicit > instantiation declaration will still be implicitly instantiated > when used so that the body can be considered for inlining, but that no > out-of-line copy of the inline function > would be generated in the translation unit. ???end note ]" > > Here, "inline function" is of course the C++ definition thereof, i.e., > functions declared "inline" or defined in the body of a class > definition, rather than outside the class. > > What that means is that we *must not* implicitly instantiate things > declared "extern template" unless they are DECL_DECLARED_INLINE_P. As a > consequence, at -O3, we cannot implicitly instantiate non-inline "extern > template" functions. > > So, I think first hunk in the patch is correct. It needs a comment, > though, right above DECL_DECLARED_INLINE to point out that this is a > restriction coming from the standard: > > /* An explicit instantiation declaration prohibits implicit > instantiation of non-inline functions. With high levels of > optimization, we would normally inline non-inline functions -- but we're > not allowed to do that for "extern template" functions. Therefore, we > check DECL_DECLARED_INLINE_P, rather than possibly_inlined_p. */ > > OK with that change. > > I don't yet understand why the second hunk is required. It is probably not, I just looked for all possibly_inlined_p occurrences in instantiate_decl and tried to make sure behavior does not depend on optimization level. I'll split out the first part and test/submit it. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39242
[Bug tree-optimization/39245] FAIL: gcc.dg/memcpy-1.c scan-tree-dump-times optimized "nasty_local" 0
--- Comment #1 from dominiq at lps dot ens dot fr 2009-02-19 16:52 --- Fails also on powerpc-apple-darwin* since at least revision 132577, see for instance: http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg01742.html http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg01095.html The test passes with -m64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39245
[Bug target/39247] New: FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE
Executing on host: /home/dave/gnu/gcc/objdir/gcc/xgcc -B/home/dave/gnu/gcc/objdi r/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/tree-prof/bb-reorg.c -O2 -f reorder-blocks-and-partition -fprofile-use -D_PROFILE_USE -lm -o /home/dave/g nu/gcc/objdir/gcc/testsuite/gcc/bb-reorg.x02(timeout = 300) /tmp/ccsSaXlI.s: Assembler messages: /tmp/ccsSaXlI.s:73: Error: internal_relocation (type: OFFSET_IMM) not fixed up /tmp/ccsSaXlI.s:74: Error: internal_relocation (type: OFFSET_IMM) not fixed up /tmp/ccsSaXlI.s:75: Error: internal_relocation (type: OFFSET_IMM) not fixed up /tmp/ccsSaXlI.s:88: Error: internal_relocation (type: OFFSET_IMM) not fixed up /tmp/ccsSaXlI.s:110: Error: internal_relocation (type: OFFSET_IMM) not fixed up /tmp/ccsSaXlI.s:127: Error: internal_relocation (type: OFFSET_IMM) not fixed up compiler exited with status 1 -bash-3.2$ ./xgcc -B./ -v Reading specs from ./specs Target: arm-none-linux-gnueabi Configured with: ../gcc/configure --host=arm-none-linux-gnueabi --target=arm-non e-linux-gnueabi --build=arm-none-linux-gnueabi --disable-stage1-checking --enabl e-languages=c,c++,fortran --enable-shared --enable-threads --disable-multilib -- disable-libmudflap --disable-libssp --enable-symvers=gnu --enable-__cxa_atexit - -disable-libstdcxx-pch --disable-checking --prefix=/home/dave/opt/gnu/gcc/gcc-4. 4.0 --with-gmp=/home/dave/opt/gnu Thread model: posix gcc version 4.4.0 20090218 (experimental) [trunk revision 144268] (GCC) -bash-3.2$ as --version GNU assembler (GNU Binutils) 2.19.1 Copyright 2007 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `armv5tejl-unknown-linux-gnueabi'. gcc.dg/tree-prof/pr34999.c fails same way. -- Summary: FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, - fprofile-use -D_PROFILE_USE Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: arm-none-linux-gnueabi GCC host triplet: arm-none-linux-gnueabi GCC target triplet: arm-none-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39247
[Bug c/39246] New: FAIL: gcc.dg/uninit-13.c
Executing on host: /home/dave/gnu/gcc/objdir/gcc/xgcc -B/home/dave/gnu/gcc/objdi r/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/uninit-13.c -O -Wuninitiali zed -S -o uninit-13.s(timeout = 300) /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/uninit-13.c: In function 'foo': /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/uninit-13.c:7: warning: '__real__ f' is used uninitialized in this function output is: /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/uninit-13.c: In function 'foo': /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/uninit-13.c:7: warning: '__real__ f' is used uninitialized in this function FAIL: gcc.dg/uninit-13.c unconditional (test for warnings, line 8) FAIL: gcc.dg/uninit-13.c (test for excess errors) Excess errors: /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/uninit-13.c:7: warning: '__real__ f' is used uninitialized in this function -bash-3.2$ ./xgcc -B./ -v Reading specs from ./specs Target: arm-none-linux-gnueabi Configured with: ../gcc/configure --host=arm-none-linux-gnueabi --target=arm-non e-linux-gnueabi --build=arm-none-linux-gnueabi --disable-stage1-checking --enabl e-languages=c,c++,fortran --enable-shared --enable-threads --disable-multilib -- disable-libmudflap --disable-libssp --enable-symvers=gnu --enable-__cxa_atexit - -disable-libstdcxx-pch --disable-checking --prefix=/home/dave/opt/gnu/gcc/gcc-4.4.0 --with-gmp=/home/dave/opt/gnu Thread model: posix gcc version 4.4.0 20090218 (experimental) [trunk revision 144268] (GCC) -- Summary: FAIL: gcc.dg/uninit-13.c Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: arm-none-linux-gnueabi GCC host triplet: arm-none-linux-gnueabi GCC target triplet: arm-none-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246
[Bug c++/39242] [4.4 Regression] Inconsistent reject / accept of code
--- Comment #10 from mark at codesourcery dot com 2009-02-19 16:41 --- Subject: Re: [4.4 Regression] Inconsistent reject / accept of code rguenth at gcc dot gnu dot org wrote: > The ultimate question is of course if the standard allows (or even requires) > an error here. The (someone old) C++ WP I have is pretty clear: "An explicit instantiation declaration that names a class template specialization has no effect on the class template specialization itself (except for perhaps resulting in its implicit instantiation). Except for inline functions, other explicit instantiation declarations have the effect of suppressing the implicit instantiation of the entity to which they refer. [ Note: The intent is that an inline function that is the subject of an explicit instantiation declaration will still be implicitly instantiated when used so that the body can be considered for inlining, but that no out-of-line copy of the inline function would be generated in the translation unit. âend note ]" Here, "inline function" is of course the C++ definition thereof, i.e., functions declared "inline" or defined in the body of a class definition, rather than outside the class. What that means is that we *must not* implicitly instantiate things declared "extern template" unless they are DECL_DECLARED_INLINE_P. As a consequence, at -O3, we cannot implicitly instantiate non-inline "extern template" functions. So, I think first hunk in the patch is correct. It needs a comment, though, right above DECL_DECLARED_INLINE to point out that this is a restriction coming from the standard: /* An explicit instantiation declaration prohibits implicit instantiation of non-inline functions. With high levels of optimization, we would normally inline non-inline functions -- but we're not allowed to do that for "extern template" functions. Therefore, we check DECL_DECLARED_INLINE_P, rather than possibly_inlined_p. */ OK with that change. I don't yet understand why the second hunk is required. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39242
[Bug tree-optimization/39245] New: FAIL: gcc.dg/memcpy-1.c scan-tree-dump-times optimized "nasty_local" 0
Executing on host: /home/dave/gnu/gcc/objdir/gcc/xgcc
-B/home/dave/gnu/gcc/objdi
r/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/memcpy-1.c -O2
-fdump-tree-
optimized -S -o memcpy-1.s(timeout = 300)
PASS: gcc.dg/memcpy-1.c (test for excess errors)
FAIL: gcc.dg/memcpy-1.c scan-tree-dump-times optimized "nasty_local" 0
-bash-3.2$ less memcpy-1.c.123t.optimized
;; Function test (test)
Analyzing Edge Insertions.
test (struct a a)
{
struct a nasty_local;
:
nasty_local = a;
return nasty_local.a;
}
-bash-3.2$ ./xgcc -B./ -v
Reading specs from ./specs
Target: arm-none-linux-gnueabi
Configured with: ../gcc/configure --host=arm-none-linux-gnueabi
--target=arm-none-linux-gnueabi --build=arm-none-linux-gnueabi
--disable-stage1-checking --enable-languages=c,c++,fortran --enable-shared
--enable-threads --disable-multilib --disable-libmudflap --disable-libssp
--enable-symvers=gnu --enable-__cxa_atexit --disable-libstdcxx-pch
--disable-checking --prefix=/home/dave/opt/gnu/gcc/gcc-4.4.0
--with-gmp=/home/dave/opt/gnu
Thread model: posix
gcc version 4.4.0 20090218 (experimental) [trunk revision 144268] (GCC)
--
Summary: FAIL: gcc.dg/memcpy-1.c scan-tree-dump-times optimized
"nasty_local" 0
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
GCC build triplet: arm-none-linux-gnueabi
GCC host triplet: arm-none-linux-gnueabi
GCC target triplet: arm-none-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39245
[Bug target/39244] Various cleanup tests fail
--- Comment #1 from danglin at gcc dot gnu dot org 2009-02-19 16:06 ---
(gdb) p i
$6 = 4
(gdb) p/x mask
$8 = 0x4ff0
(gdb) p/x ((phase1_vrs *)context)->core.r
$11 = {0x0, 0x0, 0xe, 0x817, 0x0, 0x0, 0xbee108d4, 0x0, 0x0, 0x861c, 0x0,
0x84bc, 0x0, 0x1c, 0x0, 0x40025000}
R_SP is 13. So, the problem is with the context.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39244
[Bug target/39244] New: Various cleanup tests fail
Various cleanup and other exception related tests fail: FAIL: gcc.dg/cleanup-10.c execution test FAIL: gcc.dg/cleanup-11.c execution test FAIL: gcc.dg/cleanup-8.c execution test FAIL: gcc.dg/cleanup-9.c execution test FAIL: g++.dg/ext/cleanup-10.C execution test FAIL: g++.dg/ext/cleanup-11.C execution test FAIL: g++.dg/ext/cleanup-8.C execution test FAIL: g++.dg/ext/cleanup-9.C execution test (gdb) r Starting program: /home/dave/gnu/gcc/objdir/gcc/testsuite/gcc/cleanup-8.xg Program received signal SIGSEGV, Segmentation fault. 0x8584 in fn2 () at /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/cleanup-8.c:74 74*null = 0; (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault. _Unwind_VRS_Pop (context=0xbee652a8, regclass=, discriminator=, representation=_UVRSD_FLOAT) at ../../../gcc/libgcc/../gcc/config/arm/unwind-arm.c:318 318 vrs->core.r[i] = *(ptr++); (gdb) bt #0 _Unwind_VRS_Pop (context=0xbee652a8, regclass=, discriminator=, representation=_UVRSD_FLOAT) at ../../../gcc/libgcc/../gcc/config/arm/unwind-arm.c:318 #1 0x400de694 in __gnu_unwind_execute (context=0xbee652a8, uws=0xbee6525c) at ../../../gcc/libgcc/../gcc/config/arm/pr-support.c:278 #2 0x400ddefc in __gnu_unwind_pr_common (state=_US_UNWIND_FRAME_STARTING, ucbp=0x11008, context=0xbee652a8, id=0) at ../../../gcc/libgcc/../gcc/config/arm/unwind-arm.c:1229 #3 0x400dd834 in unwind_phase2_forced (ucbp=0x11008, entry_vrs=, resuming=) at ../../../gcc/libgcc/../gcc/config/arm/unwind-arm.c:751 #4 0x400dd9c8 in __gnu_Unwind_Resume (ucbp=0x11008, entry_vrs=0xbee65764) at ../../../gcc/libgcc/../gcc/config/arm/unwind-arm.c:886 #5 0x400de400 in ___Unwind_Resume () at ../../../gcc/libgcc/../gcc/config/arm/libunwind.S:339 #6 0x8658 in fn4 (sig=) at /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/cleanup-8.c:43 #7 #8 0x8584 in fn2 () at /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/cleanup-8.c:74 #9 0x85c8 in fn1 () at /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/cleanup-8.c:83 #10 0x8690 in fn0 () ---Type to continue, or q to quit--- at /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/cleanup-8.c:90 #11 0x86d0 in main () at /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/cleanup-8.c:97 (gdb) p/x $pc $3 = 0x400ddae0 (gdb) disass 0x400ddad0 0x400ddaf0 Dump of assembler code from 0x400ddad0 to 0x400ddaf0: 0x400ddad0 <_Unwind_VRS_Pop+200>: ldr r1, [r0, #56] 0x400ddad4 <_Unwind_VRS_Pop+204>: lsr r2, r2, #16 0x400ddad8 <_Unwind_VRS_Pop+208>: mov r0, #1 ; 0x1 0x400ddadc <_Unwind_VRS_Pop+212>: andsr12, r2, r0, lsl r3 0x400ddae0 <_Unwind_VRS_Pop+216>: ldrne r5, [r1], #4 0x400ddae4 <_Unwind_VRS_Pop+220>: addne r12, r4, r3, lsl #2 0x400ddae8 <_Unwind_VRS_Pop+224>: add r3, r3, #1 ; 0x1 0x400ddaec <_Unwind_VRS_Pop+228>: strne r5, [r12, #4] End of assembler dump. (gdb) p/x $r1 $4 = 0x1c (gdb) p ptr $5 = (_uw *) 0x1c -bash-3.2$ ./xgcc -B./ -v Reading specs from ./specs Target: arm-none-linux-gnueabi Configured with: ../gcc/configure --host=arm-none-linux-gnueabi --target=arm-none-linux-gnueabi --build=arm-none-linux-gnueabi --disable-stage1-checking --enable-languages=c,c++,fortran --enable-shared --enable-threads --disable-multilib --disable-libmudflap --disable-libssp --enable-symvers=gnu --enable-__cxa_atexit --disable-libstdcxx-pch --disable-checking --prefix=/home/dave/opt/gnu/gcc/gcc-4.4.0 --with-gmp=/home/dave/opt/gnu Thread model: posix gcc version 4.4.0 20090218 (experimental) [trunk revision 144268] (GCC) -- Summary: Various cleanup tests fail Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: arm-none-linux-gnueabi GCC host triplet: arm-none-linux-gnueabi GCC target triplet: arm-none-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39244
[Bug target/39241] [4.4 Regression] ICE in subreg_get_info, at rtlanal.c:3104
--- Comment #2 from hjl dot tools at gmail dot com 2009-02-19 15:44 --- It is caused by revision 138804: http://gcc.gnu.org/ml/gcc-cvs/2008-08/msg00363.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||jsm28 at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-02-19 15:44:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39241
[Bug c++/39242] [4.4 Regression] Inconsistent reject / accept of code
--- Comment #9 from hubicka at ucw dot cz 2009-02-19 15:40 --- Subject: Re: [4.4 Regression] Inconsistent reject / accept of code > /* Check to see whether we know that this template will be > instantiated in some other file, as with "extern template" > extension. */ > external_p = (DECL_INTERFACE_KNOWN (d) && DECL_REALLY_EXTERN (d)); > /* In general, we do not instantiate such templates... */ > if (external_p > /* ... but we instantiate inline functions so that we can inline > them and ... */ > && ! (TREE_CODE (d) == FUNCTION_DECL > && DECL_DECLARED_INLINE_P (d)) Hmm, in general it is benefical to instantiate stuff for sake of IPA optimizers. It would be interesting to know how this affects code quality... Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39242
[Bug fortran/39239] Reject SAVEd variables EQUIVALENCEd to a COMMON
--- Comment #1 from burnus at gcc dot gnu dot org 2009-02-19 15:37 ---
I now asked at c.l.f but so far there was no direct pointer to the standard.
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/695d799c2e81b1b3
I think (in line with the replies in c.l.f) that
"C517 (R501) The SAVE attribute shall not be specified for an object that is in
a common block [...]"
plus some wording in the storage association part of the standard implies that
an object which is equivalent to a common object is also itself a common
object.
If I read Tim's reply correctly, ifort has only a warning since the SAVE does
not matter: COMMON block variables are always in the static memory ("SAVE").
Still, I would follow sunf95/openf95/pathf95 (which all seem to have a common
linage) and print an error and not a warning.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39239
[Bug c++/39188] G++ doesn't handle static anonymous union right
--- Comment #4 from hjl at gcc dot gnu dot org 2009-02-19 15:22 --- Subject: Bug 39188 Author: hjl Date: Thu Feb 19 15:22:28 2009 New Revision: 144297 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144297 Log: gcc/ 2009-02-19 H.J. Lu PR c++/39188 * varasm.c (assemble_variable): Don't check DECL_NAME when globalizing a variable. gcc/cp/ 2009-02-19 H.J. Lu PR c++/39188 * cp-tree.h (maybe_commonize_var): New. * decl.c (maybe_commonize_var): Make it extern. * decl2.c (finish_anon_union): Call maybe_commonize_var. gcc/testsuite/ 2009-02-19 H.J. Lu PR c++/39188 * g++.dg/abi/pr39188-1a.C: New. * g++.dg/abi/pr39188-1b.C: Likewise. * g++.dg/abi/pr39188-1.h: Likewise. * g++.dg/abi/pr39188-2a.C: Likewise. * g++.dg/abi/pr39188-2b.C: Likewise. * g++.dg/abi/pr39188-2.h: Likewise. * g++.dg/abi/pr39188-3a.C: Likewise. * g++.dg/abi/pr39188-3b.C: Likewise. * g++.dg/abi/pr39188-3.h: Likewise. Added: trunk/gcc/testsuite/g++.dg/abi/pr39188-1.h trunk/gcc/testsuite/g++.dg/abi/pr39188-1a.C trunk/gcc/testsuite/g++.dg/abi/pr39188-1b.C trunk/gcc/testsuite/g++.dg/abi/pr39188-2.h trunk/gcc/testsuite/g++.dg/abi/pr39188-2a.C trunk/gcc/testsuite/g++.dg/abi/pr39188-2b.C trunk/gcc/testsuite/g++.dg/abi/pr39188-3.h trunk/gcc/testsuite/g++.dg/abi/pr39188-3a.C trunk/gcc/testsuite/g++.dg/abi/pr39188-3b.C Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/decl2.c trunk/gcc/testsuite/ChangeLog trunk/gcc/varasm.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39188
[Bug c++/39242] [4.4 Regression] Inconsistent reject / accept of code
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-02-19 15:20 --- Note that the patch only affects extern explicit template instantiations. /* Check to see whether we know that this template will be instantiated in some other file, as with "extern template" extension. */ external_p = (DECL_INTERFACE_KNOWN (d) && DECL_REALLY_EXTERN (d)); /* In general, we do not instantiate such templates... */ if (external_p /* ... but we instantiate inline functions so that we can inline them and ... */ && ! (TREE_CODE (d) == FUNCTION_DECL && DECL_DECLARED_INLINE_P (d)) For them we would no longer inline (or rather instantiate) not inline declared members. This may affect parts of libstdc++, but I don't know. In YCP the extern trick seems to be used to break a dependency cycle, so the situation is somewhat special. The ultimate question is of course if the standard allows (or even requires) an error here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39242
[Bug libstdc++/39243] New: Invalid thousands separator in russian locale
I create this simple program:
#include
#include
#include
#include
using namespace std;
int main()
{
locale loc("ru_RU.UTF-8");
cout.imbue(loc);
cout << 1234.56 << std::endl;
setlocale(LC_NUMERIC, "ru_RU.UTF-8");
printf("%'.2f\n", 1234.56);
return 0;
}
Result is:
1?234,56: (in hex): \x31\xC2\x32\x33\x34\x2C\x35\x36
1 234,56: (in hex): \x31\x20\x32\x33\x34\x2C\x35\x36
Here '?' is invalid symbol \xC2
then I try (code in C):
#include
#include
int main() {
setlocale(LC_ALL, "ru_RU.UTF-8");
printf("\"%s\"\n", localeconv()->thousands_sep);
printf("%f\n", 1234.56);
return 0;
}
Output is: " " (one space in double quotes)
--
Summary: Invalid thousands separator in russian locale
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Sergey dot Belyashov at gmail dot com
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39243
[Bug c++/39242] [4.4 Regression] Inconsistent reject / accept of code
--- Comment #7 from hubicka at ucw dot cz 2009-02-19 14:59 --- Subject: Re: [4.4 Regression] Inconsistent reject / accept of code > Index: cp/pt.c > === > --- cp/pt.c (revision 144292) > +++ cp/pt.c (working copy) > @@ -15285,7 +15285,7 @@ instantiate_decl (tree d, int defer_ok, >/* ... but we instantiate inline functions so that we can inline > them and ... */ >&& ! (TREE_CODE (d) == FUNCTION_DECL > - && possibly_inlined_p (d)) > + && DECL_DECLARED_INLINE_P (d)) this way we will lose inlining opurtunities at -O3, sine we will never instantiate methods not declared inline. Is standard really making difference in between inline and !inline here? Or we are just supposed to suppress the errors and instantiate only stuff that is complette or are we supposed to give error at -O0 too or is it up to our choice? Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39242
[Bug middle-end/38694] gcc.c-torture/compile/pr11832.c and pr33009.c -frtl-abstract-sequences ICE on arm-linux-gnueabi on 4.3.2 and trunk
--- Comment #4 from danglin at gcc dot gnu dot org 2009-02-19 14:58 --- Confirmed with: -bash-3.2$ ../../xgcc -B../../ -v Reading specs from ../../specs Target: arm-none-linux-gnueabi Configured with: ../gcc/configure --host=arm-none-linux-gnueabi --target=arm-none-linux-gnueabi --build=arm-none-linux-gnueabi --disable-stage1-checking --enable-languages=c,c++,fortran --enable-shared --enable-threads --disable-multilib --disable-libmudflap --disable-libssp --enable-symvers=gnu --enable-__cxa_atexit --disable-libstdcxx-pch --disable-checking --prefix=/home/dave/opt/gnu/gcc/gcc-4.4.0 --with-gmp=/home/dave/opt/gnu Thread model: posix gcc version 4.4.0 20090218 (experimental) [trunk revision 144268] (GCC) -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-02-19 14:58:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38694
[Bug rtl-optimization/11832] Optimization of common code in switch statements
--- Comment #7 from danglin at gcc dot gnu dot org 2009-02-19 14:52 --- Reconfirmed with trunk revision 144268. -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11832
[Bug c++/39242] [4.4 Regression] Inconsistent reject / accept of code
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-02-19 14:51 --- Note that in the original testcase YStatement is incomplete, but properly derives from Rep in the TU with the explicit instantiation of RepPtrStore. Instead of not instantiating so much we could also try to suppress errors (like SFINAE) here. Of course reading the C++0x standard about explicit instantiation declarations isn't very conclusive (either there's no explanation or everything covering explicit instantiations also covers their declarations). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||mark at codesourcery dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39242
[Bug c++/39242] [4.4 Regression] Inconsistent reject / accept of code
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-02-19 14:30 --- Or rather we don't want template instantiation (and errors from it) to differ from optimized to non-optimized build. So, Index: cp/pt.c === --- cp/pt.c (revision 144292) +++ cp/pt.c (working copy) @@ -15285,7 +15285,7 @@ instantiate_decl (tree d, int defer_ok, /* ... but we instantiate inline functions so that we can inline them and ... */ && ! (TREE_CODE (d) == FUNCTION_DECL - && possibly_inlined_p (d)) + && DECL_DECLARED_INLINE_P (d)) /* ... we instantiate static data members whose values are needed in integral constant expressions. */ && ! (TREE_CODE (d) == VAR_DECL @@ -15363,7 +15363,7 @@ instantiate_decl (tree d, int defer_ok, /* Instantiate inline functions so that the inliner can do its job, even though we'll not be emitting a copy of this function. */ - if (!(TREE_CODE (d) == FUNCTION_DECL && possibly_inlined_p (d))) + if (!(TREE_CODE (d) == FUNCTION_DECL && !DECL_UNINLINABLE (d))) goto out; } ? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39242
[Bug c++/39242] [4.4 Regression] Inconsistent reject / accept of code
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-02-19 14:19 ---
This fixes it for me:
Index: decl2.c
===
--- decl2.c (revision 144292)
+++ decl2.c (working copy)
@@ -3755,7 +3755,8 @@ bool
possibly_inlined_p (tree decl)
{
gcc_assert (TREE_CODE (decl) == FUNCTION_DECL);
- if (DECL_UNINLINABLE (decl))
+ if (DECL_UNINLINABLE (decl)
+ || DECL_REALLY_EXTERN (decl))
return false;
if (!optimize)
return DECL_DECLARED_INLINE_P (decl);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39242
[Bug c/38483] generated aborts lose previous side-effects
--- Comment #3 from jsm28 at gcc dot gnu dot org 2009-02-19 13:56 --- Fixed for 4.4.0. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38483
[Bug c/38483] generated aborts lose previous side-effects
--- Comment #2 from jsm28 at gcc dot gnu dot org 2009-02-19 13:56 --- Subject: Bug 38483 Author: jsm28 Date: Thu Feb 19 13:56:00 2009 New Revision: 144296 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144296 Log: PR c/38483 * builtins.c (gimplify_va_arg_expr): Evaluate the va_list expression before any __builtin_trap call. * c-typeck.c (build_function_call): Convert and check function arguments before generating a call to a trap. Evaluate the function arguments before the trap. testsuite: * gcc.c-torture/execute/call-trap-1.c, gcc.c-torture/execute/va-arg-trap-1.c, gcc.dg/call-diag-1.c: New tests. Added: trunk/gcc/testsuite/gcc.c-torture/execute/call-trap-1.c trunk/gcc/testsuite/gcc.c-torture/execute/va-arg-trap-1.c trunk/gcc/testsuite/gcc.dg/call-diag-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/c-typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38483
[Bug c++/39242] [4.4 Regression] Inconsistent reject / accept of code
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-02-19 13:50 --- The error is that RepPtrStore::assign is instantiated at all in face of extern template class RepPtrStore; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39242
[Bug c++/39242] [4.4 Regression] Inconsistent reject / accept of code
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-02-19 13:46 --- Randomly poking around the tree shows Index: cp/ChangeLog === --- cp/ChangeLog(revision 138149) +++ cp/ChangeLog(revision 138150) @@ -1,3 +1,20 @@ +2008-07-25 Jan Hubicka + + * typeck.c (inline_conversion): Remove. + (cp_build_function_call): Do not use inline_conversion. + * decl.c (duplicate_decls): Do not insist on inline being declared + early. + (start_cleanup_fn): Do not assume that INLINE flags prevent function + from being output. We now remove static functions always. + (finish_function): Do return warning on all static functions. + * call.c (build_over_call): Do not use inline_conversion. + * cp-tree.h (possibly_inlined_p): Declare. + (inline_conversion): Remove. + * pt.c (instantiate_decl): Use possibly_inlined_p predicate. + * decl2.c (cp_write_global_declarations): Likewise. + (mark_used): Likewise. + (possibly_inlined_p): New functions. as very likely candidate introducing the regression (the optimize dependency). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39242
[Bug target/35294] iwmmxt intrinsics, internal compiler error
--- Comment #2 from ixt at nm dot ru 2009-02-19 13:44 ---
Testing sample with gcc-4.3.3 (released after 2009-01-02 12:06) also fail:
sergeyhost:/tmp$ cat ./main.c
#include
void foo()
{
_mm_srli_pi16(_mm_setzero_si64(), 8);
}
sergeyhost:/tmp$
sergeyhost:/tmp$ arm-iwmmx-linux-gnueabi-gcc -flax-vector-conversions -c -O2
./main.c
/opt/toolchain/arm-iwmmx-linux-gnueabi/gcc-4.3.3-glibc-2.8-binutils-2.18-kernel-2.6.22-sanitized/lib/gcc/arm-iwmmx-linux-gnueabi/4.3.3/include/mmintrin.h:
In function 'foo':
/opt/toolchain/arm-iwmmx-linux-gnueabi/gcc-4.3.3-glibc-2.8-binutils-2.18-kernel-2.6.22-sanitized/lib/gcc/arm-iwmmx-linux-gnueabi/4.3.3/include/mmintrin.h:529:
internal compiler error: in arm_expand_binop_builtin, at config/arm/arm.c:15380
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
sergeyhost:/tmp$
I am use OSELAS.Toolchan-1.99.3
arm-iwmmx-linux-gnueabi_gcc-4.3.2_glibc-2.8_binutils-2.18_kernel-2.6.27-sanitized
with small changes for me (update compiler because in contains "regression
fixes and docs only" and downgrade kernel headers). I think this changes
unimportant for bug.
--
ixt at nm dot ru changed:
What|Removed |Added
CC||ixt at nm dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35294
[Bug c++/39242] [4.4 Regression] Inconsistent reject / accept of code
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39242
[Bug c++/39242] [4.4 Regression] Inconsistent reject / accept of code
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-19 13:40 --- Created an attachment (id=17329) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17329&action=view) original testcase Original testcase from Yast YCP. Requires -std=c++0x. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39242
[Bug c++/39242] New: [4.4 Regression] Inconsistent reject / accept of code
With -O0 the following is accepted, with -O1 it is rejected with
Parser.3.ii: In member function void RepPtrStore<_Tp, _Bt>::_assign(_Tp*)
[with _Tp = YStatement, _Bt = YCode]:
Parser.3.ii:11: instantiated from RepPtrStore<_Tp, _Bt>::~RepPtrStore()
[with _Tp = YStatement, _Bt = YCode]
Parser.3.ii:21: instantiated from here
Parser.3.ii:16: error: no matching function for call to
Rep::unref(YStatement*&)
Parser.3.ii:3: note: candidates are: void Rep::unref() const
Parser.3.ii:4: note: static void Rep::unref(const Rep*)
testcase:
class Rep {
public:
void unref() const { }
static void unref (const Rep * obj_r) { obj_r->unref(); }
};
template
class RepPtrStore {
_Tp * _obj;
void _assign( _Tp * new_r );
public:
~RepPtrStore() { _assign( 0 ); }
};
template
void RepPtrStore<_Tp,_Bt>::_assign( _Tp * new_r )
{
Rep::unref( _obj );
}
class RepPtrBase { };
template class PtrBase : public RepPtrBase { };
template
class Ptr : public PtrBase<_Bt> {
RepPtrStore<_Tp,_Bt> _ptr;
};
class YCode;
class YStatement;
typedef Ptr YStatementPtr;
extern template class RepPtrStore;
class ExecutionEnvironment {
YStatementPtr m_statement;
~ExecutionEnvironment() { };
};
GCC 4.3 accepts the code unconditionally, so does EDG.
--
Summary: [4.4 Regression] Inconsistent reject / accept of code
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39242
[Bug target/39241] [4.4 Regression] ICE in subreg_get_info, at rtlanal.c:3104
--- Comment #1 from jakub at gcc dot gnu dot org 2009-02-19 13:16 ---
Reduced testcase:
static inline int
foo (float f)
{
return *((int *) &f) - 1;
}
float
bar (float x, float y, float *z)
{
float c = y < 0.002f ? 0.002f : y;
float d = x < c ? c : x;
return z[foo (c)] + z[foo (d * 255.0f)];
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39241
[Bug debug/38479] Incorrect dwarf generated for function with parameters greater 4 words in length
--- Comment #5 from francois at b-powers dot be 2009-02-19 13:10 --- Any update on this bug ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38479
[Bug target/39228] [4.3/4.4 Regression] 387 optimised __builtin_isinf() gives incorrect result
--- Comment #7 from ubizjak at gmail dot com 2009-02-19 12:58 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- |http://gcc.gnu.org/ml/gcc- |patches/2009- |patches/2009- |02/msg00825.html|02/msg00899.html Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39228
[Bug target/39240] [4.2/4.3/4.4 Regression] Invalid sibcall optimization with promoted return types and differing signedness
--- Comment #2 from jakub at gcc dot gnu dot org 2009-02-19 12:45 --- Created an attachment (id=17328) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17328&action=view) gcc44-pr39240.patch Patch I'm going to bootstrap/regtest. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39240
[Bug target/39228] [4.3/4.4 Regression] 387 optimised __builtin_isinf() gives incorrect result
--- Comment #6 from uros at gcc dot gnu dot org 2009-02-19 12:44 --- Subject: Bug 39228 Author: uros Date: Thu Feb 19 12:44:40 2009 New Revision: 144295 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144295 Log: PR target/39228 * config/i386/i386.md (isinfxf2): Split from isinf2. (UNSPEC_FXAM_MEM): New unspec. (fxam2_i387_with_temp): New insn and split pattern. (isinf2): Use MODEF mode iterator. Force operand[1] through memory using fxam2_i387_with_temp to remove excess precision. testsuite/ChangeLog: PR target/39228 * gcc.c-torture/execute/pr39228.c: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/execute/pr39228.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/config/i386/i386.md branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39228
[Bug target/39241] [4.4 Regression] ICE in subreg_get_info, at rtlanal.c:3104
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39241
[Bug target/39241] New: [4.4 Regression] ICE in subreg_get_info, at rtlanal.c:3104
ICEs with -O[123s], likely due to the VIEW_CONVERT_EXPR we construct from
*((int*)&f) after inlining.
struct FTprocCompressor {
float * _amp;
float * _env;
float * _as;
};
static inline int f_round(float f)
{
return *((int*)&f) - 0x4b40;
}
void process (struct FTprocCompressor *_this, float *attack, float *release,
float *data, unsigned int fftn)
{
float ga;
float gr;
float att, rel;
int fftN2 = (fftn+1) >> 1;
int i;
for (i = 0; i < fftN2-1; i++)
{
att =
((attack[i])<(0.002f)?(0.002f):((attack[i])>(1.0f)?(1.0f):(attack[i])));
rel =
((release[i])<(att)?(att):((release[i])>(1.0f)?(1.0f):(release[i])));
ga = _this->_as[f_round(att * (float)(256 -1))];
gr = _this->_as[f_round(rel * (float)(256 -1))];
if (_this->_amp[i] > _this->_env[i])
{
_this->_env[i] = _this->_env[i] * ga + _this->_amp[i] * (1.0f - ga);
_this->_env[i] = _this->_env[i] * gr + _this->_amp[i] * (1.0f - gr);
}
}
}
--
Summary: [4.4 Regression] ICE in subreg_get_info, at
rtlanal.c:3104
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
GCC target triplet: i?86-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39241
[Bug target/39240] [4.2/4.3/4.4 Regression] Invalid sibcall optimization with promoted return types and differing signedness
--- Comment #1 from jakub at gcc dot gnu dot org 2009-02-19 11:16 --- Ah, it is a regression from 3.4.x. -- 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 | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Priority|P3 |P1 Last reconfirmed|-00-00 00:00:00 |2009-02-19 11:16:54 date|| Summary|Invalid sibcall optimization|[4.2/4.3/4.4 Regression] |with promoted return types |Invalid sibcall optimization |and differing signedness|with promoted return types ||and differing signedness Target Milestone|--- |4.2.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39240
[Bug target/39240] New: Invalid sibcall optimization with promoted return types and differing signedness
extern void abort (void);
__attribute__ ((noinline))
static int foo1 (int x)
{
return x;
}
__attribute__ ((noinline))
unsigned int bar1 (int x)
{
return foo1 (x + 6);
}
unsigned long l1 = (unsigned int) -4;
__attribute__ ((noinline))
static short int foo2 (int x)
{
return x;
}
__attribute__ ((noinline))
unsigned short int bar2 (int x)
{
return foo2 (x + 6);
}
unsigned long l2 = (unsigned short int) -4;
__attribute__ ((noinline))
static signed char foo3 (int x)
{
return x;
}
__attribute__ ((noinline))
unsigned char bar3 (int x)
{
return foo3 (x + 6);
}
unsigned long l3 = (unsigned char) -4;
__attribute__ ((noinline))
static unsigned int foo4 (int x)
{
return x;
}
__attribute__ ((noinline))
int bar4 (int x)
{
return foo4 (x + 6);
}
unsigned long l4 = (int) -4;
__attribute__ ((noinline))
static unsigned short int foo5 (int x)
{
return x;
}
__attribute__ ((noinline))
short int bar5 (int x)
{
return foo5 (x + 6);
}
unsigned long l5 = (short int) -4;
__attribute__ ((noinline))
static unsigned char foo6 (int x)
{
return x;
}
__attribute__ ((noinline))
signed char bar6 (int x)
{
return foo6 (x + 6);
}
unsigned long l6 = (signed char) -4;
int
main (void)
{
if (bar1 (-10) != l1)
abort ();
if (bar2 (-10) != l2)
abort ();
if (bar3 (-10) != l3)
abort ();
if (bar4 (-10) != l4)
abort ();
if (bar5 (-10) != l5)
abort ();
if (bar6 (-10) != l6)
abort ();
return 0;
}
aborts on powerpc64-linux, both -m32 and -m64, at -O2 and higher (whenever
-foptimize-sibling-calls is in effect). In 4.4 this causes a Linux kernel
miscompilation on ppc64, see https://bugzilla.redhat.com/show_bug.cgi?id=485067
so to some extent it could be considered a regression, that said, the testcase
I'm providing here fails with 4.1, 4.3 as well as trunk.
As the psABI says that integral return values are passed in r3 and
zero-extended/sign-extended as needed to 64-bits (32-bits for 32-bit psABI),
obviously integral types with smaller precision than that need to have the same
signedness between caller and tail callee.
Just wonder whether this is something that should be fixed in rs6000
function_ok_for_sibcall hook (would probably be less risky for 4.4 and release
branches) or whether calls.c should do that generically.
--
Summary: Invalid sibcall optimization with promoted return types
and differing signedness
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39240
[Bug target/39228] [4.3/4.4 Regression] 387 optimised __builtin_isinf() gives incorrect result
--- Comment #5 from uros at gcc dot gnu dot org 2009-02-19 10:51 --- Subject: Bug 39228 Author: uros Date: Thu Feb 19 10:51:04 2009 New Revision: 144293 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144293 Log: PR target/39228 * config/i386/i386.md (isinfxf2): Split from isinf2. (UNSPEC_FXAM_MEM): New unspec. (fxam2_i387_with_temp): New insn and split pattern. (isinf2): Use MODEF mode iterator. Force operand[1] through memory using fxam2_i387_with_temp to remove excess precision. testsuite/ChangeLog: PR target/39228 * gcc.c-torture/execute/pr39228.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr39228.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39228
[Bug tree-optimization/39074] [4.2/4.3 Regression] PTA constraint processing for *x = y is wrong
--- Comment #18 from rguenth at gcc dot gnu dot org 2009-02-19 10:13 --- Fixed on the trunk as well. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.1.3 4.2.4 4.3.3 4.4.0 |4.1.3 4.2.4 4.3.3 Known to work|4.0.4 |4.0.4 4.4.0 Summary|[4.2/4.3/4.4 Regression] PTA|[4.2/4.3 Regression] PTA |constraint processing for *x|constraint processing for *x |= y is wrong|= y is wrong http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39074
[Bug tree-optimization/39207] [4.4 Regression] Strict aliasing warnings in libstdc++ headers
--- Comment #18 from rguenth at gcc dot gnu dot org 2009-02-19 10:12 --- Fixed again. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39207
[Bug tree-optimization/39074] [4.2/4.3/4.4 Regression] PTA constraint processing for *x = y is wrong
--- Comment #17 from rguenth at gcc dot gnu dot org 2009-02-19 10:12 --- Subject: Bug 39074 Author: rguenth Date: Thu Feb 19 10:12:25 2009 New Revision: 144292 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144292 Log: 2009-02-19 Richard Guenther PR tree-optimization/39207 PR tree-optimization/39074 * tree-ssa-structalias.c (storedanything_id, var_storedanything, storedanything_tree): New. (do_ds_constraint): Simplify ANYTHING shortcutting. Update the STOREDANYTHING solution if the lhs solution contains ANYTHING. (build_succ_graph): Add edges from STOREDANYTHING to all non-direct nodes. (init_base_vars): Initialize STOREDANYTHING. (compute_points_to_sets): Free substitution info after building the succ graph. (ipa_pta_execute): Likewise. * gcc.dg/torture/pr39074.c: New testcase. * gcc.dg/torture/pr39074-2.c: Likewise. * gcc.dg/torture/pr39074-3.c: Likewise. * tree-ssa-structalias.c (struct variable_info): Add may_have_pointers field. (do_ds_constraint): Do not add to special var or non-pointer field solutions. (type_could_have_pointers): Split out from ... (could_have_pointers): ... here. For arrays use the element type. (create_variable_info_for): Initialize may_have_pointers. (new_var_info): Likewise. (handle_lhs_call): Make the HEAP variable unknown-sized. (intra_create_variable_infos): Use a type with pointers for PARM_NOALIAS, make it unknown-sized. Added: trunk/gcc/testsuite/gcc.dg/torture/pr39074-2.c trunk/gcc/testsuite/gcc.dg/torture/pr39074-3.c trunk/gcc/testsuite/gcc.dg/torture/pr39074.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-structalias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39074
[Bug tree-optimization/39207] [4.4 Regression] Strict aliasing warnings in libstdc++ headers
--- Comment #17 from rguenth at gcc dot gnu dot org 2009-02-19 10:12 --- Subject: Bug 39207 Author: rguenth Date: Thu Feb 19 10:12:25 2009 New Revision: 144292 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144292 Log: 2009-02-19 Richard Guenther PR tree-optimization/39207 PR tree-optimization/39074 * tree-ssa-structalias.c (storedanything_id, var_storedanything, storedanything_tree): New. (do_ds_constraint): Simplify ANYTHING shortcutting. Update the STOREDANYTHING solution if the lhs solution contains ANYTHING. (build_succ_graph): Add edges from STOREDANYTHING to all non-direct nodes. (init_base_vars): Initialize STOREDANYTHING. (compute_points_to_sets): Free substitution info after building the succ graph. (ipa_pta_execute): Likewise. * gcc.dg/torture/pr39074.c: New testcase. * gcc.dg/torture/pr39074-2.c: Likewise. * gcc.dg/torture/pr39074-3.c: Likewise. * tree-ssa-structalias.c (struct variable_info): Add may_have_pointers field. (do_ds_constraint): Do not add to special var or non-pointer field solutions. (type_could_have_pointers): Split out from ... (could_have_pointers): ... here. For arrays use the element type. (create_variable_info_for): Initialize may_have_pointers. (new_var_info): Likewise. (handle_lhs_call): Make the HEAP variable unknown-sized. (intra_create_variable_infos): Use a type with pointers for PARM_NOALIAS, make it unknown-sized. Added: trunk/gcc/testsuite/gcc.dg/torture/pr39074-2.c trunk/gcc/testsuite/gcc.dg/torture/pr39074-3.c trunk/gcc/testsuite/gcc.dg/torture/pr39074.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-structalias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39207
[Bug fortran/39239] New: Reject SAVEd variables EQUIVALENCEd to a COMMON
The following program is presumably invalid (I have not checked the standard). ifort and sunf95 reject it with: warning #6755: A COMMON block data object may not have the SAVE attribute. ERROR: Object "I2" has the SAVE attribute, so it must not be equivalenced to an object in a common block. Ad hoc I don't see why it is only a warning and not an error with ifort. (g95, gfortran, NAG 95 accept it without warning.) integer :: i1, i2 common /block/ i1 save i2 equivalence(i1,i2) end -- Summary: Reject SAVEd variables EQUIVALENCEd to a COMMON Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39239
