Hi Gerald,
Thinks for your review. As your suggestion, change the HTML ids to
lowercase. And pushed.
Thanks.
Chenghua
On 5/7/22 22:38, Gerald Pfeifer wrote:
On Sat, 7 May 2022, xucheng...@loongson.cn wrote:
+LoongArch
I usually recommend all lowercase for HTML ids. That is only a
recomme
Corrected version that avoids an uninitialized warning:
This PR complains that we emit the "enumeration value not handled in
switch" warning even though the enumerator was marked with the
[[maybe_unused]] attribute.
The first snag was that I couldn't just check TREE_USED, because
the enumerator c
This PR complains that we emit the "enumeration value not handled in
switch" warning even though the enumerator was marked with the
[[maybe_unused]] attribute.
The first snag was that I couldn't just check TREE_USED, because
the enumerator could have been used earlier in the function, which
doesn'
On 5/7/22 15:11, Marek Polacek wrote:
On Tue, May 03, 2022 at 04:59:38PM -0400, Jason Merrill wrote:
Does this testcase still work with this patch?
struct A {
const A* p = this;
};
struct B {
A a = A{};
};
constexpr B b;
static_assert (b.a.p == &b.a);
Ouch, no. Thanks for catching th
On 5/6/22 16:46, Patrick Palka wrote:
On Fri, 6 May 2022, Jason Merrill wrote:
On 5/6/22 16:10, Patrick Palka wrote:
On Fri, 6 May 2022, Patrick Palka wrote:
On Fri, 6 May 2022, Jason Merrill wrote:
On 5/6/22 14:00, Patrick Palka wrote:
On Fri, 6 May 2022, Patrick Palka wrote:
On Fri, 6
On Tue, May 03, 2022 at 04:59:38PM -0400, Jason Merrill wrote:
> Does this testcase still work with this patch?
>
> struct A {
> const A* p = this;
> };
>
> struct B {
> A a = A{};
> };
>
> constexpr B b;
> static_assert (b.a.p == &b.a);
Ouch, no. Thanks for catching this, it would have be
On Sat, 7 May 2022, xucheng...@loongson.cn wrote:
> +LoongArch
I usually recommend all lowercase for HTML ids. That is only a
recommendation, though, and if you strongly prefer "LoongArch"
over "loong" or "loongarch" that is fine.
Okay, thanks.
Gerald
PING.
Summary: gcc-go currently assumes that both loff_t and off64_t are defined
as a typedef. However, musl defines them as a CPP macro causing gccgo to
not compile with musl libc.
See: https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593527.html
If an alternative solution to the problem is
On Fri, May 6, 2022 at 6:42 PM Qing Zhao wrote:
>
>
>
> > On May 6, 2022, at 10:58 AM, Uros Bizjak wrote:
> >
> > On Fri, May 6, 2022 at 4:29 PM Qing Zhao wrote:
> >>
> >> Hi,
> >>
> >> As Kee’s requested in this PR:
> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101891
> >>
> >> =
> >>
On Sat, May 7, 2022 at 3:20 AM Jiang, Haochen wrote:
>
> Hi Uros,
>
> I understand that we always keep the old testcases there. It is always safe
> to do that.
>
> But I have another question, if we add something new in one of the existing
> files in the future,
> should we use __builtin_cpu_sup
From: Chenghua Xu
---
htdocs/gcc-12/changes.html | 13 +
1 file changed, 13 insertions(+)
diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
index c64827bd..995a1a42 100644
--- a/htdocs/gcc-12/changes.html
+++ b/htdocs/gcc-12/changes.html
@@ -695,6 +695,19 @@ funct
11 matches
Mail list logo
