https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #37 from GCC Commits ---
The releases/gcc-14 branch has been updated by Francois Dumont
:
https://gcc.gnu.org/g:955202eb2cdbe2bc74c626bce90ee1eac410ad4f
commit r14-10272-g955202eb2cdbe2bc74c626bce90ee1eac410ad4f
Author: François Du
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #36 from GCC Commits ---
The master branch has been updated by Francois Dumont :
https://gcc.gnu.org/g:0426be454448f8cfb9db21f4f669426afb7b57c8
commit r15-996-g0426be454448f8cfb9db21f4f669426afb7b57c8
Author: François Dumont
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #35 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #31)
> Bisection points to r14-5831-gaae723d360ca26cd9fd0b039fb0a616bd0eae363 for
> that remaining FAIL as well (and it isn't fixed by the new patch).
>
> It int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #34 from Martin Jambor ---
(In reply to Jan Hubicka from comment #32)
> > /tmp/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:437:
> > warning: 'void* __builtin_memcpy(void*, const void*, long unsigned int)'
> > w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #33 from GCC Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:302461ad9a04d82fee904bddac69811d13d5bb6a
commit r14-5971-g302461ad9a04d82fee904bddac69811d13d5bb6a
Author: Martin Jambor
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #32 from Jan Hubicka ---
> /tmp/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:437:
> warning: 'void* __builtin_memcpy(void*, const void*, long unsigned int)'
> writing between 2 and 9223372036854775806 bytes into
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #31 from Jonathan Wakely ---
Bisection points to r14-5831-gaae723d360ca26cd9fd0b039fb0a616bd0eae363 for that
remaining FAIL as well (and it isn't fixed by the new patch).
It introduced a new warning which wasn't present before:
/tm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #30 from Jonathan Wakely ---
So far the only FAIL is still see is:
FAIL: 23_containers/vector/types/1.cc -std=gnu++98 (test for excess errors)
I'm not sure if this is caused by your patch or one of Honza's. The test only
fails wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #29 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #28)
> (In reply to Martin Jambor from comment #27)
> > Can you please try if
> > https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638318.html
> > fixes th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #28 from Jonathan Wakely ---
(In reply to Martin Jambor from comment #27)
> Unfortunately I cannot reproduce this, the above (on pristine master
> commit 006e90e1344 on an x86_64-linux) results in:
>
> Running target unix/-D_GLIBCXX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #27 from Martin Jambor ---
(In reply to Jonathan Wakely from comment #26)
> (In reply to GCC Commits from comment #23)
> > https://gcc.gnu.org/g:aae723d360ca26cd9fd0b039fb0a616bd0eae363
> >
> > commit r14-5831-gaae723d360ca26cd9fd0b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #26 from Jonathan Wakely ---
(In reply to GCC Commits from comment #23)
> https://gcc.gnu.org/g:aae723d360ca26cd9fd0b039fb0a616bd0eae363
>
> commit r14-5831-gaae723d360ca26cd9fd0b039fb0a616bd0eae363
> Author: Martin Jambor
> Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
Bug 109849 depends on bug 112653, which changed state.
Bug 112653 Summary: PTA should handle correctly escape information of values
returned by a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112653
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #25 from Martin Jambor ---
(In reply to Richard Biener from comment #7)
> There is nothing to sink really, loop header copying introduces a PHI and
> there's not partial redundancies but only partial-partial and those are not
> obvio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #24 from CVS Commits ---
The master branch has been updated by Jan Hubicka :
https://gcc.gnu.org/g:c2dcfb6ba6e9a84a16e63ae73a822ae2a843170c
commit r14-5832-gc2dcfb6ba6e9a84a16e63ae73a822ae2a843170c
Author: Jan Hubicka
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #23 from CVS Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:aae723d360ca26cd9fd0b039fb0a616bd0eae363
commit r14-5831-gaae723d360ca26cd9fd0b039fb0a616bd0eae363
Author: Martin Jambor
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
Bug 109849 depends on bug 110377, which changed state.
Bug 110377 Summary: Early VRP and IPA-PROP should work out value ranges from
__builtin_unreachable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110377
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #22 from CVS Commits ---
The master branch has been updated by Jan Hubicka :
https://gcc.gnu.org/g:1d82fc2e6824bf83159389729c31a942f7b91b04
commit r14-5679-g1d82fc2e6824bf83159389729c31a942f7b91b04
Author: Jan Hubicka
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #21 from Jan Hubicka ---
Patch
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637265.html
gets us closer to inlining _M_realloc_insert at -O3 (3 insns away)
Patch
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/6369
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #20 from CVS Commits ---
The master branch has been updated by Jan Hubicka :
https://gcc.gnu.org/g:eab57b825bcc350e9ff44eb2fa739a80199d9bb1
commit r14-2219-geab57b825bcc350e9ff44eb2fa739a80199d9bb1
Author: Jan Hubicka
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #19 from CVS Commits ---
The master branch has been updated by Jan Hubicka :
https://gcc.gnu.org/g:9dc18fca431626404b0692c689a2e103666e7adb
commit r14-2202-g9dc18fca431626404b0692c689a2e103666e7adb
Author: Jan Hubicka
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #18 from CVS Commits ---
The master branch has been updated by Jan Hubicka :
https://gcc.gnu.org/g:45c53768b6fa3d737ae818e31d3c50da62e0ad2b
commit r14-2157-g45c53768b6fa3d737ae818e31d3c50da62e0ad2b
Author: Jan Hubicka
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #17 from CVS Commits ---
The master branch has been updated by Jan Hubicka :
https://gcc.gnu.org/g:c2ebccc97190a978a44e341516b488f02a78c598
commit r14-2101-gc2ebccc97190a978a44e341516b488f02a78c598
Author: Jan Hubicka
Date: Mon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #16 from CVS Commits ---
The master branch has been updated by Jan Hubicka :
https://gcc.gnu.org/g:7b34cacc5735385e7e2855d7c0a6fad60ef4a99b
commit r14-1951-g7b34cacc5735385e7e2855d7c0a6fad60ef4a99b
Author: Jan Hubicka
Date: Mon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #15 from CVS Commits ---
The master branch has been updated by Jan Hubicka :
https://gcc.gnu.org/g:5a1ef1cfac005370d0a5a0f85798724cb2c9cf5e
commit r14-1909-g5a1ef1cfac005370d0a5a0f85798724cb2c9cf5e
Author: Honza
Date: Sun Jun 18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #14 from Jan Hubicka ---
One interesting situation is:
void std::vector >::push_back (struct
vector * const this, const struct value_type & __x)
{
struct __normal_iterator D.27894;
struct pair * _1;
struct pair * _2;
struct p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #13 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:5476de2618ffb77f3a52e59e2c9f10b018329689
commit r14-1161-g5476de2618ffb77f3a52e59e2c9f10b018329689
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #12 from Richard Biener ---
So this fixed the missing code hoisting - partial PRE is done with -O3 only.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #11 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:9e2017ae6ac788d3e36999bb0f0d20ea0f62c20e
commit r14-1127-g9e2017ae6ac788d3e36999bb0f0d20ea0f62c20e
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #10 from Jan Hubicka ---
Thanks. I tested the patch on jpegxl and it does not help there (I guess
becuase the redundancy there is partial). But it is cool we compile at least
the simplified testcase well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #9 from Richard Biener ---
Created attachment 55110
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55110&action=edit
patch for the missed hoisting
For the testcase in comment#6 there is a missing code hoisting from PRE
which i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #8 from Jan Hubicka ---
We can only SRA if the address is non-escaping. Clang does not seem to need it
to optimize better:
jan@localhost:~> cat t.c
extern void q(int *);
__attribute__ ((noinline))
void
test()
{
for (int a =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
Jan Hubicka changed:
What|Removed |Added
Blocks||109811
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2023-05-15
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #5 from Jan Hubicka ---
> Actually why didn't we copy the loop header in the first place?
Because it is considered to be do-while loop already (thanks to
the in-loop conitional, do_while_loop_p is happy).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #4 from Jan Hubicka ---
> Rather, because store-motion out of a loop that might iterate zero times would
> create a data race.
Good point. If we did copy loop headers all the way to the store the
problem will go away. Also I assume
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #2 from Andrew Pinski ---
(In reply to Jan Hubicka from comment #0)
> saving an instruction. Why we do not move stack+8 updating out of the loop?
Maybe because of a clobber:
cur$second_5 = MEM[(const struct pairD.26349 &)_7 +
1844
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #1 from Andrew Pinski ---
Actually why didn't we copy the loop header in the first place?
40 matches
Mail list logo
