| Summary: | ASTERISK-28792: codec_gsm: while building, optimization flag is overwritten | ||
| Reporter: | Alexander Traud (traud) | Labels: | |
| Date Opened: | 2020-03-26 06:27:25 | Date Closed: | |
| Priority: | Minor | Regression? | |
| Status: | Open/New | Components: | Codecs/codec_gsm Core/BuildSystem |
| Versions: | 13.32.0 16.9.0 17.3.0 | Frequency of Occurrence | |
| Related Issues: | |||
| Environment: | Attachments: | ||
| Description: | Because of ASTERISK-28374, I found this issue here.
With the Compiler Flag DONT_OPTIMIZE is enabled, Clang erred while compiling the file {{codecs/gsm/src/add.c}}. This happens, because the {{Makefile}} in the directory {{codecs/gsm}} checks for a specific GCC version as well. That check works correctly. However, the variable name OPTIMIZE is re-used. Because of that, the value of OPTIMIZE from the default {{Makefile.rules}} is used (even when DONT_OPTIMIZE is enabled). Consequently, this is not a Clang specific issue but also affects GCC. The related issues reports are: * Mantis 17688 (now ASTERISK-16408) * Mantis 11243 (now ASTERISK-10762) * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34216 The easy fix would be to change the names of those two OPTIMIZE (and the hope that -O0 -O3 gets -O0). The correct fix would be to investigate that GCC -O3 issue finally and possibly remove that compiler switch completely. Not sure what to do. Therefore, I am just reporting this actual 13 year old software bug. Because ASTERISK-28374 is now fixed, the issue here is a no-care actually. | ||
| Comments: | By: Asterisk Team (asteriskteam) 2020-03-26 06:27:26.444-0500 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur. By: Benjamin Keith Ford (bford) 2020-03-27 10:28:26.593-0500 What versions of {{clang}} / {{gcc}} are you running? By: Alexander Traud (traud) 2020-03-27 11:48:01.161-0500 Should not matter as it affects all versions never than GCC 4.2. Anyway, I am on Ubuntu 19.10 with the default compilers: * clang 9.0.0 * gcc 9.2.1 By: Alexander Traud (traud) 2020-04-16 03:22:36.252-0500 Mhm. I re-ran the whole code with {{NOISY_BUILD=yes ./configure}}. Actually, that Makefile check affects just GCC 4.2, only that specific version. Consequently, this issue does not need deeper analysis. The problem is just the name clash ‘OPTIMIZE’. GSM is build with -O3, always. When DONT_OPTIMIZE is active, GSM is build with -O0 -O3. By: Alexander Traud (traud) 2020-05-28 05:31:38.802-0500 bq. hope that -O0 -O3 gets -O0 Yes and no. The GCC documentation [states|https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html]: ‘If you use multiple -O options \[…\] the last such option is the one that is effective.’ Hopefully, this is true for other compilers. Anyway, Asterisk is appending the top-level optimization level again, resulting in three optimization flags. Is that another issue or intended? Okay, let me summarize: * GCC 4.2 is given -Oi -O2 -Oi * all other versions and compilers get -Oi -O3 -Oi A) Let us assume that third -Oi is intended. Then we have two issues: # OPTIMIZE from the top Makefile is given to GCC, regardless of the state of DONT_OPTIMIZE # that special handling of GCC 4.2 does not work at all because GCC uses the last -Oi B) Let us assume that third -Oi is *not* intended. Then we have two issues: # OPTIMIZE from the top Makefile is given to GCC, regardless of the state of DONT_OPTIMIZE # that additional = third -Oi | ||