Remove warnings for gcc 4.0 IA64 compilation.

Remove warnings for gcc 4.0 IA64 compilation.

[Peter Chubb]

The appended patch removes some compilation warnings, mostly
trivially.

Signed-off-by; Peter Chubb <peterc@gelato.unsw.edu.au>

Index: linux-2.6-import/arch/ia64/kernel/acpi.c
=================================--- linux-2.6-import.orig/arch/ia64/kernel/acpi.c	2005-09-09 12:43:30.166366764 +1000
+++ linux-2.6-import/arch/ia64/kernel/acpi.c	2005-09-15 13:01:04.281898032 +1000
@@ -892,21 +892,21 @@ acpi_map_iosapic(acpi_handle handle, u32
 }
 #endif				/* CONFIG_NUMA */
 
 int acpi_register_ioapic(acpi_handle handle, u64 phys_addr, u32 gsi_base)
 {
 	int err;
 
 	if ((err = iosapic_init(phys_addr, gsi_base)))
 		return err;
 
-#if CONFIG_ACPI_NUMA
+#ifdef CONFIG_ACPI_NUMA
 	acpi_map_iosapic(handle, 0, NULL, NULL);
 #endif				/* CONFIG_ACPI_NUMA */
 
 	return 0;
 }
 
 EXPORT_SYMBOL(acpi_register_ioapic);
 
 int acpi_unregister_ioapic(acpi_handle handle, u32 gsi_base)
 {
Index: linux-2.6-import/arch/ia64/kernel/entry.S
=================================--- linux-2.6-import.orig/arch/ia64/kernel/entry.S	2005-09-12 10:26:38.383367114 +1000
+++ linux-2.6-import/arch/ia64/kernel/entry.S	2005-09-15 13:01:42.265576317 +1000
@@ -484,21 +484,21 @@ GLOBAL_ENTRY(prefetch_stack)
 	lfetch.fault [r16], 128
 	;;
 	lfetch.fault.excl [r14], 128
 	lfetch.fault [r16], 128
 	;;
 	lfetch.fault.excl [r14], 128
 	lfetch.fault [r16], 128
 	;;
 	lfetch.fault [r16], 128
 	br.ret.sptk.many rp
-END(prefetch_switch_stack)
+END(prefetch_stack)
 
 GLOBAL_ENTRY(execve)
 	mov r15=__NR_execve			// put syscall number in place
 	break __BREAK_SYSCALL
 	br.ret.sptk.many rp
 END(execve)
 
 GLOBAL_ENTRY(clone)
 	mov r15=__NR_clone			// put syscall number in place
 	break __BREAK_SYSCALL
Index: linux-2.6-import/arch/ia64/kernel/perfmon.c
=================================--- linux-2.6-import.orig/arch/ia64/kernel/perfmon.c	2005-09-12 10:26:38.415366925 +1000
+++ linux-2.6-import/arch/ia64/kernel/perfmon.c	2005-09-15 13:05:36.651604242 +1000
@@ -567,21 +567,21 @@ pfm_unreserve_page(unsigned long a)
 	ClearPageReserved(vmalloc_to_page((void*)a));
 }
 
 static inline unsigned long
 pfm_protect_ctx_ctxsw(pfm_context_t *x)
 {
 	spin_lock(&(x)->ctx_lock);
 	return 0UL;
 }
 
-static inline unsigned long
+static inline void
 pfm_unprotect_ctx_ctxsw(pfm_context_t *x, unsigned long f)
 {
 	spin_unlock(&(x)->ctx_lock);
 }
 
 static inline unsigned int
 pfm_do_munmap(struct mm_struct *mm, unsigned long addr, size_t len, int acct)
 {
 	return do_munmap(mm, addr, len);
 }
Index: linux-2.6-import/arch/ia64/kernel/time.c
=================================--- linux-2.6-import.orig/arch/ia64/kernel/time.c	2005-07-28 11:17:28.748959464 +1000
+++ linux-2.6-import/arch/ia64/kernel/time.c	2005-09-15 13:04:49.847996264 +1000
@@ -185,21 +185,21 @@ ia64_init_itm (void)
 		platform_base_drift = -1;
 	}
 	if (!proc_ratio.den)
 		proc_ratio.den = 1;	/* avoid division by zero */
 	if (!itc_ratio.den)
 		itc_ratio.den = 1;	/* avoid division by zero */
 
 	itc_freq = (platform_base_freq*itc_ratio.num)/itc_ratio.den;
 
 	local_cpu_data->itm_delta = (itc_freq + HZ/2) / HZ;
-	printk(KERN_DEBUG "CPU %d: base freq=%lu.%03luMHz, ITC ratio=%lu/%lu, "
+	printk(KERN_DEBUG "CPU %d: base freq=%lu.%03luMHz, ITC ratio=%u/%u, "
 	       "ITC freq=%lu.%03luMHz", smp_processor_id(),
 	       platform_base_freq / 1000000, (platform_base_freq / 1000) % 1000,
 	       itc_ratio.num, itc_ratio.den, itc_freq / 1000000, (itc_freq / 1000) % 1000);
 
 	if (platform_base_drift != -1) {
 		itc_drift = platform_base_drift*itc_ratio.num/itc_ratio.den;
 		printk("+/-%ldppm\n", itc_drift);
 	} else {
 		itc_drift = -1;
 		printk("\n");
Index: linux-2.6-import/drivers/char/agp/hp-agp.c
=================================--- linux-2.6-import.orig/drivers/char/agp/hp-agp.c	2005-07-28 11:17:46.800825682 +1000
+++ linux-2.6-import/drivers/char/agp/hp-agp.c	2005-09-15 13:15:49.802544884 +1000
@@ -245,21 +245,21 @@ hp_zx1_configure (void)
 
 	agp_bridge->gart_bus_addr = hp->gart_base;
 	agp_bridge->capndx = hp->lba_cap_offset;
 	agp_bridge->mode = readl(hp->lba_regs+hp->lba_cap_offset+PCI_AGP_STATUS);
 
 	if (hp->io_pdir_owner) {
 		writel(virt_to_gart(hp->io_pdir), hp->ioc_regs+HP_ZX1_PDIR_BASE);
 		readl(hp->ioc_regs+HP_ZX1_PDIR_BASE);
 		writel(hp->io_tlb_ps, hp->ioc_regs+HP_ZX1_TCNFG);
 		readl(hp->ioc_regs+HP_ZX1_TCNFG);
-		writel(~(HP_ZX1_IOVA_SIZE-1), hp->ioc_regs+HP_ZX1_IMASK);
+		writel((unsigned int)(~(HP_ZX1_IOVA_SIZE-1)), hp->ioc_regs+HP_ZX1_IMASK);
 		readl(hp->ioc_regs+HP_ZX1_IMASK);
 		writel(hp->iova_base|1, hp->ioc_regs+HP_ZX1_IBASE);
 		readl(hp->ioc_regs+HP_ZX1_IBASE);
 		writel(hp->iova_base|log2(HP_ZX1_IOVA_SIZE), hp->ioc_regs+HP_ZX1_PCOM);
 		readl(hp->ioc_regs+HP_ZX1_PCOM);
 	}
 
 	return 0;
 }
 

Re: Remove warnings for gcc 4.0 IA64 compilation.

[Luck, Tony]

On Thu, Sep 15, 2005 at 03:36:35PM +1000, Peter Chubb wrote:
> Index: linux-2.6-import/arch/ia64/kernel/time.c
> -	printk(KERN_DEBUG "CPU %d: base freq=%lu.%03luMHz, ITC ratio=%lu/%lu, "
> +	printk(KERN_DEBUG "CPU %d: base freq=%lu.%03luMHz, ITC ratio=%u/%u, "
>  	       "ITC freq=%lu.%03luMHz", smp_processor_id(),
>  	       platform_base_freq / 1000000, (platform_base_freq / 1000) % 1000,
>  	       itc_ratio.num, itc_ratio.den, itc_freq / 1000000, (itc_freq / 1000) % 1000);

This hunk is surely wrong?  itc_freq is unsigned long, so itc_freq/1000000
still has unsigned long type.

The other pieces all look good.

-Tony

Re: Remove warnings for gcc 4.0 IA64 compilation.

[Peter Chubb]

Tony Luck wrote: 
On Thu, Sep 15, 2005 at 03:36:35PM +1000, Peter Chubb wrote:
> Index: linux-2.6-import/arch/ia64/kernel/time.c
> -	printk(KERN_DEBUG "CPU %d: base freq=%lu.%03luMHz, ITC ratio=%lu/%lu, "
> +	printk(KERN_DEBUG "CPU %d: base freq=%lu.%03luMHz, ITC ratio=%u/%u, "
>  	       "ITC freq=%lu.%03luMHz", smp_processor_id(),
>  	       platform_base_freq / 1000000, (platform_base_freq / 1000) % 1000,
>  	       itc_ratio.num, itc_ratio.den, itc_freq / 1000000, (itc_freq / 1000) % 1000);

Tony> This hunk is surely wrong?  itc_freq is unsigned long, so
Tony> itc_freq/1000000 still has unsigned long type.

Sure, but itc_ratio.num and itc_ratio.den (which are the only bits
affected, unless I've severely miscalculated the match between format
and args) are both 32-bit quantities

Peter C
--
Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
The technical we do immediately,  the political takes *forever*

Re: Remove warnings for gcc 4.0 IA64 compilation.

[Tony Luck]

On 9/18/05, Peter Chubb <peterc@gelato.unsw.edu.au> wrote:

> Sure, but itc_ratio.num and itc_ratio.den (which are the only bits
> affected, unless I've severely miscalculated the match between format
> and args) are both 32-bit quantities

Very odd.  I don't see a warning with the current code (using gcc 3.4).
But when I applied this patch, I did get a warning (which is what made
me take a closer[1] look at this part).

-Tony

[1] not close enough, because I obviously didn't match the arguments
before sending the e-mail.

RE: Remove warnings for gcc 4.0 IA64 compilation.

[Luck, Tony]

[-- Attachment #1: Type: text/plain, Size: 1115 bytes --]


>Very odd.  I don't see a warning with the current code (using gcc 3.4).
>But when I applied this patch, I did get a warning (which is what made
>me take a closer[1] look at this part).

Ok.  the definition of the pal_freq_ratio structure uses 32-bit wide
bitfields that are type u64.  So something changed in gcc between
3.4 and 4.0 about how such a declaration is interpreted.

Anyone know which is right?

We could change the definition in asm/pal.h to read:

typedef[1] struct pal_freq_ratio {
	u32	den;
	u32	num;
} itc_ratio, proc_ratio;

and then both version of gcc would be happy with "%u" (but there
are a few more spots to change in palinfo.c in addition to the
change to time.c ... doesn't gcc 4 spit out warnings for line 654
of palinfo.c args 3, 4, 5, 6, 7, 8?  If not, why not?)

Is there any reason to prefer bitfields over separate elements here?

Does the attached patch make gcc 4.0 happy?

-Tony

[1] we could kill this typedef while editing here, nobody uses
the "itc_ratio" and proc_ratio" types.  All places that use this
just use "struct pal_freq_ratio ...".

[-- Attachment #2: proc-freq-info.patch --]
[-- Type: application/octet-stream, Size: 1820 bytes --]

diff --git a/arch/ia64/kernel/palinfo.c b/arch/ia64/kernel/palinfo.c
--- a/arch/ia64/kernel/palinfo.c
+++ b/arch/ia64/kernel/palinfo.c
@@ -648,9 +648,9 @@ frequency_info(char *page)
 	if (ia64_pal_freq_ratios(&proc, &bus, &itc) != 0) return 0;
 
 	p += sprintf(p,
-		     "Processor/Clock ratio   : %ld/%ld\n"
-		     "Bus/Clock ratio         : %ld/%ld\n"
-		     "ITC/Clock ratio         : %ld/%ld\n",
+		     "Processor/Clock ratio   : %u/%u\n"
+		     "Bus/Clock ratio         : %u/%u\n"
+		     "ITC/Clock ratio         : %u/%u\n",
 		     proc.num, proc.den, bus.num, bus.den, itc.num, itc.den);
 
 	return p - page;
diff --git a/arch/ia64/kernel/time.c b/arch/ia64/kernel/time.c
--- a/arch/ia64/kernel/time.c
+++ b/arch/ia64/kernel/time.c
@@ -192,7 +192,7 @@ ia64_init_itm (void)
 	itc_freq = (platform_base_freq*itc_ratio.num)/itc_ratio.den;
 
 	local_cpu_data->itm_delta = (itc_freq + HZ/2) / HZ;
-	printk(KERN_DEBUG "CPU %d: base freq=%lu.%03luMHz, ITC ratio=%lu/%lu, "
+	printk(KERN_DEBUG "CPU %d: base freq=%lu.%03luMHz, ITC ratio=%u/%u, "
 	       "ITC freq=%lu.%03luMHz", smp_processor_id(),
 	       platform_base_freq / 1000000, (platform_base_freq / 1000) % 1000,
 	       itc_ratio.num, itc_ratio.den, itc_freq / 1000000, (itc_freq / 1000) % 1000);
diff --git a/include/asm-ia64/pal.h b/include/asm-ia64/pal.h
--- a/include/asm-ia64/pal.h
+++ b/include/asm-ia64/pal.h
@@ -129,9 +129,10 @@ typedef u64				pal_cache_line_state_t;
 #define PAL_CACHE_LINE_STATE_EXCLUSIVE	2	/* Exclusive */
 #define PAL_CACHE_LINE_STATE_MODIFIED	3	/* Modified */
 
-typedef struct pal_freq_ratio {
-	u64 den : 32, num : 32;	/* numerator & denominator */
-} itc_ratio, proc_ratio;
+struct pal_freq_ratio {
+	u32	den;		/* denominator */
+	u32	num;		/* numerator */
+};
 
 typedef	union  pal_cache_config_info_1_s {
 	struct {

Re: Remove warnings for gcc 4.0 IA64 compilation.

[David Mosberger-Tang]

This issue has been discussed before:

  http://www.gelato.unsw.edu.au/archives/linux-ia64/0507/14541.html

I'm still not sure what the proper solution is.  It sure _feels_ wrong
to me for GCC to issue a warning in that case, but there clearly are
weird corners in the C standard so I'm not sure what the right
solution is.

  --david

On 9/19/05, Luck, Tony <tony.luck@intel.com> wrote:
> 
> >Very odd.  I don't see a warning with the current code (using gcc 3.4).
> >But when I applied this patch, I did get a warning (which is what made
> >me take a closer[1] look at this part).
> 
> Ok.  the definition of the pal_freq_ratio structure uses 32-bit wide
> bitfields that are type u64.  So something changed in gcc between
> 3.4 and 4.0 about how such a declaration is interpreted.
> 
> Anyone know which is right?
> 
> We could change the definition in asm/pal.h to read:
> 
> typedef[1] struct pal_freq_ratio {
>         u32     den;
>         u32     num;
> } itc_ratio, proc_ratio;
> 
> and then both version of gcc would be happy with "%u" (but there
> are a few more spots to change in palinfo.c in addition to the
> change to time.c ... doesn't gcc 4 spit out warnings for line 654
> of palinfo.c args 3, 4, 5, 6, 7, 8?  If not, why not?)
> 
> Is there any reason to prefer bitfields over separate elements here?
> 
> Does the attached patch make gcc 4.0 happy?
> 
> -Tony
> 
> [1] we could kill this typedef while editing here, nobody uses
> the "itc_ratio" and proc_ratio" types.  All places that use this
> just use "struct pal_freq_ratio ...".
> 
> 
> 


-- 
Mosberger Consulting LLC, voice/fax: 510-744-9372,
http://www.mosberger-consulting.com/
35706 Runckel Lane, Fremont, CA 94536

Re: Remove warnings for gcc 4.0 IA64 compilation.

[James E Wilson]

On Mon, 2005-09-19 at 10:46, David Mosberger-Tang wrote:
> This issue has been discussed before:
>   http://www.gelato.unsw.edu.au/archives/linux-ia64/0507/14541.html

It is wrong for gcc to complain about this, and it has been fixed for
the gcc-4.0.2 release, which should be out within a few weeks.  The
above URL contains a pointer to the GCC bug report which contains more
details.

Re: Remove warnings for gcc 4.0 IA64 compilation.

[David Mosberger-Tang]

On 19 Sep 2005 12:01:23 -0700, James E Wilson <wilson@tuliptree.org> wrote:
> On Mon, 2005-09-19 at 10:46, David Mosberger-Tang wrote:
> > This issue has been discussed before:
> >   http://www.gelato.unsw.edu.au/archives/linux-ia64/0507/14541.html
> 
> It is wrong for gcc to complain about this, and it has been fixed for
> the gcc-4.0.2 release, which should be out within a few weeks.

Ah, that's good to hear.

Thanks!

  --david