public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Simon Horman <horms@verge.net.au>
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	Stephen Tweedie <sct@redhat.com>,
	Eduardo Habkost <ehabkost@redhat.com>,
	Mark McLoughlin <markmc@redhat.com>, Ingo Molnar <mingo@elte.hu>,
	Jan Beulich <jbeulich@novell.com>,
	Dhaval Giani <dhaval@linux.vnet.ibm.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: Allow compile with CONFIG_DEBUG_INFO=y, X86_PAE not set on gcc 3.4.5
Date: Thu, 07 Aug 2008 23:37:55 -0700	[thread overview]
Message-ID: <489BE9C3.2010006@goop.org> (raw)
In-Reply-To: <20080808050429.GA8473@verge.net.au>

Simon Horman wrote:
> Hi,
>
> It appears that "x86: preallocate and prepopulate separately"
> (d8d5900ef8afc562088f8470feeaf17c4747790f) introduced a minor regression.
> The build fails on gcc 3.4.5 if CONFIG_DEBUG_INFO=y (that is gcc is
> called with -g) and X86_PAE not set.
>
> There was previously some discussion of this without resolution.
> http://lkml.org/lkml/2008/7/18/250
>
> 	arch/x86/mm/pgtable.c: In function `pgd_prepopulate_pmd':
> 	arch/x86/mm/pgtable.c:222: internal compiler error: in remove_insn, at emit-rtl.c:3746
> 	Please submit a full bug report,
> 	with preprocessed source if appropriate.
> 	See <URL:http://gcc.gnu.org/bugs.html> for instructions.
>
> 	# i686-unknown-linux-gnu-gcc --version
> 	i686-unknown-linux-gnu-gcc (GCC) 3.4.5
>
> My investigations seem to show that gcc 3.4.5 can't cope with the following
> construct:
>
> 	for (i = 0; i < 0; i++)
> 		...
>
> or more specifically:
>
> 	for (i = 0; i < PREALLOCTED_PMDS; i++)
> 		...
>
> when PREALLOCTED_PMDS is 0. That is, when X86_PAE is not set.
>
> This patch resolves this problem by moving the relevant code inside
> #define X86_PAE and providing dummy functions outside !X86_PAE.
>
> Signed-off-by: Simon Horman <horms@verge.net.au>
>   

We resolved the other report by saying that gcc 3.4.4 is broken. It 
seems 3.4.5 is as well.  Could you just update the compiler?  I'd rather 
not have to clutter the code with more ifdefs if we can possibly avoid it.

Does putting

	if (PREALLOCATED_PMDS == 0)
		return;


before the for loop help?

    J

> Index: linux-2.6/arch/x86/mm/pgtable.c
> ===================================================================
> --- linux-2.6.orig/arch/x86/mm/pgtable.c	2008-08-08 14:35:29.000000000 +1000
> +++ linux-2.6/arch/x86/mm/pgtable.c	2008-08-08 15:00:07.000000000 +1000
> @@ -141,12 +141,6 @@ void pud_populate(struct mm_struct *mm, 
>  	if (mm == current->active_mm)
>  		write_cr3(read_cr3());
>  }
> -#else  /* !CONFIG_X86_PAE */
> -
> -/* No need to prepopulate any pagetable entries in non-PAE modes. */
> -#define PREALLOCATED_PMDS	0
> -
> -#endif	/* CONFIG_X86_PAE */
>  
>  static void free_pmds(pmd_t *pmds[])
>  {
> @@ -221,6 +215,19 @@ static void pgd_prepopulate_pmd(struct m
>  	}
>  }
>  
> +#else  /* !CONFIG_X86_PAE */
> +
> +/* No need to prepopulate any pagetable entries in non-PAE modes. */
> +#define PREALLOCATED_PMDS	0
> +
> +static int preallocate_pmds(pmd_t *pmds[]) { return 0; }
> +static void pgd_prepopulate_pmd(struct mm_struct *mm, pgd_t *pgd, pmd_t *pmds[])
> +{ }
> +static void free_pmds(pmd_t *pmds[]) { }
> +static void pgd_mop_up_pmds(struct mm_struct *mm, pgd_t *pgdp) { }
> +
> +#endif	/* CONFIG_X86_PAE */
> +
>  pgd_t *pgd_alloc(struct mm_struct *mm)
>  {
>  	pgd_t *pgd;
>   


  reply	other threads:[~2008-08-08  6:38 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-08  5:04 Allow compile with CONFIG_DEBUG_INFO=y, X86_PAE not set on gcc 3.4.5 Simon Horman
2008-08-08  6:37 ` Jeremy Fitzhardinge [this message]
2008-08-08  7:50   ` Simon Horman
2008-08-08  8:01   ` Adrian Bunk
2008-08-08 15:21     ` [Xen-devel] " Jeremy Fitzhardinge
2008-08-08 16:13       ` Adrian Bunk
2008-08-08 18:01         ` Jeremy Fitzhardinge
2008-08-08 18:37           ` Adrian Bunk
2008-08-08 20:46             ` [PATCH] x86: work around gcc 3.4.x bug Jeremy Fitzhardinge
2008-08-09  6:29               ` Simon Horman
2008-08-11 16:44                 ` Ingo Molnar

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=489BE9C3.2010006@goop.org \
    --to=jeremy@goop.org \
    --cc=dhaval@linux.vnet.ibm.com \
    --cc=ehabkost@redhat.com \
    --cc=horms@verge.net.au \
    --cc=hpa@zytor.com \
    --cc=jbeulich@novell.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=markmc@redhat.com \
    --cc=mingo@elte.hu \
    --cc=sct@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=xen-devel@lists.xensource.com \
    /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