[Bug target/80833] 32-bit x86 causes store-forwarding stalls for int64_t -> xmm

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80833 --- Comment #2 from Peter Cordes --- On most CPUs, psrldq / movd is optimal for xmm[1] -> int without SSE4. On SnB-family, movd runs on port0, and psrldq can run on port5, so they can execute in parallel. (And the second movd can run the next c

[Bug target/80833] 32-bit x86 causes store-forwarding stalls for int64_t -> xmm

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80833 --- Comment #3 from Peter Cordes --- Atom's movd xmm->int is slower (lat=4, rtput=2) than its movd int->xmm (lat=3, rtput=1), which is opposite of every other CPU (except Silvermont where they're the same throughput but xmm->int is 1c slower). S

[Bug target/80833] 32-bit x86 causes store-forwarding stalls for int64_t -> xmm

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80833 --- Comment #4 from Peter Cordes --- I don't think it's worth anyone's time to implement this in 2017, but using MMX regs for 64-bit store/load would be faster on really old CPUs that split 128b vectors insns into two halves, like K8 and Pentium

[Bug fortran/80610] Compiler crashes ungraciously when large static array is initialized with anything other than zero

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80610 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment

[Bug fortran/80610] Compiler crashes ungraciously when large static array is initialized with anything other than zero

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80610 --- Comment #13 from Steve Kargl --- On Sat, May 20, 2017 at 04:59:10AM +, jvdelisle at gcc dot gnu.org wrote: > > Yes that will take some frontend magic and we have so few people to support > gfortran (for free remember) that we may not be

[Bug c/78503] -Wint-in-bool-context false positive on unsigned multiplication

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78503 --- Comment #3 from Bernd Edlinger --- It is on purpose that the warning gets suppressed when "(N) != 0" or "(N) + 0" is used, so that won't go away. But may I suggest the following for the XALLOCAVEC macro: #define XALLOCAVEC(T, N) ((N) > 0 ?

[Bug driver/80828] Command line option -e not documented

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80828 --- Comment #1 from Andrew Pinski --- e Driver Joined Separate From binutils' ld man page: -e entry --entry=entry Use entry as the explicit symbol for beginning execution of your program, rather than the default entry po

[Bug middle-end/80824] Missing 'variable-is-used-uninitialized' warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80824 Andrew Pinski changed: What|Removed |Added Component|c |middle-end Blocks|

<    1   2