simplify_relational_operation and unsigned char
(gcc-4.4.1) Hi, I found out some strange behavior of simplify_relational_operation. Apparently it assumes QImode is signed even though this could not be deduced from the EQ operator. Here is an example: rtx reg = gen_reg_rtx(QImode); ... rtx test = simplify_relational_operation(EQ, VOIDmode, QImode, reg, GEN_INT(129)); In this case simplify_relational_operation returns const_int 0 because of comparisons optimization with upper and lower bounds performed on simplify_const_relational_operation. The problem with this behavior was the removal of a "case 129:" in a switch during cse pass (proprietary target and backend). Perhaps EQ and NE could be treated as unsigned, like the GEU,LEU,GTU,LTU operators? Amir
Possibly gcc/ld bug
I'm pretty sure I found a bug in psp-gcc (or actually in ld). It may be with the specific psp-gcc/ld bfd or it may be in ld itself. I'm not sure this is the right forum to post this, but hopefully the experts can assist me. I'm working on the PSP (MIPS architecture), doing some unusual linking in Scummvm to get dynamic plugins going. I borrowed the method from the Dreamcast Scummvm code, where it works just fine. Essentially, I use a custom linker file to put all the shorts (.sbss, .sdata) in one area in my main executable, and then I ask ld to keep the relocation entries for the plugin files with the '-q' option, and to take all the symbols from the main executable. Within ScummVM itself I relocate the things in memory. Things were generally working fine in most games. However, looking into one of the games (Kyrandia), I found the following relocations: eb44 0405 R_MIPS_HI16 000fcf60 .rodata eb48 0406 R_MIPS_LO16 000fcf60 .rodata eb54 00106206 R_MIPS_LO16 08aecb54 _ZN4Kyra14KyraEngine_L eb58 00223d06 R_MIPS_LO16 08aecb5c _ZN4Kyra14KyraEngine_L Notice that ld is chaining LO16 relocations after HI16's. However, it's doing something completely illegal since the LO16 for 08aecb54 is not preceded by a valid HI16 entry! ld got confused by the two address ranges. The reason I never came across this before is that this is the first time the compiler chose to access things in the shorts section using HI/LO16s instead of GPRELs. I didn't know that was even legal. Since I kept my -G parameter at the default of 8 (i.e. I dropped it), most games never accessed the $gp relative section using HI/LO16s. This is the only game that had arrays of 8 bytes, and I guess the compiler decided it was worth it to just use HI/LO16s to access them. This means also that if I enlarge my -G parameter, I'll get more of these issues. -- View this message in context: http://www.nabble.com/Possibly-gcc-ld-bug-tp26112337p26112337.html Sent from the gcc - Dev mailing list archive at Nabble.com.
[PATCH][LTO] Fix PR41858
You wrote: > I refrained from adding a 4000 file testcase ;) Never mind - I have one. I didn't understand why lto1 said this: /usr/snp/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../x86_64-unknown-linux -gnu/bin/ld: fatal error: could not open/create temporary file while dealing with the largest executable of our weather forecasting system. [ BTW, you could just say ulimit -n 10 before running the test :-) ] -- Toon Moene, KNMI (Weer/Onderzoek), The Netherlands Phone: +31 30 2206443; e-mail: mo...@knmi.nl
Re: [PATCH][LTO] Fix PR41858
On Thu, 29 Oct 2009, Toon Moene wrote: > You wrote: > > > I refrained from adding a 4000 file testcase ;) > > Never mind - I have one. I didn't understand why lto1 said this: > > /usr/snp/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../x86_64-unknown-linux > -gnu/bin/ld: fatal error: could not open/create temporary file > > while dealing with the largest executable of our weather forecasting system. > > [ BTW, you could just say ulimit -n 10 before running the test :-) ] Heh, indeed. Btw, I didn't yet hit the above error. Are you using the linker plugin? Richard.
Re: [PATCH][LTO] Fix PR41858
Richard Guenther wrote: On Thu, 29 Oct 2009, Toon Moene wrote: You wrote: I refrained from adding a 4000 file testcase ;) Never mind - I have one. I didn't understand why lto1 said this: /usr/snp/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../x86_64-unknown-linux -gnu/bin/ld: fatal error: could not open/create temporary file while dealing with the largest executable of our weather forecasting system. [ BTW, you could just say ulimit -n 10 before running the test :-) ] Heh, indeed. Btw, I didn't yet hit the above error. Are you using the linker plugin? Indeed. Your fix *does* work for that case, no ? -- Toon Moene, KNMI (Weer/Onderzoek), The Netherlands Phone: +31 30 2206443; e-mail: mo...@knmi.nl
Re: [PATCH][LTO] Fix PR41858
On Thu, 29 Oct 2009, Toon Moene wrote: > Richard Guenther wrote: > > > On Thu, 29 Oct 2009, Toon Moene wrote: > > > > > You wrote: > > > > > > > I refrained from adding a 4000 file testcase ;) > > > Never mind - I have one. I didn't understand why lto1 said this: > > > > > > /usr/snp/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../x86_64-unknown-linux > > > -gnu/bin/ld: fatal error: could not open/create temporary file > > > > > > while dealing with the largest executable of our weather forecasting > > > system. > > > > > > [ BTW, you could just say ulimit -n 10 before running the test :-) ] > > > > Heh, indeed. Btw, I didn't yet hit the above error. Are you using > > the linker plugin? > > Indeed. Your fix *does* work for that case, no ? Well, it fixes a leak in lto1 which affected both using the linker plugin and not. The above error seems to be from ld instead or the linker plugin (or maybe collect2). Richard.
Re: simplify_relational_operation and unsigned char
On 10/29/2009 03:35 AM, Amir Gonnen wrote: rtx test = simplify_relational_operation(EQ, VOIDmode, QImode, reg, GEN_INT(129)); CONST_INT is always signed. If you really wrote this as you quote here, that would be the breakage. Try gen_int_mode (129, QImode) instead. r~
Re: simplify_relational_operation and unsigned char
Amir Gonnen wrote: > Perhaps EQ and NE could be treated as unsigned, like the > GEU,LEU,GTU,LTU operators? :) What exactly is "signed equality" and how does/would it differ from "unsigned equality"? I'm not sure the concept makes any sense! (And that's always a warning sign that your diagnosis has gone astray somewhere and led you to a false understanding of the problem you're working on.) cheers, DaveK
MPC 0.8 prerelease tarball (last release before MPC is mandatory!)
A prerelease tarball of the upcoming mpc-0.8 is available here: http://www.multiprecision.org/mpc/download/mpc-0.8-dev.tar.gz This release is feature complete with respect to C99 and GCC's needs. So I expect to make this version be the one made mandatory for the gcc-4.5 release. If there are any remaining bugs especially portability problems to GCC's primary or secondary platforms, I'd like to get those reported and fixed before this release is final. Please test this MPC package and report back the results of running "make check" along with your target triplet, the compiler version you used, and the versions of gmp/mpfr used to compile it. You do not necessarily need to bootstrap mainline GCC with this MPC, but if you have the spare time and cycles it would be nice too. Thanks, --Kaveh -- Kaveh R. Ghazi gh...@caip.rutgers.edu
SHN_UNDEF symbols with non-zero value in MIPS shared object
Hi, Cross-MIPS gcc version (for Linux target) used is 4.3.2 Today I saw that .so files of MIPS contain some undef symbols with non-zero value The few I saw are defined in libC Wont this confuse dynamic linker of 4.3.2 ? ( i know that in 4.3.3. , there is the STO_MIPS_PLT check which skip these. ) How does the dynamic linker ignore them during lookup ? What is the purpose of these symbols ? thanks shankar
"uninitialized variable" warning from compiler
Hi,
I have few questions about inbuilt mechanism of gcc/g++ for
warning about uninitialized variable.
I am interested in cases where compiler is unable to warn. I am
aware that all the known bugs about warning-failure are
mentioned at bugzilla http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
a) The compiler activates the warning mechanism only if optimisation
is enabled at compilation time with -O option. For all the bugs that
I went through at bugzilla, the failure is not -O level dependent.
The warning-failure occurs for all levels of optimisation. So, I
believe this is the general case.
But then I came across the following failure case.
#include
int Check(int *a)
{
if (*a == 0)
{
printf("This is sample \n");
}
return *a;
}
int main()
{
int call;
Check(&call);
return 0;
}
/
This one fails to warn when compiled with any level below 3.
With -O3, gcc is able to warn.
Can someone tell me which is the corresponding bug logged at bugzilla ?
Are there any more such bugs which disappear when compiled with
specific -O level ?
b) Are there any known "fail to do uninitialised-warning" gcc bugs
which are language-dependent ? I mean bugs which occur only in C++ ,
but not in C. ( Bugs which arise out of C++ language features/syntax. ) .
If so, I would like to know.
Elsewhere, someone pointed out to me that these are not "bugs", but occur
due to tradeoff in compiler against false positive warnings. I am
referring them
as "bugs" only because compiler hackers do so.
thanks for your time
Uma shankar
gcc-4.5-20091029 is now available
Snapshot gcc-4.5-20091029 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20091029/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 153727 You'll find: gcc-4.5-20091029.tar.bz2 Complete GCC (includes all of below) gcc-core-4.5-20091029.tar.bz2 C front end and core compiler gcc-ada-4.5-20091029.tar.bz2 Ada front end and runtime gcc-fortran-4.5-20091029.tar.bz2 Fortran front end and runtime gcc-g++-4.5-20091029.tar.bz2 C++ front end and runtime gcc-java-4.5-20091029.tar.bz2 Java front end and runtime gcc-objc-4.5-20091029.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.5-20091029.tar.bz2The GCC testsuite Diffs from 4.5-20091022 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: MPC 0.8 prerelease tarball (last release before MPC is mandatory!)
From: "David Fang" On powerpc-apple-darwin8: gmp: 4.3.1 mpfr: 2.4.1 % gcc -v Using built-in specs. Target: powerpc-apple-darwin8 Configured with: /var/tmp/gcc/gcc-5370~2/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 Thread model: posix gcc version 4.0.1 (Apple Computer, Inc. build 5370) CPU: dual G4, powerpc 7400 === All 57 tests passed === Thanks!
Re: MPC 0.8 prerelease tarball (last release before MPC is mandatory!)
From: "Allan McRae" Nothing exotic: i686-pc-linux-gnu & x86_64-unknown-linux-gnu Both: === All 57 tests passed === gcc-4.4.2 mpfr-2.4.1 gmp-4.3.1 Also fine on i686-pc-linux-gnu with gcc-4.5-20091008 Allan Thanks!
Re: Possibly gcc/ld bug
Bluddy writes: > Notice that ld is chaining LO16 relocations after HI16's. However, it's > doing something completely illegal since the LO16 for 08aecb54 is not > preceded by a valid HI16 entry! ld got confused by the two address ranges. While the calculation of a HI16 reloc requires the LO16 reloc, the reverse is not true: you can calculate LO16 without HI16. The GNU toolchain takes advantage of this fact. Ian
Re: SHN_UNDEF symbols with non-zero value in MIPS shared object
Uma shankar writes: > Cross-MIPS gcc version (for Linux target) used is 4.3.2 > > Today I saw that .so files of MIPS contain some undef symbols with > non-zero value > > The few I saw are defined in libC > > Wont this confuse dynamic linker of 4.3.2 ? ( i know that in 4.3.3. > , there is the STO_MIPS_PLT check which skip these. ) > > How does the dynamic linker ignore them during lookup ? > What is the purpose of these symbols ? This question is not appropriate for the gcc@gcc.gnu.org mailing list. It would be appropriate for gcc-h...@gcc.gnu.org. Please take any followups to gcc-help. Thanks. Having SHN_UNDEF symbols with a non-zero value is perfectly normal for MIPS shared libraries. The dynamic linker uses them to handle function pointer comparisons across shared libraries. For details see the ELF MIPS processor supplement, which is available online. Ian
Re: "uninitialized variable" warning from compiler
Uma shankar writes:
> a) The compiler activates the warning mechanism only if optimisation
> is enabled at compilation time with -O option. For all the bugs that
> I went through at bugzilla, the failure is not -O level dependent.
> The warning-failure occurs for all levels of optimisation. So, I
> believe this is the general case.
>
> But then I came across the following failure case.
>
>
> #include
> int Check(int *a)
> {
> if (*a == 0)
> {
> printf("This is sample \n");
> }
> return *a;
> }
> int main()
> {
> int call;
> Check(&call);
> return 0;
> }
> /
>
> This one fails to warn when compiled with any level below 3.
> With -O3, gcc is able to warn.
>
> Can someone tell me which is the corresponding bug logged at bugzilla ?
>
> Are there any more such bugs which disappear when compiled with
> specific -O level ?
>
> b) Are there any known "fail to do uninitialised-warning" gcc bugs
> which are language-dependent ? I mean bugs which occur only in C++ ,
> but not in C. ( Bugs which arise out of C++ language features/syntax. ) .
> If so, I would like to know.
>
> Elsewhere, someone pointed out to me that these are not "bugs", but occur
> due to tradeoff in compiler against false positive warnings. I am
> referring them
> as "bugs" only because compiler hackers do so.
This message is also not appropriate for gcc@gcc.gnu.org, but is
appropriate for gcc-h...@gcc.gnu.org.
gcc is known to be inconsistent about when it issues warnings about
uninitialized variables. This is not a good thing. It is a
consequence of the fact that gcc issues those warnings based on the
implementation of different optimizations.
I'm not aware of any attempts to characterize precisely when gcc warns
and when it does not. Any such characterization would have to be
updated for each new release in any case.
Ian
