Re: This is a Cygwin failure yeah?
On 18/01/2009, Dave Korn wrote: > Andy Scott wrote: > > > Again stage3 part of build, and this is what actually stops the build > > the above issue doesn't seem to (I think it happens in stage 2), I get > > the following: > > > > > > > < a few more lines of log deleted :) > > > > > ../../../gcc/libiberty/strsignal.c -o strsignal.o > > ../../../gcc/libiberty/strsignal.c:408: error: conflicting types for > 'strsignal' > > /usr/include/string.h:78: note: previous declaration of 'strsignal' was > here > > make[2]: *** [strsignal.o] Error 1 > > make[2]: Leaving directory > `/home/andy/live-gcc/my_gcc/i686-pc-cygwin/libiberty' > > make[1]: *** [all-target-libiberty] Error 2 > > make[1]: Leaving directory `/home/andy/live-gcc/my_gcc' > > make: *** [all] Error 2 > > > Hi Andy, > > I created a bugzilla entry for the failure: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38903 > > I've applied a patch to GCC SVN HEAD to fix the strsignal bug (r.143487), > and would appreciate if you could verify that it solves the build > failure for you. > > thanks, > DaveK > The two test machines I set going with this both managed succesful builds. (Even if it did take them 5hrs+ to do it :s ) Thanks again for your effort on this. Now I'll try to get the full test suite running for them now. Andy -- Brain upgrade required: a working hypothalamus
cross-compilation, deprecated option and libgcc
Hi,
I am still trying to generate a cross-compiler targeting wince-pe from
trunk.
Last time it seems nobody was able to answer so now I am going to ask
simpler questions :
1) When I compile bootstrap gcc, I am using make all-gcc and make
install-gcc and it seems it doesn't build libgcc anymore.
${BASE_DIRECTORY}/${gcc_src}/configure \
--with-gcc \
--with-gnu-ld \
--with-gnu-as \
--target=${TARGET} \
--prefix=${PREFIX} \
--disable-threads \
--disable-nls \
--enable-languages=c \
--disable-win32-registry \
--disable-multilib \
--disable-shared \
--disable-interwork\
--without-newlib \
--enable-checking
make ${PARALLELISM} all-gcc
make install-gcc
So my first question is : For a bootstrap gcc do I need to build libgcc and
in this case should I use make all and make install instead ?
2) On my previous post I had an issue when building mingw because linker
was missing crtbegin.o adn crtend.o so I tried to replace
make all-gcc by make all but then there was some missing headers to compile
libgcc.
So I have added a --with-headers option and I thought everything was fine
because crtbegin/crtend are available but now I get the following error:
arm-mingw32ce-gcc -Wl,--base-file=mingwthrd.base -B./ -mdll
-Wl,--image-base,0x6FBC mthr.o mthr_init.o -Lmingwex \
-o mingwthrd_dummy.exe
arm-mingw32ce-gcc -Wl,--base-file=mingwthrd.base -B./ -mdll
-Wl,--image-base,0x6FBC mthr.o mthr_init.o -Lmingwex \
-o mingwthrd_dummy.exe
/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.4.0/../../../../arm-mingw32ce/bin/ld:
warning: cannot find entry symbol DllMainCRTStartup; defaulting to 6fbc1000
./libmingw32.a(winmain_ce.o): In function `WinMain':
/home/Vincent/cegcc-4.4.0/src/mingw/winmain_ce.c:151: undefined reference
to `main'
/home/Vincent/cegcc-4.4.0/src/mingw/winmain_ce.c:151: relocation truncated
to fit: ARM_26 against undefined symbol `main'
collect2: ld returned 1 exit status
make: *** [mingwthrd.def] Error 1
I wanted also to use --with-sysroot because --with-headers is marked as
'deprecated' so I tried the --with-sysroot option
but then I had the following message :
configure: WARNING: you should use --build, --host, --target
configure: WARNING: invalid host type:
This message is quite explicit so I have added this options and I still
have this error message.
When I check in config.log :
/home/Vincent/cegcc-4.4.0/src/gcc/configure --host=i686-pc-cygwin
--build=i686-pc-cygwin --target=arm-mingw32ce --prefix=/opt/mingw32ce
--with-sysroot=/home/Vincent/cegcc-4.4.0/src/w32api/include
Just to be sure I will try again on a linux box to be sure the problem is
not related to cygwin ...
If someone could help or at least answer question 1)
Thanks
gcc-4.3.3.tar.bz2 md5sum does not match
I've tried two mirrors with the same results: $ cat md5.sum | grep gcc-4.3.3.tar.bz2 d3338b75fa6f83be08908b1eed56d439 gcc-4.3.3.tar.bz2 $ md5sum gcc-4.3.3.tar.bz2 cc3c5565fdb9ab87a05ddb106ba0bd1f gcc-4.3.3.tar.bz2 Can someone confirm/fix this? Thanks! Andrew Walrond
Re: gcc-4.3.3.tar.bz2 md5sum does not match
On Mon, Jan 26, 2009 at 4:23 PM, Andrew Walrond wrote: > I've tried two mirrors with the same results: > > $ cat md5.sum | grep gcc-4.3.3.tar.bz2 > > d3338b75fa6f83be08908b1eed56d439 gcc-4.3.3.tar.bz2 > > $ md5sum gcc-4.3.3.tar.bz2 > cc3c5565fdb9ab87a05ddb106ba0bd1f gcc-4.3.3.tar.bz2 > > Can someone confirm/fix this? Appearantly the md5.sum file is autogenerated somehow and this happened before the upload was complete. Does somebody know how to re-trigger it? Thanks, Richard. > Thanks! > > Andrew Walrond >
Inline limits
Hi, I ran into some code-size/stack size bloat using -Os for a piece of code. This seemed to happen only when certain single call-site functions are defined "static" and not otherwise. On investigating further on this, i see that the inline_functions_called_once seems to rely only on "cgraph_check_inline_limits", whereas other inlining code go through more rigorous cost-benefit analysis to decide on inlining (especially with INLINE_SIZE). I have been looking at re-setting some of the parameters used in "cgraph_check_inline_limits" for inlining for picochip. I could not understand the way PARAM_LARGE_FUNCTION_GROWTH and PARAM_STACK_FRAME_GROWTH are used in this function. Both of these parameters are used as a fraction of the bigger (or to) function. I want to be able to say, if the inlining would increase the code size or stack frame size, dont inline. Otherwise, go ahead an inline. Of course, i am compiling this code at -Os, so this condition is probably obvious. Can you advice me on how to use these parameters to do that? A side question... Are 'static' single call-site functions always inlined? I would hope not (under -Os), but just checking. Thanks Hari PS: If this were to be considered a "bug", i will file a report with a testcase.
Re: gcc-4.3.3.tar.bz2 md5sum does not match
On Mon, Jan 26, 2009 at 7:49 AM, Richard Guenther wrote: > On Mon, Jan 26, 2009 at 4:23 PM, Andrew Walrond wrote: >> I've tried two mirrors with the same results: >> >> $ cat md5.sum | grep gcc-4.3.3.tar.bz2 >> >> d3338b75fa6f83be08908b1eed56d439 gcc-4.3.3.tar.bz2 >> >> $ md5sum gcc-4.3.3.tar.bz2 >> cc3c5565fdb9ab87a05ddb106ba0bd1f gcc-4.3.3.tar.bz2 >> >> Can someone confirm/fix this? > > Appearantly the md5.sum file is autogenerated somehow and > this happened before the upload was complete. > One way to solve it to have a staging area on the same filesystem. After upload to staging area is done, you do a "mv staging dest". -- H.J.
Re: Inline limits
On Mon, Jan 26, 2009 at 5:41 PM, Richard Guenther wrote: > On Mon, Jan 26, 2009 at 5:29 PM, Hariharan wrote: >> Hi, >> I ran into some code-size/stack size bloat using -Os for a piece of code. >> This seemed to happen only when certain single call-site functions are >> defined "static" and not otherwise. On investigating further on this, i see >> that the inline_functions_called_once seems to rely only on >> "cgraph_check_inline_limits", whereas other inlining code go through more >> rigorous cost-benefit analysis to decide on inlining (especially with >> INLINE_SIZE). >> >> I have been looking at re-setting some of the parameters used in >> "cgraph_check_inline_limits" for inlining for picochip. I could not >> understand the way PARAM_LARGE_FUNCTION_GROWTH and PARAM_STACK_FRAME_GROWTH >> are used in this function. Both of these parameters are used as a fraction >> of the bigger (or to) function. >> >> I want to be able to say, if the inlining would increase the code size or >> stack frame size, dont inline. Otherwise, go ahead an inline. Of course, i >> am compiling this code at -Os, so this condition is probably obvious. Can >> you advice me on how to use these parameters to do that? > > For -Os it should be enough to set PARAM_STACK_FRAME_GROWTH > to zero. Oh, and LARGE_STACK_FRAME to zero as well, for result stack frame sizes below LARGE_STACK_FRAME the growth limit is not applied. > Inlining at -Os should already only happen if it decreases > (overall!) code-size. Thus, inlining a function that is called once and > that does not need to be emitted will always be an overall code-size > win. > >> A side question... Are 'static' single call-site functions always inlined? I >> would hope not (under -Os), but just checking. > > Yes. This is always a code-size win. > > Richard. > >> Thanks >> Hari >> >> PS: If this were to be considered a "bug", i will file a report with a >> testcase. >> >> >
Re: Inline limits
On Mon, Jan 26, 2009 at 5:29 PM, Hariharan wrote: > Hi, > I ran into some code-size/stack size bloat using -Os for a piece of code. > This seemed to happen only when certain single call-site functions are > defined "static" and not otherwise. On investigating further on this, i see > that the inline_functions_called_once seems to rely only on > "cgraph_check_inline_limits", whereas other inlining code go through more > rigorous cost-benefit analysis to decide on inlining (especially with > INLINE_SIZE). > > I have been looking at re-setting some of the parameters used in > "cgraph_check_inline_limits" for inlining for picochip. I could not > understand the way PARAM_LARGE_FUNCTION_GROWTH and PARAM_STACK_FRAME_GROWTH > are used in this function. Both of these parameters are used as a fraction > of the bigger (or to) function. > > I want to be able to say, if the inlining would increase the code size or > stack frame size, dont inline. Otherwise, go ahead an inline. Of course, i > am compiling this code at -Os, so this condition is probably obvious. Can > you advice me on how to use these parameters to do that? For -Os it should be enough to set PARAM_STACK_FRAME_GROWTH to zero. Inlining at -Os should already only happen if it decreases (overall!) code-size. Thus, inlining a function that is called once and that does not need to be emitted will always be an overall code-size win. > A side question... Are 'static' single call-site functions always inlined? I > would hope not (under -Os), but just checking. Yes. This is always a code-size win. Richard. > Thanks > Hari > > PS: If this were to be considered a "bug", i will file a report with a > testcase. > >
Re: gcc-4.3.3.tar.bz2 md5sum does not match
On Mon, Jan 26, 2009 at 5:37 PM, H.J. Lu wrote: > On Mon, Jan 26, 2009 at 7:49 AM, Richard Guenther > wrote: >> On Mon, Jan 26, 2009 at 4:23 PM, Andrew Walrond wrote: >>> I've tried two mirrors with the same results: >>> >>> $ cat md5.sum | grep gcc-4.3.3.tar.bz2 >>> >>> d3338b75fa6f83be08908b1eed56d439 gcc-4.3.3.tar.bz2 >>> >>> $ md5sum gcc-4.3.3.tar.bz2 >>> cc3c5565fdb9ab87a05ddb106ba0bd1f gcc-4.3.3.tar.bz2 >>> >>> Can someone confirm/fix this? >> >> Appearantly the md5.sum file is autogenerated somehow and >> this happened before the upload was complete. >> > > One way to solve it to have a staging area on the same filesystem. > After upload to staging area is done, you do a "mv staging dest". Sure. The gcc_release script does not do that though. The file is owned by root, so I cannot delete it either ... Richard.
Announce: MPFR 2.4.0 is release
MPFR 2.4.0 ("andouillette sauce moutarde") is now available for download
from the MPFR web site:
http://www.mpfr.org/mpfr-2.4.0/
Thanks very much to those who sent us bug reports and/or tested the release
candidate.
md5sum :
f5916d785d4f7e7282057f6a3ebff9ce mpfr-2.4.0.tar.bz2
6a6162517d7e4f74900e86410f313be9 mpfr-2.4.0.tar.gz
64b0d60ee5c3833b943a75ae63724d1e mpfr-2.4.0.tar.lzma
c835d03e94be6452b2bf9c2f39c9d83f mpfr-2.4.0.zip
Changes from version 2.3.2 to version 2.4.0:
- MPFR is now a GNU package.
- Changes in the behavior of mpfr_strtofr and in its documentation
concerning particular cases where the code and the documentation
did not match; this change is also present in MPFR 2.3.1.
- Behavior of mpfr_check_range changed: if the value is an inexact
infinity, the overflow flag is set (in case it was lost); this
change is also present in MPFR 2.3.2.
- Function mpfr_init_gmp_rand (only defined when building MPFR without
the --with-gmp-build configure option) is no longer defined at all.
This function was private and not documented, and was used only in
the MPFR test suite. User code that calls it is regarded as broken
and may fail as a consequence. Running the old test suite against
MPFR 2.4.0 may also fail.
- New functions:
* between a MPFR number and a double: mpfr_add_d, mpfr_sub_d,
mpfr_d_sub, mpfr_mul_d, mpfr_div_d, mpfr_d_div,
* formatted input/output:
mpfr_printf, mpfr_fprintf, mpfr_vprintf, mpfr_vfprintf,
mpfr_sprintf, mpfr_snprintf, mpfr_vsprintf, mpfr_vsnprintf,
mpfr_asprintf, mpfr_vasprintf.
* mpfr_sinh_cosh, mpfr_li2, mpfr_modf, mpfr_fmod, mpfr_rec_sqrt.
- Configure test for TLS support.
- Get default $CC and $CFLAGS from gmp.h (__GMP_CC / __GMP_CFLAGS,
which are available as of GMP 4.2.3).
- Documented the fact that mpfr_random and mpfr_random2 will be
suppressed in the next release, and that the specification of
mpfr_eq may change in the next release (for compatibility with
the mpf layer of GMP).
- Bug fixes.
You can send success and failure reports to , and give us
the canonical system name as returned by the config.guess script, the
processor and compiler version, in order to complete the "Platforms Known
to Support MPFR" section of the MPFR 2.4.0 web page.
Regards,
--
Vincent Lefèvre - Web:
Re: C++0x Concepts development schedule
Rodolfo Lima wrote: When the time to get the hands dirty arrives, I'll need to know if somebody's working off-branch on some parts to avoid unnecessary work. I don't think anyone is working on it at the moment; since Apple hired Doug Gregor he isn't working on GCC at all anymore. I also know that ConceptGCC's implementation isn't the best, so it'll be good to know which parts of it are in good shape and which must be rethought and reimplemented. He'd be the best person to ask about that, I haven't had a chance to review it yet. I believe the conceptgcc-branch is more current than the cxx0x-concepts-branch. Jason
Re: C++0X constexpr implementation status
Ed Smith-Rowland wrote: In my efforts to build C++-0X library components I've noticed that constexpr member variables are used in several places. I was unable to implement these as intended and reverted to const accessors. It seems like the intent is sort of a static const function except that it binds to a specific instance. I looked around and it looked like some effort had taken place to implement constexpr in the front end. I was wondering where this effort left off? Will it be picked up in the gcc-4.5 time frame? Gabriel dos Reis was working on constexpr. I don't know its current status. Jason
Re: gcc-4.3.3.tar.bz2 md5sum does not match
Richard Guenther writes: > On Mon, Jan 26, 2009 at 4:23 PM, Andrew Walrond wrote: >> I've tried two mirrors with the same results: >> >> $ cat md5.sum | grep gcc-4.3.3.tar.bz2 >> >> d3338b75fa6f83be08908b1eed56d439 gcc-4.3.3.tar.bz2 >> >> $ md5sum gcc-4.3.3.tar.bz2 >> cc3c5565fdb9ab87a05ddb106ba0bd1f gcc-4.3.3.tar.bz2 >> >> Can someone confirm/fix this? > > Appearantly the md5.sum file is autogenerated somehow and > this happened before the upload was complete. > > Does somebody know how to re-trigger it? I removed the md5.sum file. It should be rebuilt automatically within one hour. Ian
Re: Archive for SPEC CPU 2K/2006 results?
"H.J. Lu" writes: > My website isn't visible to public. Also it isn't really benchmark since > I only run functional tests. My reports only show pass or which tests > failed. For what it's worth, Diego is posting his spec runs on my website, at http://www.airs.com/dnovillo/spec2000/ . I'd be happy to open up space there if it would be helpful. Ian
Re: Archive for SPEC CPU 2K/2006 results?
On Mon, Jan 26, 2009 at 11:31 AM, Ian Lance Taylor wrote: > "H.J. Lu" writes: > >> My website isn't visible to public. Also it isn't really benchmark since >> I only run functional tests. My reports only show pass or which tests >> failed. > > For what it's worth, Diego is posting his spec runs on my website, at > http://www.airs.com/dnovillo/spec2000/ . I'd be happy to open up > space there if it would be helpful. > Hi Ian, Reports of my functional tests for SPEC CPU 2K/2006 are very short. * From: h...@gnu-65.sc.intel.com (H.J. Lu) * Subject: gcc (GCC) 4.4.0 20090125 (experimental) [trunk revision 143664] passed SPEC CPU 2006 on x86_64 * Date: Mon, 26 Jan 2009 08:53:57 -0800 (PST) With runspec -c lnx-x86_64-gcc.cfg -T base -e o2 -n 1 -l -o asc -I all I would appreciate if I can email my reports to your website. Thanks. -- H.J.
Re: cross-compilation, deprecated option and libgcc
On Mon, 2009-01-26 at 14:19 +0100, Vincent R. wrote: > 1) When I compile bootstrap gcc, I am using make all-gcc and make > install-gcc and it seems it doesn't build libgcc anymore. I think that's correct; make all-gcc just builds gcc these days. To build libgcc, you need to run make all-target-libgcc. libgcc is no longer built as part of gcc, but like any other of the target libraries. It's best to do a make all and make install to avoid these hassles. If you want to keep the workload down, use --enable-languages to prune the set of languages you support in your "bootstrap" compiler. (Is there a reason why you can't just build the cross using your system compiler?) > So my first question is : For a bootstrap gcc do I need to build libgcc and > in this case should I use make all and make install instead ? Yes. Cheers, Ben
x86-64 and large code model questions/bugs
I have a user who is trying to use the large code model on x86-64 Linux
(-mcmodel=large) and is running into some trouble and I have a couple of
questions for the x86-64 experts/maintainers.
The first one is: would it be reasonable to compile crt files with
-mcmodel=large by default on the x86-64 linux platform? Currently the
crt files are not compiled with this option and that makes it impossible
to compile a program where the text segment is above 4GB (for example)
because the crt files can't handle the large code model if they aren't
compiled with this option.
The second issue is a couple of bugs we have run into while trying to
compile crtstuff.c with this option. The first bug is in
cselib_hash_rtx where it can't handle the 'u' and 'B' format codes in an
rtx. I fixed this by skipping them just like '0' and 't' are skipped
but that resulted in the second bug:
x.c:15: error: invalid rtl sharing found in the insn
(insn 84 83 85 2 x.c:5 (set (reg:DI 40 r11)
(unspec:DI [
(note/s 82 81 83 2 "" NOTE_INSN_DELETED_LABEL 6)
] 17)) -1 (nil))
x.c:15: error: shared rtx
(note/s 82 81 83 2 "" NOTE_INSN_DELETED_LABEL 6)
x.c:15: internal compiler error: internal consistency failure
Both issues can be reproduced by compiling this code from crtstuff.c
on an x86-64 linux box with '-O2 -fPIC -mcmodel=large'.
typedef long unsigned int size_t;
typedef void (*func_ptr) (void);
static func_ptr __DTOR_LIST__[1] = { (func_ptr) (-1) };
static void __attribute__((used)) __do_global_dtors_aux (void)
{
extern func_ptr __DTOR_END__[];
size_t dtor_idx = 0;
const size_t max_idx = __DTOR_END__ - __DTOR_LIST__ - 1;
func_ptr f;
while (dtor_idx < max_idx)
{
f = __DTOR_LIST__[++dtor_idx];
f ();
}
}
I think the second bug is coming from the label created in
ix86_expand_prologue (line 8154) when generating the set_rip_rex64 and
set_got_offset_rex64 instructions and that later gets removed during
optimization but I am not sure what to do about it.
Steve Ellcey
s...@cup.hp.com
Re: GCC RES: Restrictive Exception Specification: 0.1 - Alpha. Feedback Request.
Hi Simon > I recently (on 18/12/2008) mailed a GCC patch to this mailing list, > but I went on holiday after and have only just arrived back. I > probably should have asked for some feedback then. Thanks for taking the time to describe your work in the right amount of detail. I think you need a C++ maintainer to indicate their willingness to accept your patch in principle, and then in final form. In the meantime, for such a significant patch, you are going to need to get your copyright assignment paperwork cleared up before the patch can be accepted. Do you have one yet? Cheers, Ben
Re: Archive for SPEC CPU 2K/2006 results?
On Sun, Jan 25, 2009 at 11:17 AM, H.J. Lu wrote: > On Sun, Jan 25, 2009 at 11:04 AM, Richard Guenther > wrote: >> On Sun, Jan 25, 2009 at 7:56 PM, H.J. Lu wrote: >>> On Sun, Jan 25, 2009 at 10:45 AM, Richard Guenther >>> wrote: On Sun, Jan 25, 2009 at 7:34 PM, H.J. Lu wrote: > Hi, > > We have been running functional tests on SPEC CPU 2K/2006 > on Linux/ia32 and Linux/Intel64 at -O2 and -O3. We'd like to > report pass and regressions. We may send SPEC CPU > regressions to > > http://gcc.gnu.org/ml/gcc-regression/ > > But for passes, there is no suitable place to report. > > http://gcc.gnu.org/ml/gcc-testresults/ > > is for gcc testsuite. If I send SPEC CPU pass to it, it > may be buried by normal test results. > > Any suggestions. Put it on a website and link to it from http://gcc.gnu.org/benchmarks/ >>> >>> My website isn't visible to public. Also it isn't really benchmark since >>> I only run functional tests. My reports only show pass or which tests >>> failed. >> >> I see. I agree that gcc-regression is appropriate for FAILs then. Is it >> important to have PASSes available somewhere? (you can assume PASSes >> if there are no FAIL reports). >> > > But you won't know what exactly the last passing revision is and > you can't tell if my SPEC CPU machines are running normally. > I changed my SPEC CPU machines to send SPEC CPU regressions to gcc-regression. The report may look like --- Subject: gcc (GCC) 4.3.3 20090117 (prerelease) [gcc-4_3-branch revision 143474] failed SPEC CPU 2006 on i686 Date: Sun, 18 Jan 2009 09:22:44 -0800 (PST) From: h...@gnu-27.sc.intel.com (H.J. Lu (Intel64)) With runspec -c lnx-i686-gcc.cfg -n 1 -l -o asc -I all -T base -e o2 Error: 1x464.h264ref --- I'd like to send my SPEC CPU success to a gcc mailing list. I am not sure if SPEC SPU success is appropriate for gcc-regression. A new mailing list, like, gcc-results or gcc-success, is useful for my purpose. People can also use it to report gcc success for other important packages, like Linux kernel or glibc. Thanks. -- H.J.
Serious code generation/optimisation bug (I think)
I was debugging a function and by inserting the debug statement crashed
the system. Some investigation revealed that gcc 4.3.2 arm-eabi (compiled
from sources) with -O2 under some circumstances assumes that if a pointer
is dereferenced, it can not be NULL therefore explicite tests against
NULL can be later eliminated. Here is a short function that demonstrates
the erroneous behaviour:
extern void Debug( unsigned int x );
typedef struct s_head {
struct s_head *next;
unsigned intvalue;
} A_STRUCT;
void InsertByValue( A_STRUCT **queue, A_STRUCT *ptr )
{
A_STRUCT *tst;
for ( tst = *queue ; ; queue = &tst->next, tst = *queue ) {
// Debug( tst->value );
if ( ! tst ) {
ptr->next = (void *) 0;
break;
}
if ( tst->value < ptr->value ) {
ptr->next = tst;
break;
}
}
*queue = ptr;
}
Compiling this function with
arm-eabi-gcc -O2 -S foo.c
generates perfect code. However, if the Debug( tst->value ); is not
commented out, then the generated code looks like this:
InsertByValue:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
stmfd sp!, {r4, r5, r6, lr}
mov r6, r0
ldr r4, [r0, #0]
mov r5, r1
b .L3
.L2:
mov r6, r4
ldr r4, [r4, #0]
.L3:
ldr r0, [r4, #4]
bl Debug
ldr r2, [r4, #4]
ldr r3, [r5, #4]
cmp r2, r3
bcs .L2
str r4, [r5, #0]
str r5, [r6, #0]
ldmfd sp!, {r4, r5, r6, lr}
bx lr
As you can see, when 'tst' is fetched to R4, it is not checked against
being 0 anywhere and the whole if ( ! tst ) { ... } bit is completely
eliminated from the code. Indeed, the actual compiled code crashes because
the loop does not stop when the end of the list is reached.
I know that you are not supposed to dereference a NULL pointer, however,
on the microcontroller I have it is perfectly legal: what you get is an
element of the exception vector table that resides at 0x0.
I don't think that the compiler has a right to remove my test, just
because it assumes that if I derferenced a pointer then it surely was not
NULL. At least it should give me a warning (which it does not, not even
with -W -Wall -Wextra).
Zoltan
