[Bug tree-optimization/119718] __attribute__((musttail)) affects whether -foptimize-tail-calls will in fact optimize a tail call

2025-04-12 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119718 --- Comment #16 from lucier at math dot purdue.edu --- I'm sorry, I don't understand how to get the information from the recent changes https://gcc.gnu.org/cgit/gcc/commit/?id=0562e17bd04b65aebff4721db05631b9f34af146 and https://gcc.gnu.org/cgit/

[Bug tree-optimization/119718] __attribute__((musttail)) affects whether -foptimize-tail-calls will in fact optimize a tail call

2025-04-11 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119718 --- Comment #13 from lucier at math dot purdue.edu --- This is the change I made to report warnings when was maybe_complain_about_tail_call called: heine:~/programs/gcc/gcc-mainline/gcc> git diff diff --git a/gcc/calls.cc b/gcc/calls.cc index b3

[Bug tree-optimization/119718] __attribute__((musttail)) affects whether -foptimize-tail-calls will in fact optimize a tail call

2025-04-11 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119718 --- Comment #12 from lucier at math dot purdue.edu --- (In reply to Jakub Jelinek from comment #7) > We can't just warn on all calls, most of them obviously aren't in tail call > positions and such warning would have extreme amounts of false posi

[Bug tree-optimization/119718] __attribute__((musttail)) affects whether -foptimize-tail-calls will in fact optimize a tail call

2025-04-10 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119718 --- Comment #8 from lucier at math dot purdue.edu --- What I have in mind is along the lines of the patch I proposed here: https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626368.html That adds a warning to -Wdisabled-optimization for when

[Bug tree-optimization/119718] __attribute__((musttail)) affects whether -foptimize-tail-calls will in fact optimize a tail call

2025-04-10 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119718 --- Comment #6 from lucier at math dot purdue.edu --- Thank you for the detailed explanation. What initially got me investigating this is that (a) these tail calls were not optimized by GCC 14 and I got segfaults, so (b) I added musttail and t

[Bug tree-optimization/119718] __attribute__((musttail)) affects whether -foptimize-tail-calls will in fact optimize a tail call

2025-04-10 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119718 --- Comment #3 from lucier at math dot purdue.edu --- Originally I understood musttail to be "It's crucial that this call be optimized, fail and tell me why if you can't do it", without changing whether a call is optimized. (This is always assum

[Bug tree-optimization/119718] __attribute__((musttail)) affects whether -foptimize-tail-calls will in fact optimize a tail call

2025-04-10 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119718 --- Comment #1 from lucier at math dot purdue.edu --- Created attachment 61068 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61068&action=edit test file This is the file with the single incident of __attribute__((musttail)). If you remov

[Bug tree-optimization/119718] New: __attribute__((musttail)) affects whether -foptimize-tail-calls will in fact optimize a tail call

2025-04-10 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119718 Bug ID: 119718 Summary: __attribute__((musttail)) affects whether -foptimize-tail-calls will in fact optimize a tail call Product: gcc Version: 15.0

[Bug ipa/119376] [15 Regression] musttail does not get dropped after inlining?

2025-04-09 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119376 --- Comment #35 from lucier at math dot purdue.edu --- (In reply to Jakub Jelinek from comment #34) > (In reply to lucier from comment #33) > > It is my understanding that with the set of patches related to this PR, GCC > > 15 with -foptimize-ta

[Bug ipa/119376] [15 Regression] musttail does not get dropped after inlining?

2025-04-09 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119376 --- Comment #33 from lucier at math dot purdue.edu --- Sorry, I screwed up and fired off my comment before it was finished. Here's the rest: (c) With today's GCC mainline head, those tail calls *are* optimized, as confirmed with the musttail at

[Bug ipa/119376] [15 Regression] musttail does not get dropped after inlining?

2025-04-09 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119376 lucier at math dot purdue.edu changed: What|Removed |Added CC||feeley at iro dot umontre

[Bug c/116545] Support old style statement attributes

2025-03-13 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116545 --- Comment #10 from lucier at math dot purdue.edu --- (In reply to Jakub Jelinek from comment #7) > Created attachment 60738 [details] > gcc15-pr116545.patch > > Full untested patch. I built and minimally tested this patch, and will upload the

[Bug c/116545] Support old style statement attributes

2025-03-13 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116545 --- Comment #11 from lucier at math dot purdue.edu --- Created attachment 60745 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60745&action=edit Test summary

[Bug c/116545] Support old style statement attributes

2025-03-13 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116545 --- Comment #8 from lucier at math dot purdue.edu --- (In reply to Jakub Jelinek from comment #7) > Created attachment 60738 [details] > gcc15-pr116545.patch > > Full untested patch. I don't know how to apply this patch to the git checked-out s

[Bug c/116545] Support old style statement attributes

2025-03-12 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116545 --- Comment #6 from lucier at math dot purdue.edu --- (In reply to Jakub Jelinek from comment #4) > > does that for C. I built mainline with these changes, and the resulting compiler builds Gambit without complaint or error. I'm now running ma

[Bug c/116545] Support old style statement attributes

2025-03-12 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116545 --- Comment #1 from lucier at math dot purdue.edu --- A pre-release of GCC 15 is now in Fedora Rawhide, and building Gambit Scheme fails with this issue: https://github.com/gambit/gambit/issues/949

[Bug c/83324] [feature request] Pragma or special syntax for guaranteed tail calls

2024-08-25 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83324 --- Comment #33 from lucier at math dot purdue.edu --- I don't know what the issues are about whether to support __attribute__, whether the notation is obsolete or nonstandard. If gcc doesn't support this notation, it might lead to just one more

[Bug c/83324] [feature request] Pragma or special syntax for guaranteed tail calls

2024-08-24 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83324 --- Comment #31 from lucier at math dot purdue.edu --- Are there plans to support the __attribute__((musttail)) notation for C code? It appears that with heine:~/programs/gambit/gambit> clang -v Ubuntu clang version 14.0.0-1ubuntu1.1 one needs

[Bug c/83324] [feature request] Pragma or special syntax for guaranteed tail calls

2024-08-23 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83324 --- Comment #30 from lucier at math dot purdue.edu --- Thanks. I asked for some help in testing this new attribute at gcc-help: https://gcc.gnu.org/pipermail/gcc-help/2024-August/143676.html

[Bug c/83324] [feature request] Pragma or special syntax for guaranteed tail calls

2024-08-21 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83324 lucier at math dot purdue.edu changed: What|Removed |Added CC||lucier at math dot purdue.

[Bug middle-end/64928] [11 Regression] Inordinate cpu time and memory usage in "phase opt and generate" with -ftest-coverage -fprofile-arcs

2023-10-01 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64928 --- Comment #45 from lucier at math dot purdue.edu --- I confirm that I no longer have this problem with > gcc-12 -v Using built-in specs. COLLECT_GCC=gcc-12 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper OFFLOAD_TARGET_NAMES=nv

[Bug tree-optimization/26854] Inordinate compile times on large routines

2023-02-08 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854 --- Comment #146 from lucier at math dot purdue.edu --- Here are a few memory and time statistics picked from report-compiler4 that seem to be more extreme than the others: -

[Bug tree-optimization/26854] Inordinate compile times on large routines

2023-02-07 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854 --- Comment #145 from lucier at math dot purdue.edu --- Created attachment 54424 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54424&action=edit CPU and Memory usage reports for mainline 13.0.1 (mainline) Thank you for looking at this issu

[Bug tree-optimization/26854] Inordinate compile times on large routines

2021-12-17 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854 --- Comment #141 from lucier at math dot purdue.edu --- Created attachment 52027 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52027&action=edit CPU and Memorty usage reports for compilling all.i, _num.i, and compiler.i

[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign

2021-12-17 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446 --- Comment #17 from lucier at math dot purdue.edu --- (In reply to lucier from comment #16) > Created attachment 52026 [details] > CPU and Memorty usage reports for compilling all.i, _num.i, and compiler.i Sorry, added comment to wrong PR.

[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign

2021-12-17 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446 --- Comment #16 from lucier at math dot purdue.edu --- Created attachment 52026 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52026&action=edit CPU and Memorty usage reports for compilling all.i, _num.i, and compiler.i

[Bug tree-optimization/26854] Inordinate compile times on large routines

2021-12-17 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854 --- Comment #140 from lucier at math dot purdue.edu --- (In reply to Andrew Pinski from comment #139) > Does anyone have recent #s on this testcase? I downloaded all.i.gz from https://www.math.purdue.edu/~lucier/gcc/test-files/bugzilla/1/ and _

[Bug target/100152] [10 Regression] used caller-saved register not preserved across a call.

2021-07-22 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #58 from lucier at math dot purdue.edu --- Thanks. Brad

[Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.

2021-05-12 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #54 from lucier at math dot purdue.edu --- After an update to Fink's dejagnu, I got similar results.

[Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.

2021-05-09 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #51 from lucier at math dot purdue.edu --- I'm running fink: i expect 5.45-206Tool for automatic interactive applications i dejagnu 1.6.1-1 Framework for testing other programs i tcltk 1:8.6.10-2 Too

[Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.

2021-05-09 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #49 from lucier at math dot purdue.edu --- > > and "make; make -k check". > > Which, presumably, succeeded [repeatably?] (also presumably with some > failing tests, since we don't have a clean testsuite on macOS). It gave reasonab

[Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.

2021-05-08 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #47 from lucier at math dot purdue.edu --- I downloaded [Bradleys-Mac-mini:~/programs/gcc/gcc-mainline] lucier% git log -1 --oneline 2254b3233b5 (HEAD -> master, origin/trunk, origin/master, origin/HEAD) PR middle-end/100325 - missin

[Bug target/100152] [10.3, 11, 12 Regression] [Darwin, X86] used caller-saved register not preserved across a call.

2021-04-22 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #25 from lucier at math dot purdue.edu --- Thanks, I'll just use an older compiler for building Gambit.

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

2021-04-21 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #23 from lucier at math dot purdue.edu --- With the mainline compiler git log -1 --oneline 0c0bdcc60cf (HEAD -> master, origin/trunk, origin/master, origin/HEAD) libgomp.fortran/depobj-1.f90: Fix omp_depend_kind the Gambit build run

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

2021-04-21 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #18 from lucier at math dot purdue.edu --- I can't see to build mainline on this machine, it fails with ../../../gcc-mainline/gcc/rtl.h:4547:42: error: use of undeclared identifier 'TARGET_ISA_64BIT' && GET_MODE_PRECISION (int_

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

2021-04-21 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #16 from lucier at math dot purdue.edu --- I have figured out how to build and then run the app in lldb to reliably reproduce the error. To configure and build Gambit, the Scheme->C compiler: 51 8:56mkdir gambit-test 52

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

2021-04-20 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #13 from lucier at math dot purdue.edu --- (In reply to Iain Sandoe from comment #8) > the values of rbp. r10 and esi would be interesting too. I'm not really familiar with assembler, don't know what register esi is, here's what lldb

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

2021-04-20 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #12 from lucier at math dot purdue.edu --- (In reply to Iain Sandoe from comment #11) > is this specific to macOS? (or is it unknown if the effect would also show > on Linux)? It does not show up on Linux with gcc-10.3.0. I forgot

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

2021-04-20 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #10 from lucier at math dot purdue.edu --- (In reply to Iain Sandoe from comment #8) > (In reply to lucier from comment #7) > > (In reply to Iain Sandoe from comment #6) > > > > > yes please - also the original source, if that's OK?

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

2021-04-20 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #9 from lucier at math dot purdue.edu --- (In reply to Iain Sandoe from comment #8) > (In reply to lucier from comment #7) > > (In reply to Iain Sandoe from comment #6) > > > > > yes please - also the original source, if that's OK? >

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

2021-04-20 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #7 from lucier at math dot purdue.edu --- (In reply to Iain Sandoe from comment #6) > yes please - also the original source, if that's OK? It's highly macrofied C code with a lot of "includes"; is the .i file not enough? Brad

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

2021-04-20 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #5 from lucier at math dot purdue.edu --- I didn't have this trouble with 10.2 or 9.3; should I add these to the "Known to work" field?

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

2021-04-20 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #2 from lucier at math dot purdue.edu --- Created attachment 50639 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50639&action=edit Gzipped assembly file

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

2021-04-20 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #1 from lucier at math dot purdue.edu --- Created attachment 50638 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50638&action=edit preprocessed source file

[Bug target/100152] New: Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

2021-04-20 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 Bug ID: 100152 Summary: Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina) Product: gcc Version: 10.3.0 Status: UNCONFIRMED

[Bug middle-end/64928] [8/9/10/11 Regression] Inordinate cpu time and memory usage in "phase opt and generate" with -ftest-coverage -fprofile-arcs

2021-03-10 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64928 --- Comment #37 from lucier at math dot purdue.edu --- Created attachment 50352 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50352&action=edit Smaller parameterized test file This file is generated from a single copy of the fibonacci func

[Bug middle-end/64928] [8/9/10/11 Regression] Inordinate cpu time and memory usage in "phase opt and generate" with -ftest-coverage -fprofile-arcs

2021-03-09 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64928 --- Comment #35 from lucier at math dot purdue.edu --- Created attachment 50345 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50345&action=edit Parametrized input files for test coverage testing. These are the .i files that go with my prev

[Bug middle-end/64928] [8/9/10/11 Regression] Inordinate cpu time and memory usage in "phase opt and generate" with -ftest-coverage -fprofile-arcs

2021-03-09 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64928 --- Comment #34 from lucier at math dot purdue.edu --- I decided to approach this a bit more methodically by generating a series of synthetic programs, each twice as long as the previous, and to measure the compilation time. I'll attach the assoc

[Bug middle-end/64928] [8/9/10/11 Regression] Inordinate cpu time and memory usage in "phase opt and generate" with -ftest-coverage -fprofile-arcs

2020-09-29 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64928 --- Comment #32 from lucier at math dot purdue.edu --- I don't know precisely what you're saying, but it compiles fine without the instrumentation.

[Bug middle-end/64928] [8/9/10/11 Regression] Inordinate cpu time and memory usage in "phase opt and generate" with -ftest-coverage -fprofile-arcs

2020-09-28 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64928 --- Comment #30 from lucier at math dot purdue.edu --- I'm coming back to this project. I naively thought "Well, I don't need arc profiling, I'll just set -ftest-coverage without -fprofile-arcs" but it appears that I can't do that, the gcda files