https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106265
--- Comment #5 from Richard Biener ---
So why do we even emit unsupported 'li 4096' and leave it to the linker to
"optimize(?)"? At least the cost of this should be reflected - IIRC powerpc
recently got improvements for similar cases by changin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106264
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106262
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106261
--- Comment #2 from Richard Biener ---
@item -dx
@opindex dx
Just generate RTL for a function instead of compiling it. Usually used
with @option{-fdump-rtl-expand}.
@end table
so possibly some side-effect of not doing things something we do la
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106260
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106258
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106257
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101551
--- Comment #3 from CVS Commits ---
The master branch has been updated by Thomas Schwinge :
https://gcc.gnu.org/g:3723aedaad20a129741c2f6f3c22b3dd1220a3fc
commit r13-1611-g3723aedaad20a129741c2f6f3c22b3dd1220a3fc
Author: Thomas Schwinge
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106240
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42612
--- Comment #7 from Andrew Pinski ---
(In reply to Dmitry Baksheev from comment #6)
> Please consider fixing this issue. Here is another example where not using
> post-increment for loops produces suboptimal code on AArch64. The code is 4x
> slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42612
Dmitry Baksheev changed:
What|Removed |Added
CC||bd at mail dot ru
--- Comment #6 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106265
--- Comment #4 from Vineet Gupta ---
Going back to first dump (upstream 6abe341558a w/o riscv_rtx_costs() adj): the
3rd instruction addi is marking a2 REG_DEAD at 315 cprop.hardreg
--->8 314r.rnreg
(insn 2663 2662 1714 3 (set (reg:DI 13 a3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106265
--- Comment #3 from Vineet Gupta ---
Digging into RTL dumps, the li instructions are introduced by 300r reload.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106265
--- Comment #2 from Vineet Gupta ---
I've experimented with riscv_rtx_costs() setting cost of const to 1 as
discussed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98596. This does
reduce the number of li 4096 instances to 10 (from 14), but th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106265
--- Comment #1 from Vineet Gupta ---
Analyzed a section of -dP dump where reg a2 is setup with exact same value
while being live.
rhs-cred.cc:42: (*(double *)((char *)&ao)[k] + *(double *)((char *)0)[12] +
#(insn 2662 1711 76 (set (reg:DI 12 a2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106265
Bug ID: 106265
Summary: RISC-V SPEC2017 507.cactu code bloat due to address
generation
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106146
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106146
--- Comment #1 from Andrew Pinski ---
-march=armv8-a+sve2 -O3 -ffast-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106123
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106119
Andrew Pinski changed:
What|Removed |Added
Summary|Bogus use-after-free|[12/13 Regression] Bogus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106253
--- Comment #5 from Andrew Pinski ---
(In reply to rsand...@gcc.gnu.org from comment #4)
> I think for those we have to honour the prevailing
> flush-to-zero mode, which makes the
> functions at best pure rather than const.
GCC does handle chan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66290
Lewis Hyatt changed:
What|Removed |Added
CC||lhyatt at gcc dot gnu.org
--- Comment #3 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106264
--- Comment #3 from Andrew Pinski ---
(In reply to Martin Sebor from comment #2)
> The most likely culprit is r261705.
Yes this part:
(fold_builtin_n): Avoid setting TREE_NO_WARNING.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106261
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |10.5
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106264
--- Comment #2 from Martin Sebor ---
The most likely culprit is r261705.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106261
--- Comment #1 from Andrew Pinski ---
Created attachment 53289
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53289&action=edit
testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106264
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106264
Andrew Pinski changed:
What|Removed |Added
Summary|spurious -Wunused-value on |[10/11/12/13 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106264
Bug ID: 106264
Summary: spurious -Wunused-value on a folded frexp, modf, and
remquo calls with unused result
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106260
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |10.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106240
--- Comment #3 from Andrew Pinski ---
(In reply to Jeffrey A. Law from comment #2)
> I don't mind deferring this -- I *think* the .ps variants are deprecated in
> newer versions of the ISA. So we could easily move this to P4 and let the
> MIPS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106240
--- Comment #2 from Jeffrey A. Law ---
I don't mind deferring this -- I *think* the .ps variants are deprecated in
newer versions of the ISA. So we could easily move this to P4 and let the MIPS
folks take care of it if/when they feel the need.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106263
Bug ID: 106263
Summary: BTF_KIND_FUNC type does not encode linkage
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106257
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106261
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106260
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2022-07-11
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106258
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106257
Martin Liška changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106258
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106262
Bug ID: 106262
Summary: [13 regression] test case g++.dg/modules/loc-prune-4.C
fails
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106259
--- Comment #2 from Marek Polacek ---
Looks like
struct A::W
isn't in the class2loc hash table so we crash here:
33894 tree spec = specialization_of (type);
33895 cdlguide = class2loc.get (spec);
33896 gcc_assert (cdlguide !=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106259
Marek Polacek changed:
What|Removed |Added
Summary|ICE in |[10/11/12/13 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106261
Bug ID: 106261
Summary: ICE in output_call_frame_info, at dwarf2out.cc:943
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106260
Bug ID: 106260
Summary: [10/11/12/13 Regression] ICE in
initialize_node_lattices, at ipa-cp.cc:1289
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106259
Bug ID: 106259
Summary: ICE in diag_mismatched_tags, at cp/parser.cc:33896
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106258
Bug ID: 106258
Summary: ICE in ipa_verify_edge_has_no_modifications, at
ipa-param-manipulation.cc:139
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106257
Bug ID: 106257
Summary: [13 Regression] ICE in expand_builtin_unreachable, at
builtins.cc:5189
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106234
Andrew Macleod changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106234
--- Comment #4 from CVS Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:12a9b98ac574bc8092a75849b5c462135d35c31d
commit r13-1608-g12a9b98ac574bc8092a75849b5c462135d35c31d
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106254
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106010
Andrew Pinski changed:
What|Removed |Added
CC||zhongyunde at huawei dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106254
--- Comment #2 from Andrew Pinski ---
/app/example.c:6:21: note: === vect_analyze_data_refs ===
/app/example.c:6:21: missed: not vectorized: no vectype for stmt: _5 = *_3;
scalar_type: complex double
/app/example.c:7:13: missed: not vect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106238
--- Comment #4 from Rogério de Souza Moraes ---
Hi Andrew,
thank you for the quick reply. The "getLocalCopy" on this example is just to
provide a quick way to reproduce the issue. Here is the getLocalCopy function
of this example.
extern void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106238
--- Comment #3 from Rogério de Souza Moraes ---
Created attachment 53288
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53288&action=edit
Second example to reproduce the issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105860
--- Comment #8 from CVS Commits ---
The releases/gcc-12 branch has been updated by Martin Jambor
:
https://gcc.gnu.org/g:1a78fffb3845f879e36ba33b4d15e75b3df8d5a7
commit r12-8564-g1a78fffb3845f879e36ba33b4d15e75b3df8d5a7
Author: Martin Jambor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106256
Bug ID: 106256
Summary: Custom diagnostics for unsatisified standard concepts
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106238
--- Comment #2 from Rogério de Souza Moraes ---
Created attachment 53287
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53287&action=edit
C++ code to reproduce the issue.
C++ code to reproduce the issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105838
luydorarko at vusra dot com changed:
What|Removed |Added
CC||luydorarko at vusra dot co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106237
--- Comment #2 from seurer at gcc dot gnu.org ---
They use whichever mcpu matches the machine.
The ICEs are fixed but there is a different problem introduced with your fix
g:79f18ac6b7ab7744fcf8937ea4bc0c40f3efc629, r13-1599-g79f18ac6b7ab77
mak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106250
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106250
--- Comment #3 from CVS Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:e7a7fed818d238d45b18dfd927cde93b4711052d
commit r13-1606-ge7a7fed818d238d45b18dfd927cde93b4711052d
Author: Richard Sandiford
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105616
--- Comment #2 from Cristian Morales Vega ---
I don't think so.
Supposedly it was fixed 2 months ago in trunk
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105562#c14). But in
https://godbolt.org/z/8a979Gha8 the warnings are still present (even
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106252
Lewis Hyatt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106252
--- Comment #3 from CVS Commits ---
The master branch has been updated by Lewis Hyatt :
https://gcc.gnu.org/g:cb7b01db7a1979a45fd1dce87a8738e80568520e
commit r13-1605-gcb7b01db7a1979a45fd1dce87a8738e80568520e
Author: Lewis Hyatt
Date: Mon J
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106255
Andreas Schwab changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106254
--- Comment #1 from Andreas Schwab ---
*** Bug 106255 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106248
--- Comment #7 from Jonathan Wakely ---
Comment 6 isn't right (it should be sgetc not snextc, and it needs to consider
the stream's field width) but I'm testing a working patch now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99416
--- Comment #3 from Richard Biener ---
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.
Possible alias data dependence to break:
Fuse partit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99416
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106255
Bug ID: 106255
Summary: [suboptinal] llvm uses instructions with larger access
bit width
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106254
Bug ID: 106254
Summary: [suboptinal] llvm uses instructions with larger access
bit width
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106253
--- Comment #4 from rsandifo at gcc dot gnu.org
---
I guess we'll need different patterns in that case. These builtins
are also used to expand ACLE intrinsics, and I think for those we
have to honour the prevailing flush-to-zero mode, which ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106240
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2022-07-11
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106248
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106253
--- Comment #3 from Richard Biener ---
aarch64_builtin_vectorized_function is what returns these, but the decls
seem to be generated elsewhere.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106253
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|rguenth at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106252
--- Comment #2 from Martin Liška ---
It's a ASAN bootstrap that needs the following configure option:
--with-build-config=bootstrap-asan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106248
--- Comment #6 from Jonathan Wakely ---
I think this would restore the previous behaviour without losing the overflow
prevention:
--- a/libstdc++-v3/include/std/istream
+++ b/libstdc++-v3/include/std/istream
@@ -813,8 +813,17 @@ _GLIBCXX_BEGIN_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106252
Lewis Hyatt changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |lhyatt at gcc dot
gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106248
--- Comment #5 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #1)
> This is interesting because I get the same behavior in clang with LLVM's
> libc++.
Are you sure? I do not see any dependency on optimization level when using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106248
--- Comment #4 from Jonathan Wakely ---
To put it another way, in C++17 and earlier, writing the buffer stops because
we reach EOF when reading from the istream. If it *didn't* stop there, it would
overflow the buffer and have undefined behaviou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106248
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2022-07-11
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106253
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106250
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106248
--- Comment #2 from Jonathan Wakely ---
I haven't analyzed it yet but this is probably due to r11-2581-g17abcc77341584
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106241
--- Comment #7 from Jonathan Wakely ---
(In reply to Robert Durkacz from comment #3)
> So I guess the compiler just does not address this particular kind of use
> case but it seems to me that, on the contrary, there should be a compilation
> cap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106250
Martin Liška changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106251
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106253
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2022-07-11
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106253
Bug ID: 106253
Summary: [13 Regression] ICE in vect_transform_loops, at
tree-vectorizer.cc:1032x
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106228
--- Comment #16 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:415d2c38edadf97950eb14b8d7e6b1491c98cdd5
commit r13-1603-g415d2c38edadf97950eb14b8d7e6b1491c98cdd5
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106250
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106252
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106250
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106252
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2022-07-11
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106246
--- Comment #7 from Richard Biener ---
OK, indeed this is caused by my most recent change. The following should fix
this, I'm going to test this on x86_64-linux (no convenient ppc testing machine
available for me right now)
diff --git a/gcc/tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106252
Bug ID: 106252
Summary: [13 Regression] AddressSanitizer:
global-buffer-overflow on address since
r13-1544-ge46f4d7430c521
Product: gcc
Version: 13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105459
Richard Biener changed:
What|Removed |Added
Assignee|linkw at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105459
--- Comment #13 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:4c94382a132a4b2b9d020806549a006fa6764d1b
commit r13-1600-g4c94382a132a4b2b9d020806549a006fa6764d1b
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106170
Martin Liška changed:
What|Removed |Added
Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot
gnu.org
1 - 100 of 110 matches
Mail list logo