fix warnings in psycho_common after ull conversion

After conversion to use unsigned long long for u64
I saw following warnings:

  CC      arch/sparc/kernel/psycho_common.o
arch/sparc/kernel/psycho_common.c: In function `psycho_check_stc_error':
arch/sparc/kernel/psycho_common.c:104: warning: long long unsigned int format, long unsigned int arg (arg 4)
arch/sparc/kernel/psycho_common.c:104: warning: long long unsigned int format, long unsigned int arg (arg 5)
arch/sparc/kernel/psycho_common.c:114: warning: long long unsigned int format, long unsigned int arg (arg 4)
arch/sparc/kernel/psycho_common.c:114: warning: long long unsigned int format, long unsigned int arg (arg 5)
arch/sparc/kernel/psycho_common.c:114: warning: long long unsigned int format, long unsigned int arg (arg 6)
arch/sparc/kernel/psycho_common.c:114: warning: long long unsigned int format, long unsigned int arg (arg 7)
arch/sparc/kernel/psycho_common.c: In function `psycho_dump_iommu_tags_and_data':
arch/sparc/kernel/psycho_common.c:187: warning: long long unsigned int format, long unsigned int arg (arg 8)
arch/sparc/kernel/psycho_common.c:193: warning: long long unsigned int format, long unsigned int arg (arg 6)
arch/sparc/kernel/psycho_common.c: In function `psycho_pcierr_intr':
arch/sparc/kernel/psycho_common.c:333: warning: long long unsigned int format, long unsigned int arg (arg 3)
arch/sparc/kernel/psycho_common.c:333: warning: long long unsigned int format, long unsigned int arg (arg 4)

This is due to different integer promotion in my 32 bit hosted gcc.
The fix is to force a few constants to ULL.

The following stands out from the rest:
+#define  PSYCHO_IOMMU_TAG_VPAGE         0x7ffffULL
+#define  PSYCHO_IOMMU_DATA_PPAGE 0xfffffffULL

They were needed otherwise the expression:

    (data_val & PSYCHO_IOMMU_DATA_PPAGE) << IOMMU_PAGE_SHIFT)

were promoted to a unsigned long and not a unsigned long long as expected.

I tried the alternative solution and made IOMMU_PAGE_SHIFT an ULL but that did not help.
The only way gcc would make this expression an unsigned long long was to
define PSYCHO_IOMMU_DATA_PPAGE as ULL. The alternative to add a cast was
not considered a valid solution.

We had this issue in two places and this were the only places the above
two constants are used.

A small coding style diff sneaked in too. 

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
---

I have so far not seen any other fallout due to this.
If I see more I will submit patches.

	Sam

--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

From: Sam Ravnborg <sam@ravnborg.org>
Date: Thu, 8 Jan 2009 20:27:23 +0100

> This is due to different integer promotion in my 32 bit hosted gcc.

That's a bug.

C language promotion rules shouldn't change because
the compiler is crossed from a 32-bit host to a 64-bit
one.

I'll apply this, but I don't really know how much more of these
gcc-3.4.x 32/64 cross compiler bug workarounds I can tolerate.
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Thu, Jan 08, 2009 at 11:34:37AM -0800, David Miller wrote:
> From: Sam Ravnborg <sam@ravnborg.org>
> Date: Thu, 8 Jan 2009 20:27:23 +0100
> 
> > This is due to different integer promotion in my 32 bit hosted gcc.
> 
> That's a bug.
> 
> C language promotion rules shouldn't change because
> the compiler is crossed from a 32-bit host to a 64-bit
> one.
> 
> I'll apply this, but I don't really know how much more of these
> gcc-3.4.x 32/64 cross compiler bug workarounds I can tolerate.

Understood and agreed on.

When I get time I will upgrade my working environment
and then I hope to find a solution so I can use a more sensible
toolchain as it seems my current setup is only causing problems.

	Sam
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Thu, Jan 08, 2009 at 01:30:03PM -0700, Chris Torek wrote:
> Just FYI:
> 
> >I tried the alternative solution and made IOMMU_PAGE_SHIFT an ULL
> >but that did not help.
> 
> The type of (X << Y) is independent of the type of Y.  Which means
> that these (unchanged) defines:
> 
> > #define  PSYCHO_IOMMU_TAG_WRITE	 (0x1UL << 21UL)
> > #define  PSYCHO_IOMMU_TAG_STREAM (0x1UL << 20UL)
> > #define  PSYCHO_IOMMU_TAG_SIZE	 (0x1UL << 19UL)
> 
> have extra ULs in them.  (Harmlessly, though.)
> 
> (I think some truly ancient versions of gcc, perhaps 1.x or 2.x,
> accidentally used the type of Y in computing a type for X<<Y, which
> might be where this started.)

What I see with my broken gcc is that the following code snippet:

$ cat ull.c
#include <stdio.h>

#define BAR 0UL
void bar(void)
{
        unsigned long long foo;

        printf("%lld, %ld, %lld", foo, BAR, foo & BAR);
}

Produces the following warning:

$ sparc64-unknown-linux-gnu-gcc -c -Wall ull.c
ull.c: In function `bar':
ull.c:8: warning: long long int format, long unsigned int arg (arg 4)

And davem with his native gcc (on a 64 bit sparc host) does not see it.

For the record my native gcc on my 32 bit host does NOT produce the warning.

The conclusion is simple.

   I should scrap my sparc gcc ASAP.

I will do soonish. Only problem is that I need to bring up a new
box that I do not have at the moment. My current box is running an
ancient fedora and I simply do not dare to touch it until I have
a replacement up and running.

My recently acuired SUN Blade 100 is not an option at the moment :-(

	Sam
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html