[Bug target/77333] Incorrect stack adjust in epilogue when targeting i686-w64-mingw32

2017-02-20 Thread tony at kelman dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77333

--- Comment #19 from Tony Kelman  ---
The patch also applies and fixes the problem on the gcc-5-branch. I haven't
tried with trunk.

[Bug target/77333] Incorrect stack adjust in epilogue when targeting i686-w64-mingw32

2017-02-17 Thread tony at kelman dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77333

--- Comment #18 from Tony Kelman  ---
Sorry for the delay in getting to trying out your patch. Yes, it looks like it
does fix the test case here when applied to the gcc 6 branch.

Can running the test suite provide meaningful information from a cross-compile
build?

[Bug target/77333] Incorrect stack adjust in epilogue when targeting i686-w64-mingw32

2017-01-27 Thread tony at kelman dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77333

--- Comment #15 from Tony Kelman  ---
Created attachment 40608
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40608=edit
smaller copy of SLPVectorizer.cpp that reproduces issue

[Bug target/77333] Incorrect stack adjust in epilogue when targeting i686-w64-mingw32

2017-01-27 Thread tony at kelman dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77333

--- Comment #14 from Tony Kelman  ---
I'll look into whether the same flag changes the behavior in the same way on
gcc 5.

Using the opensuse repo's current cross compiler version, I reduced
SLPVectorizer.cpp down to the attached version. It's maybe so small that
there's UB making it useless to look at, but replacing SLPVectorizer.cpp with
this copy reproduces the known-good behavior with -fno-ipa-cp and the segfault
without.

[Bug target/77333] Incorrect stack adjust in epilogue when targeting i686-w64-mingw32

2017-01-25 Thread tony at kelman dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77333

--- Comment #12 from Tony Kelman  ---
Output of dump options uploaded here (8.2 MB file):
https://github.com/tkelman/docker-gcc-bisect/raw/07f6fa56e2f6d60ff90613b9c036f830fb8a422a/LLVMVectorize.tar.gz

[Bug target/77333] Incorrect stack adjust in epilogue when targeting i686-w64-mingw32

2017-01-25 Thread tony at kelman dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77333

--- Comment #11 from Tony Kelman  ---
Thank you!

-fno-devirtualize on its own did not help.

-fno-ipa-cp on its own did fix the problem.

Adding -fno-ipa-cp only when compiling
lib/Transforms/Vectorize/SLPVectorizer.cpp was enough to fix the problem.
Adding -fsanitize-undefined-trap-on-error as well for that same file didn't
make a difference.

I can post dump output for compiling that same file, if that's what you meant.

In terms of whether or not this is caused by undefined behavior in the source
being compiled, the commit
https://github.com/llvm-mirror/llvm/commit/225dd82d634ca277 made a small
modification to the file in question that prevented the problem from
manifesting. If anything jumps out at you as being definitely undefined
behavior prior to that commit, then we could look into carrying that patch, but
it's very strange that this only happens with this one particular target. That
commit was even intended to not be changing any behavior except when a
newly-added feature is used.

[Bug target/77333] Incorrect stack adjust in epilogue when targeting i686-w64-mingw32

2017-01-19 Thread tony at kelman dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77333

--- Comment #9 from Tony Kelman  ---
How can we help get this moving towards resolution? This has kept us stuck on
GCC 4.9, which is getting increasingly problematic. We can attempt to reduce
this to "minimal working piece of opt.exe with gcc 4.9" vs "broken equivalent
piece with gcc 5+," but given the IPA nature of r217587 I'm not sure how that
will go.

[Bug target/77333] Incorrect stack adjust in epilogue when targeting i686-w64-mingw32

2016-09-09 Thread tony at kelman dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77333

--- Comment #8 from Tony Kelman  ---
`git grep -n deriviz` returns nothing anywhere in the gcc source code
and -fno-derivization gives an error: unrecognized command line option.

[Bug target/77333] Incorrect stack adjust in epilogue when targeting i686-w64-mingw32

2016-09-09 Thread tony at kelman dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77333

--- Comment #6 from Tony Kelman  ---
Created attachment 39590
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39590=edit
bisect-log.txt

[Bug target/77333] Incorrect stack adjust in epilogue when targeting i686-w64-mingw32

2016-09-09 Thread tony at kelman dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77333

--- Comment #5 from Tony Kelman  ---
Created attachment 39589
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39589=edit
bisect-run.sh

[Bug target/77333] Incorrect stack adjust in epilogue when targeting i686-w64-mingw32

2016-09-09 Thread tony at kelman dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77333

--- Comment #4 from Tony Kelman  ---
I managed to bisect this to SVN revision 217587 by
Martin Jambor  using the attached
Dockerfile and bisect-run.sh. This was cross-compiling
from openSUSE 42.1 which happened to have most of the
build-deps easily available but should be reproducible
with a cross-compiler most places you can get wine.

[Bug target/77333] Incorrect stack adjust in epilogue when targeting i686-w64-mingw32

2016-09-09 Thread tony at kelman dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77333

--- Comment #3 from Tony Kelman  ---
Created attachment 39588
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39588=edit
Dockerfile

[Bug c/71505] -O3 internal compiler error in vect_analyze_data_ref_accesses, at tree-vect-data-refs.c:2596

2016-06-11 Thread tony at kelman dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71505

--- Comment #2 from Tony Kelman  ---
Created attachment 38689
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38689=edit
other local minima from creduce - 2

[Bug c/71505] -O3 internal compiler error in vect_analyze_data_ref_accesses, at tree-vect-data-refs.c:2596

2016-06-11 Thread tony at kelman dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71505

--- Comment #1 from Tony Kelman  ---
Created attachment 38688
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38688=edit
other local minima from creduce - 1

[Bug c/71505] New: -O3 internal compiler error in vect_analyze_data_ref_accesses, at tree-vect-data-refs.c:2596

2016-06-11 Thread tony at kelman dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71505

Bug ID: 71505
   Summary: -O3 internal compiler error in
vect_analyze_data_ref_accesses, at
tree-vect-data-refs.c:2596
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tony at kelman dot net
  Target Milestone: ---

Created attachment 38687
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38687=edit
cholmod_updown.i

This is in Alpine Linux - I can provide a Docker container and/or the
pre-reduced test case if it would help. Works at -O2, errors at -O3.


gcc -v -O3 -c cholmod_updown.i

Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64-alpine-linux-musl
Configured with: /home/buildozer/aports/main/gcc/src/gcc-5.3.0/configure
--prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info
--build=x86_64-alpine-linux-musl --host=x86_64-alpine-linux-musl
--target=x86_64-alpine-linux-musl --with-pkgversion='Alpine 5.3.0'
--enable-checking=release --disable-fixed-point --disable-libstdcxx-pch
--disable-multilib --disable-nls --disable-werror --disable-symvers
--enable-__cxa_atexit --enable-esp --enable-cloog-backend
--enable-languages=c,c++,objc,java,fortran,ada --disable-libssp
--disable-libmudflap --disable-libsanitizer --enable-shared --enable-threads
--enable-tls --with-system-zlib
Thread model: posix
gcc version 5.3.0 (Alpine 5.3.0) 
COLLECT_GCC_OPTIONS='-v' '-O3' '-c' '-mtune=generic' '-march=x86-64' '-fPIE'
'-pie' '-fstack-protector-strong'
 /usr/libexec/gcc/x86_64-alpine-linux-musl/5.3.0/cc1 -fpreprocessed
cholmod_updown.i -fno-strict-overflow -quiet -dumpbase cholmod_updown.i
-mtune=generic -march=x86-64 -auxbase cholmod_updown -O3 -version -fPIE
-fstack-protector-strong -o /tmp/cchiEaiB.s
GNU C11 (Alpine 5.3.0) version 5.3.0 (x86_64-alpine-linux-musl)
compiled by GNU C version 5.3.0, GMP version 6.1.0, MPFR version 3.1.2,
MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C11 (Alpine 5.3.0) version 5.3.0 (x86_64-alpine-linux-musl)
compiled by GNU C version 5.3.0, GMP version 6.1.0, MPFR version 3.1.2,
MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: a4d39a24f4e8cf2c8d4e626e52fac5ce
cholmod_updown.i: In function 'fn1':
cholmod_updown.i:4:6: internal compiler error: in
vect_analyze_data_ref_accesses, at tree-vect-data-refs.c:2596
 void fn1() {
  ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

[Bug target/66655] [5/6 Regression] miscompilation due to ipa-ra on MinGW

2016-01-20 Thread tony at kelman dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655

--- Comment #13 from Tony Kelman  ---
Should this change be for ming-but-not-cyg then?

[Bug target/66655] [5/6 Regression] miscompilation due to ipa-ra on MinGW

2016-01-01 Thread tony at kelman dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655

Tony Kelman  changed:

   What|Removed |Added

 CC||tony at kelman dot net

--- Comment #6 from Tony Kelman  ---
I applied Nick's patch to OpenSUSE's build of mingw64-gcc 5.3.0 here:
https://build.opensuse.org/package/show/home:kelman:branches:windows:mingw:win64/mingw64-gcc

And the resulting build did not exhibit the abort in the original test case,
whereas the unpatched build at
https://build.opensuse.org/package/show/windows:mingw:win64/mingw64-gcc does
reproduce the abort.

[Bug c++/60850] pedantic warning behavior when casting void* to ptr-to-func

2014-07-28 Thread tony at kelman dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60850

--- Comment #9 from Tony Kelman tony at kelman dot net ---
Sure. In a configure.ac, (in this case using autoconf 2.59, not sure the most
recent version for which this applies) a macro like

AC_CHECK_DECL([rand],[AC_DEFINE([HAVE_RAND],[1],
[Define to 1 if function rand is
available])],,[
#ifdef HAVE_CSTDLIB
# include cstdlib
#else
# ifdef HAVE_STDLIB_H
#  include stdlib.h
# endif
#endif
])

expands into a probe that looks like this (plus the above includes)

int
main ()
{
#ifndef rand
  char *p = (char *) rand;
#endif

  ;
  return 0;
}

This compiles successfully (with a warning ISO C++ forbids casting between
pointer-to-function and pointer-to-object [enabled by default], but autoconf
cares more about the exit code) when -pedantic-errors is given with GCC 4.8.2,
and every other released GCC version I'm aware of, except that it errors with
4.8.3. The message with 4.8.3 is the same, but now it's an error and listed as
[-Werror=pedantic], and cc1plus reports some warnings being treated as
errors.

The new behavior is arguably more correct, but has unfortunate consequences
with respect to backwards-compatibility.


[Bug c++/60850] pedantic warning behavior when casting void* to ptr-to-func

2014-07-25 Thread tony at kelman dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60850

Tony Kelman tony at kelman dot net changed:

   What|Removed |Added

 CC||tony at kelman dot net

--- Comment #7 from Tony Kelman tony at kelman dot net ---
Applying this change has made GCC 4.8.3 unusable for a large body of legacy
code. Not good for a patch release. Anything that uses old versions of autoconf
where the AC_CHECK_DECL probe used exactly this kind of cast, and has
-pedantic-errors in its CFLAGS, now gets completely different results from
configure, in many cases failing to build.

I realize the right solution is to update to a newer version of autoconf in
these cases, but there are many thousands of lines of custom autoconf macros
out there that make that much easier said than done. Or remove
-pedantic-errors, but that could lead to a different set of problems. As GCC
4.8.3 makes it into more distributions this is going to become a maintenance
burden, forcing a great deal of patching around the problem or recommending
users install different compiler versions than their default.