https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #40 from Jakub Jelinek ---
(In reply to Jan Hubicka from comment #39)
> This testcase
> #include
> int data[100];
>
> __attribute__((noinline))
> int bar (int d, unsigned int d2)
> {
> if (d2 > 10)
> printf ("Bingo\n");
> r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #39 from Jan Hubicka ---
This testcase
#include
int data[100];
__attribute__((noinline))
int bar (int d, unsigned int d2)
{
if (d2 > 10)
printf ("Bingo\n");
return d + d2;
}
int
test2 (unsigned int i)
{
if (i > 10)
_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #38 from Jakub Jelinek ---
(In reply to Jan Hubicka from comment #36)
> > > Having a testcase is great. I was just playing with crafting one.
> > > I am still concerned about value ranges in ipa-prop's jump functions.
> >
> > Maybe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #37 from Jan Hubicka ---
> Also remember we like to have a fix that's easily backportable, and
> that's probably going to be resetting the info. We can do something
> more fancy for GCC 15
Rejecting to merge function with different
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #36 from Jan Hubicka ---
> > Having a testcase is great. I was just playing with crafting one.
> > I am still concerned about value ranges in ipa-prop's jump functions.
>
> Maybe my imagination is too limited, but if the ipa-prop's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #35 from rguenther at suse dot de ---
On Thu, 15 Feb 2024, rguenther at suse dot de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
>
> --- Comment #34 from rguenther at suse dot de ---
> On Thu, 15 Feb 2024, jakub at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #34 from rguenther at suse dot de ---
On Thu, 15 Feb 2024, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
>
> --- Comment #32 from Jakub Jelinek ---
> (In reply to Jan Hubicka from comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #33 from Jakub Jelinek ---
Anyway, should I work on the union variant or do you want to take this over?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #32 from Jakub Jelinek ---
(In reply to Jan Hubicka from comment #31)
> Having a testcase is great. I was just playing with crafting one.
> I am still concerned about value ranges in ipa-prop's jump functions.
Maybe my imagination i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #31 from Jan Hubicka ---
Having a testcase is great. I was just playing with crafting one.
I am still concerned about value ranges in ipa-prop's jump functions.
Let me see if I can modify the testcase to also trigger problem with val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
Sam James changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #30 from Jakub Jelinek ---
Created attachment 57426
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57426&action=edit
gcc14-pr113907.patch
I've managed to come up with a small runtime testcase.
Now with a patch which does the r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #28 from rguenther at suse dot de ---
On Wed, 14 Feb 2024, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
>
> --- Comment #27 from Jakub Jelinek ---
> So:
> --- gcc/ipa-icf.cc.jj 2024-02-10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #27 from Jakub Jelinek ---
So:
--- gcc/ipa-icf.cc.jj 2024-02-10 11:25:09.645478952 +0100
+++ gcc/ipa-icf.cc 2024-02-14 10:44:27.906216458 +0100
@@ -1244,6 +1244,29 @@ sem_function::merge (sem_item *alias_ite
else
creat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #26 from Richard Biener ---
(In reply to Jakub Jelinek from comment #25)
> So, to sum up what has been discussed on IRC, LTO streaming doesn't seem to
> stream SSA_NAME_INFO, only the final IPA phases of say IPA-VRP can set
> SSA_NAM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #25 from Jakub Jelinek ---
So, to sum up what has been discussed on IRC, LTO streaming doesn't seem to
stream SSA_NAME_INFO, only the final IPA phases of say IPA-VRP can set
SSA_NAME_INFO.
Thus, this bug is most likely solely about -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #24 from Jakub Jelinek ---
static inline int
foo (int len, void *indata, void *outdata)
{
if (len < 0 || (len & 7) != 0)
return 0;
if (len != 0 && indata != outdata)
__builtin_memcpy (outdata, indata, len);
return len;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #23 from Jakub Jelinek ---
(In reply to Andrew Pinski from comment #22)
> (In reply to Andrew Pinski from comment #21)
> > Yep that is the same descriptions as what is happening in PR 113665.
>
> Specifically https://gcc.gnu.org/bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #22 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #21)
> Yep that is the same descriptions as what is happening in PR 113665.
Specifically https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113665#c5 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #21 from Andrew Pinski ---
(In reply to Jakub Jelinek from comment #20)
> Ah, I think it is IPA-ICF.
> What happens is that fnsplit splits the uprv_copyArray{16,32,64} functions,
> where the
> inline part does what is actually differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
Jakub Jelinek changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #19 from Jakub Jelinek ---
Diffing the -fdump-{tree,ipa}-all-alias dumps from r14-5108 and r14-5109,
085i.fnsummary still looks good (the 2/4/8 in the ranges corresponds to whether
it is in 16/32/64 suffixed/infixed function).
But th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #17 from Jakub Jelinek ---
One set of range changes in evrp is more precise ranges in return values of
uprv_swapArray{16,32,64}, those contain early return 0 if
length<0 || (length&1)!=0
or
length<0 || (length&3)!=0
or
length<0 || (l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #16 from Sam James ---
(In reply to Jakub Jelinek from comment #14
> So it certainly doesn't surprise me some length < 8 check is optimized away
> given the above range info. The question is if it is correct and what
> values the le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #15 from Andrew Pinski ---
Note the range part looks correct when taking the mask into account so I am
suspecting the mask is messed up. Let me see if I could spot it later today.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #14 from Jakub Jelinek ---
There are significant differences in the ranges starting with evrp.
Even optimized has:
--- pr113907.ii.261t.optimized_ 2024-02-13 09:52:13.090609512 -0500
+++ pr113907.ii.261t.optimized 2024-02-13 09:53:3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #13 from Sam James ---
(In reply to Andrew Pinski from comment #11)
> Does -fwrapv help?
no (and ubsan suppresses the crash, everything works fine w/ no ubsan output)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #12 from Sam James ---
-O2 -march=i686 -std=c++11 -m32 -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #11 from Andrew Pinski ---
Does -fwrapv help?
If so does -fsanitize=undefined say anything?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #10 from Jakub Jelinek ---
g++ command line for that TU?
-O2 -march=i686 -std=c++14 -m32
?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #9 from Sam James ---
(In reply to Sam James from comment #4)
> Created attachment 57409 [details]
> udataswp.ii.xz
>
> It goes wrong in common/udataswp.cpp's uprv_copyArray16 and uprv_copyArray64.
>
ah, uprv_copyArray64 -> uprv_c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #8 from Sam James ---
Created attachment 57413
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57413&action=edit
udataswp.o (bad, r14-5109-ga291237b628f41)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #7 from Sam James ---
Created attachment 57412
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57412&action=edit
udataswp.o (good, r14-5108-g751fc7bcdcdf25)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #6 from Sam James ---
Created attachment 57411
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57411&action=edit
udataswp.cpp.262r.expand (bad)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #5 from Sam James ---
Created attachment 57410
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57410&action=edit
udataswp.cpp.262r.expand (good)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #4 from Sam James ---
Created attachment 57409
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57409&action=edit
udataswp.ii.xz
It goes wrong in common/udataswp.cpp's uprv_copyArray16 and uprv_copyArray64.
(Seemingly both of t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #2 from Sam James ---
Program received signal SIGSEGV, Segmentation fault.
0xf770e5c0 in memcpy (__dest=, __src=,
__len=) at /usr/include/bits/string_fortified.h:29
29return __builtin___memcpy_chk (__dest, __src, __len,
(gdb)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #1 from Sam James ---
I will do the usual bisection of objects and also narrow it down with pragmas.
I won't be able to get much further than that though, I suspect.
-fsanitize=address,undefined builds fine (i.e. it doesn't even seg
43 matches
Mail list logo
