[Bug bootstrap/87252] gcc-4.4 cross-builds broken, apparently in self-tests

2020-04-05 Thread abrahm.scully at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87252 --- Comment #7 from Abrahm Scully --- I hit an ICE today that looks like this bug. I attempted to build gcc-10-20200329 on 32-bit CentOS 6 using g++ 4.4.7-23.el6. I don't see this bug building gcc-6.3, gcc-7.3, gcc-8.3, or gcc-9-20200118 on the s

[Bug bootstrap/87252] gcc-4.4 cross-builds broken, apparently in self-tests

2020-04-05 Thread abrahm.scully at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87252 --- Comment #8 from Abrahm Scully --- I don't think anything is wrong with gcc-10-20200329. The code looks fine. I realized later that the versions of gcc I mentioned where I don't see this problem are all from release branches. As described in

[Bug target/94494] New: gcc-10 unrecognizable insn

2020-04-05 Thread abrahm.scully at gmail dot com
Assignee: unassigned at gcc dot gnu.org Reporter: abrahm.scully at gmail dot com Target Milestone: --- with gcc-10-20200329 built on 32-bit CentOS 6, passing -m32 -march=pentium3 -mfpmath=sse -mstackrealign -O2 -ftree-vectorize -flto ... got the following. /build/file.cpp:1510:1: error

[Bug target/94494] gcc-10 unrecognizable insn

2020-04-10 Thread abrahm.scully at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94494 --- Comment #2 from Abrahm Scully --- Created attachment 48255 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48255&action=edit preprocessed source file With gcc-10-20200329, "g++ -Wall -ftree-vectorize -march=pentium3 -O2 -m32 -c illegal-

[Bug target/94494] gcc-10 unrecognizable insn

2020-04-10 Thread abrahm.scully at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94494 --- Comment #3 from Abrahm Scully --- Not sure if this is helpful, but "gcc -v" outputs: Reading specs from /opt/tools-20200401/lib/gcc/i686-pc-linux-gnu/10/specs COLLECT_GCC=/opt/tools-20200401/bin/gcc COLLECT_LTO_WRAPPER=/opt/tools-20200401/lib

[Bug bootstrap/87252] gcc-4.4 cross-builds broken, apparently in self-tests

2020-04-10 Thread abrahm.scully at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87252 --- Comment #9 from Abrahm Scully --- I'm no longer convinced that I didn't see the problem previously because I just wasn't running the tests. Stage 1 has checking enabled... so I don't know why this problem showed up for others in gcc 9 but not

[Bug target/94494] gcc-10 unrecognizable insn

2020-04-10 Thread abrahm.scully at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94494 --- Comment #5 from Abrahm Scully --- I can't comment on the patch's correctness, but applied to gcc-10-20200405 it does prevent the "unrecognizable insn" error.

[Bug target/93254] New: g++ -m32 -mfpmath=sse -msse generates sse2 instructions

2020-01-13 Thread abrahm.scully at gmail dot com
Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: abrahm.scully at gmail dot com Target Milestone: --- Created attachment 47648 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47648&action=edit preprocessed source file Running

[Bug target/93254] g++ -m32 -mfpmath=sse -msse generates sse2 instructions

2020-01-13 Thread abrahm.scully at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93254 --- Comment #2 from Abrahm Scully --- (In reply to Uroš Bizjak from comment #1) > The following patch that disables non-sse2 alternatives in *movsf_internal > should fix the issue: > Uroš, thank you for the quick help! The patch does appear to

[Bug c++/96720] ICE with* after include

2020-11-04 Thread abrahm.scully at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96720 Abrahm Scully changed: What|Removed |Added CC||abrahm.scully at gmail dot com

[Bug c++/96720] ICE with* after include

2020-11-05 Thread abrahm.scully at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96720 --- Comment #4 from Abrahm Scully --- I think this bug should have keyword ice-on-valid-code and not ice-on-invalid-code. The preprocessed source I attached to reproduce the issue does not have the stray '*' in the original reproducer.