|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #60925 fpm_atomic.h says unknown processor (m68k)
Submitted: 2012-01-29 19:31 UTC Modified: 2020-04-19 04:22 UTC
Avg. Score:3.7 ± 0.9
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: tg at debian dot org Assigned: cmb (profile)
Status: No Feedback Package: FPM related
PHP Version: 5.4 OS: Linux
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: tg at debian dot org
New email:
PHP Version: OS:


 [2012-01-29 19:31 UTC] tg at debian dot org
/tmp/buildd/php5-5.3.9/sapi/fpm/fpm/fpm_atomic.h:142:2: error: #error Unsupported processor. Please open a bug report (

This is on:
Linux 3.2.0-1+m68k.1-atari #1 Mon Jan 23 06:44:50 UTC 2012 m68k GNU/Linux

php5_5.3.3-7 compiled, so this is a regression.

Test script:
dpkg-buildpackage -rfakeroot -B


m68k-fpm-atomic-ops (last revision 2012-04-16 18:28 UTC by tg at debian dot org)

Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2012-01-30 12:24 UTC]
This isn't a regression in PHP as such, as the Debian 5.3.3-7 package had a 
patch specifically to use gcc's atomic builtins where available. A modified 
version of that patch was brought upstream in the fix for bug #52407 and 
released in 5.3.4.

Can you please try building a vanilla PHP tarball? It would also be helpful to 
get the version of gcc you're running and the bit of config.log including and 
immediately following the line "checking if gcc supports 
 [2012-01-30 12:24 UTC]
-Summary: fpm_atomic.h says unknown processor +Summary: fpm_atomic.h says unknown processor (m68k) -Status: Open +Status: Feedback
 [2012-01-30 16:39 UTC] tg at debian dot org
-Status: Feedback +Status: Open
 [2012-01-30 16:39 UTC] tg at debian dot org
gcc version 4.6.2 (Debian 4.6.2-12) 

I know for sure it does NOT support __sync_* atomic builtins;
on m68k, gcc-4.7 will introduce them, and a backport is not
likely (I looked at it, but it depends on mach-indep changes
that aren’t in 4.6 and I fear to break other things by that).
Several other architectures also do not have support for them
(but I can only sort-of speak for m68k at the moment).

Do I still need to try building a vanilla tarball with this
 [2012-01-30 16:52 UTC] tg at debian dot org
configure:12302: checking if gcc supports __sync_bool_compare_and_swap
configure:12319: m68k-linux-gnu-gcc -o conftest -O2 -Wall -fsigned-char -fno-strict-aliasing  -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -gstabs -fvisibility=hidden   conftest.c  -lrt >&5
/tmp/ccmCFUbp.o: In function `main':
conftest.c:48: undefined reference to `__sync_bool_compare_and_swap_4'
conftest.c:49: undefined reference to `__sync_add_and_fetch_4'
collect2: ld returned 1 exit status
configure:12319: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_URL ""
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define __EXTENSIONS__ 1
| #define _ALL_SOURCE 1
| #define _GNU_SOURCE 1
| #define _TANDEM_SOURCE 1
| #define HAVE_DEV_URANDOM 1
| #define HAVE_SETENV 1
| #define HAVE_CLEARENV 1
| #define HAVE_ERRNO_H 1
| #define HAVE_FCNTL_H 1
| #define HAVE_STDIO_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_SYS_UIO_H 1
| #define HAVE_SYS_SELECT_H 1
| #define HAVE_SYS_SOCKET_H 1
| #define HAVE_SYS_TIME_H 1
| #define HAVE_ARPA_INET_H 1
| #define HAVE_NETINET_IN_H 1
| #define HAVE_PRCTL 1
| #define HAVE_PTRACE 1
| #define PROC_MEM_FILE "mem"
| /* end confdefs.h.  */
| int
| main ()
| {
|     int variable = 1;
|     return (__sync_bool_compare_and_swap(&variable, 1, 2)
|            && __sync_add_and_fetch(&variable, 1)) ? 1 : 0;
|   ;
|   return 0;
| }
configure:12329: result: no
 [2012-01-31 00:06 UTC]
Ah, I didn't know that, so no, no need on the vanilla tarball front. Thanks!

The fix here would be a patch for fpm_atomic.h implementing the same atomic 
functions for m68k as the other fallback platforms in there, such as x86 and SPARC 
v9. I'm not actually sure why 5.3.3-7 built at all, actually -- the only patch it 
had over stock 5.3.3 (which had no support at all for m68k) was implementing 
support for __sync_bool_compare_and_swap() if it existed, so it should have failed 
with the same #error. Interesting.
 [2012-01-31 00:39 UTC] tg at debian dot org
Heh, your comment made me go and read the old changelogs
of the Debian package on a guess, and I guessed right:

php5 (5.3.5-1) unstable; urgency=low

   * Build the FPM SAPI (Closes: #603174)

So this was simply never built before. Now there are two
possibilities, disable FPM on m68k (unless gcc-4.7 or up
is used) or ask the m68k porters for an implementation
of the atomic things. I think. If you’ve got a better
idea, do tell.

By the way, there’s libatomic-ops-dev, which contains a
number of atomic primitives and composed operations on a
number of data types (but the catch is, you’ve got to use
the data types of libatomic-ops-dev, not e.g. like mesa
have a function atomic_dec which is passed an int32_t*
so it’s not a plug-in replacement. That might be more
interesting than hacking in m68k support now, and support
for $next_arch later…

m68k atomic operations apparently have another twist: the
compare-and-swap operation only exists on some processors,
and not in the Coldfire line, so the Linux kernel got a
syscall now to ensure atomicity. GCC 4.7 uses the syscall;
most “inlined” application code doesn’t…
 [2012-01-31 00:50 UTC]
-Package: Compile Failure +Package: FPM related
 [2012-01-31 00:50 UTC]
Thanks again. It's been good to triage this down. :)

I'll let Jérôme figure out what he wants to do here, since he's the FPM 
maintainer. I think your list of options pretty much covers it.
 [2012-02-02 20:11 UTC] tg at debian dot org
OK; in the meantime I’ll try building without FPM, to see whether there are any other lurking issues on m68k. Thanks for the help with this.
 [2012-03-12 23:31 UTC] tg at debian dot org
I’ve built 5.4.0 with a small patch. We’re working on getting it usable for upstream inclusion. On Linux/m68k, one uses a syscall for compare-and-swap 32 bit, as some CPUs do not support the machine instruction and probing for it is too tricky in user space. The syscall was introduced along with TLS support, now we probably need to safeguard this from being compiled on “too old” Linux systems. The patch doesn’t address nōn-Linux m68k, as those are different beasts, and see above. (The ColdFire does not support the instruction, and Linux and MiNT may very well both run on one with MMU, soonish.)
 [2012-04-16 18:31 UTC] tg at debian dot org
-PHP Version: 5.3.9 +PHP Version: 5.4
 [2012-04-16 18:31 UTC] tg at debian dot org
Make of this patch what you want. I’ve not gotten anything from the Linux/m68k porters other than “what do you do if the syscall does not exist?” with no solution. (On the other hand, it exists with every Linux kernel from 2.6.34 onwards or Debian 2.6.32; and older systems won’t support the last few eglibc major releases anyway, so chances are low someone’s trying PHP on such systems. And the patch keeps the #error for non-Linux systems.)
 [2012-04-19 23:50 UTC]
-Status: Open +Status: Assigned -Assigned To: +Assigned To: fat
 [2013-10-27 17:54 UTC]
-Assigned To: fat +Assigned To: tony2001
 [2017-10-24 04:57 UTC]
-Status: Assigned +Status: Analyzed -Assigned To: tony2001 +Assigned To:
 [2020-04-08 11:11 UTC]
-Status: Analyzed +Status: Feedback -Assigned To: +Assigned To: cmb
 [2020-04-08 11:11 UTC]
Has this issue been resolved in the meantime?
 [2020-04-19 04:22 UTC] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Mon Aug 08 05:03:33 2022 UTC