https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103370
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
--- Comment #5 from Richard Biener
102211314-g9ff206d3865-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20220102 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50581
--- Comment #8 from Andrew Pinski ---
I am hearing there is a C23 proposal to that might fix this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92453
Andrew Pinski changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103893
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103893
Bug ID: 103893
Summary: ada demangler heap overflow
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: demangler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33193
Andrew Pinski changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
From: Andrew Pinski
While cleaning up the bug database, I noticed there was a request
to improve the documentation of the _Complex type extensions.
So I rewrote part of the documentation to make things clearer on
__real/__imag and even added documentation about casts between
the scalar and the
Hi Michael,
If you are building libraries that contain modules with multiple long double
types, you must use the '-mno-gnu-attribute'. We also use the '-Wno-psabi'
option, which silences the warning that you are switching long double types (if
glibc is not 2.34 or newer). We may need to tweak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103892
Bug ID: 103892
Summary: -Wanalyzer-double-free false positive when compiling
libpipeline
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Snapshot gcc-12-20220102 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/12-20220102/
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=101762
--- Comment #4 from anlauf at gcc dot gnu.org ---
Created attachment 52108
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52108=edit
Improved patch
The previous patch was too strict. The attached version does a much better
job, but needs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103891
--- Comment #1 from Andrew Pinski ---
>Should libstdc++ work as is against clang++? Does it perhaps need a small
>tweak?
it depends, It might be the case that clang does not implement all of C++20
that GCC implements either.
There is also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103891
Bug ID: 103891
Summary: clang-13 fails to compile libstdc++'s
std::variant>: error: attempt to use
a deleted function
Product: gcc
Version: 12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101762
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
On Thu, Dec 30, 2021 at 3:45 PM Uros Bizjak wrote:
>
> This patch adds basic V2QImode infrastructure and V2QImode arithmetic
> operations (plus, minus and neg). The patched compiler can emit SSE
> vectorized QImode operations (e.g. PADDB) with partial QImode vector,
> and also synthesized double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102332
--- Comment #5 from CVS Commits ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:718b47e1cd4e667ef3e9b24630f0a2d923d7c802
commit r11-9428-g718b47e1cd4e667ef3e9b24630f0a2d923d7c802
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103861
--- Comment #5 from CVS Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:9ff206d3865df5cb8407490aa9481029beac087f
commit r12-6173-g9ff206d3865df5cb8407490aa9481029beac087f
Author: Uros Bizjak
Date: Sun
Hi Sandra,
Am 02.01.22 um 19:32 schrieb Sandra Loosemore:
This patch is for PR103390. For background on this issue, the Fortran
standard requires that, when passing a non-contiguous array from Fortran
to a BIND(C) function with the CONTIGUOUS attribute on the corresponding
dummy argument, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103783
--- Comment #4 from David Stone ---
A correction to my previous comment: n4868 is technically a C++23 working draft
(but claims to have only editorial fixes to the C++20 paper). However, I
believe the wording fixes to this section are intended
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103890
--- Comment #2 from dave.anglin at bell dot net ---
Is that what we want?
Fixes shadd-2.c and shadd-3.c test fails on trunk.
Committed to trunk.
Dave
---
Adjust shadd-2 and shadd-3 scan counts.
2022-01-02 John David Anglin
gcc/testsuite/ChangeLog:
* gcc.target/hppa/shadd-2.c: Adjust count to 3.
* gcc.target/hppa/shadd-3.c: Likewise.
diff --git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103890
--- Comment #1 from Andreas Schwab ---
That's because '/\.dynsym/,/^$/' is matching two regions. The first region is
the .dynsym section, the second region is starting at the section symbol in the
normal symtab. The latter produces the
This test hangs on hppa-linux. Don't know why exactly but it seems
to be a sequencing issue with gdb. The hang breaks automated builds
as the test doesn't timeout.
Tested on hppa-unknown-linux-gnu. Committed to trunk.
Dave
---
Skip gcc.dg/guality/example.c on hppa-linux.
2022-01-02 John David
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103390
--- Comment #6 from sandra at gcc dot gnu.org ---
Patch posted:
https://gcc.gnu.org/pipermail/fortran/2022-January/057249.html
This patch is for PR103390. For background on this issue, the Fortran
standard requires that, when passing a non-contiguous array from Fortran
to a BIND(C) function with the CONTIGUOUS attribute on the corresponding
dummy argument, the compiler has to arrange for it to be copied to/from
a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103890
Bug ID: 103890
Summary: Generated baseline symbol file seems to have redundant
lines
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
It would be nice to handle language-specific codes in the tree
pretty-printer, but until then we can at least indent them appropriately.
Tested x86_64-pc-linux-gnu, ok for trunk?
gcc/ChangeLog:
* tree-pretty-print.c (do_niy): Add spc parameter.
(NIY): Pass it.
While working on PR66139 I noticed that if the destructor of a temporary
created during array initialization throws, we were failing to destroy the
last array element constructed. Throwing destructors are rare since C++11,
but this should be fixed.
Tested x86_64-pc-linux-gnu, applying to trunk.
Since C++11, the vast majority of destructors are noexcept, so
wrap_temporary_cleanups adds a bunch of useless TRY_CATCH_EXPR to be removed
later in the optimizers. It's simple to avoid adding them in the first
place.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
*
The kernel compare and exchange calls will never succeed if they
return -EFAULT. This change generates an instruction fault if a
call returns -EFAULT. This prevents the code from spinning forever.
Tested on hppa-unknown-linux-gnu. Committed to trunk and gcc-11 branch.
Dave
---
Generate illegal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103783
--- Comment #3 from David Stone ---
Fedor, it looks like that wording was changed to a non-normative note and
expanded in N4868 to say: "There cannot be a static and a non-static member
function with the same name, parameter-type-list, and
This patch revises the atomic store code for hppa-linux to use optab_libfunc
to access the sync_lock_test_and_set libfunc. We now call
convert_memory_address() to convert the memory address to Pmode. This
should handle more memory addresses.
Tested on hppa-unknown-linux-gnu. Committed to trunk
From: Sören Tempel
Both glibc and musl libc declare pt_regs as an incomplete type. This
type has to be completed by inclusion of another header. On Linux, the
asm/ptrace.h header file provides this type definition. Without
including this header file, it is not possible to access the regs member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103889
--- Comment #13 from John Doe ---
(In reply to Andrew Pinski from comment #12)
> Because the Linux-gnu folks will always use lib64 instead of lib here. So
> there is no need to fix gcc/config/riscv/t-linux. There is a LSF on purpose
> which I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103882
Andreas Schwab changed:
What|Removed |Added
Resolution|WORKSFORME |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103882
Jose Silva changed:
What|Removed |Added
Resolution|INVALID |WORKSFORME
--- Comment #15 from Jose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103889
--- Comment #12 from Andrew Pinski ---
(In reply to John Doe from comment #11)
> Right, but I assume this problem should also exist on glibc systems which
> only have /lib/ instead of /lib64/ then. So apart from adding a
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103889
--- Comment #11 from John Doe ---
(In reply to Andrew Pinski from comment #10)
> Well RISCV port is new enough that nobody has tested --disable-multilib and
> put things in /lib/ really. Really there should be a
> gcc/config/riscv/t-linux-musl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103882
Jakub Jelinek changed:
What|Removed |Added
Resolution|WONTFIX |INVALID
--- Comment #14 from Jakub
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103889
Andrew Pinski changed:
What|Removed |Added
Summary|gccgo is unable to find its |gccgo is unable to find its
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103889
--- Comment #9 from John Doe ---
(In reply to Andrew Pinski from comment #8)
> Also there is much support we can do on modified sources really.
Yes, I totally understand that I was just looking for some guidance on how to
debug this further to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103889
--- Comment #8 from Andrew Pinski ---
Also there is much support we can do on modified sources really. But I didn't
see any patches which would have modified this part. I suspect there is some
funny multilib/non-multilib going on with RISCV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103889
--- Comment #7 from John Doe ---
(In reply to Andrew Pinski from comment #5)
> I should note that libgo is not able to compile for musl on the FSF GCC
> until just recently, after r12-5979.
This patch is included with the Alpine version of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103889
--- Comment #6 from John Doe ---
(In reply to Andreas Schwab from comment #4)
> LIBRARY_PATH=/usr/lib64/gcc/riscv64-suse-linux/11/:/usr/lib64/gcc/riscv64-
> suse-linux/11/../../../../riscv64-suse-linux/lib/:/lib64/lp64d/:/usr/lib64/
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103889
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2022-01-02
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103881
--- Comment #3 from thomas at habets dot se ---
Interesting.
So the difference between "x |= a & a" and "x |= f() & f()" is that the latter
has passed a somewhat arbitrary level of complexity after which GCC is not able
to prove that it's safe,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103889
--- Comment #4 from Andreas Schwab ---
$ gccgo hellogo.go -o hellogo -v
Using built-in specs.
COLLECT_GCC=gccgo
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/riscv64-suse-linux/11/lto-wrapper
Target: riscv64-suse-linux
Configured with: ../configure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84920
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|9.5 |---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103889
--- Comment #3 from John Doe ---
(In reply to Andreas Schwab from comment #2)
> Probably specific to musl. Worksforme on openSUSE.
Might be. Are you also compiling GCC with --disable-multilib on RV64? What's
your output of `gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103889
--- Comment #2 from Andreas Schwab ---
Probably specific to musl. Worksforme on openSUSE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102398
Pierre Vigier changed:
What|Removed |Added
CC||pierre.vigier at ymail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87464
Jonathan Wakely changed:
What|Removed |Added
Severity|normal |enhancement
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103889
--- Comment #1 from John Doe ---
[Hm, somehow bugzilla didn't add the description? Adding it again here.]
When compiling GCC with --disable-multilib on 64-Bit RISC-V (RV64), the gccgo
frontend does not seem to be able to find it's standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103889
Bug ID: 103889
Summary: gccgo is unable to find its standard library by
default on 64-Bit RISC-V
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity:
Hi,
This is the first part of a three-patch series to fix PR 82207
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207), making gfortran handle
signaling NaNs. This part fixes the library code implementing IEEE_CLASS, by
using the issignaling macro (from TS 18661-1:2014) to check whether a NaN
56 matches
Mail list logo
