> Am 20.08.2023 um 00:45 schrieb ZiNgA BuRgA via Gcc-patches
> :
>
> Hi,
>
> With the proposed design of these switches, how would I restrict AVX10.1 to
> particular AVX-512 subsets?
>
> For example, usage of the |_mm256_rol_epi32| intrinsic should be compatible
> on any AVX10/256
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835
Eric Gallager changed:
What|Removed |Added
Assignee|egallager at gcc dot gnu.org |unassigned at gcc dot
gnu.org
On Thu, Aug 17, 2023 at 11:38 PM Eric Gallager wrote:
>
> On Thu, Aug 17, 2023 at 4:05 PM Iain Sandoe wrote:
> >
> > Hi Eric,
> >
> > thanks for working on this.
> >
> > > On 17 Aug 2023, at 20:35, Eric Gallager wrote:
> > >
> > > This is a pretty simple patch that ought to help Darwin users
Thanks, I committed the version with Iain's suggested change in wording:
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627796.html
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=9a5d1fceb86a61c9ead380df89ce3c4ba387d2e5
(sorry that this got sent multiple times; I thought the email hadn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835
--- Comment #35 from CVS Commits ---
The master branch has been updated by Eric Gallager :
https://gcc.gnu.org/g:9a5d1fceb86a61c9ead380df89ce3c4ba387d2e5
commit r14-3335-g9a5d1fceb86a61c9ead380df89ce3c4ba387d2e5
Author: Eric Gallager
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100249
Jiang An changed:
What|Removed |Added
CC||de34 at live dot cn
--- Comment #13 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130
--- Comment #21 from CVS Commits ---
The master branch has been updated by Jonathan Yong :
https://gcc.gnu.org/g:966f3c134bb4802ac7ba0517de4e8e3f6384cfa3
commit r14-3334-g966f3c134bb4802ac7ba0517de4e8e3f6384cfa3
Author: Tomas Kalibera
Date:
Hi,
With the proposed design of these switches, how would I restrict AVX10.1
to particular AVX-512 subsets?
For example, usage of the |_mm256_rol_epi32| intrinsic should be
compatible on any AVX10/256 implementation, /as well as /any AVX-512VL
without AVX10 implementation (e.g. Skylake-X).
Snapshot gcc-13-20230819 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/13-20230819/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 13 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
Hi FX,
thanks for chasing these fails down,
> On 19 Aug 2023, at 22:28, FX Coudert wrote:
>
> gcc.dg/analyzer/ currently has 80 failures on Darwin (both
> x86_64-apple-darwin and aarch64-apple-darwin). All those come from two issues:
>
> 1. Many tests use memset() without including the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106677
--- Comment #3 from Andrew Pinski ---
On the trunk we now get:
_25 = SR.116_117 == 0;
_27 = (unsigned char) _25;
_32 = _27 | SR.116_117;
Rather than:
_119 = MAX_EXPR <1, SR.115_117>;
But we should instead just get:
SR.116_117 | 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111079
Bug ID: 111079
Summary: Failing to reject a defaulted/deleted local function
definition if it is a friend of a local class
Product: gcc
Version: 14.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104042
--- Comment #5 from Francois-Xavier Coudert ---
Patch posted for Darwin at
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627923.html
Hi,
gcc.dg/analyzer/ currently has 80 failures on Darwin (both x86_64-apple-darwin
and aarch64-apple-darwin). All those come from two issues:
1. Many tests use memset() without including the header. We can fix
that easily.
2. Other tests fail because of the use of macOS headers, which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #11 from waffl3x ---
(In reply to Jonathan Wakely from comment #9)
> If we're right about that, then I agree that a warning would be useful for
> classes that have no such implicit conversion from S to S*.
>
> I think the warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111078
--- Comment #1 from Andrew Pinski ---
Another form:
```
int f1(int a, int b)
{
int t = a != b;
return (-t)|1;
}
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111078
Bug ID: 111078
Summary: csneg is not used for (cset) * 2 - 1
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111066
--- Comment #3 from Francois-Xavier Coudert ---
Makes sense, patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627922.html
Bordering on obvious, tested on darwin where the test case fails before (and
now passes).
OK to commit?
FX
0001-Testsuite-fix-contructor-priority-test.patch
Description: Binary data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111077
--- Comment #5 from Andrew Pinski ---
See
https://gcc.gnu.org/pipermail/libstdc++/2022-October/054899.html
Also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106899
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111067
--- Comment #2 from Francois-Xavier Coudert ---
I tried with:
diff --git a/gcc/testsuite/g++.dg/opt/icf1.C b/gcc/testsuite/g++.dg/opt/icf1.C
index fbb275e635a..d4e4bbf91b9 100644
--- a/gcc/testsuite/g++.dg/opt/icf1.C
+++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111077
--- Comment #4 from Andrew Pinski ---
reading through all of these discussions almost want to say the paper on
atomic_ref and padding bits of compare_and_exchange still missed the point of
this issue. Maybe this is undefined and maybe this is
On 8/17/23 12:59, Eric Gallager via Gcc-patches wrote:
Subject:
[PATCH] improve error when /usr/include isn't found [PR90835]
From:
Eric Gallager via Gcc-patches
Date:
8/17/23, 12:59
To:
gcc-patches@gcc.gnu.org
CC:
ia...@gcc.gnu.org, Eric Gallager
This is a pretty simple patch that ought
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111077
Andrew Pinski changed:
What|Removed |Added
Component|c++ |libstdc++
--- Comment #3 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111077
--- Comment #2 from Andrew Pinski ---
https://lists.llvm.org/pipermail/cfe-dev/2018-December/060537.html
Here is a rebased patch following the resize_and_overwrite change.
I confirm that tests are now fixed after the change in tzdb.cc.
I'll prepare a fix for those tests still but preparing also a test to
detect allocations in the lib.
François
On 17/08/2023 21:44, Jonathan Wakely wrote:
On
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111077
Andrew Pinski changed:
What|Removed |Added
Component|libstdc++ |c++
--- Comment #1 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130
--- Comment #20 from Tomas Kalibera ---
(In reply to Julian Waters from comment #19)
> (In reply to Tomas Kalibera from comment #17)
> > (In reply to Tomas Kalibera from comment #16)
> > > (In reply to Julian Waters from comment #15)
> > > > It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111077
Bug ID: 111077
Summary: atomic_ref compare_exchange_strong doesn't properly
ignore padding bits
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111076
Bug ID: 111076
Summary: RISC-V: segmentation fault during RTL pass: shorten
(debug build)
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111065
--- Comment #6 from Tommy Murphy ---
Hi Kito/Palmer - should I maybe close this issue here and take it up in the
riscv-gnu-toolchain/riscv-gcc repos instead?
* https://github.com/riscv-collab/riscv-gnu-toolchain
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #10 from Gašper Ažman ---
Yes, the explicit object parameter always receives the cv-l/r qualified
reference to the object of the call. Implicit conversions are then of
course allowed, same as any other parameter. S* is not that
On Fri, 18 Aug 2023 at 17:11, Richard Biener wrote:
>
> On Fri, 18 Aug 2023, Richard Biener wrote:
>
> > On Thu, 17 Aug 2023, Prathamesh Kulkarni wrote:
> >
> > > On Tue, 15 Aug 2023 at 14:28, Richard Sandiford
> > > wrote:
> > > >
> > > > Richard Biener writes:
> > > > > On Mon, 14 Aug 2023,
Thank you very much, I think this should also be backported to Gcc12/13.
Huacai
On Sat, Aug 19, 2023 at 11:59 AM Chenghua Xu wrote:
>
> Pushed as r14-3331.
>
> Thanks.
> chenglulu writes:
>
> > LGTM!
> >
> > 在 2023/8/16 上午9:48, Guo Jie 写道:
> >> gcc/ChangeLog:
> >>
> >> *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111075
Francois-Xavier Coudert changed:
What|Removed |Added
Target||x86_64-apple-darwin20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111075
Bug ID: 111075
Summary: ICE on g++.dg/torture/tail-padding1.C on darwin
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110932
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> So the general rule is:
> (simplify
> (eq:c @0 (convert (cmp @1 @2)))
> (if (bitwise_equal_p (@0, @1))
> (with {
> bool zeroalwaystrue = ...
> bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110932
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111074
Bug ID: 111074
Summary: RISC-V: segmentation fault during RTL pass: vsetvl
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
(Pinging since I realised that this is required for my later Low Overhead Loop
patch series to work)
Ok for trunk with the updated changelog that Christophe mentioned?
Thanks,
Stamatis/Stam Markianos-Wright
From: Stam Markianos-Wright
Sent: Tuesday, August 1,
On Sat, 19 Aug 2023, 11:45 FX Coudert, wrote:
> Hi,
>
> > That seems like a bug in the aarch64-darwin port.
> > 1.0q should definitely be __float128 rather than _Float128.
>
> Is there a simple way to test what type 1.0q is, in C? I tried using
> _Generic, but it says
>
> > a.c:7:52: error:
Hi,
> That seems like a bug in the aarch64-darwin port.
> 1.0q should definitely be __float128 rather than _Float128.
Is there a simple way to test what type 1.0q is, in C? I tried using _Generic,
but it says
> a.c:7:52: error: ‘_Generic’ specifies two compatible types
> 7 | int i =
On Fri, 18 Aug 2023 at 14:52, Richard Biener wrote:
>
> On Fri, 18 Aug 2023, Richard Sandiford wrote:
>
> > Richard Biener writes:
> > > The following avoids running into somehow flawed logic in fold_vec_perm
> > > for non-VLA vectors.
> > >
> > > Bootstrap & regtest running on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130
--- Comment #19 from Julian Waters ---
(In reply to Tomas Kalibera from comment #17)
> (In reply to Tomas Kalibera from comment #16)
> > (In reply to Julian Waters from comment #15)
> > > It seems like the patch also doesn't fix the strftime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111069
--- Comment #4 from Jakub Jelinek ---
Created attachment 55763
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55763=edit
gcc14-pr111069-wip.patch
WIP patch. Seems to get the basics right, but mangling of guard vars (_ZGV*)
and
On Sat, Aug 19, 2023 at 11:58:31AM +0200, Jakub Jelinek via Gcc wrote:
> well. So, if aarch64-darwin wants 64-bit long double, the question is if
> it should have __float128 support and q suffix support at all. If it
> should, then it needs to initialize float128t_type_node to a distinct type
>
On Thu, 17 Aug 2023 at 13:22, Jonathan Wakely via Libstdc++
wrote:
>
> Tested x86_64-linux. Pushed to trunk. Backport to gcc-13 will follow.
Re the backport, I forgot to say that this changes the order/values of
the enumerators for _Pres_type. In theory that could cause
incompatibilities between
On Sat, Aug 19, 2023 at 10:25:50AM +0100, Jonathan Wakely wrote:
> On Fri, 18 Aug 2023 at 20:08, FX Coudert via Gcc wrote:
> >
> > Hello,
> >
> > On the WIP aarch64-darwin port of GCC
> > (https://github.com/iains/gcc-darwin-arm64), there are some C++ testsuite
> > failures which are due to the
Hi,
> I don't know why 1.0q is _Float128 on aarch64 instead of __float128.
That’s weird. I create it in this way:
+ /* Populate the float128 node if it is not already done so that the FEs
+ know it is available. */
+ if (float128_type_node == NULL_TREE)
+{
+ float128_type_node =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #9 from Jonathan Wakely ---
If we're right about that, then I agree that a warning would be useful for
classes that have no such implicit conversion from S to S*.
I think the warning would give a false positive in the case below,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #8 from Jonathan Wakely ---
I don't see anything forbidding that declaration, but I think it can only be
called if S& has an implicit conversion to S* because the object parameter is
an lvalue of type S, and so it can only match S*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107876
Francois-Xavier Coudert changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
On Fri, 18 Aug 2023 at 20:08, FX Coudert via Gcc wrote:
>
> Hello,
>
> On the WIP aarch64-darwin port of GCC
> (https://github.com/iains/gcc-darwin-arm64), there are some C++ testsuite
> failures which are due to the following:
>
> 1. The testsuite check_effective_target_has_q_floating_suffix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105838
Francois-Xavier Coudert changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
On Sat, 19 Aug 2023 at 09:58, h3140067...@163.com
wrote:
> Is it similar to the gnu as86 assembly compiler? Actually, I just hope to
> have a separate branch of the as86 assembly compiler
>
I don't know what GNU as86 is, but GCC does not have any assembler. GCC
uses your system's assembler,
Hi Jakub,
I should have pinged you, I see you recently touched that code.
FX
> Le 18 août 2023 à 21:07, FX Coudert a écrit :
>
> Hello,
>
> On the WIP aarch64-darwin port of GCC
> (https://github.com/iains/gcc-darwin-arm64), there are some C++ testsuite
> failures which are due to the
Is it similar to the gnu as86 assembly compiler? Actually, I just hope to have
a separate branch of the as86 assembly compiler
Replied Message
| From | Jonathan Wakely |
| Date | 08/19/2023 14:29 |
| To | h3140067...@163.com |
| Cc | gcc |
| Subject | Re: gnu as |
On Sat, 19 Aug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #7 from waffl3x ---
struct S {
int f(this S*) {
return 5;
}
};
int main()
{
S s{};
return s.f();
}
Here is my current progress, this code works. I have a good feeling that the
rest is going to be easy.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111038
--- Comment #3 from Gejoe ---
Not sure of that..Will have to check.
Noticed trivial syntax errors in gcc/ada/expect.c when tried to compile gcc 13.2 as cross-compiler
for target i686-pc-msdosdjgpp.
Errors were there since
Tiedostossa, joka sisällytettiin kohdasta expect.c:54:
expect.c:Funktio ”__gnat_waitpid”:
expect.c:353:13:virhe: expected ”(” before numeric
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111070
David Binderman changed:
What|Removed |Added
Keywords||needs-bisection
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111073
Sam James changed:
What|Removed |Added
Summary|[13/14 regression] |[13/14 regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111073
Sam James changed:
What|Removed |Added
Blocks||88443
--- Comment #1 from Sam James ---
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111073
Bug ID: 111073
Summary: [13/14 regression] False-positive -Wstringop-overflow
when building gdb from trunk
Product: gcc
Version: 14.0
Status: UNCONFIRMED
On Sat, 19 Aug 2023, 00:21 h3140067568--- via Gcc, wrote:
> Hi, I am an open-source enthusiast from China. I really like the cross
> platform features of AS assembly compilers. I hope the community can
> independently open source a branch of the backend assembly compiler of GCC
> compiler in
66 matches
Mail list logo
