https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106266
Bug ID: 106266
Summary: Libgo fails with recent glibc
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106266
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2022-07-12
Status|UNCONFIRME
To be clear, `li rx, 4096' isn't unsupported: it's a
very-much-supported idiom for `lui rx, 1`.
On Mon, Jul 11, 2022 at 11:45 PM rguenth at gcc dot gnu.org via
Gcc-bugs wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106265
>
> --- Comment #5 from Richard Biener ---
> So why do we even
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106265
--- Comment #6 from Andrew Waterman ---
To be clear, `li rx, 4096' isn't unsupported: it's a
very-much-supported idiom for `lui rx, 1`.
On Mon, Jul 11, 2022 at 11:45 PM rguenth at gcc dot gnu.org via
Gcc-bugs wrote:
>
> https://gcc.gnu.org/bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106267
Bug ID: 106267
Summary: #pragma GCC diagnostic ignored not preserved for a
-Wattribute-alias warning
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106267
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106268
Bug ID: 106268
Summary: [suboptimal] Remove unnecessary loops releated to
fortran compare to ifort
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106267
--- Comment #1 from Martin Liška ---
Simplified test-case:
#define SYSCALL_ALIAS_PROTO(a) \
_Pragma ("GCC diagnostic push"); \
_Pragma ("GCC diagnostic ignored \"-Wattribute-alias\""); \
typeof(a) a __attribute__((alias("sys_ni_posix_time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106267
Martin Liška changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97498
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97498
--- Comment #6 from Martin Liška ---
Am I correct that it's not something for backport to GCC 12 or any older
version?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97498
--- Comment #7 from Martin Liška ---
(In reply to Martin Liška from comment #6)
> Am I correct that it's not something for backport to GCC 12 or any older
> version?
We actually speak about 2 modified lines, so can we backport it, please?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99416
--- Comment #4 from Richard Biener ---
(In reply to Richard Biener from comment #3)
> Note it's only the outer loop that confuses us here. With that removed we
> have
> the following because of yet another "heuristic" to disable distribution.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106268
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106253
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45840
Jonathan Wakely changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105860
--- Comment #9 from CVS Commits ---
The releases/gcc-11 branch has been updated by Martin Jambor
:
https://gcc.gnu.org/g:16afe2e2862f3dd93c711d7f8d436dee23c6c34d
commit r11-10144-g16afe2e2862f3dd93c711d7f8d436dee23c6c34d
Author: Martin Jambor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106269
Bug ID: 106269
Summary: the "operator delete" selection does not follow c++
spec
Product: gcc
Version: rust/master
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106268
--- Comment #2 from vfdff ---
it seems different for the C version, see detail
https://godbolt.org/z/vc1edYKhf
in your above case, the icc also doesn't elide the outer loop.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106269
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106253
--- Comment #7 from Richard Biener ---
Btw, I can see
FAIL: gcc.dg/vect/vect-rounding-lceil.c (internal compiler error: in
vect_transf
orm_loops, at tree-vectorizer.cc:1032)
FAIL: gcc.dg/vect/vect-rounding-lfloor.c (internal compiler error: in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106253
--- Comment #8 from CVS Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:00eab0c654e09c8a0f1b1a3b1c7bff8764e64991
commit r13-1647-g00eab0c654e09c8a0f1b1a3b1c7bff8764e64991
Author: Richard Sandiford
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106253
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105989
--- Comment #4 from Michal Jankovič ---
Comment on attachment 53273
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53273
Experimental patch implementing the proposed transformation
diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66290
--- Comment #4 from Lewis Hyatt ---
OK, I understand now why done_lexing is necessary, plenty of places call back
into libcpp after lexing, e.g. to interpret strings, and this may generate
warnings.
I think that one line patch is the way to go th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105989
Michal Jankovič changed:
What|Removed |Added
Attachment #53273|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105912
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106270
Bug ID: 106270
Summary: [Aarch64] -mlong-calls should be provided on aarch64
for users with large applications
Product: gcc
Version: 13.0
Status: UNCONFIRMED
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106270
--- Comment #1 from qinzhao at gcc dot gnu.org ---
from Jose Marchesi:
We looked at this issue and these are our findings.
- When this problem happens:
When the linker (ld) fails to insert a veneer (that transforms the
immediate bl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106249
--- Comment #4 from Arseny Solokha ---
Finally, a C testcase, and w/o -funreachable-traps:
void
foo (double *arr)
{
int i, j;
for (i = 0; i < 4; ++i)
for (j = 0; j < 4; ++j)
arr[j] = 0;
for (i = 1; i < 4; ++i)
for (j = 0;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106270
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #2 from Wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106270
--- Comment #3 from Jose E. Marchesi ---
Wilco: The assessment in comment 1 was extracted from an internal discussion on
an issue that is still under investigation. We are certainly hitting a
cant-reach-the-linker-generated-veneer problem, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106271
Bug ID: 106271
Summary: Bootstrap on RISC-V on Ubuntu 22.04 LTS:
bits/libc-header-start.h: No such file or directory
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106270
--- Comment #4 from Qing Zhao ---
> On Jul 12, 2022, at 1:02 PM, wilco at gcc dot gnu.org
> wrote:
>
> Note that GCC could split huge .text sections automatically to allow insertion
> of linker veneers every 128MB.
Does GCC do this by defaul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106271
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106049
--- Comment #4 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:6e9d5dfc2911e3acc6039ebfe3837e7ba4be197f
commit r13-1650-g6e9d5dfc2911e3acc6039ebfe3837e7ba4be197f
Author: Harald Anlauf
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106049
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106270
--- Comment #5 from Wilco ---
(In reply to Jose E. Marchesi from comment #3)
> Wilco: The assessment in comment 1 was extracted from an internal discussion
> on an issue that is still under investigation. We are certainly hitting a
> cant-reach
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106270
--- Comment #6 from Wilco ---
(In reply to Qing Zhao from comment #4)
> > On Jul 12, 2022, at 1:02 PM, wilco at gcc dot gnu.org
> > wrote:
> >
> > Note that GCC could split huge .text sections automatically to allow
> > insertion
> > of link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106272
Bug ID: 106272
Summary: clang build: new warning ?
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106272
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2022-07-12
Ever confirmed|0
as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r13-1649-20220712164051-gcab411a2b4b-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20220712 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106273
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106272
--- Comment #2 from David Binderman ---
I just noticed similar four lines earlier:
libcpp/include/line-map.h:1876:12: warning: moving a temporary object prevents
copy elision [-Wpessimizing-move]
Source code is
return std::move (label_tex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106274
Bug ID: 106274
Summary: Loss of macro tracking information with -flto
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106265
--- Comment #7 from Vineet Gupta ---
(In reply to Richard Biener from comment #5)
> So why do we even emit unsupported 'li 4096' and leave it to the linker to
> "optimize(?)"?
li 4096 is really a pseudo-op - LUI is used to build 32-bit constan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106272
Eric Gallager changed:
What|Removed |Added
Keywords||build, diagnostic
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106271
--- Comment #2 from Thomas Koenig ---
(In reply to Andrew Pinski from comment #1)
> I suspect configure is not detecting multi-arch correctly or
> --disable-multilib interacting with multi-arch support which causes things
> to be broken.
> OR mu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106275
Bug ID: 106275
Summary: unordered_map with std::string key,
std::hash, and custom equality predicate
weirdness
Product: gcc
Version: 12.1.0
Status: U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106275
--- Comment #1 from Chris Uzdavinis ---
Created attachment 53293
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53293&action=edit
preprocessed code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106246
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106248
--- Comment #8 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:5ae74944af1de032d4a27fad4a2287bd3a2163fd
commit r13-1651-g5ae74944af1de032d4a27fad4a2287bd3a2163fd
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106248
Jonathan Wakely changed:
What|Removed |Added
Known to fail||12.1.0
Summary|[11/12/13 R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106275
--- Comment #2 from Jonathan Wakely ---
The difference in behaviour is due to r12-6272-ge3ef832a9e8d6a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106275
--- Comment #3 from Jonathan Wakely ---
template
struct _Hashtable_hash_traits
{
static constexpr std::size_t
__small_size_threshold() noexcept
{ return std::__is_fast_hash<_Hash>::value ? 0 : 20; }
};
This new t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106275
--- Comment #4 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #3)
> The __is_fast_hash trait is true for std::hash but false for
> your custom hash function.
Oops, I mean the other way around! std::hash is considered slow,
y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106275
--- Comment #5 from Jonathan Wakely ---
This "bug" (i.e. doing a linear search for small containers using slow hash
functions) makes the find operation more than twice as fast:
BM_std_hash 4.67 ns 4.66 ns150610579
BM_custom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106272
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106272
Marek Polacek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106276
Bug ID: 106276
Summary: Missing -Wpessimizing-move warning
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106272
Marek Polacek changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106277
Bug ID: 106277
Summary: missed-optimization: redundant movzx
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-en
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106237
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106274
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
64 matches
Mail list logo
