[Bug tree-optimization/108500] [11/12 Regression] -O -finline-small-functions results in "internal compiler error: Segmentation fault" on a very large program (700k function calls)

2023-02-02 Thread dhekir at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108500 --- Comment #17 from dhekir at gmail dot com --- To be honest, the "real" test case is very similar to the last one I sent: it's a semi-generated code, with some initialization of the data in the beginning, and then a lot of statem

[Bug tree-optimization/108500] [11/12 Regression] -O -finline-small-functions results in "internal compiler error: Segmentation fault" on a very large program (700k function calls)

2023-02-01 Thread dhekir at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108500 --- Comment #13 from dhekir at gmail dot com --- Thank you very much for the work. Running the attached file with `-O -finline-small-functions` does compile in under 30 seconds on my computer. However, when trying to compile the original

[Bug tree-optimization/108500] [11/12 Regression] -O -finline-small-functions results in "internal compiler error: Segmentation fault" on a very large program (700k function calls)

2023-02-01 Thread dhekir at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108500 --- Comment #12 from dhekir at gmail dot com --- Created attachment 54386 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54386=edit another test case, this time with 1M calls and structs as arguments A more complex test case, which st

[Bug c/108500] -O -finline-small-functions results in "internal compiler error: Segmentation fault" on a very large program (700k function calls)

2023-01-23 Thread dhekir at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108500 dhekir at gmail dot com changed: What|Removed |Added Attachment #54328|0 |1 is obsolete

[Bug c/108500] New: -O -finline-small-functions results in "internal compiler error: Segmentation fault" on a very large program (700k function calls)

2023-01-23 Thread dhekir at gmail dot com via Gcc-bugs
oduct: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dhekir at gmail dot com Target Milestone: --- Created attachment 54328 --> https:

[Bug preprocessor/78008] New: Forbid or document #pragma pack(0)

2016-10-17 Thread dhekir at gmail dot com
Assignee: unassigned at gcc dot gnu.org Reporter: dhekir at gmail dot com Target Milestone: --- The GCC online doc (https://gcc.gnu.org/onlinedocs/gcc/Structure-Layout-Pragmas.html) says that #pragma pack is supported for compatibility with MS compilers. However, the MSVC doc

[Bug c/66736] New: float rounding differences when using constant literal versus variable

2015-07-02 Thread dhekir at gmail dot com
Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dhekir at gmail dot com Target Milestone: --- Calling function log10f(3) with a constant literal or via a variable, such as float f = 3; log10f(f) gives different rounding results

[Bug c/66736] float rounding differences when using constant literal versus variable

2015-07-02 Thread dhekir at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66736 --- Comment #2 from dhekir at gmail dot com --- Isn't the library implementation of log10f used to compute the literal constants generated in the assembly code? Would it then be a double precision result that would be precomputed and rounded