[Bug c++/39511] New: Bad warning, with return type, switch and enum
I have:
main.cpp: In function 'QString parityToString(ParityType)':
main.cpp:312: warning: control reaches end of non-void function
When:
enum ParityType
{
PAR_NONE,
PAR_ODD,
PAR_EVEN,
PAR_MARK, //WINDOWS ONLY
PAR_SPACE
};
And my function:
QString parityToString(ParityType value)
{
switch(value)
{
case PAR_NONE:
return "none";
case PAR_ODD:
return "odd";
case PAR_EVEN:
return "even";
case PAR_MARK:
return "mark";
case PAR_SPACE:
return "space";
}
}
--
Summary: Bad warning, with return type, switch and enum
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alpha dot super-one at laposte dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39511
[Bug driver/39356] assembler isn't called
--- Comment #11 from nightstrike at gmail dot com 2009-03-20 05:28 --- I can confirm that our 4.3 release worked, and that this is a 4.4 regression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39356
[Bug target/27288] barfs on glibc code with an ICE (freescale's messy targets)
--- Comment #5 from bje at gcc dot gnu dot org 2009-03-20 04:59 --- Closing as this has been fixed in numerous releases for some time. -- bje at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27288
[Bug target/15767] ppc-linux type attribute aligned, packed on vector types behaves wrongly
--- Comment #3 from bje at gcc dot gnu dot org 2009-03-20 04:45 --- The first test case (t.c) now works correctly on mainline. The second still does not work correctly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15767
[Bug c/38847] error: Link tests are not allowed after GCC_NO_EXECUTABLES
--- Comment #2 from bje at gcc dot gnu dot org 2009-03-20 04:06 --- You should not be using --target=powerpc-405-linux-gnu, as this is not a valid triplet. You should be using --target=powerpc-linux-gnu. -- bje at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38847
[Bug c++/39509] bad optimization(?) pure virtual function call with -O2
--- Comment #2 from eric dot niebler at gmail dot com 2009-03-20 04:04 --- Additional information: adding "__attribute__((noinline))" to the constructor for xpression_adaptor (line 82452) makes the problem go away. Definitely looks like an optimization problem to me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39509
[Bug rtl-optimization/39510] New: [avr] missed optimisation with IO read and register variables
Code:
#include
register uint8_t test asm("r2");
int main(void)
{
test = TCNT0;
}
Compiled with -Os results in the following instruction sequence:
0092 :
92: 82 b7 in r24, 0x32 ; 50
94: 28 2e mov r2, r24
96: 08 95 ret
This is particularly nasty for naked interrupts, where one would expect the
compiler to generate just a single instruction:
in r2, 0x32
Apparently the compiler behaves correctly when opposite transfer is requested,
generating single OUT opcode.
--
Summary: [avr] missed optimisation with IO read and register
variables
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: k dot kosciuszkiewicz+gcc at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39510
[Bug c++/39509] bad optimization(?) pure virtual function call with -O2
--- Comment #1 from eric dot niebler at gmail dot com 2009-03-20 03:03 --- Created an attachment (id=17501) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17501&action=view) tarred, gzipped preprocessed c++ source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39509
[Bug c++/39509] New: bad optimization(?) pure virtual function call with -O2
When attached code is compiled with "g++ -01 -x c++ main.i" the result executes file. When compiled with -O2 it segfaults with "pure virtual function call". This may be a case of an overeager optimization. -- Summary: bad optimization(?) pure virtual function call with -O2 Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: eric dot niebler at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39509
[Bug bootstrap/31418] Bootstrap failure with -O2 -funroll-loops -funsafe-math-optimizations options on PPC
--- Comment #1 from bje at gcc dot gnu dot org 2009-03-20 02:46 --- Reproduced today with current tip of the 4.3 branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31418
[Bug fortran/39505] Consider a 'no arg check' directive
--- Comment #3 from w6ws at earthlink dot net 2009-03-20 02:13 --- Subject: Re: Consider a 'no arg check' directive Gents, I was unaware of Bills TR proposal for a TYPE(*). This is good news, and would totally solve the problem. BTW, the no_arg_check directive actually works pretty well in practice. But I agree that if a TR to address the problem is within sight, gfortran should wait for that. Walter -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39505
[Bug debug/39355] [4.4 Regression] Revision 144529 miscompiled libcpp/expr.c
--- Comment #29 from dave at hiauly1 dot hia dot nrc dot ca 2009-03-20 01:30 --- Subject: Re: [4.4 Regression] Revision 144529 miscompiled libcpp/expr.c > I'd say first try to add noinline attribute on all callers of num_positive, if > it fails even with those, add also __attribute__((__optimize__(0))) to them > one > by one. If the noinline attribute to those makes the miscompilation go away, > search one by one which one it is and retry with all callers of that function. With todays, head, it seems the miscompilation is related to the inlining of check_promotion. Adding noinline attribute makes the ICE go away. Adding __attribute__((__optimize__(0))) or __attribute__((__optimize__(1))) also makes the ICE go away. Removing either half of the "if (op->value.unsignedp)" also makes the ICE go away. However, I haven't been able to spot the actual miscompilation yet. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355
[Bug bootstrap/39503] [4.4 Regression] libgcc2.c doesn't compile anymore
--- Comment #4 from sezeroz at gmail dot com 2009-03-19 23:27 ---
Regarding that the former type was int instead of DWORD, my suggest would be
replacing DWORD by unsigned int, like:
--- gcc/gcc/libgcc2.c.orig
+++ gcc/gcc/libgcc2.c
@@ -2068,7 +2068,7 @@ getpagesize (void)
int
mprotect (char *addr, int len, int prot)
{
- DWORD np, op;
+ unsigned int np, op;
if (prot == 7)
np = 0x40;
... that is, of course, if the headers are really not to blame.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39503
[Bug regression/39508] gcc libdecnumber 4.3.4 & 4.3.3 x86_64 linux : /usr/bin/ld: /usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.4//libgcc.a(bid_decimal_globals.o): TLS transition from R_X86_64_TLSGD to R_
--- Comment #3 from jason dot vas dot dias at gmail dot com 2009-03-19 23:22 --- RE: Comment #1 : Sorry, the linker input files contain proprietary software of my employer that I am legally prohibited from sharing - if the new binutils doesn't fix it, I'll try to get permission tomorrow to send you a link map file . RE: Comment #2 : I'm trying the binutils now. CORRECTION TO DESCRIPTION : Sorry, I think "GCC-4.3.4" was a version of my own invention to distinguish this version, which was entirely unmodified gcc source from : svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch with .svn config tag : 2009-02-23T00:16:27.324527Z from the unmodified Gentoo portage ebuild of gcc-4.3.3.ebuild with all gentoo patches applied; this version, which was of course also gcc-4.3.3 , also exhibited the bug , and differed in being a slightly earlier 4.3.3 checkout and from having the '--disable-altivec' configure argument - BTW, anyone know why the gentoo folk do that ? I've been using 4.1.2, 4.2.2, 4.2.3 without --disable-altivec with no problems. Anyway, many thanks - the latest binutils is building now and I'll post back with the results. -- jason dot vas dot dias at gmail dot com changed: What|Removed |Added Known to fail|4.3.3 4.3.4 |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39508
[Bug regression/39508] gcc libdecnumber 4.3.4 & 4.3.3 x86_64 linux : /usr/bin/ld: /usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.4//libgcc.a(bid_decimal_globals.o): TLS transition from R_X86_64_TLSGD to R_
--- Comment #2 from hjl dot tools at gmail dot com 2009-03-19 22:35 --- I think it may be the same as http://www.sourceware.org/bugzilla/show_bug.cgi?id=9938 Please try the current binutils in CVS. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39508
[Bug regression/39508] gcc libdecnumber 4.3.4 & 4.3.3 x86_64 linux : /usr/bin/ld: /usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.4//libgcc.a(bid_decimal_globals.o): TLS transition from R_X86_64_TLSGD to R_
--- Comment #1 from hjl dot tools at gmail dot com 2009-03-19 22:24 --- Please provide all linker input files so that I can reproduce it. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39508
[Bug bootstrap/39503] [4.4 Regression] libgcc2.c doesn't compile anymore
--- Comment #3 from gerald at pfeifer dot com 2009-03-19 21:45 --- Ian, Ozkan, would you mind having a look on how to best solve this? -- gerald at pfeifer dot com changed: What|Removed |Added CC|gerald at gcc dot gnu dot |sezeroz at gmail dot com, |org |iant at google dot com, ||gerald at pfeifer dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39503
[Bug regression/39508] New: gcc libdecnumber 4.3.4 & 4.3.3 x86_64 linux : /usr/bin/ld: /usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.4//libgcc.a(bid_decimal_globals.o): TLS transition from R_X86_64_TLSGD
With the latest gcc-4.3.4-branch and gcc-4.3.3 branches checked out as of
2008-02-26, built with "vanilla options" with binutils 2.19.51.20090224
and glibc-2.9.90 of 2009-03-17, under Linux kernel 2.6.29-rc8, on an
originally Gentoo based system but with pretty much everything rebuilt
from latest versions with "vanilla" / GNU configure options, I get
this error under both 4.3.3 and 4.3.4 when linking a large dynamic executable,
when ALL objects are compiled with -fPIC, when GCC attempts to link
in GCC's internal "libdecnumber.a" object :
$ gcc -o $my_executable { .. @ 16MB of objects & shared libs } ... \
-m64 -O -g -march=native -mtune=native -ggdb3
-Wl,-R,/usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.4
/usr/bin/ld:
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.4//libgcc.a(bid_decimal_globals.o):
TLS transition from R_X86_64_TLSGD to R_X86_64_GOTTPOFF against
`__bid_IDEC_glbround' at 0x7 in section `.text' failed
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.4//libgcc.a(bid_decimal_globals.o):
could not read symbols: Bad value
collect2: ld returned 1 exit status
This happens with several different versions of ld(1), but NOT with gcc-4.2.3 .
( with libgcc_s.so.1 being ONLY installed under the
/usr/lib/gcc/$GCC_ARCH/$GCC_VERSION
directories, so I use RPATH, which makes supporting executables
linked with many different versions of libgcc easier
).
GCC 4.3.3 and 4.3.4 were configured identically with :
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/usr --enable-languages=c,c++,treelang
--enable-targets=x86_64,i686 --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.3
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.3
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.3/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.3/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/include/g--enable-multilib
--enable-bootstrap --enable-serial-configure --with-build-time-tools=/usr
--with-ld=/usr/bin/ld --with-as=/usr/bin/as --with-gnu-ld --with-gnu-as
--enable-threads=posix --enable-tls --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gomp --enable-mudflap --enable-libssp
--enable-system-zlib --enable-system-gettext --enable-nls
--without-included-gettext --disable-werror --enable-secureplt
--enable-libmudflap --enable-libgomp --enable-cld --enable-__cxa_atexit
--enable-clocale=gnu --with-pkgversion='Linux 2.6.29 GCC 4.3.4 JVD 2009-02-24'
Thread model: posix
gcc version 4.3.4 20090223 (prerelease) (Linux 2.6.29 GCC 4.3.3 JVD 2009-02-24)
Dozens of other executables and packages build just fine with 4.3.4 and 4.3.3 -
but for some reason this large database, X-Windows & GTK application, which
also uses AT&T AST sfio & vmalloc, does not .
While gcc-4.2.3 was configured with:
$ /usr/x86_64-pc-linux-gnu/gcc-bin/4.2.3/gcc -v
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-4.2.3/configure --prefix=/usr --with-system-zlib
--host=x86_64-pc-linux-gnu --enable-multilib --enable-threads=posix
Thread model: posix
gcc version 4.2.3
Any ideas anyone ?
This one is driving me round the bend.
Thanks in advance!
--
Summary: gcc libdecnumber 4.3.4 & 4.3.3 x86_64 linux :
/usr/bin/ld: /usr/lib/gcc/x86_64-unknown-linux-
gnu/4.3.4//libgcc.a(bid_decimal_globals.o): TLS
transition from R_X86_64_TLSGD to R_X86_64_GOTTPOFF
against `__bid_IDEC_glbround' at 0x7 in section `.text'
failed
Product: gcc
Version: 4.3.4
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jason dot vas dot dias at gmail dot com
GCC build triplet: x86_64-pc-linux-gnu gcc-4.2.3 glibc-2.9.90 binutils-
2.19.51.2009
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39508
[Bug fortran/39505] Consider a 'no arg check' directive
--- Comment #2 from burnus at gcc dot gnu dot org 2009-03-19 21:37 --- (In reply to comment #0) > The alternative to this is to do as OpenMPI does and generate dozens of > specific 'glue' routines, and tie them together under a generic name. Or to use "TYPE(*),DIMENSION(..)" as proposed in a Technical Report (that part was requested by the MPI forum); see N1761 and N1766 at http://www.nag.co.uk/SC22WG5/. I think those parts of the TR might get relatively quickly implemented, but it won't happen before there is more consensus at J3/WG5 (cf. N1766). (In reply to comment #1) > Really I think this is a bad idea. I agree. The TR solution seems to fix this and then I don't see any advantage of a gfortran 4.5 with "!$GCC attributes no_arg_check" compared to a gfortran 4.5 with "TYPE(*), DIMENSION(..)". If you see something which is not covered by the TR, can you contact Bill Long to make sure it will be considered for inclusion? Of you still think something !$GCC should be added, can you explain why the TR is not sufficient? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39505
[Bug debug/37890] Incorrect nesting for DW_TAG_imported_declaration
--- Comment #5 from swagiaal at redhat dot com 2009-03-19 20:07 --- Hmm.. compiling the testcase from comment #2 with gcc from http://koji.fedoraproject.org/koji/buildinfo?buildID=94544 still produces import statements only at the global level: ... <1><42>: Abbrev Number: 4 (DW_TAG_imported_declaration) <43> DW_AT_name: B <45> DW_AT_decl_file : 1 <46> DW_AT_decl_line : 6 <47> DW_AT_import : <0x29> [Abbrev Number: 2 (DW_TAG_namespace)] <1><4b>: Abbrev Number: 5 (DW_TAG_subprogram) <4c> DW_AT_external: 1 <4d> DW_AT_name: foo <51> DW_AT_decl_file : 1 <52> DW_AT_decl_line : 9 <53> DW_AT_MIPS_linkage_name: (indirect string, offset: 0x7d): _Z3foov <57> DW_AT_low_pc : 0x8048444 <5b> DW_AT_high_pc : 0x8048470 <5f> DW_AT_frame_base : 0x0 (location list) <63> DW_AT_sibling : <0x7b> <2><67>: Abbrev Number: 6 (DW_TAG_lexical_block) <68> DW_AT_low_pc : 0x8048447 <6c> DW_AT_high_pc : 0x804846e <3><70>: Abbrev Number: 7 (DW_TAG_lexical_block) <71> DW_AT_low_pc : 0x8048461 <75> DW_AT_high_pc : 0x804846e <1><7b>: Abbrev Number: 4 (DW_TAG_imported_declaration) <7c> DW_AT_name: C <7e> DW_AT_decl_file : 1 <7f> DW_AT_decl_line : 11 <80> DW_AT_import : <0x29> [Abbrev Number: 2 (DW_TAG_namespace)] <1><84>: Abbrev Number: 4 (DW_TAG_imported_declaration) <85> DW_AT_name: D <87> DW_AT_decl_file : 1 <88> DW_AT_decl_line : 16 <89> DW_AT_import : <0x29> [Abbrev Number: 2 (DW_TAG_namespace)] ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37890
[Bug target/39346] no mxp target port
--- Comment #1 from amylaar at gcc dot gnu dot org 2009-03-19 19:59 --- This port would be of rather limited use without an ARCompact port (See PR39303). It is doubtful that the mxp port will ever be properly finished. Moreover, due to the lack of overall design and instability of the instruction set, and a programming model that is different in a number of aspects from every other GCC target, and in even more aspects different from the majority of GCC targets, this is a high-maintenance port. Adding this port to the trunk without a maintainer who is able and willing to competently maintain this port on an on-going basis would only serve to impede GCC development. The port is available in branches/arc-20081210-branch. -- amylaar at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn|39302 | Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39346
[Bug target/39303] ARC port does not support ARCompact architecture
--- Comment #1 from amylaar at gcc dot gnu dot org 2009-03-19 19:55 --- Due to having numerous subtargets and the close interaction between branch shortening, alignment calculation, conditional execution and instruction scheduling, and idiosyncrasies of the zero-overhead loop implementations, this is a high-maintenance port. Adding this port to the trunk without a maintainer who is able and willing to competently maintain this port on an on-going basis would only serve to impede GCC development. The port is available in branches/arc-20081210-branch. -- amylaar at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn|39302 | Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39303
[Bug target/39496] [4.2/4.3 Regression] GCC uses non-standard calling conventions for static functions with -O0.
--- Comment #9 from jimb at red-bean dot com 2009-03-19 19:51 --- Fixed for me in r144969. Thank you all! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39496
[Bug target/32838] gcc generates incorrect trampoline code in thumb mode
--- Comment #6 from leo at marco dot de 2009-03-19 19:08 --- Subject: Re: gcc generates incorrect trampoline code in thumb mode sam at gcc dot gnu dot org wrote: > --- Comment #5 from sam at gcc dot gnu dot org 2009-03-19 10:15 --- > Matthias, > > I think Laurent was asking for an executable test case, which fails before > your > test and succeeds after, so that it can enter the regression suite. > > > We are using the compiler strictly for our embedded systems (software running on the bare hardware). Sorry, I cannot provide you an exececutable testcase. Regards, Matthias -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32838
[Bug pch/39492] [4.3/4.4 Regression] Parallel compilation fail using PCH on Windows NT>= 5.0
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-03-19 18:47 --- Confirmed, I saw this too while doing GCC work. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-03-19 18:47:00 date|| Summary|Parallel compilation fail |[4.3/4.4 Regression] |using PCH on Windows NT>= |Parallel compilation fail |5.0 |using PCH on Windows NT>= ||5.0 Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39492
[Bug target/39501] -O -ffinite-math-only gets min(x,y) optimization wrong for SF on arm-*-gnueabi
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-03-19 18:17 --- *** Bug 39507 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||kurt at roeckx dot be http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39501
[Bug target/39507] -ffinite-math-only causes wrong results on armel
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-03-19 18:17 --- *** This bug has been marked as a duplicate of 39501 *** *** This bug has been marked as a duplicate of 39501 *** -- 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=39507
[Bug target/39507] -ffinite-math-only causes wrong results on armel
--- Comment #1 from kurt at roeckx dot be 2009-03-19 18:17 --- Created an attachment (id=17500) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17500&action=view) testcase showing the problem /* ** This file is in the Public Domain. ** ** This program demonstrates a bug in the -ffast-math option of the gcc ** armel compiler : gcc version 4.3.2 (Debian 4.3.2-1.1) ** ** This works as expected: ** ** > gcc -Wall -O3 gcc-test.c -o gcc-test && ./gcc-test ** min : 0.max : 0. ** ** Compile with -ffast-math and things goes screwy. ** ** > gcc -Wall -O3 -ffast-math gcc-test.c -o gcc-test && ./gcc-test ** min : 9.max : 0. */ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39507
[Bug target/39507] New: -ffinite-math-only causes wrong results on armel
Hi, vorbis is creating wrong output on armel when using -ffast-math and -O1 or higher. It's the option -ffinith-math-only that cause the problems. I tried and can reproduce this problem with gcc versions 4.1.3, 4.2.4 and 4.3.3. I've tried this test on various arches without problem, including i386, x86_64, hppa, ia64, mips, mipsel. They did now show any problem. I'll attach a test case shortly. There is more information available at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520429 Kurt -- Summary: -ffinite-math-only causes wrong results on armel Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kurt at roeckx dot be GCC host triplet: arm-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39507
[Bug fortran/39505] Consider a 'no arg check' directive
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-03-19 18:08 --- Really I think this is a bad idea. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39505
[Bug target/39063] libgcc2.c:mprotect() for mingw, incompatible pointer type warning
--- Comment #5 from sezeroz at gmail dot com 2009-03-19 17:49 --- The prototype for VirtualProtect() is known but the definition of DWORD is not?? Hrmph. In any case, it should be fixed easily by changing DWORD into unsigned int which is what a DWORD is always defined as. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39063
[Bug tree-optimization/39506] PTA TBAA pruning wrong for -fargument-noalias-*
--- Comment #6 from dnovillo at gcc dot gnu dot org 2009-03-19 17:12 --- (In reply to comment #5) > I agree with pinskia, and think this should be closed as invalid. Likewise. At most we could emit a warning when we see p = &i. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39506
[Bug tree-optimization/39506] PTA TBAA pruning wrong for -fargument-noalias-*
--- Comment #5 from dberlin at gcc dot gnu dot org 2009-03-19 17:10 --- I agree with pinskia, and think this should be closed as invalid. fargument-noalias-* is an assertion by you, the user, that these things will never alias. You are telling the compiler it is allowed to assume it is always true. It is not simply a "starting point" of what the compiler is allowed to assume Your testcase makes your assertion not true, so it is invalid in the face of those options. We absolutely should not try to make this work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39506
[Bug tree-optimization/39506] PTA TBAA pruning wrong for -fargument-noalias-*
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-03-19 17:03 --- -fargument-noalias- is not flow sensitive at all and not supposed to be. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39506
[Bug tree-optimization/39506] PTA TBAA pruning wrong for -fargument-noalias-*
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-03-19 17:02 ---
> int foo (int *p, int b)
> {
> if (b)
>p = &i;
I think this is invalid for -fargument-noalias-*. I don't think you can assign
to another pointer to p with this option turned on with defined results because
it says p does not alias any global all the time, and you just caused it to
alias i.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39506
[Bug target/39501] -O -ffinite-math-only gets min(x,y) optimization wrong for SF on arm-*-gnueabi
--- Comment #6 from rearnsha at gcc dot gnu dot org 2009-03-19 17:02 --- Correction: it doesn't affect movdfcc since that only matches on hard-float targets. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39501
[Bug middle-end/39254] [4.4 Regression] gcc.c-torture/execute/va-arg-trap-1.c ICEs on powerpc-apple-darwin9
--- Comment #12 from janis at gcc dot gnu dot org 2009-03-19 17:00 ---
I tested this patch, which I assume is what was described in comment #11:
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c (revision 144923)
+++ gcc/config/rs6000/rs6000.c (working copy)
@@ -5206,15 +5206,6 @@ rs6000_emit_move (rtx dest, rtx source,
&& ! legitimate_constant_pool_address_p (operands[1])
&& ! toc_relative_expr_p (operands[1]))
{
- /* Emit a USE operation so that the constant isn't deleted if
-expensive optimizations are turned on because nobody
-references it. This should only be done for operands that
-contain SYMBOL_REFs with CONSTANT_POOL_ADDRESS_P set.
-This should not be done for operands that contain LABEL_REFs.
-For now, we just handle the obvious case. */
- if (GET_CODE (operands[1]) != LABEL_REF)
- emit_use (operands[1]);
-
#if TARGET_MACHO
/* Darwin uses a special PIC legitimizer. */
if (DEFAULT_ABI == ABI_DARWIN && MACHOPIC_INDIRECT)
I bootstrapped all languages except Ada on powerpc64-unknown-linux-gnu and ran
the testsuite with -m32/-m64, and the only change was that test va-arg-trap-1
now passes.
--
janis at gcc dot gnu dot org changed:
What|Removed |Added
CC||dje at gcc dot gnu dot org,
||janis at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39254
[Bug tree-optimization/39506] PTA TBAA pruning wrong for -fargument-noalias-*
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-03-19 17:00 ---
int i;
int __attribute__((noinline))
foo (int *p, int b)
{
if (b)
p = &i;
i = 1;
*p = 0;
return i;
}
extern void abort (void);
int main()
{
if (foo((void *)0, 1) != 0)
abort ();
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39506
[Bug tree-optimization/39506] PTA TBAA pruning wrong for -fargument-noalias-*
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-19 16:58 --- Mine. -- 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-03-19 16:58:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39506
[Bug tree-optimization/39506] New: PTA TBAA pruning wrong for -fargument-noalias-*
int i;
int foo (int *p, int b)
{
if (b)
p = &i;
i = 1;
*p = 0;
return i;
}
at -O2 -fargument-noalias-global shows
# p_1 = PHI
# i_7 = VDEF
i = 1;
# PARM_NOALIAS.10_9 = VDEF
*p_1 = 0;
# VUSE
D.1596_5 = i;
even though *p_1 aliases i.
--
Summary: PTA TBAA pruning wrong for -fargument-noalias-*
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
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=39506
[Bug target/39501] -O -ffinite-math-only gets min(x,y) optimization wrong for SF on arm-*-gnueabi
--- Comment #5 from rearnsha at gcc dot gnu dot org 2009-03-19 16:53 --- Also affects all other EABI target builds. THe bug is in movsfcc (and movdfcc) which have not been corrected to account for the libcall comparisons returning a bool value in the EABI. I'm currently testing a fix -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rearnsha at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Priority|P3 |P2 Last reconfirmed|-00-00 00:00:00 |2009-03-19 16:53:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39501
[Bug target/39501] -O -ffinite-math-only gets min(x,y) optimization wrong for SF on arm-*-gnueabi
--- Comment #4 from ramana dot r at gmail dot com 2009-03-19 16:49 --- (In reply to comment #3) > ramana: > I think you'll find the flags are only set for the 3-way comparisons. > __aeabi_cmple just returns 0 or 1 > "Use for C <=" in the table means the C language, not the carry flag. > If you can find where the error is in the GCC source, that'd be great. It was pointed out that I was looking at the wrong function in the runtime ABI - so I take that back. I was referring to the void __aeabi_cfcmple(float, float) variant rather than the fcmple that's used in this case. So if you were to use the cfcmple variants (which gcc can't at the moment) the extra cmp might be removed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39501
[Bug c/39456] Functions of a file in different named sections
--- Comment #1 from etienne_lorrain at yahoo dot fr 2009-03-19 16:33
---
Also, you cannot put function in another section and then
use -ffunction-sections, i.e.:
etie...@gujin:~$ gcc --version
gcc (Debian 4.3.3-3) 4.3.3
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.
etie...@gujin:~$ cat tmp.c
__attribute__((section(".extracode"))) int fct1 (void) {
return 1;
}
__attribute__((section(".extracode"))) int fct2 (void) {
return 2;
}
etie...@gujin:~$ gcc -Os -fomit-frame-pointer -ffunction-sections -S tmp.c -o
tmp.s
etie...@gujin:~$ cat tmp.s
.file "tmp.c"
.section.extracode,"ax",@progbits
.globl fct1
.type fct1, @function
fct1:
movl$1, %eax
ret
.size fct1, .-fct1
.globl fct2
.type fct2, @function
fct2:
movl$2, %eax
ret
.size fct2, .-fct2
.ident "GCC: (Debian 4.3.3-3) 4.3.3"
.section.note.GNU-stack,"",@progbits
etie...@gujin:~$
So you cannot use garbage collection in the linker...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39456
[Bug fortran/39505] New: Consider a 'no arg check' directive
A few compilers support a 'no arg check' compiler directive which tells the compiler to ignore type/kind/rank checking on specified arguments. This is useful when routines have 'generic' arguments which are simply passed on to other routines. Two compilers which support this feature are ifort, with the '!dec$ attributes no_arg_check' directive, and MIPSpro f90, with the '!dir$ ignore_tkr' directive. For example, in the Message Passing Interface (MPI), the send and receive buffer arguments are typically 'choice' arguments which can have any type. This makes it difficult to write interface blocks to help validate the remaining arguments (and allow keyword=value usage for better self-documenting code.) Using the Intel compiler directive, an interface block could be written as follows: interface subroutine mpi_send (BUF, COUNT, DATATYPE, DEST, TAG, COMM, IERROR) implicit none integer :: BUF(*) !dec$ attributes no_arg_check::buf integer, intent(in) :: COUNT, DATATYPE, DEST, TAG, COMM integer, intent(out) :: IERROR end subroutine end interface The alternative to this is to do as OpenMPI does and generate dozens of specific 'glue' routines, and tie them together under a generic name. (Tedious, less so by using a preprocessor.) Or to not have explicit interfaces at all, at least for routines with 'choice' arguments, and get no argument checking at all. (In most cases, the current status quo.) -- Summary: Consider a 'no arg check' directive Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: w6ws at earthlink dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39505
[Bug target/39501] -O -ffinite-math-only gets min(x,y) optimization wrong for SF on arm-*-gnueabi
--- Comment #3 from martinwguy at yahoo dot it 2009-03-19 16:29 --- ramana: I think you'll find the flags are only set for the 3-way comparisons. __aeabi_cmple just returns 0 or 1 "Use for C <=" in the table means the C language, not the carry flag. If you can find where the error is in the GCC source, that'd be great. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39501
[Bug bootstrap/39503] [4.4 Regression] libgcc2.c doesn't compile anymore
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet||arm-wince-pe Keywords||build Summary|libgcc2.c doesn't compile |[4.4 Regression] libgcc2.c |anymore |doesn't compile anymore Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39503
[Bug bootstrap/39503] libgcc2.c doesn't compile anymore
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-03-19 16:19 --- Btw, this was recently changed by PR target/39063 * libgcc2.c (mprotect): Do not use signed arguments for VirtualProtect, use DWORD arguments. Also fix the 'may be used uninitialized' warning for the np variable. http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144957 -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||gerald at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39503
[Bug c/39504] Incorrect code at -O2 and -O3
--- Comment #6 from jk500500 at yahoo dot com 2009-03-19 16:11 --- Thanks for the info. I had assumed the SPEC code would not have issues like this; guess not :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39504
[Bug c/39504] Incorrect code at -O2 and -O3
--- Comment #5 from jakub at gcc dot gnu dot org 2009-03-19 16:07 --- Yeah. In GCC this has been fixed by: http://gcc.gnu.org/ml/gcc-patches/1999-01/msg00206.html but SPEC2k contains older copy of GCC source code. You need to either patch it, or use -fno-strict-aliasing to compile the buggy CUs. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39504
[Bug target/39501] -O -ffinite-math-only gets min(x,y) optimization wrong for SF on arm-*-gnueabi
--- Comment #2 from ramana dot r at gmail dot com 2009-03-19 16:05 --- Or get rid of the cmp. The Runtime ABI suggests that the Z,N,C flags are set for the result of the comparison. If that is true then the second cmp is unnecessary. Table 5 section 4.1.2 of the ARM Runtime ABI suggests this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39501
[Bug c/39504] Incorrect code at -O2 and -O3
--- Comment #3 from jk500500 at yahoo dot com 2009-03-19 16:01 --- Sorry, forgot to mention that the gcc command line is just: mipsisa32-unknown-elf-gcc -O2 -S gcc0.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39504
[Bug c/39504] Incorrect code at -O2 and -O3
--- Comment #4 from pinskia at gmail dot com 2009-03-19 16:01 ---
Subject: Re: New: Incorrect code at -O2 and -O3
Sent from my iPhone
On Mar 19, 2009, at 8:38 AM, "jk500500 at yahoo dot com"
wrote:
> The attached test program -- which I extracted and simplified from the
> '176.gcc'
> SPEC2000 benchmark -- is compiled incorrectly at -O2 and -O3. The
> code is
> correct at -O1 and -O0.
>
> The bad code I am reporting here is produced by a MIPS gcc-4.3.3
> cross-compiler.
> However, I see the same problem with an in-house port of gcc-4.3.3
> to an
> in-house-developed CPU, so I believe the problem is generic to GCC and
> not specific to the MIPS version.
>
> I am attaching the complete testcase (a self-contained C file), but
> the
> problem is specifically with this C code:
>
> rtx
> rtx_alloc (enum rtx_code jsk_code_arg) {
>rtx rt;
>struct obstack *ob = &rtl_obstack;
>int length;
>_obstack_newchunk(ob);
>rt = (rtx)ob->object_base;
>length = (sizeof (struct rtx_def) - sizeof (rtunion) - 1) /
> sizeof (int);
>for (; length >= 0; length--) {
>((int *) rt)[length] = 0;
>}
This is undefined code. The code in spec is known to violate C90/C99/C+
+98 aliasing rules.
>
>
> #ifdef WORKAROUND
>/* If enabled, will fix the issue */
>__asm__ __volatile__ ( "sll r0,r0,0" );
> #endif
>
>rt->jsk_code_val = jsk_code_arg;
>return rt;
> }
>
>
> The "rt->jsk_code_val = jsk_code_arg" assignment is incorrectly
> dropped
> from the generated code. As the comment in the C code indicates, if I
> insert a volatile asm statement between the zero'ing of the *rt struct
> and the jsk_code_val assignment, correct code results at all
> optimization
> levels.
>
> At -O2, the MIPS assembly code is below. There is a 'sw' (store 32-
> bit word)
> instruction near the end that results in the jsk_code_val field being
> set to zero rather than to the value of jsk_code_arg.
>
> rtx_alloc:
>.frame $sp,16,$31 # vars= 0, regs= 3/0, args=
> 0, gp= 0
>.mask 0x8003,-4
>.fmask 0x,0
>.setnoreorder
>.setnomacro
>
>addiu $sp,$sp,-16
>sw $16,4($sp)
>lui $16,%hi(rtl_obstack)
>addiu $4,$16,%lo(rtl_obstack)
>addiu $16,$16,%lo(rtl_obstack)
>sw $31,12($sp)
>jal _obstack_newchunk
>sw $17,8($sp)
>
>lw $2,8($16)
>lw $31,12($sp)
>lw $17,8($sp)
>lw $16,4($sp)
>sw $0,4($2)
>sw $0,0($2) <--- Writes 'jsk_code_val' to zero
>j $31
>addiu $sp,$sp,16
>
>
>
> With the WORKAROUND define enabled, the code becomes as shown
> below. Now
> there is the correct 'sh' (store 16-bit halfword) instruction to set
> jsk_code_arg to the value of jsk_code_val.
>
> rtx_alloc:
>.frame $sp,16,$31 # vars= 0, regs= 3/0, args=
> 0, gp= 0
>.mask 0x8003,-4
>.fmask 0x,0
>addiu $sp,$sp,-16
>sw $16,4($sp)
>lui $16,%hi(rtl_obstack)
>sw $17,8($sp)
>move$17,$4
>addiu $4,$16,%lo(rtl_obstack)
>sw $31,12($sp)
>.setnoreorder
>.setnomacro
>jal _obstack_newchunk
>addiu $16,$16,%lo(rtl_obstack)
>.setmacro
>.setreorder
>
>lw $2,8($16)
>sw $0,4($2)
>sw $0,0($2)
> #APP
> # 78 "./gcc0.c" 1
>sll r0,r0,0
> # 0 "" 2
> #NO_APP
>lw $31,12($sp)
>sh $17,0($2)<- sets jsk_code_val to
> jsk_code_arg
>lw $16,4($sp)
>lw $17,8($sp)
>.setnoreorder
>.setnomacro
>j $31
>addiu $sp,$sp,16
>
>
> --
> Summary: Incorrect code at -O2 and -O3
> Product: gcc
> Version: 4.3.3
>Status: UNCONFIRMED
> Severity: normal
> Priority: P3
> Component: c
>AssignedTo: unassigned at gcc dot gnu dot org
>ReportedBy: jk500500 at yahoo dot com
> GCC build triplet: x86_64-unknown-linux-gnu
> GCC host triplet: x86_64-unknown-linux-gnu
> GCC target triplet: mipsisa32-unknown-elf
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39504
>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39504
Re: [Bug c/39504] New: Incorrect code at -O2 and -O3
Sent from my iPhone
On Mar 19, 2009, at 8:38 AM, "jk500500 at yahoo dot com" > wrote:
The attached test program -- which I extracted and simplified from the
'176.gcc'
SPEC2000 benchmark -- is compiled incorrectly at -O2 and -O3. The
code is
correct at -O1 and -O0.
The bad code I am reporting here is produced by a MIPS gcc-4.3.3
cross-compiler.
However, I see the same problem with an in-house port of gcc-4.3.3
to an
in-house-developed CPU, so I believe the problem is generic to GCC and
not specific to the MIPS version.
I am attaching the complete testcase (a self-contained C file), but
the
problem is specifically with this C code:
rtx
rtx_alloc (enum rtx_code jsk_code_arg) {
rtx rt;
struct obstack *ob = &rtl_obstack;
int length;
_obstack_newchunk(ob);
rt = (rtx)ob->object_base;
length = (sizeof (struct rtx_def) - sizeof (rtunion) - 1) /
sizeof (int);
for (; length >= 0; length--) {
((int *) rt)[length] = 0;
}
This is undefined code. The code in spec is known to violate C90/C99/C+
+98 aliasing rules.
#ifdef WORKAROUND
/* If enabled, will fix the issue */
__asm__ __volatile__ ( "sll r0,r0,0" );
#endif
rt->jsk_code_val = jsk_code_arg;
return rt;
}
The "rt->jsk_code_val = jsk_code_arg" assignment is incorrectly
dropped
from the generated code. As the comment in the C code indicates, if I
insert a volatile asm statement between the zero'ing of the *rt struct
and the jsk_code_val assignment, correct code results at all
optimization
levels.
At -O2, the MIPS assembly code is below. There is a 'sw' (store 32-
bit word)
instruction near the end that results in the jsk_code_val field being
set to zero rather than to the value of jsk_code_arg.
rtx_alloc:
.frame $sp,16,$31 # vars= 0, regs= 3/0, args=
0, gp= 0
.mask 0x8003,-4
.fmask 0x,0
.setnoreorder
.setnomacro
addiu $sp,$sp,-16
sw $16,4($sp)
lui $16,%hi(rtl_obstack)
addiu $4,$16,%lo(rtl_obstack)
addiu $16,$16,%lo(rtl_obstack)
sw $31,12($sp)
jal _obstack_newchunk
sw $17,8($sp)
lw $2,8($16)
lw $31,12($sp)
lw $17,8($sp)
lw $16,4($sp)
sw $0,4($2)
sw $0,0($2) <--- Writes 'jsk_code_val' to zero
j $31
addiu $sp,$sp,16
With the WORKAROUND define enabled, the code becomes as shown
below. Now
there is the correct 'sh' (store 16-bit halfword) instruction to set
jsk_code_arg to the value of jsk_code_val.
rtx_alloc:
.frame $sp,16,$31 # vars= 0, regs= 3/0, args=
0, gp= 0
.mask 0x8003,-4
.fmask 0x,0
addiu $sp,$sp,-16
sw $16,4($sp)
lui $16,%hi(rtl_obstack)
sw $17,8($sp)
move$17,$4
addiu $4,$16,%lo(rtl_obstack)
sw $31,12($sp)
.setnoreorder
.setnomacro
jal _obstack_newchunk
addiu $16,$16,%lo(rtl_obstack)
.setmacro
.setreorder
lw $2,8($16)
sw $0,4($2)
sw $0,0($2)
#APP
# 78 "./gcc0.c" 1
sll r0,r0,0
# 0 "" 2
#NO_APP
lw $31,12($sp)
sh $17,0($2)<- sets jsk_code_val to
jsk_code_arg
lw $16,4($sp)
lw $17,8($sp)
.setnoreorder
.setnomacro
j $31
addiu $sp,$sp,16
--
Summary: Incorrect code at -O2 and -O3
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jk500500 at yahoo dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: mipsisa32-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39504
[Bug target/39501] -O -ffinite-math-only gets min(x,y) optimization wrong for SF on arm-*-gnueabi
--- Comment #1 from ramana dot r at gmail dot com 2009-03-19 15:53 --- Adding self to CC list - mainline is also broken. The only difference in mainline is that we generate a movle instead of movgt. It should indeed be a moveq instead of a movle. cheers Ramana -- ramana dot r at gmail dot com changed: What|Removed |Added CC||rearnsha at gcc dot gnu dot ||org, ramana dot r at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39501
[Bug c/39495] OMP parallel loop w/ unsigned index var rejected
--- Comment #3 from jakub at gcc dot gnu dot org 2009-03-19 15:52 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39495
[Bug bootstrap/39503] libgcc2.c doesn't compile anymore
--- Comment #1 from forumer at smartmobili dot com 2009-03-19 15:45 --- Hum maybe there is a problem in my defines because libgcc2 is using some windows functions and in particular mprotect so maybe I should try to find why DWORD is not defined in my case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39503
[Bug c/39504] Incorrect code at -O2 and -O3
--- Comment #2 from jk500500 at yahoo dot com 2009-03-19 15:44 --- Created an attachment (id=17499) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17499&action=view) gcc -v output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39504
[Bug c/39504] Incorrect code at -O2 and -O3
--- Comment #1 from jk500500 at yahoo dot com 2009-03-19 15:40 --- Created an attachment (id=17498) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17498&action=view) Testcase (self-contained C file) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39504
[Bug c/39504] New: Incorrect code at -O2 and -O3
The attached test program -- which I extracted and simplified from the
'176.gcc'
SPEC2000 benchmark -- is compiled incorrectly at -O2 and -O3. The code is
correct at -O1 and -O0.
The bad code I am reporting here is produced by a MIPS gcc-4.3.3
cross-compiler.
However, I see the same problem with an in-house port of gcc-4.3.3 to an
in-house-developed CPU, so I believe the problem is generic to GCC and
not specific to the MIPS version.
I am attaching the complete testcase (a self-contained C file), but the
problem is specifically with this C code:
rtx
rtx_alloc (enum rtx_code jsk_code_arg) {
rtx rt;
struct obstack *ob = &rtl_obstack;
int length;
_obstack_newchunk(ob);
rt = (rtx)ob->object_base;
length = (sizeof (struct rtx_def) - sizeof (rtunion) - 1) / sizeof (int);
for (; length >= 0; length--) {
((int *) rt)[length] = 0;
}
#ifdef WORKAROUND
/* If enabled, will fix the issue */
__asm__ __volatile__ ( "sll r0,r0,0" );
#endif
rt->jsk_code_val = jsk_code_arg;
return rt;
}
The "rt->jsk_code_val = jsk_code_arg" assignment is incorrectly dropped
from the generated code. As the comment in the C code indicates, if I
insert a volatile asm statement between the zero'ing of the *rt struct
and the jsk_code_val assignment, correct code results at all optimization
levels.
At -O2, the MIPS assembly code is below. There is a 'sw' (store 32-bit word)
instruction near the end that results in the jsk_code_val field being
set to zero rather than to the value of jsk_code_arg.
rtx_alloc:
.frame $sp,16,$31 # vars= 0, regs= 3/0, args= 0, gp= 0
.mask 0x8003,-4
.fmask 0x,0
.setnoreorder
.setnomacro
addiu $sp,$sp,-16
sw $16,4($sp)
lui $16,%hi(rtl_obstack)
addiu $4,$16,%lo(rtl_obstack)
addiu $16,$16,%lo(rtl_obstack)
sw $31,12($sp)
jal _obstack_newchunk
sw $17,8($sp)
lw $2,8($16)
lw $31,12($sp)
lw $17,8($sp)
lw $16,4($sp)
sw $0,4($2)
sw $0,0($2) <--- Writes 'jsk_code_val' to zero
j $31
addiu $sp,$sp,16
With the WORKAROUND define enabled, the code becomes as shown below. Now
there is the correct 'sh' (store 16-bit halfword) instruction to set
jsk_code_arg to the value of jsk_code_val.
rtx_alloc:
.frame $sp,16,$31 # vars= 0, regs= 3/0, args= 0, gp= 0
.mask 0x8003,-4
.fmask 0x,0
addiu $sp,$sp,-16
sw $16,4($sp)
lui $16,%hi(rtl_obstack)
sw $17,8($sp)
move$17,$4
addiu $4,$16,%lo(rtl_obstack)
sw $31,12($sp)
.setnoreorder
.setnomacro
jal _obstack_newchunk
addiu $16,$16,%lo(rtl_obstack)
.setmacro
.setreorder
lw $2,8($16)
sw $0,4($2)
sw $0,0($2)
#APP
# 78 "./gcc0.c" 1
sll r0,r0,0
# 0 "" 2
#NO_APP
lw $31,12($sp)
sh $17,0($2)<- sets jsk_code_val to jsk_code_arg
lw $16,4($sp)
lw $17,8($sp)
.setnoreorder
.setnomacro
j $31
addiu $sp,$sp,16
--
Summary: Incorrect code at -O2 and -O3
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jk500500 at yahoo dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: mipsisa32-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39504
[Bug c/39495] OMP parallel loop w/ unsigned index var rejected
--- Comment #2 from jakub at gcc dot gnu dot org 2009-03-19 15:34 --- Subject: Bug 39495 Author: jakub Date: Thu Mar 19 15:34:00 2009 New Revision: 144965 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144965 Log: PR c/39495 * c-omp.c (c_finish_omp_for): Allow NE_EXPR with TREE_TYPE (decl)'s minimum or maximum value. * parser.c (cp_parser_omp_for_cond): Don't check lhs if decl is NULL. (cp_parser_omp_for_loop): Always use cp_parser_omp_for_cond. * gcc.dg/gomp/pr39495-1.c: New test. * gcc.dg/gomp/pr39495-2.c: New test. * g++.dg/gomp/pr39495-1.C: New test. * g++.dg/gomp/pr39495-2.C: New test. Added: trunk/gcc/testsuite/g++.dg/gomp/pr39495-1.C trunk/gcc/testsuite/g++.dg/gomp/pr39495-2.C trunk/gcc/testsuite/gcc.dg/gomp/pr39495-1.c trunk/gcc/testsuite/gcc.dg/gomp/pr39495-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-omp.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39495
[Bug bootstrap/39503] New: libgcc2.c doesn't compile anymore
When trying to generate a cross-compiler targeting arm-wince-pe I have noticed
that libgcc2.c was not compiling anymore because of the following function :
int
mprotect (char *addr, int len, int prot)
{
DWORD np, op;
if (prot == 7)
np = 0x40;
else if (prot == 5)
np = 0x20;
else if (prot == 4)
np = 0x10;
else if (prot == 3)
np = 0x04;
else if (prot == 1)
np = 0x02;
else if (prot == 0)
np = 0x01;
if (VirtualProtect (addr, len, np, &op))
return 0;
else
return -1;
}
The problem comes from the DWORD because compiler doesn't know its
definition.
Before is was defined as an int and everything was working fine.
By the way I think you should use a unsigned long instead of a int because
a DWORD is defined like this :
typedef unsigned long DWORD;
--
Summary: libgcc2.c doesn't compile anymore
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: forumer at smartmobili dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39503
[Bug target/39063] libgcc2.c:mprotect() for mingw, incompatible pointer type warning
--- Comment #4 from hjl dot tools at gmail dot com 2009-03-19 14:52 --- The fix may have broken cross compiling: http://gcc.gnu.org/ml/gcc/2009-03/msg00525.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39063
[Bug driver/39356] assembler isn't called
--- Comment #10 from ktietz at gcc dot gnu dot org 2009-03-19 14:33 --- (In reply to comment #9) Patch sent. See http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00914.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39356
[Bug ada/39502] Unexpected uninitialized warning
--- Comment #5 from alex at segv dot de 2009-03-19 14:02 --- Created an attachment (id=17497) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17497&action=view) Similar code, not sure if same or different bug. This sample code is closer to our original finding of the bug. Not sure if the first package oversimplified and found another/similar bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39502
[Bug ada/39502] Unexpected uninitialized warning
--- Comment #4 from alex at segv dot de 2009-03-19 13:47 --- Created an attachment (id=17496) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17496&action=view) Makefile to compile the sample code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39502
[Bug ada/39502] Unexpected uninitialized warning
--- Comment #3 from alex at segv dot de 2009-03-19 13:47 --- Created an attachment (id=17495) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17495&action=view) seperate body with code triggering the warning -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39502
[Bug ada/39502] Unexpected uninitialized warning
--- Comment #2 from alex at segv dot de 2009-03-19 13:46 --- Created an attachment (id=17494) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17494&action=view) Body to spec -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39502
[Bug ada/39502] Unexpected uninitialized warning
--- Comment #1 from alex at segv dot de 2009-03-19 13:46 --- Created an attachment (id=17493) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17493&action=view) spec file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39502
[Bug ada/39502] New: Unexpected uninitialized warning
By compiling the attached files I get a warning like this: ./some_package-some_seperate_package.adb: In function 'SOME_PACKAGE.SOME_SEPERATE_PACKAGE.GET_STATE': ./some_package-some_seperate_package.adb:22: warning: 'state_infos.current_state' is used uninitialized in this function but I think there should be no warning at all. It seems it takes several conditions to trigger this warning: - a record variable as a out parameter - the code most be in a seperate package - The flags -Wuninitialized and -fPIC need to be set I can reproduce this on 4.3.3 and 4.3.0 (and probably more versions). $ gcc -v -save-temps -c -I./ -Wuninitialized -fPIC -O2 ./some_package.adb Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.3-5ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-I./' '-Wuninitialized' '-fPIC' '-O2' '-mtune=generic' /usr/lib/gcc/x86_64-linux-gnu/4.3.3/gnat1 -I./ -quiet -dumpbase some_package.adb -O2 -Wuninitialized -fPIC -mtune=generic ./some_package.adb -o some_package.s ./some_package-some_seperate_package.adb: In function 'SOME_PACKAGE.SOME_SEPERATE_PACKAGE.GET_STATE': ./some_package-some_seperate_package.adb:22: warning: 'state_infos.current_state' is used uninitialized in this function COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-I./' '-Wuninitialized' '-fPIC' '-O2' '-mtune=generic' as -V -Qy -o some_package.o some_package.s GNU assembler version 2.19.1 (x86_64-linux-gnu) using BFD version (GNU Binutils for Ubuntu) 2.19.1 COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.3.3/:/usr/lib/gcc/x86_64-linux-gnu/4.3.3/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.3.3/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.3.3/:/usr/lib/gcc/x86_64-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.3.3/:/usr/lib/gcc/x86_64-linux-gnu/4.3.3/:/usr/lib/gcc/x86_64-linux-gnu/4.3.3/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.3.3/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-I./' '-Wuninitialized' '-fPIC' '-O2' '-mtune=generic' Regards Alexander Elbs. -- Summary: Unexpected uninitialized warning Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: alex at segv dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39502
[Bug target/39501] New: -O -ffinite-math-only gets min(x,y) optimization wrong for SF on arm-*-gnueabi
The following fragment when compiled -O -ffinite-math-only on arm-linux-gnueabi
should print 0.00 but with gcc-4.1.2, 4.2.4, 4.3.3 it prints 9.00
#include
#define test_min(x,y) ((x) > (y) ? (y) : (x))
int
main (void)
{
static float data [1];
float min = 9.0 ;
min = test_min (min, data[0]) ;
printf("min = %f\n", min);
return min != 0.0 ;
}
This only happens for floats, not doubles. The main difference in the asm is
that without -ffinite-math-only (working) it goes
mov r0, r4
ldr r1, .L6+4
bl __aeabi_fcmplt
cmp r0, #0
ldr r3, .L6+4
moveq r4, r3
mov r0, r4
while with -ffinite-math-only (broken) it goes
ldr r5, .L5+4
mov r0, r4
mov r1, r5
bl __aeabi_fcmple
cmp r0, #0
movgt r4, r5
mov r0, r4
I guess that should be moveq.
This makes libvorbis fail on arm-linux-gnueabi when using softfloat.
See https://trac.xiph.org/ticket/1526 for a longer code example failing on
min() and max().
--
Summary: -O -ffinite-math-only gets min(x,y) optimization wrong
for SF on arm-*-gnueabi
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: martinwguy at yahoo dot it
GCC target triplet: arm-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39501
[Bug middle-end/26461] liveness of thread local references across function calls
--- Comment #7 from gpderetta at gmail dot com 2009-03-19 12:14 ---
Hi, I'm the author of Boost.Coroutine (not yet part of boost, but one day...).
I have the exact same problem: gcc caches the address of TLS variables across
function calls which breaks when coroutines move from one thread to another.
Note that in my case I'm definitely *not* reinventing threads in user space.
Coroutines are for different use cases than threads (i.e. when you do not need
preemption but simply a way to organize event driven code). One use of
boost.coroutine is on top of boost.asio.
Posix has both threads and swapcontext and nowhere it says that swapcontext
can't be used in threaded applications. In fact is simply states that the saved
context is restored after a call to setcontext, and IMHO any posix compatible
compiler should support this.
FWIW The microsoft c++ compiler has the /GT (fiber safe TLS) flag to prevent
exactly this kind of optimizations. Probably GCC should support something like
that too.
See:
http://www.crystalclearsoftware.com/soc/coroutine/coroutinecoroutine_thread.html
for details.
Finally I see the problem even with plain pointers and references, not only
arrays, at least with gcc4.3:
#include
void bar(int&);
__thread int x = 0;
void foo(ucontext_t&oucp, ucontext_t& ucp) {
bar(x);
swapcontext(&oucp, &ucp);
bar(x);
}
Compiles down to this (with -O3, on x86_64):
:_Z3fooR8ucontextS0_:
movq%fs:0, %rax
movq%rbp, -16(%rsp)
movq%rbx, -24(%rsp)
movq%r12, -8(%rsp)
movq%rsi, %rbx
subq$24, %rsp
movq%rdi, %r12
leaqx...@tpoff(%rax), %rbp
movq%rbp, %rdi
call_Z3barRi
movq%r12, %rdi
movq%rbx, %rsi
callswapcontext
movq%rbp, %rdi
movq(%rsp), %rbx
movq8(%rsp), %rbp
movq16(%rsp), %r12
addq$24, %rsp
jmp _Z3barRi
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26461
[Bug target/39496] [4.2/4.3 Regression] GCC uses non-standard calling conventions for static functions with -O0.
--- Comment #8 from jakub at gcc dot gnu dot org 2009-03-19 12:02 --- Fixed on the trunk so far. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.0.4 4.3.3 4.4.0 |4.0.4 4.3.3 Known to work|3.3.6 |3.3.6 4.4.0 Summary|[4.2/4.3/4.4 Regression] GCC|[4.2/4.3 Regression] GCC |uses non-standard calling |uses non-standard calling |conventions for static |conventions for static |functions with -O0. |functions with -O0. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39496
[Bug target/39063] libgcc2.c:mprotect() for mingw, incompatible pointer type warning
--- Comment #3 from gerald at gcc dot gnu dot org 2009-03-19 10:40 --- Subject: Bug 39063 Author: gerald Date: Thu Mar 19 10:40:32 2009 New Revision: 144957 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144957 Log: PR target/39063 * libgcc2.c (mprotect): Do not use signed arguments for VirtualProtect, use DWORD arguments. Also fix the 'may be used uninitialized' warning for the np variable. Modified: trunk/gcc/ChangeLog trunk/gcc/libgcc2.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39063
[Bug target/39496] [4.2/4.3/4.4 Regression] GCC uses non-standard calling conventions for static functions with -O0.
--- Comment #7 from jakub at gcc dot gnu dot org 2009-03-19 10:25 --- Subject: Bug 39496 Author: jakub Date: Thu Mar 19 10:25:43 2009 New Revision: 144955 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144955 Log: PR target/39496 * config/i386/i386.c (ix86_function_regparm): Don't optimize local functions using regparm calling conventions when not optimizing. (ix86_function_sseregparm): Similarly for sseregparm calling conventions. * gcc.target/i386/pr39496.c: New test. * g++.dg/other/pr39496.C: New test. Added: trunk/gcc/testsuite/g++.dg/other/pr39496.C trunk/gcc/testsuite/gcc.target/i386/pr39496.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39496
[Bug target/32838] gcc generates incorrect trampoline code in thumb mode
--- Comment #5 from sam at gcc dot gnu dot org 2009-03-19 10:15 --- Matthias, I think Laurent was asking for an executable test case, which fails before your test and succeeds after, so that it can enter the regression suite. -- sam at gcc dot gnu dot org changed: What|Removed |Added CC||sam at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32838
[Bug ada/39498] [4.4 Regression] ACATS test c94001c fails
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-03-19 10:11 --- Closed then. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39498
[Bug fortran/39489] [4.3 Regression] write_atom(): Writing negative integer
--- Comment #9 from n dot pinhao at netvisao dot pt 2009-03-19 08:24 --- Created an attachment (id=17492) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17492&action=view) Streamlined module files reproducing the error (2) A file was missing on this test. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39489
[Bug target/39496] [4.2/4.3/4.4 Regression] GCC uses non-standard calling conventions for static functions with -O0.
--- Comment #6 from jakub at gcc dot gnu dot org 2009-03-19 07:58 --- Created an attachment (id=17491) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17491&action=view) gcc44-pr39496.patch && optimize, not !optimize. Here is what I'm going to bootstrap/regtest. -- 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|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39496
[Bug ada/39498] [4.4 Regression] ACATS test c94001c fails
--- Comment #5 from andreasmeier80 at gmx dot de 2009-03-19 07:47 --- With revision 144946 everything is okay. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39498
[Bug objc/27377] [4.2/4.3/4.4 Regression] false compiler warnings generated in Objective-C code
--- Comment #7 from ayers at gcc dot gnu dot org 2009-03-19 07:07 --- For the record: the official RFA was posted here: http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00666.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27377
