Reply to topic  [ 2 posts ] 
configure hangs on fputest if -Os is present in CFLAGS 
Author Message
Yorick Master

Joined: Tue Mar 07, 2006 10:31 pm
Posts: 125
Location: Meudon, France
Post configure hangs on fputest if -Os is present in CFLAGS


configure does not recognize -Os (or -Oz I presume) as optimization flags in CFLAGS. It therefore lets them go through when compiling fputest, which for some reason hangs under Mac OS X when compiled with any -O option.

Workaround: use -O2 instead of -Os. Would be best to fix configure, though. Or to fix fputest, if at all possible. I might come up with a patch when time permits.

Regards, Thibaut.

Original post:

Under Mac OS X 10.9 (Mavericks), using the Apple-provided compiler (clang from LLVM), if fputest was compiled with any sort of optimization, it will run forever, hanging the configuration process.

Quick solution is to not use any optimization at all.
bash-3.2$ clang -o fputest -DFPU_GCC_X86_64 fputest.c
bash-3.2$ ./fputest
SIGFPE handling works properly
bash-3.2$ clang -o fputest -DFPU_GCC_X86_64 -O2 fputest.c
bash-3.2$ ./fputest
bash-3.2$ clang -o fputest -DFPU_GCC_X86_64 -Os fputest.c
bash-3.2$ ./fputest
bash-3.2$ clang -o fputest -DFPU_GCC_X86_64 -O fputest.c
bash-3.2$ ./fputest


Regards, Thibaut.

Wed Nov 20, 2013 8:30 am
Profile WWW
Yorick Master

Joined: Mon Nov 22, 2004 9:43 am
Posts: 354
Location: Livermore, CA, USA
Post Re: configure hangs on fputest if -Os is present in CFLAGS
I'm unclear on whether there is anything I should do here. Avoiding this sort of problem is why yorick's default optimization is simply "-O". On many current machines this is equivalent to -O2. I haven't used clang, so I don't know what "-Os" means. Are you saying that if you unpack yorick on a 10.9 machine and type "make" or "env CC=clang make" that yorick doesn't build? If so, how do I modify configure to make it work? If not, I'm not really interested in debugging clang's optimizer.

On the other hand, if you understand the mechanisim of the failure, I would be interested in hearing about it. I can think of a couple of scenarios where this could be a harbinger of a new chapter in the long struggle to make SIGFPE work. The infinite loop sounds like what happens if my SIGFPE signal handler fails to reset the FPE bit in the SCR before re-enabling the FPE signal. Potentially the optimizer removes the instruction that resets that bit. No one else will ever detect or complain about this clang bug, because yorick is the only known program that enables SIGFPE delivery. Fiddling with that bit has no effect whatsoever on any other program ever run under MacOS X, so perhaps the compiler people consider it simply a waste of time to fiddle with, and remove the instruction to avoid its cost. Probably we will be forced to give up on SIGFPE delivery eventually, which means that yorick will be forced to explicitly check whether an FPE has been raised after every interpreted instruction. I assume that eventually the CPUs will stop supporting SIGFPE delivery entirely, which is a shame, but perhaps inevitable. No one cares about floating point arithmetic any more.

Sat Nov 30, 2013 1:41 pm
Display posts from previous:  Sort by  
Reply to topic   [ 2 posts ] 

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by STSoftware for PTF.