All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Christian Ehrhardt <christian.ehrhardt@canonical.com>,
	qemu-devel <qemu-devel@nongnu.org>
Subject: Re: Weird conflict with gcc-15
Date: Wed, 27 Aug 2025 10:47:05 +0200	[thread overview]
Message-ID: <1426a2bf-24fa-4424-b045-4cd37d2f091c@redhat.com> (raw)
In-Reply-To: <CAATJJ0++oPyjgXsekOKpHosps4jTpe9p9TWGGDpb2igbf6iipw@mail.gmail.com>

On 8/27/25 10:26, Christian Ehrhardt wrote:
> Hi,
> in testing qemu 10.1 since rc levels I've found yet another odd
> behavior. As far as I can tell it's not your fault, but I wanted to
> tell you for awareness and potentially to help me get the right debug
> data.
> 
> A test that triggered when checking Ubuntu was the one of EDK2,
> emulating riscv when running on ppc64, example log [1]. Yep, yet again
> not the most common setup :-) and the same emulation in all other
> Ubuntu architectures as host works fine.
> Gladly this was reproducible and it eventually led me to a wild
> journey which now makes me consider gcc-15 (15.2.0-1ubuntu1) as the
> suspect here.
> 
> Since I know the arch, the function and the tunable - I can use a
> rather surgical mitigation like this.
> 
> diff --git a/target/riscv/pmu.c b/target/riscv/pmu.c
> index a68809eef3..5317d8be57 100644
> --- a/target/riscv/pmu.c
> +++ b/target/riscv/pmu.c
> @@ -189,6 +189,13 @@ static int riscv_pmu_incr_ctr_rv64(RISCVCPU *cpu,
> uint32_t ctr_idx)
>    * env->priv and env->virt_enabled contain old priv and old virt and
>    * new priv and new virt values are passed in as arguments.
>    */
> +#if defined(__powerpc64__) || defined(__ppc64__)
> + #define NO_GCSE_ATTR __attribute__((optimize("no-gcse")))
> +#else
> + #define NO_GCSE_ATTR
> +#endif
> +
> +NO_GCSE_ATTR
>   static void riscv_pmu_icount_update_priv(CPURISCVState *env,
>                                            target_ulong newpriv, bool new_virt)
>   {
> 
> But a mitigation is all that it is, ideally, I'd report this as a gcc bug.
> Yet the - understandable - hard requirement of getting the
> pre-processed files makes this quite complex. As I can't even exactly
> point to where exactly things go wrong.
> I'd ask if one of you has experience in providing gcc-bugs out of a
> qemu build. Is it as obvious as throwing -save-temps into *flags or is
> there more to consider get what would be needed?

Yes, it's like that.  Run "ninja -v 
./libqemu-riscv64-softmmu.a.p/target_riscv_pmu.c.o", stick -save-temps 
at the end and submit the resulting .i file as an attachment to the GCC bug.

Paolo



  reply	other threads:[~2025-08-27  8:48 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-27  8:26 Weird conflict with gcc-15 Christian Ehrhardt
2025-08-27  8:47 ` Paolo Bonzini [this message]
2025-08-27 10:06   ` Christian Ehrhardt

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=1426a2bf-24fa-4424-b045-4cd37d2f091c@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=christian.ehrhardt@canonical.com \
    --cc=qemu-devel@nongnu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.