https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109298
Richard Biener changed:
What|Removed |Added
Component|c |tree-optimization
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109299
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109300
Richard Biener changed:
What|Removed |Added
Priority|P2 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109301
--- Comment #4 from Richard Biener ---
(In reply to Jakub Jelinek from comment #3)
> Tried -Ofast -mavx512f
> #include
>
> void
> foo (double *a, double *b)
> {
> for (int i = 0; i < 1024; i++)
> a[i] = pow (a[i], b[i]);
> }
>
> void
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109302
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2023-03-28
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109303
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109304
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109312
Bug ID: 109312
Summary: Missing __riscv_v_intrinsic
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Ass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109309
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2023-03-28
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109293
--- Comment #7 from CVS Commits ---
The master branch has been updated by Xi Ruoyao :
https://gcc.gnu.org/g:21c74b6ea41d21ef96813b34bfa55c51a82d6c99
commit r13-6888-g21c74b6ea41d21ef96813b34bfa55c51a82d6c99
Author: Xi Ruoyao
Date: Tue Mar 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109293
Xi Ruoyao changed:
What|Removed |Added
Summary|[12/13 Regression] Missing |[12 Regression] Missing
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109311
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109311
--- Comment #3 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:b462947dae9f8c0dd7c11165ccfdf6acd6f12a1c
commit r13-6889-gb462947dae9f8c0dd7c11165ccfdf6acd6f12a1c
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109311
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109313
Bug ID: 109313
Summary: Incorrect line number in Use-After-Scope report
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109314
Bug ID: 109314
Summary: Typo 'composit' in diagnostic
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109192
chenglulu changed:
What|Removed |Added
CC||chenglulu at loongson dot cn
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109304
--- Comment #6 from Richard Biener ---
Early IPA visibility introduces a local alias (because of
-fno-semantic-interposition). Local IPA pure-const makes PyUnicode_FindChar
looping pure.
IPA profile instruments the functions, but the .localalia
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109140
Eric Botcazou changed:
What|Removed |Added
Target Milestone|13.0|12.3
Summary|internal error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109192
--- Comment #13 from chenglulu ---
(In reply to CVS Commits from comment #9)
> The master branch has been updated by Andrew Macleod :
>
> https://gcc.gnu.org/g:0963cb5fde158cce986523a90fa9edc51c881f31
>
> commit r13-6787-g0963cb5fde158cce98652
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109315
Bug ID: 109315
Summary: typo: inconsistant
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402
--- Comment #60 from Richard Biener ---
(In reply to Martin Liška from comment #59)
> (In reply to Andrew Carlotti from comment #58)
> > Since November 2021, there's been a significant regression in the compile
> > time for gimple-match.cc during
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #22 from Richard Biener ---
(In reply to Jakub Jelinek from comment #21)
> Created attachment 54770 [details]
> gcc13-pr109154.patch
>
> So what about this then?
> It matches the x86 FTZ behavior, because FTZ is a masked reaction to
.
(fpcmpu_vis): Likewise.
(vcondu): New VIS 4 expander.
gcc/testsuite/
* gcc.target/sparc/20230328-1.c: New test.
* gcc.target/sparc/20230328-2.c: Likewise.
* gcc.target/sparc/20230328-3.c: Likewise.
* gcc.target/sparc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109276
--- Comment #18 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:4b5ef857f5faf09f274c0a95c67faaa80d198124
commit r13-6894-g4b5ef857f5faf09f274c0a95c67faaa80d198124
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109276
Jakub Jelinek changed:
What|Removed |Added
Summary|[11/12/13 Regression] ICE: |[11/12 Regression] ICE: in
): Move around.
(fpcmpu_vis): Likewise.
(vcondu): New VIS 4 expander.
gcc/testsuite/
* gcc.target/sparc/20230328-1.c: New test.
* gcc.target/sparc/20230328-2.c: Likewise.
* gcc.target/sparc/20230328-3.c: Likewise.
* gcc.target
): Move around.
(fpcmpu_vis): Likewise.
(vcondu): New VIS 4 expander.
gcc/testsuite/
* gcc.target/sparc/20230328-1.c: New test.
* gcc.target/sparc/20230328-2.c: Likewise.
* gcc.target/sparc/20230328-3.c: Likewise.
* gcc.target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109140
Eric Botcazou changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402
--- Comment #62 from Jakub Jelinek ---
Looking at gimple-match.cc, the case CFN_BUILT_IN_ATOMIC_FETCH_OR_{1,2,4,8,16}:
etc. blocks are identical there, except for the numbers in next_after_fail*
label numbers.
So, could we perhaps expand everythi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109308
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #4 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106190
--- Comment #9 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:39a43dc336561e0eba0de477b16c7355f19d84ee
commit r13-6897-g39a43dc336561e0eba0de477b16c7355f19d84ee
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #23 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:ce3974e5962b0e1f72a1f71ebda39d53a77b7cc9
commit r13-6898-gce3974e5962b0e1f72a1f71ebda39d53a77b7cc9
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402
--- Comment #63 from rguenther at suse dot de ---
On Tue, 28 Mar 2023, amonakov at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402
>
> Alexander Monakov changed:
>
>What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108581
Paul Thomas changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109312
--- Comment #1 from Andreas Schwab ---
You need at least enable the V extension (-march=rv64gcv).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103387
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2021-11-23 00:00:00 |2023-3-28
--- Comment #6 from Jonatha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106190
Jakub Jelinek changed:
What|Removed |Added
Summary|[10/11/12/13 Regression]|[10/11/12 Regression] ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109299
--- Comment #5 from Jonathan Wakely ---
This is not a library bug. The library code is:
basic_string(basic_string&& __str) noexcept
: _M_dataplus(_M_local_data(), std::move(__str._M_get_allocator()))
{
if (__str._M_is_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109293
--- Comment #9 from Jan Dubiec ---
I can confirm that now everything is fine on this issue on Windows/MingW.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109312
--- Comment #2 from Mathieu Malaterre ---
(In reply to Andreas Schwab from comment #1)
> You need at least enable the V extension (-march=rv64gcv).
Oh, right ! Here is the correct full listing this time:
% /usr/lib/gcc-snapshot/bin/gcc -march=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109299
--- Comment #6 from Jonathan Wakely ---
This change to bits/basic_string.h seems to shut the compiler up:
--- include/bits/basic_string.h 2023-02-27 13:42:21.295513537 +
@@ -271,7 +271,15 @@
_GLIBCXX20_CONSTEXPR
bool
_M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109314
--- Comment #1 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:0ecebc3a0947adad322281c0905afa9f8e3c4aee
commit r13-6899-g0ecebc3a0947adad322281c0905afa9f8e3c4aee
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109314
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Assi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109299
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105205
Paul Thomas changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
Last reconfirm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109293
--- Comment #10 from CVS Commits ---
The releases/gcc-12 branch has been updated by Xi Ruoyao :
https://gcc.gnu.org/g:743088c3c7c670f180978dd7b59a57fd9626c5a2
commit r12-9326-g743088c3c7c670f180978dd7b59a57fd9626c5a2
Author: Xi Ruoyao
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109293
Xi Ruoyao changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109299
--- Comment #8 from Jonathan Wakely ---
Yes, it looks better:
--- 109299-orig.s 2023-03-28 11:01:09.886119878 +0100
+++ 109299-fixed.s 2023-03-28 11:01:21.361187289 +0100
@@ -235,21 +235,14 @@
xorl%esi, %esi
call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109299
--- Comment #9 from Jonathan Wakely ---
And the reason I put the hint in _M_is_local() not in the function giving the
warning is that it might help in other functions too.
I haven't tested it yet though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #24 from Tamar Christina ---
(In reply to Jakub Jelinek from comment #12)
> (In reply to Richard Biener from comment #11)
> > _1 shoud be [-Inf, nextafter (0.0, -Inf)], not [-Inf, -0.0]
> The reduced testcase is invalid because it us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #25 from Tamar Christina ---
Created attachment 54777
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54777&action=edit
extracted codegen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98408
--- Comment #3 from Paul Thomas ---
(In reply to Dominique d'Humieres from comment #2)
> Compiling the test with -Wall gives
>
> 2 | character (len=:), allocatable :: a(:)
> |^
> Warning: '.a'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109302
Jakub Jelinek changed:
What|Removed |Added
Keywords|needs-bisection |
--- Comment #2 from Jakub Jelinek ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108129
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109302
--- Comment #3 from Jakub Jelinek ---
I think the problem is that ccp1 decides to fold
_4 = 0;
...
VIEW_CONVERT_EXPR<__int128 unsigned[4]>(v)[_4] = _8;
into
v_18 = BIT_INSERT_EXPR ;
while the function is still TARGET_AVX512F and so has V4T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402
--- Comment #64 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:75cda3be0232f745cda4e177d514f6900390af0b
commit r13-6902-g75cda3be0232f745cda4e177d514f6900390af0b
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108129
--- Comment #6 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:75cda3be0232f745cda4e177d514f6900390af0b
commit r13-6902-g75cda3be0232f745cda4e177d514f6900390af0b
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108129
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109072
--- Comment #9 from CVS Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:fcb411564a655a01f759eea3bb16bfd1bc879bfd
commit r13-6903-gfcb411564a655a01f759eea3bb16bfd1bc879bfd
Author: Richard Sandiford
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109290
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2023-03-28
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #26 from Jakub Jelinek ---
The above slightly simplified (dead var removal, preprocessing etc.):
typedef struct __attribute__((__packed__)) _Atom { float x, y, z; int type; }
Atom;
typedef struct __attribute__((__packed__)) _FFParams
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109048
Richard Biener changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #27 from Richard Biener ---
I've added heuristics to threading to PR109048 but I think it's too strong to
reject them.
For the testcase in this PR ranger could fix up if it managed to properly
propagate the singleton range early. A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #28 from Richard Biener ---
So as for what ranger should get, the testcase in comment#2 after EVRP still
sees
:
_1 = (float) l_10;
_2 = _1 < 0.0;
zone1_17 = (int) _2;
if (_1 < 0.0)
goto ; [INV]
else
goto ; [INV]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109308
--- Comment #5 from Siddhesh Poyarekar ---
This kinda has happened before:
https://github.com/Perl/perl5/issues/20678
Should we keep this bug open for the message, which is obviously wrong?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109072
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Summary|[12/13 Regression] SLP |[12 Regression] SLP costs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109309
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #29 from Richard Biener ---
For the testcase in comment#26 we see that if-conversion from
if (distbb_170 >= 0.0)
goto ; [59.00%]
else
goto ; [41.00%]
[local count: 311875831]:
...
if (distbb_170 < iftmp.0_97)
g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109192
--- Comment #14 from Andrew Macleod ---
The upcoming patch for 109274 should resolve this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107087
--- Comment #5 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:2b9d76c1af189b918a9970f471e6d2e2c08f7e7d
commit r13-6905-g2b9d76c1af189b918a9970f471e6d2e2c08f7e7d
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97048
Bug 97048 depends on bug 107087, which changed state.
Bug 107087 Summary: [13 Regression] bits/stl_algobase.h:431: warning: 'void*
__builtin_memcpy(void*, const void*, unsigned int)' reading between 8 and
2147483644 bytes from a region of size 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107087
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109316
Bug ID: 109316
Summary: incorrect "warning: declaration does not declare
anything" for anonymous enums in structs, for
-std=(gnu|c)-17
Product: gcc
Version: unkn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109265
--- Comment #11 from CVS Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:dd63bba0c8dc3a6ae06cfdc084bca7c68b8bbd39
commit r13-6906-gdd63bba0c8dc3a6ae06cfdc084bca7c68b8bbd39
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109274
--- Comment #13 from CVS Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:dd63bba0c8dc3a6ae06cfdc084bca7c68b8bbd39
commit r13-6906-gdd63bba0c8dc3a6ae06cfdc084bca7c68b8bbd39
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109274
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #30 from Jakub Jelinek ---
But at least the zone1_100 stuff is unused in #c26, so improving #c28 there
wouldn't help.
distbb_99 = distij_98 - radij_82;
_27 = distbb_99 < 0.0;
# RANGE [irange] const int [0, 1] NONZERO 0x1
zone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109187
--- Comment #5 from CVS Commits ---
The master branch has been updated by Alexander Monakov :
https://gcc.gnu.org/g:fb046e69f0ed2d637ea715ae71ad50131f30cb2d
commit r13-6907-gfb046e69f0ed2d637ea715ae71ad50131f30cb2d
Author: Alexander Monakov
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109187
Alexander Monakov changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #31 from Jakub Jelinek ---
On the #c28 testcase, my #c23 patch seems to improve something only visible in
the details of the evrp dump:
zone1_12 : [irange] int [0, 1] NONZERO 0x1
-2->3 (T) _1 : [frange] float [-Inf, -0.0 (-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107002
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103387
--- Comment #7 from Jonathan Wakely ---
OK, I see what's happening now:
Breakpoint 3.3, std::__gnu_cxx_ldbl128::num_put > >::num_put (
this=0x101c1f98 <(anonymous namespace)::num_put_c>, __refs=1)
at
/home/test/build/powerpc64le-unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106124
--- Comment #4 from Jakub Jelinek ---
(In reply to Richard Biener from comment #3)
> I suppose that's the OMP reduction function and that's always(?) inlined?
The reduction "function" is something artificial which holds some expressions
for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109312
--- Comment #3 from CVS Commits ---
The master branch has been updated by Kito Cheng :
https://gcc.gnu.org/g:5a923516ae61ddc6dd863891db13189cbf392411
commit r13-6909-g5a923516ae61ddc6dd863891db13189cbf392411
Author: Kito Cheng
Date: Tue Mar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103387
--- Comment #8 from Jonathan Wakely ---
And that's because we're using the ostream's cached _M_num_put but that is the
wrong one:
(gdb) step
std::basic_ostream >::_M_insert<__ieee128>
(this=0x101c0900 , __v=0.100
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109315
Gaius Mulley changed:
What|Removed |Added
Last reconfirmed||2023-03-28
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109312
Kito Cheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107163
--- Comment #4 from CVS Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:0e8fc610fb7112deb8c33c673a52983368dde9b7
commit r13-6910-g0e8fc610fb7112deb8c33c673a52983368dde9b7
Author: Jason Merrill
Date: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #32 from Andrew Macleod ---
The issues is here is pruning to avoid significant time growth.
_1 = (float) l_11(D);
_2 = _1 < 0.0;
zone1_12 = (int) _2;
if (_1 < 0.0)
goto ; [INV]
_1 is an export from the block. In theor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #33 from Jakub Jelinek ---
(In reply to Andrew Macleod from comment #32)
> We could in theory expand it to look at 2 levels if its a single operand...
Yeah, that would help here and could be worth it.
> which will help with some of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109309
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:af45b17d0a8fe3e7ae08662008a1f41e48a4a3eb
commit r13-6911-gaf45b17d0a8fe3e7ae08662008a1f41e48a4a3eb
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109309
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
St
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #34 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #33)
> (In reply to Andrew Macleod from comment #32)
> > We could in theory expand it to look at 2 levels if its a single operand...
>
> Yeah, that would help here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #35 from Jakub Jelinek ---
(In reply to Andrew Macleod from comment #34)
> I will poke at whether its possible to cheaply handle a second (or third)
> level for single dependency defs.
Will those include also binary ops which have o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109305
--- Comment #4 from Marc-André Laverdière ---
The comment is "If this allocation throws there are no effects:" and I didn't
understand the implications. Thanks for you spelled it out the logic behind it.
May I encourage you to update the comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109305
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109305
--- Comment #6 from Jonathan Wakely ---
For your reproducer, the allocator is std::allocator which is an empty
class and copying is a no-op. There is no efficiency concern whatsoever.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109305
--- Comment #7 from Charles-Henri Gros ---
For context, we're trying to detect cases where using "auto" unintentionally
creates a copy (it's regrettably common).
Here the copy is necessary to get a non-const value; that's definitely
something we
1 - 100 of 169 matches
Mail list logo
