[Bug analyzer/97090] gcc.dg/analyzer/malloc-vs-local-1b.c fails on arm and powerpc64*-linux-gnu

2021-12-02 Thread dmalcolm at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97090

--- Comment #17 from David Malcolm  ---
Thanks for the confirmations.

[Bug analyzer/97090] gcc.dg/analyzer/malloc-vs-local-1b.c fails on arm and powerpc64*-linux-gnu

2021-12-02 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97090

--- Comment #16 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
The last time I saw the failure on Solaris was on 20210106.

[Bug analyzer/97090] gcc.dg/analyzer/malloc-vs-local-1b.c fails on arm and powerpc64*-linux-gnu

2021-12-01 Thread clyon at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97090

--- Comment #15 from Christophe Lyon  ---
Indeed I don't see that anymore.

[Bug analyzer/97090] gcc.dg/analyzer/malloc-vs-local-1b.c fails on arm and powerpc64*-linux-gnu

2021-11-30 Thread dmalcolm at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97090

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #14 from David Malcolm  ---
Looking at recents posts to gcc-testresults, I don't see any reference to
"analyzer"; e.g.:

Results for 12.0.0 (DEFMODE=thumb DEFARCH=armv7-a DEFCPU=default DEFFPU=default
TESTFLAGS=) [r12-4816] (GCC) testsuite on arm-none-linux-gnueabi
  https://gcc.gnu.org/pipermail/gcc-testresults/2021-November/732306.html

Results for 12.0.0 (DEFMODE=default DEFARCH=default DEFCPU=default
DEFFPU=default TESTFLAGS=-mthumb/-mfloat-abi=hard/-march=armv7e-m+fp)
[r12-4816] (GCC) testsuite on arm-none-eabi
  https://gcc.gnu.org/pipermail/gcc-testresults/2021-November/732304.html

Results for 12.0.0 (DEFMODE=default DEFARCH=default DEFCPU=default
DEFFPU=default TESTFLAGS=-mabi=ilp32) [r12-4816] (GCC) testsuite on
aarch64-none-elf
  https://gcc.gnu.org/pipermail/gcc-testresults/2021-November/732301.html

Is anyone still seeing these failures with trunk?

I'm going to go ahead and mark this as resolved; please reopen it if you're
still seeing issues.

[Bug analyzer/97090] gcc.dg/analyzer/malloc-vs-local-1b.c fails on arm and powerpc64*-linux-gnu

2021-07-28 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97090

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|11.2|---

[Bug analyzer/97090] gcc.dg/analyzer/malloc-vs-local-1b.c fails on arm and powerpc64*-linux-gnu

2021-04-27 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97090

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|11.0|11.2

--- Comment #13 from Jakub Jelinek  ---
GCC 11.1 has been released, retargeting bugs to GCC 11.2.

[Bug analyzer/97090] gcc.dg/analyzer/malloc-vs-local-1b.c fails on arm and powerpc64*-linux-gnu

2021-03-04 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97090

--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #11 from David Malcolm  ---
> Re comment #10: I just tested unknown-fns-4.c and malloc-vs-local-1b.c 500
> times each on a --target=i386-pc-solaris2.11 build using the script from
> comment #8 and the results were identical each time.  So hopefully the
> nondeterminism is fixed, at least.

Indeed: the last time I saw the flakyness in my daily builds was on 20210106.

[Bug analyzer/97090] gcc.dg/analyzer/malloc-vs-local-1b.c fails on arm and powerpc64*-linux-gnu

2021-03-03 Thread dmalcolm at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97090

--- Comment #11 from David Malcolm  ---
Re comment #10: I just tested unknown-fns-4.c and malloc-vs-local-1b.c 500
times each on a --target=i386-pc-solaris2.11 build using the script from
comment #8 and the results were identical each time.  So hopefully the
nondeterminism is fixed, at least.

[Bug analyzer/97090] gcc.dg/analyzer/malloc-vs-local-1b.c fails on arm and powerpc64*-linux-gnu

2020-12-10 Thread ro at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97090

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
 CC||ro at gcc dot gnu.org

--- Comment #10 from Rainer Orth  ---
I see the same flakyness of both gcc.dg/analyzer/unknown-fns-4.c (usually
XPASSing

XPASS: gcc.dg/analyzer/unknown-fns-4.c  (test for warnings, line 13)

but PASSing once in a while) and gcc.dg/analyzer/malloc-vs-local-1b.c (usually
FAILing

FAIL: gcc.dg/analyzer/malloc-vs-local-1b.c  (test for bogus messages, line 170)

but PASSing once in a while) on both sparc-sun-solaris2.11 and
i386-pc-solaris2.11.

[Bug analyzer/97090] gcc.dg/analyzer/malloc-vs-local-1b.c fails on arm and powerpc64*-linux-gnu

2020-11-30 Thread seurer at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97090

--- Comment #9 from seurer at gcc dot gnu.org ---
I saw

FAIL: gcc.dg/analyzer/malloc-vs-local-1b.c  (test for bogus messages, line 170)

on a make check for 66dde7bc64b75d4a338266333c9c490b12d49825, r11-5583 just
moments ago on a powerpc64 BE box.

I reran just that test and it failed 3 times in a row.

Looking back at the logs on this machine it's failed on and off since r11-4323
(run on 23 October).

[Bug analyzer/97090] gcc.dg/analyzer/malloc-vs-local-1b.c fails on arm and powerpc64*-linux-gnu

2020-10-28 Thread dmalcolm at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97090

--- Comment #8 from David Malcolm  ---
I tested with a cross build on x86_64-pc-linux-gnu with
target==powerpc64-unknown-linux-gnu after various fixes for non-determinism
(g:f635f0ce87d687b177b734968f18226d50499e75) and I'm not seeing the bogus
diagnostic at line 170.

I ran 100 iterations (with address-space randomization enabled), via this
script:

SRC_DIR=$(dirname $1)
FILENAME=$(basename $1)
rm $FILENAME.*
for i in `seq 1 100`; do
echo "iteration: $i"
./xgcc -B. -fanalyzer -c $SRC_DIR/$FILENAME -m64  
-fdiagnostics-plain-output   -fanalyzer -Wanalyzer-too-complex
-fanalyzer-call-summaries -fdump-analyzer -fanalyzer-call-summaries -S
-fdump-analyzer-supergraph -fdump-analyzer-exploded-graph -fdump-analyzer
-fdump-noaddr -fdump-analyzer-exploded-nodes-2
mv $FILENAME.supergraph.dot $FILENAME.$i.supergraph.dot
mv $FILENAME.analyzer.txt $FILENAME.$i.analyzer.txt
mv $FILENAME.supergraph-eg.dot $FILENAME.$i.supergraph-eg.dot
mv $FILENAME.eg.txt $FILENAME.$i.eg.txt
mv $FILENAME.eg.dot $FILENAME.$i.eg.dot
done

md5sum $FILENAME.* | sort | less

and got identical md5sums for every iteration of each of the various logs.

So perhaps the determinism fixes have removed flakiness from this test.

Is anyone still seeing that test failure on any configuration, after
g:f635f0ce87d687b177b734968f18226d50499e75 ?

(I still need to investigate the other failures reported by Jakub in comment
#3)

[Bug analyzer/97090] gcc.dg/analyzer/malloc-vs-local-1b.c fails on arm and powerpc64*-linux-gnu

2020-10-28 Thread dmalcolm at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97090

--- Comment #7 from David Malcolm  ---
*** Bug 97411 has been marked as a duplicate of this bug. ***

[Bug analyzer/97090] gcc.dg/analyzer/malloc-vs-local-1b.c fails on arm and powerpc64*-linux-gnu

2020-10-28 Thread dmalcolm at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97090

--- Comment #6 from David Malcolm  ---
(In reply to Christophe Lyon from comment #1)
> I see random results from one run to another, so it's likely that something
> is not initialized correctly.
I think it's due to places in -fanalyzer that iterate though hash_map and
hash_set, that are thus implicitly relying on the ordering and thus on specific
pointer values.  Address-space randomization thus introduces a random element.

I've landed some fixes for this in master recently, and am testing some more
(sorting every time I use the results of such an iteration).

[Bug analyzer/97090] gcc.dg/analyzer/malloc-vs-local-1b.c fails on arm and powerpc64*-linux-gnu

2020-10-28 Thread dmalcolm at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97090

--- Comment #5 from David Malcolm  ---
PR 97621 reports it as starting on powerpc64*-linux-gnu with r11-4434, which
was a fix for non-determinism in -fanalyzer, so perhaps this is a flaky test
that the non-determinism fixes have made fail more reliably (which comment #1
suggests as well).

[Bug analyzer/97090] gcc.dg/analyzer/malloc-vs-local-1b.c fails on arm and powerpc64*-linux-gnu

2020-10-28 Thread dmalcolm at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97090

David Malcolm  changed:

   What|Removed |Added

 CC||seurer at gcc dot gnu.org

--- Comment #4 from David Malcolm  ---
*** Bug 97621 has been marked as a duplicate of this bug. ***

[Bug analyzer/97090] gcc.dg/analyzer/malloc-vs-local-1b.c fails on arm

2020-09-18 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97090

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
I see on i686-linux:
XPASS: gcc.dg/analyzer/feasibility-1.c  (test for warnings, line 58)
FAIL: gcc.dg/analyzer/malloc-vs-local-1b.c  (test for bogus messages, line 170)
FAIL: gcc.dg/analyzer/pr96713.c (test for excess errors)
XPASS: gcc.dg/analyzer/unknown-fns-4.c  (test for warnings, line 13)
but none of this on x86_64-linux.

[Bug analyzer/97090] gcc.dg/analyzer/malloc-vs-local-1b.c fails on arm

2020-09-18 Thread clyon at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97090

Christophe Lyon  changed:

   What|Removed |Added

 Target|arm |arm aarch64

--- Comment #2 from Christophe Lyon  ---
Saw it on aarch64 cross-compiler too, if that's easier to reproduce.

[Bug analyzer/97090] gcc.dg/analyzer/malloc-vs-local-1b.c fails on arm

2020-09-18 Thread clyon at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97090

--- Comment #1 from Christophe Lyon  ---
I see random results from one run to another, so it's likely that something is
not initialized correctly.