[Bug c++/96594] New: Compiled code behaves differently with -O1 and -O0 on s390x

Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mitya57 at gmail dot com Target Milestone: --- Created attachment 49050 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49050&action=edit Test case Hi, I was debugging Comp

[Bug c++/96594] Compiled code behaves differently with -O1 and -O0 on s390x

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96594 --- Comment #1 from Dmitry Shachnev --- Created attachment 49051 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49051&action=edit Assembly dump with -O0

[Bug c++/96594] Compiled code behaves differently with -O1 and -O0 on s390x

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96594 --- Comment #2 from Dmitry Shachnev --- Created attachment 49052 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49052&action=edit Assembly dump with -O1

[Bug c++/96594] Compiled code behaves differently with -O1 and -O0 on s390x

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96594 --- Comment #4 from Dmitry Shachnev --- Thanks a lot for the fast response! Indeed, your suggestion works. It is counter-intuitive that you need a 64-bit variable to store a 32-bit value, but I can see the rationale (long is the only standard ty

[Bug libstdc++/65434] New: Memory leak in pool constructor

++ Assignee: unassigned at gcc dot gnu.org Reporter: mitya57 at gmail dot com Constructor of `pool' class in eh_alloc.c has the following code: pool::pool() { // Allocate the arena - we could add a GLIBCXX_EH_ARENA_SIZE environment // to make this tunable. arena

[Bug libstdc++/65434] Memory leak in pool constructor

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65434 --- Comment #2 from Dmitry Shachnev --- Will anything bad happen if that memory is freed in the destructor? For me, the issue is mostly aesthetic — I got used to not seeing any Valgrind warnings in my programs :)

[Bug preprocessor/61918] New: With -isystem, symlinks are sometimes processed incorrectly

Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: mitya57 at gmail dot com Originally reported at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755767. Here is the minimal test case: $ ls -l correct lrwxrwxrwx 1 dmitry dmitry 16

[Bug preprocessor/61918] With -isystem, symlinks are sometimes processed incorrectly

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61918 Dmitry Shachnev changed: What|Removed |Added Known to work||4.7.4 Known to fail|

[Bug c/116122] New: [14 Regression]: __FLT16_MAX__ is defined even with -mno-sse2

Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: mitya57 at gmail dot com Target Milestone: --- According to https://gcc.gnu.org/onlinedocs/gcc/Half-Precision.html, “On x86 targets with SSE2 enabled, GCC supports half-precision (16-bit

[Bug target/116122] [14 Regression]: __FLT16_MAX__ is defined even with -mno-sse2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116122 --- Comment #2 from Dmitry Shachnev --- Yes, I forgot to mention that my command line examples are from 32-bit x86, and baseline for Debian’s i386 architecture is “no MMX nor SSE”: https://wiki.debian.org/ArchitectureSpecificsMemo#i386-1 And f