public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: David Mosberger-Tang <David.Mosberger@acm.org>
To: linux-ia64@vger.kernel.org
Subject: Re: Remove warnings for gcc 4.0 IA64 compilation.
Date: Mon, 19 Sep 2005 17:46:26 +0000	[thread overview]
Message-ID: <ed5aea4305091910463a94c3c8@mail.gmail.com> (raw)
In-Reply-To: <17193.2147.591751.129603@berry.gelato.unsw.EDU.AU>

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

  parent reply	other threads:[~2005-09-19 17:46 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-15  5:36 Remove warnings for gcc 4.0 IA64 compilation Peter Chubb
2005-09-16 16:42 ` Luck, Tony
2005-09-18 23:10 ` Peter Chubb
2005-09-19  6:51 ` Tony Luck
2005-09-19 16:43 ` Luck, Tony
2005-09-19 17:46 ` David Mosberger-Tang [this message]
2005-09-19 18:58 ` James E Wilson
2005-09-19 19:05 ` David Mosberger-Tang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ed5aea4305091910463a94c3c8@mail.gmail.com \
    --to=david.mosberger@acm.org \
    --cc=linux-ia64@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox