warning: comparison with string literal results in unspecified behaviour
How do i disable that? My code explicitly compares string pointers.
Re: powercp-linux cross GCC 4.2 vs GCC 4.0.0: -Os code size regression? [Emcraft #11717]
Gabriel Paubert wrote: On Thu, Jan 17, 2008 at 05:48:10PM +0300, Sergei Poselenov wrote: Hello Andrew, Preprocessed and assembler code generated by the GCC 4.2.2 ppc-linux cross-compiler: http://www.emcraft.com/codesize/gcc-4.2.2/interrupts.i http://www.emcraft.com/codesize/gcc-4.2.2/interrupts.s The same code built with gcc-4.0.0 cross-compiler: http://www.emcraft.com/codesize/gcc-4.0.0/interrupts.i http://www.emcraft.com/codesize/gcc-4.0.0/interrupts.s The functions do not appear in the same order in both files, it's a bit surprising! Anyway look for example at irq_install_handler: - gcc-4.0 saves all registers using stmw r24,xx(r1) and restores them with lmw r24,xx(r1) however this means that r29 is overwritten in the epilogue. - gcc-4.2.2 saves and restores registers individually which means that it takes 12 more instructions. There go 48 bytes. This is especially visible in the epilogue (in the prologue the saves are interspersed with other instructions). In this case -ffixed-r29 hurts, but gcc4.2.2 looks more correct. OK, so the code here is bigger, partly because a bug has been fixed. Not a bad thing, in general. I suspect that the real reason for the change in save/restore is because not using lmw/stmw is faster. That's just a guess though. gcc could probably be fixed to use ldmw/stmw if -Os is used. Anyway, now we've found something specific this is for the ppc maintainer to comment. Andrew.
Re: warning: comparison with string literal results in unspecified behaviour
On 19/01/2008, Russell Shaw wrote: > How do i disable that? My code explicitly compares string pointers. Your question is off-topic on this list, which is for development of GCC, please use the gcc-help list for help using the compiler: http://gcc.gnu.org/lists.html -Wno-address will suppress the warning, but the code still relies on unspecified behaviour. Jon
Re: powercp-linux cross GCC 4.2 vs GCC 4.0.0: -Os code size regression? [Emcraft #11717]
> Andrew Haley writes: Andrew> I suspect that the real reason for the change in save/restore is because Andrew> not using lmw/stmw is faster. That's just a guess though. gcc could probably Andrew> be fixed to use ldmw/stmw if -Os is used. Andrew> Anyway, now we've found something specific this is for the ppc maintainer to comment. GCC does use load/store multiple and load/store string instructions if -Os is used, but not when the sequence is broken up by a fixed register. David
Re: powercp-linux cross GCC 4.2 vs GCC 4.0.0: -Os code size regression? [Emcraft #11717]
David Edelsohn wrote: Andrew Haley writes: Andrew> I suspect that the real reason for the change in save/restore is because Andrew> not using lmw/stmw is faster. That's just a guess though. gcc could probably Andrew> be fixed to use ldmw/stmw if -Os is used. Andrew> Anyway, now we've found something specific this is for the ppc maintainer to comment. GCC does use load/store multiple and load/store string instructions if -Os is used, but not when the sequence is broken up by a fixed register. Err, why not? Thanks, Andrew.
Re: powercp-linux cross GCC 4.2 vs GCC 4.0.0: -Os code size regression? [Emcraft #11717]
> Andrew Haley writes: Andrew> Err, why not? Because the fixed register means it no longer is a continuous sequence of registers. And the PowerPC port does not break it up into two sequences. And fixed registers in that range are not part of any standard ABI. David
Status of GCC 4.3 on HPPA (Debian)
I recently compiled the Debian archive (around 7000 packages that need to be compiled) on HPPA (PA RISC) using trunk to identify new issues before GCC 4.3 is released. I compiled the archive with optimization set to -O3 and found the following ICEs with trunk from 20071212: - PR34458: ICE in int_cst_value, at tree.c:8047 on HWI==32 hosts Fixed by Richard Guenther - PR34525: ICE in extract_insn, at recog.c:1990 on hppa Fixed by David Anglin - PR34635: tree check: expected polynomial_chrec, have integer_cst in add_multivariate_self_dist, at tree-data-ref.c:2813 (not hppa specific) Fixed by Sebastian Pop - PR34150: output_operand: invalid expression as operand on hppa Known issue, also a problem with 4.2. - PR34651: ICE in set_value_range, at tree-vrp.c:321 Fixed by Richard Guenther - PR34679: ICE: tree check: expected integer_type, have enumeral_type in host_integerp, at tree.c:4949 Fixed by Richard Guenther The testing was done with 4.3.0 20071212 from 2007-12-12 to 2008-01-18. Thanks to LaMont Jones for giving me remote access to a HPPA machine. -- Martin Michlmayr http://www.cyrius.com/
Bootstrap broken for mipsel-linux: gcc/global.c:1020: error: array subscript is above array bounds
For r131631 bootstrap on mipsel-linux in stage2 I am getting: /home/ddaney/gccsvn/trunk-build/./prev-gcc/xgcc -B/home/ddaney/gccsvn/trunk-build/./prev-gcc/ -B/home/ddaney/gccsvn/trunk-install/mipsel-linux/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../trunk/gcc -I../../trunk/gcc/. -I../../trunk/gcc/../include -I../../trunk/gcc/../libcpp/include -I/home/ddaney/mp/include -I/home/ddaney/mp/include -I../../trunk/gcc/../libdecnumber -I../../trunk/gcc/../libdecnumber/dpd -I../libdecnumber ../../trunk/gcc/final.c -o final.o /home/ddaney/gccsvn/trunk-build/./prev-gcc/xgcc -B/home/ddaney/gccsvn/trunk-build/./prev-gcc/ -B/home/ddaney/gccsvn/trunk-install/mipsel-linux/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../trunk/gcc -I../../trunk/gcc/. -I../../trunk/gcc/../include -I../../trunk/gcc/../libcpp/include -I/home/ddaney/mp/include -I/home/ddaney/mp/include -I../../trunk/gcc/../libdecnumber -I../../trunk/gcc/../libdecnumber/dpd -I../libdecnumber ../../trunk/gcc/global.c -o global.o cc1: warnings being treated as errors ../../trunk/gcc/global.c: In function 'find_reg': ../../trunk/gcc/global.c:1020: error: array subscript is above array bounds make[3]: *** [global.o] Error 1 This is new since r131576: http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg00758.html The configuration is identical to that successful bootstrap/test
Re: Bootstrap broken for mipsel-linux: gcc/global.c:1020: error: array subscript is above array bounds
David Daney <[EMAIL PROTECTED]> writes:
> For r131631 bootstrap on mipsel-linux in stage2 I am getting:
>
> /home/ddaney/gccsvn/trunk-build/./prev-gcc/xgcc
> -B/home/ddaney/gccsvn/trunk-build/./prev-gcc/
> -B/home/ddaney/gccsvn/trunk-install/mipsel-linux/bin/ -c -g -O2
> -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
> -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute
> -pedantic -Wno-long-long
> -Wno-variadic-macros
> -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I.
> -I../../trunk/gcc -I../../trunk/gcc/. -I../../trunk/gcc/../include
> -I../../trunk/gcc/../libcpp/include -I/home/ddaney/mp/include
> -I/home/ddaney/mp/include -I../../trunk/gcc/../libdecnumber
> -I../../trunk/gcc/../libdecnumber/dpd -I../libdecnumber
> ../../trunk/gcc/final.c -o final.o
> /home/ddaney/gccsvn/trunk-build/./prev-gcc/xgcc
> -B/home/ddaney/gccsvn/trunk-build/./prev-gcc/
> -B/home/ddaney/gccsvn/trunk-install/mipsel-linux/bin/ -c -g -O2
> -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
> -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute
> -pedantic -Wno-long-long
> -Wno-variadic-macros
> -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I.
> -I../../trunk/gcc -I../../trunk/gcc/. -I../../trunk/gcc/../include
> -I../../trunk/gcc/../libcpp/include -I/home/ddaney/mp/include
> -I/home/ddaney/mp/include -I../../trunk/gcc/../libdecnumber
> -I../../trunk/gcc/../libdecnumber/dpd -I../libdecnumber
> ../../trunk/gcc/global.c -o global.o
> cc1: warnings being treated as errors
> ../../trunk/gcc/global.c: In function 'find_reg':
> ../../trunk/gcc/global.c:1020: error: array subscript is above array bounds
> make[3]: *** [global.o] Error 1
>
> This is new since r131576:
>
> http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg00758.html
>
> The configuration is identical to that successful bootstrap/test
global.c:1020 is new code that was added during that time. There's
nothing intrinsically wrong with it though. The warning is simply about
something that can't prove is dead code. (I.e. it's another example in
favour of Mark's "the middle end shouldn't warn" thing.) A reduced
testcase is:
--
#define BIT(X, B) ((X) < ((B) ? 2 : 4) ? (X) + 4 : ~0U)
void bar (unsigned int *);
void foo (unsigned int b)
{
unsigned int i, a[4];
for (i = 0; BIT (i, b) != ~0U; i++)
a[BIT (i, b) / 32] |= 1U << (BIT (i, b) % 32);
bar (a);
}
--
which generates a warning on x86_64-linux-gnu when compiled with -O2 -Wall.
We generate array accesses for a[(i + 4) / 32] and a[~0U / 32] and can't
prove that the latter are never used.
The attached patch uses the same construct as other E_R_D_R loops
and avoids the warning. I'll test it overnight and install as obvious
if it succeeds.
Richard
Index: gcc/global.c
===
--- gcc/global.c2008-01-19 23:54:32.0 +
+++ gcc/global.c2008-01-19 23:54:56.0 +
@@ -1016,8 +1016,13 @@ find_reg (int num, HARD_REG_SET losers,
if (allocno[num].no_eh_reg)
{
unsigned int j;
- for (j = 0; EH_RETURN_DATA_REGNO (j) != INVALID_REGNUM; j++)
- SET_HARD_REG_BIT (used1, EH_RETURN_DATA_REGNO (j));
+ for (j = 0; ; ++j)
+ {
+ unsigned int regno = EH_RETURN_DATA_REGNO (j);
+ if (regno == INVALID_REGNUM)
+ break;
+ SET_HARD_REG_BIT (used1, regno);
+ }
}
#endif
