Ping.
Normally we shouldn't ping a patch after only a few days, but we're
running out of time to catch GCC 12 milestone. And once GCC 12 is
released the patch will become far more complicated for a psABI warning.
And please note that the ABI difference between GCC and G++ should be
considered a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105363
--- Comment #2 from Hongtao.liu ---
Looks like neither ICC nor LLVM vectorized the loop
https://godbolt.org/z/sbheqbE6Y
Hi Tsukasa:
LGTM, and did you mind adding Signed-off-by to your patch and resending again?
I think this patch is small enough and the copyright process should
not be a blocker for this patch :)
See also: https://gcc.gnu.org/dco.html
On Sun, Apr 24, 2022 at 1:25 PM Tsukasa OI wrote:
>
>
> > and so it doesn't make
> > sense to mandate any particular ordering.
>
> No. It affects Z* extension ordering...
+1, we really need the order in ISA spec so that we could know the
canonical order for z* exts.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105363
Hongtao.liu changed:
What|Removed |Added
CC||crazylht at gmail dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105339
--- Comment #3 from CVS Commits ---
The master branch has been updated by Hongyu Wang :
https://gcc.gnu.org/g:3c940d42701707559fabe49be99296f60fbc43e7
commit r12-8238-g3c940d42701707559fabe49be99296f60fbc43e7
Author: Hongyu Wang
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105372
Bug ID: 105372
Summary: The result of the merge function is different when
it's type of parameters is the extensions type of
derived type
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105371
Bug ID: 105371
Summary: The result of the merge function is different when
it's type of parameters is the extensions type of
derived type
Product: gcc
Version:
Snapshot gcc-12-20220424 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/12-20220424/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 12 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105369
--- Comment #3 from Eric Gallager ---
(In reply to Eric Gallager from comment #0)
> Anyways, that's it for the plain-C code from that page; I'll open a separate
> bug for the C++ if it turns out that that needs one, too.
OK I opened bug 105370
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105370
Bug ID: 105370
Summary: Improved diagnostics for code from statement
expressions documentation [C++ component]
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105369
--- Comment #2 from Andrew Pinski ---
I don't think there is a way to get a warning for the abs really and maybe not
even wanted.
There should definitely be a cross reference to where the documentation says
inline functions are fast as macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105369
--- Comment #1 from Eric Gallager ---
Oh, I should probably add something to test the sentence that says, "If you
don’t know the type of the operand, you can still do this, but you must use
typeof or __auto_type (see Typeof)," too...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105369
Bug ID: 105369
Summary: Improved diagnostics for code from statement
expressions documentation [C component]
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105361
--- Comment #2 from Thomas Koenig ---
As expected:
FAIL: gfortran.dg/list_read_8.f90 -O0 execution test
FAIL: gfortran.dg/list_read_8.f90 -O1 execution test
FAIL: gfortran.dg/list_read_8.f90 -O2 execution test
FAIL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105361
--- Comment #1 from Thomas Koenig ---
This "fixes" the bug in question, but is almost certainly entirely
incorrect for a lot of other cases. Will have to look a bit further.
--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@
--prefix=/repo/gcc-trunk//binary-trunk-r12-8236-20220424133922-g6b7441a46c7-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220424 (experimental) (GCC)
=/repo/gcc-trunk//binary-trunk-r12-8236-20220424133922-g6b7441a46c7-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220424 (experimental) (GCC)
ion algorithms: zlib zstd
gcc version 12.0.1 20220424 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105365
Bug ID: 105365
Summary: [12 Regression] ICE: in cmp_cst, at
analyzer/svalue.cc:309 with -fanalyzer
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords:
About a week ago many targets started failing pr94157_0.c test like this
(bfin-elf, but many other targets are also affected):
spawn -ignore SIGHUP /home/jlaw/test/obj/bfin-elf/obj/gcc/gcc/xgcc
-B/home/jlaw/test/obj/bfin-elf/obj/gcc/gcc/ c_lto_pr94157_0.o
-fdiagnostics-plain-output -dumpbase
Greetings
my name is Ashlyn Harris I would love to know you better please reply me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104228
--- Comment #12 from CVS Commits ---
The releases/gcc-10 branch has been updated by Mikael Morin
:
https://gcc.gnu.org/g:4c8e037d32e91c0ec4ac577d1d0723ab9d6ec809
commit r10-10554-g4c8e037d32e91c0ec4ac577d1d0723ab9d6ec809
Author: Mikael Morin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104570
--- Comment #7 from CVS Commits ---
The releases/gcc-10 branch has been updated by Mikael Morin
:
https://gcc.gnu.org/g:4c8e037d32e91c0ec4ac577d1d0723ab9d6ec809
commit r10-10554-g4c8e037d32e91c0ec4ac577d1d0723ab9d6ec809
Author: Mikael Morin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105362
Andrew Pinski changed:
What|Removed |Added
Keywords||diagnostic
Component|c
Re-using the std::span printer, this now shows the contents of the
initializer list instead of the pointer and length members.
Signed-off-by: Philipp Fent
---
libstdc++-v3/python/libstdcxx/v6/printers.py | 23 +--
.../libstdc++-prettyprinters/cxx11.cc | 6 +
2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105364
Bug ID: 105364
Summary: lto-wrapper generates URLs escape sequences despite
-fdiagnostic-urls=never
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349
--- Comment #2 from Segher Boessenkool ---
Oh, or you didn't see the next commit?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90181
--- Comment #14 from Segher Boessenkool ---
It is *impossible* to have the stack registers as inputs to an inline asm, and
reliably generate correct code for it that does what the writer of that code
expected: loading up the operands to the asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105363
Bug ID: 105363
Summary: -ftree-slp-vectorize decreases performance
significantly (x64)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105362
Bug ID: 105362
Summary: Improvement: diagnose undefined behavior in
preprocessing directives
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103662
--- Comment #20 from CVS Commits ---
The master branch has been updated by Mikael Morin :
https://gcc.gnu.org/g:fa5cd7102da676dcb1757b1288421f5f3439ae0e
commit r12-8235-gfa5cd7102da676dcb1757b1288421f5f3439ae0e
Author: Mikael Morin
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105336
--- Comment #6 from Avi Kivity ---
(the reproducer was executed by gcc 12 prerelease, not gcc 11)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105336
--- Comment #5 from Avi Kivity ---
I reduced it to a few lines (attached, intentionally triggers use-after-free).
The culprit is -Og.
With
g++ coroutine-asan.cc -o coroutine-asan --std=c++20 -fsanitize=address -Og
I see
READ of size 8 at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105336
--- Comment #4 from Avi Kivity ---
Created attachment 52856
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52856=edit
intentionally buggy reproducer
From: Sören Tempel
The libgo code assumes both off64_t and loff_t to be present. For
example, for the splice(2) function prototype. Similar to glibc,
musl libc supports these types but defines them as macros, not as
typedefs. Unfortunately, -fdump-go-spec only recognizes types defined
using
Hello,
This patch fixes libgccjit link failure on loongarch* targets,
and could probably be useful for future ports.
Currently libgccjit is linked with objects from $(EXTRA_GCC_OBJS) and
libbackend.a, which is in turn linked with $(EXTRA_OBJS) files.
Thus, common object files that's shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104723
--- Comment #11 from cuilili ---
(In reply to Jakub Jelinek from comment #10)
> And for the backend, the question is how big the penalty for the overlapping
> store is compared to doing multiple non-overlapping stores. Say for those
> 49
Hello,
> Neither K nor J is an extension that exists,
That is correct.
> and so it doesn't make
> sense to mandate any particular ordering.
No. It affects Z* extension ordering...
On 2022/04/24 14:36, Andrew Waterman wrote:
> Neither K nor J is an extension that exists, and so it doesn't
39 matches
Mail list logo
