FTBFS on amd64, i386 for test-rebuild-20111222 (gcc-4.7)

Bug #911871 reported by Mathieu Trudel-Lapierre
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
bluez (Ubuntu)
Fix Released
Medium
Mathieu Trudel-Lapierre

Bug Description

bluez fails to built in the latest test rebuild (test-rebuild-20111222), with gcc-4.7:

# source='sbc/sbc_primitives_mmx.c' object='sbc/sbc_libsbc_la-sbc_primitives_mmx.lo' libtool=yes
/bin/bash ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I./lib -I./src -I./src -I./audio -I./sbc -I./gdbus -I./attrib -I./btio -I./health -D_FORTIFY_SOURCE=2 -finline-functions -fgcse-after-reload -funswitch-loops -funroll-loops -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -Wall -D_FORTIFY_SOURCE=2 -fPIC -g -c -o sbc/sbc_libsbc_la-sbc_primitives_mmx.lo `test -f 'sbc/sbc_primitives_mmx.c' || echo './'`sbc/sbc_primitives_mmx.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I./lib -I./src -I./src -I./audio -I./sbc -I./gdbus -I./attrib -I./btio -I./health -D_FORTIFY_SOURCE=2 -finline-functions -fgcse-after-reload -funswitch-loops -funroll-loops -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -Wall -D_FORTIFY_SOURCE=2 -fPIC -g -c sbc/sbc_primitives_mmx.c -fPIC -DPIC -o sbc/.libs/sbc_libsbc_la-sbc_primitives_mmx.o
sbc/sbc_primitives_mmx.c: In function 'sbc_calc_scalefactors_mmx':
sbc/sbc_primitives_mmx.c:294:4: warning: asm operand 2 probably doesn't match constraints [enabled by default]
sbc/sbc_primitives_mmx.c:294:4: error: impossible constraint in 'asm'
make[2]: *** [sbc/sbc_libsbc_la-sbc_primitives_mmx.lo] Error 1

See https://launchpadlibrarian.net/88149127/buildlog_ubuntu-precise-i386.bluez_4.96-3ubuntu4_FAILEDTOBUILD.txt.gz

It appears to be related to this piece of code:

static void sbc_calc_scalefactors_mmx(
        int32_t sb_sample_f[16][2][8],
        uint32_t scale_factor[2][8],
        int blocks, int channels, int subbands)
{
        static const SBC_ALIGNED int32_t consts[2] = {
                1 << SCALE_OUT_BITS,
                1 << SCALE_OUT_BITS,
        };
        int ch, sb;
        intptr_t blk;
        for (ch = 0; ch < channels; ch++) {
                for (sb = 0; sb < subbands; sb += 2) {
                        blk = (blocks - 1) * (((char *) &sb_sample_f[1][0][0] -
                                (char *) &sb_sample_f[0][0][0]));
                       __asm__ volatile (
                                "movq (%4), %%mm0\n"
                        "1:\n"
                                "movq (%1, %0), %%mm1\n"
                                "pxor %%mm2, %%mm2\n"
                                "pcmpgtd %%mm2, %%mm1\n"
                                "paddd (%1, %0), %%mm1\n"
                                "pcmpgtd %%mm1, %%mm2\n"
                                "pxor %%mm2, %%mm1\n"

                                "por %%mm1, %%mm0\n"

                                "sub %2, %0\n"
                                "jns 1b\n"

                                "movd %%mm0, %k0\n"
                                "psrlq $32, %%mm0\n"
                                "bsrl %k0, %k0\n"
                                "subl %5, %k0\n"
                                "movl %k0, (%3)\n"

                                "movd %%mm0, %k0\n"
                                "bsrl %k0, %k0\n"
                                "subl %5, %k0\n"
                                "movl %k0, 4(%3)\n"
                        : "+r" (blk)
                        : "r" (&sb_sample_f[0][ch][sb]),
                                "i" ((char *) &sb_sample_f[1][0][0] -
                                        (char *) &sb_sample_f[0][0][0]),
                                "r" (&scale_factor[ch][sb]),
                                "r" (&consts),
                                "i" (SCALE_OUT_BITS)
                        : "cc", "memory");

Tags: patch

Related branches

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

I'm so absolutely not sure of my fix it's not even funny. Well, it does seem to allow bluez to compile with gcc 4.7and I'm not seeing playback issues yet in testing (which is what this looks like should be affecting).

tags: added: patch
Revision history for this message
Colin Watson (cjwatson) wrote :

This looks correct to me. "i" requires the operand to be a compile-time constant. In general, the memory location of a multi-dimensional array in C isn't constant at compile-time. Now, as it happens, for ((char *) &sb_sample_f[1][0][0] - (char *) &sb_sample_f[0][0][0]) to be particularly meaningful probably requires the array to be declared directly rather than dynamically
allocated, so in practice that *difference* probably is a constant; but proving that requires the compiler to reason across function boundaries in quite complex ways.

Changing this to "r" looks sensible to me.

Changed in bluez (Ubuntu):
status: New → In Progress
importance: Undecided → Medium
assignee: nobody → Mathieu Trudel-Lapierre (mathieu-tl)
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package bluez - 4.96-3ubuntu5

---------------
bluez (4.96-3ubuntu5) precise; urgency=low

  * debian/patches/sbc_mmx.patch: fix a FTBFS due to new checks in GCC 4.7 for
    inline assembly. (LP: #911871)
 -- Mathieu Trudel-Lapierre <email address hidden> Thu, 05 Jan 2012 19:06:42 -0500

Changed in bluez (Ubuntu):
status: In Progress → Fix Released
Revision history for this message
Siarhei Siamashka (siarhei-siamashka) wrote :

This regression has been fixed in gcc: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52355

Now bluez builds fine at least with gcc 4.7.0-RC-20120302 and this issue should not be a problem for gcc 4.7.0 release. Thanks to Fedora people who were the first to escalate the issue upstream.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.