llvm dev - Jun 2013 - [LLVMdev] bug or expected behaviour?

I've been chasing down a bug for a few days in some RTOS code I'm
building with clang.  In the end it comes down to this code:

	void external(void);
	void test(char *x)
	{
	    x--;
	    if (!x)
	    {
	        external();
	    }
	}

When compiled for ARM with TOT clang (r183249) at -O1 or greater, no calls to
'external()' appear in the output code at all.  I have an example
project I can send out if anyone's interested, but it's just the above
source file and this makefile:

	.PHONY: all optimized unoptimized clean

	all: optimized unoptimized
		grep external *.s

	optimized:
		./clang -S -O1 example.c -o example-optimized.s

	unoptimized:
		./clang -S -O0 example.c -o example-unoptimized.s

	clean:
		rm -f *.s

When run, I get this output:

	$ make
	./clang -S -O1 example.c -o example-optimized.s
	./clang -S -O0 example.c -o example-unoptimized.s
	grep external *.s
	example-unoptimized.s:	bl	external

As you can see, 'example-optimized.s' contains no references to the
'external()' function.  Am I missing something subtle here
standard-wise?  Or is this an optimizer bug?  If it's a bug, what's the
right component to file it in?

I've attached the complete assembly output (both example-optimized.s and
example-unoptimized.s) in case that's helpful.  Thanks for any insight!

Oh - almost forgot - version information from the compiler:

	$ ./clang --version
	clang version 3.4 (trunk 183249)
	Target: arm-none--eabi
	Thread model: posix

-- 
Carl Norum
carl at lytro.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: example-optimized.s
Type: application/octet-stream
Size: 273 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130604/06452103/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: example-unoptimized.s
Type: application/octet-stream
Size: 479 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130604/06452103/attachment-0001.obj>

If this were a problem with an omitted statement involving a normal
variable, I'd guess you're missing a volatile qualifier. I'm not
100% sure
volatile is a valid qualifier for functions, but try it.
If RTOS stands for real time OS, then reading up on volatile would be a
really good idea.

P.S. Sorry Carl, you're going to receive this twice. I forget to CC the
list.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130604/97108ef0/attachment.html>

On Jun 4, 2013, at 4:23 PM, Tyler Hardin <tghardin1 at catamount.wcu.edu>
wrote:
> If this were a problem with an omitted statement involving a normal
variable, I'd guess you're missing a volatile qualifier. I'm not
100% sure volatile is a valid qualifier for functions, but try it.
Well, yes, if I change the signature to:

	void test(char * volatile x)

It works, but that's because I'm hamstringing the optimizers.  I
don't really see how that has anything to do with the question, though.  If
I change the signature to:

        void test(int x)

It works too... what's special about 'char *'?
> If RTOS stands for real time OS, then reading up on volatile would be a
really good idea.
I'm familiar with 'volatile' semantics, thanks.
> P.S. Sorry Carl, you're going to receive this twice. I forget to CC the
list.
No problem.

-- Carl