* Fix handling of stores in modref_summary::useful_p
@ 2020-09-27 21:46 Jan Hubicka
2020-10-05 11:52 ` Vaseeharan Vinayagamoorthy
0 siblings, 1 reply; 6+ messages in thread
From: Jan Hubicka @ 2020-09-27 21:46 UTC (permalink / raw)
To: gcc-patches, d
Hi,
this patch fixes a pasto in modref_summary::useful_p that made
ipa-modref to give up on tracking stores when all load info got lost.
Bootstrapped/regtested x86_64-linux, comitted.
gcc/ChangeLog:
2020-09-27 Jan Hubicka <hubicka@ucw.cz>
* ipa-modref.c (modref_summary::useful_p): Fix testing of stores.
diff --git a/gcc/ipa-modref.c b/gcc/ipa-modref.c
index 728c6c1523d..6225552e41a 100644
--- a/gcc/ipa-modref.c
+++ b/gcc/ipa-modref.c
@@ -135,7 +135,7 @@ modref_summary::useful_p (int ecf_flags)
return true;
if (ecf_flags & ECF_PURE)
return false;
- return stores && !loads->every_base;
+ return stores && !stores->every_base;
}
/* Dump A to OUT. */
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Fix handling of stores in modref_summary::useful_p
2020-09-27 21:46 Fix handling of stores in modref_summary::useful_p Jan Hubicka
@ 2020-10-05 11:52 ` Vaseeharan Vinayagamoorthy
2020-10-05 16:28 ` Szabolcs Nagy
0 siblings, 1 reply; 6+ messages in thread
From: Vaseeharan Vinayagamoorthy @ 2020-10-05 11:52 UTC (permalink / raw)
To: Jan Hubicka, gcc-patches, d
Hi,
After this patch, I am noticing that some glibc crypto tests get stuck in scanf which goes into busy loop.
My build/host/target setup is:
Build: aarch64-none-linux-gnu
Host: aarch64-none-linux-gnu
Target: aarch64-none-linux-gnu
Kind regards
Vasee
On 27/09/2020, 22:46, "Gcc-patches on behalf of Jan Hubicka" <gcc-patches-bounces@gcc.gnu.org on behalf of hubicka@ucw.cz> wrote:
Hi,
this patch fixes a pasto in modref_summary::useful_p that made
ipa-modref to give up on tracking stores when all load info got lost.
Bootstrapped/regtested x86_64-linux, comitted.
gcc/ChangeLog:
2020-09-27 Jan Hubicka <hubicka@ucw.cz>
* ipa-modref.c (modref_summary::useful_p): Fix testing of stores.
diff --git a/gcc/ipa-modref.c b/gcc/ipa-modref.c
index 728c6c1523d..6225552e41a 100644
--- a/gcc/ipa-modref.c
+++ b/gcc/ipa-modref.c
@@ -135,7 +135,7 @@ modref_summary::useful_p (int ecf_flags)
return true;
if (ecf_flags & ECF_PURE)
return false;
- return stores && !loads->every_base;
+ return stores && !stores->every_base;
}
/* Dump A to OUT. */
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Fix handling of stores in modref_summary::useful_p
2020-10-05 11:52 ` Vaseeharan Vinayagamoorthy
@ 2020-10-05 16:28 ` Szabolcs Nagy
2020-10-05 16:54 ` Szabolcs Nagy
0 siblings, 1 reply; 6+ messages in thread
From: Szabolcs Nagy @ 2020-10-05 16:28 UTC (permalink / raw)
To: Vaseeharan Vinayagamoorthy; +Cc: Jan Hubicka, gcc-patches, d
The 10/05/2020 12:52, Vaseeharan Vinayagamoorthy wrote:
> Hi,
>
> After this patch, I am noticing that some glibc crypto tests get stuck in scanf which goes into busy loop.
>
> My build/host/target setup is:
> Build: aarch64-none-linux-gnu
> Host: aarch64-none-linux-gnu
> Target: aarch64-none-linux-gnu
i can reproduce this on aarch64, i'm looking at it:
if i compile glibc with gcc trunk after this commit i see
$ ./testrun.sh crypt/cert < $glibcsrc/crypt/cert.input
K: 0000000000000000 P: 0000000000000000 C: 0000000000000000 Encrypt FAIL
K: 0000000000000000 P: 0000000000000000 C: 0000000000000000 Encrypt FAIL
K: 0000000000000000 P: 0000000000000000 C: 0000000000000000 Encrypt FAIL
K: 0000000000000000 P: 0000000000000000 C: 0000000000000000 Encrypt FAIL
K: 0000000000000000 P: 0000000000000000 C: 0000000000000000 Encrypt FAIL
K: 0000000000000000 P: 0000000000000000 C: 0000000000000000 Encrypt FAIL
...
it just keeps printing this.
same test binary with glibc code compiled with an
older gcc works, so something in glibc gets miscompiled.
i will have to do more digging to figure out what.
>
>
>
> Kind regards
> Vasee
>
>
> On 27/09/2020, 22:46, "Gcc-patches on behalf of Jan Hubicka" <gcc-patches-bounces@gcc.gnu.org on behalf of hubicka@ucw.cz> wrote:
>
> Hi,
> this patch fixes a pasto in modref_summary::useful_p that made
> ipa-modref to give up on tracking stores when all load info got lost.
>
> Bootstrapped/regtested x86_64-linux, comitted.
>
> gcc/ChangeLog:
>
> 2020-09-27 Jan Hubicka <hubicka@ucw.cz>
>
> * ipa-modref.c (modref_summary::useful_p): Fix testing of stores.
>
> diff --git a/gcc/ipa-modref.c b/gcc/ipa-modref.c
> index 728c6c1523d..6225552e41a 100644
> --- a/gcc/ipa-modref.c
> +++ b/gcc/ipa-modref.c
> @@ -135,7 +135,7 @@ modref_summary::useful_p (int ecf_flags)
> return true;
> if (ecf_flags & ECF_PURE)
> return false;
> - return stores && !loads->every_base;
> + return stores && !stores->every_base;
> }
>
> /* Dump A to OUT. */
>
--
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Fix handling of stores in modref_summary::useful_p
2020-10-05 16:28 ` Szabolcs Nagy
@ 2020-10-05 16:54 ` Szabolcs Nagy
2020-10-05 21:45 ` Jan Hubicka
0 siblings, 1 reply; 6+ messages in thread
From: Szabolcs Nagy @ 2020-10-05 16:54 UTC (permalink / raw)
To: Vaseeharan Vinayagamoorthy, gcc-patches, Jan Hubicka
The 10/05/2020 17:28, Szabolcs Nagy via Gcc-patches wrote:
> The 10/05/2020 12:52, Vaseeharan Vinayagamoorthy wrote:
> > Hi,
> >
> > After this patch, I am noticing that some glibc crypto tests get stuck in scanf which goes into busy loop.
> >
> > My build/host/target setup is:
> > Build: aarch64-none-linux-gnu
> > Host: aarch64-none-linux-gnu
> > Target: aarch64-none-linux-gnu
>
> i can reproduce this on aarch64, i'm looking at it:
>
> if i compile glibc with gcc trunk after this commit i see
>
> $ ./testrun.sh crypt/cert < $glibcsrc/crypt/cert.input
> K: 0000000000000000 P: 0000000000000000 C: 0000000000000000 Encrypt FAIL
> K: 0000000000000000 P: 0000000000000000 C: 0000000000000000 Encrypt FAIL
> K: 0000000000000000 P: 0000000000000000 C: 0000000000000000 Encrypt FAIL
> K: 0000000000000000 P: 0000000000000000 C: 0000000000000000 Encrypt FAIL
> K: 0000000000000000 P: 0000000000000000 C: 0000000000000000 Encrypt FAIL
> K: 0000000000000000 P: 0000000000000000 C: 0000000000000000 Encrypt FAIL
> ...
>
> it just keeps printing this.
>
> same test binary with glibc code compiled with an
> older gcc works, so something in glibc gets miscompiled.
>
> i will have to do more digging to figure out what.
minimal reproducer:
#include <stdio.h>
int main()
{
int r,t;
r = sscanf("01", "%2x", &t);
printf("scanf: %d %02x\n", r, t);
return 0;
}
should print
scanf: 1 01
but when glibc is compiled with gcc trunk on aarch64 it prints
scanf: 0 00
i will continute the debugging from here tomorrow.
> > On 27/09/2020, 22:46, "Gcc-patches on behalf of Jan Hubicka" <gcc-patches-bounces@gcc.gnu.org on behalf of hubicka@ucw.cz> wrote:
> >
> > Hi,
> > this patch fixes a pasto in modref_summary::useful_p that made
> > ipa-modref to give up on tracking stores when all load info got lost.
> >
> > Bootstrapped/regtested x86_64-linux, comitted.
> >
> > gcc/ChangeLog:
> >
> > 2020-09-27 Jan Hubicka <hubicka@ucw.cz>
> >
> > * ipa-modref.c (modref_summary::useful_p): Fix testing of stores.
> >
> > diff --git a/gcc/ipa-modref.c b/gcc/ipa-modref.c
> > index 728c6c1523d..6225552e41a 100644
> > --- a/gcc/ipa-modref.c
> > +++ b/gcc/ipa-modref.c
> > @@ -135,7 +135,7 @@ modref_summary::useful_p (int ecf_flags)
> > return true;
> > if (ecf_flags & ECF_PURE)
> > return false;
> > - return stores && !loads->every_base;
> > + return stores && !stores->every_base;
> > }
> >
> > /* Dump A to OUT. */
> >
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Fix handling of stores in modref_summary::useful_p
2020-10-05 16:54 ` Szabolcs Nagy
@ 2020-10-05 21:45 ` Jan Hubicka
2020-10-06 8:52 ` Szabolcs Nagy
0 siblings, 1 reply; 6+ messages in thread
From: Jan Hubicka @ 2020-10-05 21:45 UTC (permalink / raw)
To: Szabolcs Nagy; +Cc: Vaseeharan Vinayagamoorthy, gcc-patches
> The 10/05/2020 17:28, Szabolcs Nagy via Gcc-patches wrote:
> > The 10/05/2020 12:52, Vaseeharan Vinayagamoorthy wrote:
> > > Hi,
> > >
> > > After this patch, I am noticing that some glibc crypto tests get stuck in scanf which goes into busy loop.
> > >
> > > My build/host/target setup is:
> > > Build: aarch64-none-linux-gnu
> > > Host: aarch64-none-linux-gnu
> > > Target: aarch64-none-linux-gnu
> >
> > i can reproduce this on aarch64, i'm looking at it:
> >
> > if i compile glibc with gcc trunk after this commit i see
> >
> > $ ./testrun.sh crypt/cert < $glibcsrc/crypt/cert.input
> > K: 0000000000000000 P: 0000000000000000 C: 0000000000000000 Encrypt FAIL
> > K: 0000000000000000 P: 0000000000000000 C: 0000000000000000 Encrypt FAIL
> > K: 0000000000000000 P: 0000000000000000 C: 0000000000000000 Encrypt FAIL
> > K: 0000000000000000 P: 0000000000000000 C: 0000000000000000 Encrypt FAIL
> > K: 0000000000000000 P: 0000000000000000 C: 0000000000000000 Encrypt FAIL
> > K: 0000000000000000 P: 0000000000000000 C: 0000000000000000 Encrypt FAIL
> > ...
> >
> > it just keeps printing this.
> >
> > same test binary with glibc code compiled with an
> > older gcc works, so something in glibc gets miscompiled.
> >
> > i will have to do more digging to figure out what.
>
> minimal reproducer:
>
> #include <stdio.h>
> int main()
> {
> int r,t;
> r = sscanf("01", "%2x", &t);
> printf("scanf: %d %02x\n", r, t);
> return 0;
> }
>
> should print
>
> scanf: 1 01
>
> but when glibc is compiled with gcc trunk on aarch64 it prints
>
> scanf: 0 00
>
> i will continute the debugging from here tomorrow.
There is a report on glibc issue here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97264
it turned out to be a latent glibc bug type punning const char * and
const unsigned char *.
I wonder if it is same as problem you are seeing?
Honza
>
>
> > > On 27/09/2020, 22:46, "Gcc-patches on behalf of Jan Hubicka" <gcc-patches-bounces@gcc.gnu.org on behalf of hubicka@ucw.cz> wrote:
> > >
> > > Hi,
> > > this patch fixes a pasto in modref_summary::useful_p that made
> > > ipa-modref to give up on tracking stores when all load info got lost.
> > >
> > > Bootstrapped/regtested x86_64-linux, comitted.
> > >
> > > gcc/ChangeLog:
> > >
> > > 2020-09-27 Jan Hubicka <hubicka@ucw.cz>
> > >
> > > * ipa-modref.c (modref_summary::useful_p): Fix testing of stores.
> > >
> > > diff --git a/gcc/ipa-modref.c b/gcc/ipa-modref.c
> > > index 728c6c1523d..6225552e41a 100644
> > > --- a/gcc/ipa-modref.c
> > > +++ b/gcc/ipa-modref.c
> > > @@ -135,7 +135,7 @@ modref_summary::useful_p (int ecf_flags)
> > > return true;
> > > if (ecf_flags & ECF_PURE)
> > > return false;
> > > - return stores && !loads->every_base;
> > > + return stores && !stores->every_base;
> > > }
> > >
> > > /* Dump A to OUT. */
> > >
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Fix handling of stores in modref_summary::useful_p
2020-10-05 21:45 ` Jan Hubicka
@ 2020-10-06 8:52 ` Szabolcs Nagy
0 siblings, 0 replies; 6+ messages in thread
From: Szabolcs Nagy @ 2020-10-06 8:52 UTC (permalink / raw)
To: Jan Hubicka; +Cc: Vaseeharan Vinayagamoorthy, gcc-patches
The 10/05/2020 23:45, Jan Hubicka wrote:
> > The 10/05/2020 17:28, Szabolcs Nagy via Gcc-patches wrote:
> > minimal reproducer:
> >
> > #include <stdio.h>
> > int main()
> > {
> > int r,t;
> > r = sscanf("01", "%2x", &t);
> > printf("scanf: %d %02x\n", r, t);
> > return 0;
> > }
> >
> > should print
> >
> > scanf: 1 01
> >
> > but when glibc is compiled with gcc trunk on aarch64 it prints
> >
> > scanf: 0 00
> >
> > i will continute the debugging from here tomorrow.
>
> There is a report on glibc issue here
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97264
> it turned out to be a latent glibc bug type punning const char * and
> const unsigned char *.
>
> I wonder if it is same as problem you are seeing?
thanks, that indeed looks very similar, i'll comment on the glibc bug.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-10-06 8:52 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-27 21:46 Fix handling of stores in modref_summary::useful_p Jan Hubicka
2020-10-05 11:52 ` Vaseeharan Vinayagamoorthy
2020-10-05 16:28 ` Szabolcs Nagy
2020-10-05 16:54 ` Szabolcs Nagy
2020-10-05 21:45 ` Jan Hubicka
2020-10-06 8:52 ` Szabolcs Nagy
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).