[clang] [clang] LazyOffsetPtr: Use native pointer width (PR #111995)
thesamesam wrote: cc @glaubitz (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341) https://github.com/llvm/llvm-project/pull/111995 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [LLVM] [Clang] Support for Gentoo `*t64` triples (64-bit time_t ABIs) (PR #111302)
=?utf-8?q?Micha=C5=82_G=C3=B3rny?= , =?utf-8?q?Micha=C5=82_G=C3=B3rny?= Message-ID: In-Reply-To: https://github.com/thesamesam approved this pull request. https://github.com/llvm/llvm-project/pull/111302 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Driver][Sparc] Default to -mcpu=v9 for 32-bit Linux/sparc64 (PR #109278)
thesamesam wrote: (I'm fine with maskray's idea as well.) https://github.com/llvm/llvm-project/pull/109278 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Driver][Sparc] Default to -mcpu=v9 for 32-bit Linux/sparc64 (PR #109278)
https://github.com/thesamesam approved this pull request. https://github.com/llvm/llvm-project/pull/109278 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [libcxx] [lld] [lldb] [llvm] [mlir] [polly] python: use raw strings for regex (PR #105990)
https://github.com/thesamesam edited https://github.com/llvm/llvm-project/pull/105990 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [libcxx] [lld] [lldb] [llvm] [mlir] [polly] python: use raw strings for regex (PR #105990)
@@ -284,7 +284,7 @@ def sync_csv(rows: List[Tuple], from_github:
List[PaperInfo]) -> List[Tuple]:
results.append(gh.for_printing())
continue
elif paper.status != gh.status:
-print(f"We found a CSV row and a Github issue with different
statuses:\nrow: {row}\Github issue: {gh}")
+print(rf"We found a CSV row and a Github issue with different
statuses:\nrow: {row}\Github issue: {gh}")
thesamesam wrote:
I believe @negril is right.
Note that https://docs.python.org/3/whatsnew/3.12.html#other-language-changes
doesn't say it's exclusive to regex:
> A backslash-character pair that is not a valid escape sequence now generates
> a
> [SyntaxWarning](https://docs.python.org/3/library/exceptions.html#SyntaxWarning),
> instead of
> [DeprecationWarning](https://docs.python.org/3/library/exceptions.html#DeprecationWarning).
> For example, re.compile("\d+\.\d+") now emits a
> [SyntaxWarning](https://docs.python.org/3/library/exceptions.html#SyntaxWarning)
> ("\d" is an invalid escape sequence, use raw strings for regular expression:
> re.compile(r"\d+\.\d+")). In a future Python version,
> [SyntaxError](https://docs.python.org/3/library/exceptions.html#SyntaxError)
> will eventually be raised, instead of
> [SyntaxWarning](https://docs.python.org/3/library/exceptions.html#SyntaxWarning).
> (Contributed by Victor Stinner in
> [gh-98401](https://github.com/python/cpython/issues/98401).)
https://github.com/llvm/llvm-project/pull/105990
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] Turn -Wenum-constexpr-conversion into a hard error (PR #102364)
thesamesam wrote: re boost: I was thinking the same re waiting until it's out but I didn't want to say it. Sounds good. https://github.com/llvm/llvm-project/pull/102364 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] Turn -Wenum-constexpr-conversion into a hard error (PR #102364)
https://github.com/thesamesam edited https://github.com/llvm/llvm-project/pull/102364 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] Turn -Wenum-constexpr-conversion into a hard error (PR #102364)
https://github.com/thesamesam approved this pull request. Thanks @AaronBallman! Other than gdb (thank you Carlos for working on that), I'm only aware of two issues: * qtlocation -> boost (https://bugs.gentoo.org/895516 -> https://bugreports.qt.io/browse/QTBUG-116652 -> https://github.com/boostorg/mpl/issues/69) * pycuda (https://bugs.gentoo.org/924401 - not looked into this, it might have been fixed upstream in a newer version) cc @llvm/clang-vendors https://github.com/llvm/llvm-project/pull/102364 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Add option -fstdlib-hardening= (PR #78763)
thesamesam wrote: > So if the libc++ maintainers have a strong opinion about the flag, I think > more work needs to be done to ensure a good user experience. > Personally, I think going with the macro until the flag has more > functionality it controls makes sense. However, I'm also not opposed to a > command line option so long as we're mindful of the user experience around it. Right, ship it when it's polished. We can justify it more then. I'm not trying to bikeshed here - but I'm both one of the people who has to then deploy this to a lot of users, and also then _explain to other vendors_ what they should be doing, and I don't feel like this is helping the confusion if it goes in as-is. If we can get it wired up for other stdlib impls, it starts to become worth it and a net UX _win_. https://github.com/llvm/llvm-project/pull/78763 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Add option -fstdlib-hardening= (PR #78763)
thesamesam wrote: > > I am on the fence whether a driver option is really needed. It is a very > > shallow layer of extra abstraction that a curious reader has to look > > through. I guess I'll not object to this, if people really want to add it. > > Setting macros that are reserved names is really unappealing for people. We > want to provide a well integrated experience for library hardening and that > includes providing a friendly option at the compiler level. Other sanity > checking in the driver like erroring out when libc++ isn't in use is also > good, That pre-empts making it work for libstdc++ as suggested above... > since it calls out user mistakes early and clearly (otherwise the user might > think they are getting hardening when they are > not). Finally, in the future > this flag could potentially include more than just the macro. For example, it > could potentially > include a few additional warnings. That'd be the case for `-fhardened`. > > Overall, my opinion is that this flag is required to properly "productize" > library hardening and give it a user-friendly "frontend". That's a fair point - setting a macro with an underscore does feel a bit dirty. https://github.com/llvm/llvm-project/pull/78763 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [compiler-rt] [mlir] [clang] [libcxx] [sanitizer] Skip /include/c++/ from summary (PR #78534)
thesamesam wrote: Unfortunately, it's been a while since I've done Darwin (although may be doing a bit more soon), so no ideas for that side yet. https://github.com/llvm/llvm-project/pull/78534 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Add option -fstdlib-hardening= (PR #78763)
thesamesam wrote: > > Yes, please, unless there's a strong reason not to, consider `-fhardened`. > > `-fhardened` also enables a few compiler flags. I think it would be better to > have a separate flag that only affects the library and hopefully in the > future start supporting `-fhardened` flag that would have an aligned behavior > between GCC and Clang (including enabling equivalent compiler flags where > possible). Then why can't people just use `-D` to set the single macro? https://github.com/llvm/llvm-project/pull/78763 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [clang] [libcxx] [mlir] [compiler-rt] [sanitizer] Skip /include/c++/ from summary (PR #78534)
thesamesam wrote: Note that on Gentoo, this isn't right either, we have e.g.: ``` /usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/bits/new_allocator.h /usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/ext/new_allocator.h ``` https://github.com/llvm/llvm-project/pull/78534 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Add option -fstdlib-hardening= (PR #78763)
thesamesam wrote: > No other thoughts for now. GCC has `-fhardened` now, which already defines > that macro. This seems kinda redundant with it. Yes, please, unless there's a strong reason not to, consider `-fhardened`. Otherwise we may as well just be telling people to set `-D...` themselves. https://github.com/llvm/llvm-project/pull/78763 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [clang] [Clang][IR] add TBAA metadata on pointer, union and array types. (PR #75177)
thesamesam wrote: > I put union TBAA under the option that is disabled by default. I am also > considering to put pointer TBAA under option too, if it raises enough > concerns too. Let's please file a bug once this is merged so we remember to come back to that. https://github.com/llvm/llvm-project/pull/75177 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] Reword apologetic Clang diagnostic messages (PR #76310)
@@ -9913,11 +9913,11 @@ def warn_new_dangling_initializer_list : Warning<
"will be destroyed at the end of the full-expression">,
InGroup;
def warn_unsupported_lifetime_extension : Warning<
- "sorry, lifetime extension of "
+ "lifetime extension of "
"%select{temporary|backing array of initializer list}0 created "
- "by aggregate initialization using default member initializer "
+ "by aggregate initialization using a default member initializer "
"is not supported; lifetime of %select{temporary|backing array}0 "
thesamesam wrote:
Perhaps "is not yet supported" or similar. As noted at
https://github.com/llvm/llvm-project/issues/61256#issuecomment-1477097827, the
"sorry" kind of indicated that it was Clang's fault, rather than the code doing
something wrong.
https://github.com/llvm/llvm-project/pull/76310
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] 3403686 - [Clang] Fix JIT test on 32-bit systems
Author: Sam James
Date: 2023-09-05T16:04:22+01:00
New Revision: 3403686b72507e3fdbcd69f21fb9235ffa0ca169
URL:
https://github.com/llvm/llvm-project/commit/3403686b72507e3fdbcd69f21fb9235ffa0ca169
DIFF:
https://github.com/llvm/llvm-project/commit/3403686b72507e3fdbcd69f21fb9235ffa0ca169.diff
LOG: [Clang] Fix JIT test on 32-bit systems
As reported by mgorny at https://reviews.llvm.org/D159115#4638037, the
unsigned long long cast fails on 32-bit systems at least with GCC.
It looks like a pointer provenance/aliasing issue rather than a bug in GCC.
Acked by Vassil Vassilev on the original revision.
Added:
Modified:
clang/unittests/Interpreter/InterpreterTest.cpp
Removed:
diff --git a/clang/unittests/Interpreter/InterpreterTest.cpp
b/clang/unittests/Interpreter/InterpreterTest.cpp
index 07fb0028779ba0a..62e5bacbdd0b6d8 100644
--- a/clang/unittests/Interpreter/InterpreterTest.cpp
+++ b/clang/unittests/Interpreter/InterpreterTest.cpp
@@ -246,7 +246,7 @@ TEST(IncrementalProcessing, FindMangledNameSymbol) {
// FIXME: Re-enable when we investigate the way we handle dllimports on Win.
#ifndef _WIN32
- EXPECT_EQ((unsigned long long)&printf, Addr->getValue());
+ EXPECT_EQ((uintptr_t)&printf, Addr->getValue());
#endif // _WIN32
}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] 4ddae8b - [clangd] Fix test failure when it's built with compiler flags unknown by clang
Author: Xi Ruoyao
Date: 2023-05-16T03:56:26+01:00
New Revision: 4ddae8b941398a6579d3a6f25aa39a260e441371
URL:
https://github.com/llvm/llvm-project/commit/4ddae8b941398a6579d3a6f25aa39a260e441371
DIFF:
https://github.com/llvm/llvm-project/commit/4ddae8b941398a6579d3a6f25aa39a260e441371.diff
LOG: [clangd] Fix test failure when it's built with compiler flags unknown by
clang
If LLVM is built with a compiler other than clang, the `compile_commands.json`
file may contain compiler flags unknown by clang. When a clangd test is copied
into the build directory and checked, clangd will pick the unknown flag from
the file and cause a test failure. Create an empty `compile_commands.json` in
the test directory nested in the build directory to override it.
Reviewed By: thesamesam
Differential Revision: https://reviews.llvm.org/D150582
Added:
clang-tools-extra/clangd/test/compile_commands.json
Modified:
clang-tools-extra/clangd/test/CMakeLists.txt
Removed:
diff --git a/clang-tools-extra/clangd/test/CMakeLists.txt
b/clang-tools-extra/clangd/test/CMakeLists.txt
index 6bb578263ffc8..840fe2bdc12b0 100644
--- a/clang-tools-extra/clangd/test/CMakeLists.txt
+++ b/clang-tools-extra/clangd/test/CMakeLists.txt
@@ -28,6 +28,16 @@ configure_lit_site_cfg(
${CMAKE_CURRENT_SOURCE_DIR}/lit.cfg.py
)
+# Copy an empty compile_commands.json to override the compile_commands.json
+# in the top level build directory. Or if a clangd test involves creating a
+# temporary source file in the build directory and run clangd to check it,
+# it can pick up unrecognizable command options when LLVM is built with
+# another compiler or a
diff erent version of Clang.
+configure_file(
+ ${CMAKE_CURRENT_SOURCE_DIR}/compile_commands.json
+ ${CMAKE_CURRENT_BINARY_DIR}/compile_commands.json
+)
+
add_lit_testsuite(check-clangd "Running the Clangd regression tests"
# clangd doesn't put unittest configs in test/unit like every other project.
# Because of that, this needs to pass two folders here, while every other
diff --git a/clang-tools-extra/clangd/test/compile_commands.json
b/clang-tools-extra/clangd/test/compile_commands.json
new file mode 100644
index 0..fe51488c7066f
--- /dev/null
+++ b/clang-tools-extra/clangd/test/compile_commands.json
@@ -0,0 +1 @@
+[]
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] 136f778 - [Clang] [Python] Fix tests when default config file contains -include
Author: Sam James
Date: 2023-01-23T21:15:10Z
New Revision: 136f77805fd89cd30e69b3d1204fbf7efedd9a12
URL:
https://github.com/llvm/llvm-project/commit/136f77805fd89cd30e69b3d1204fbf7efedd9a12
DIFF:
https://github.com/llvm/llvm-project/commit/136f77805fd89cd30e69b3d1204fbf7efedd9a12.diff
LOG: [Clang] [Python] Fix tests when default config file contains -include
In Gentoo, we make use of Clang's recently-enhanced config file support
and add a default include to `clang` invocations using '-include ...'.
This breaks clang-python tests like so:
```
==
ERROR: test_includes (tests.cindex.test_translation_unit.TestTranslationUnit)
--
Traceback (most recent call last):
File
"/var/tmp/portage/dev-python/clang-python-15.0.6/work/clang/bindings/python/tests/cindex/test_translation_unit.py",
line 145, in test_includes
eq(i[0], i[1])
File
"/var/tmp/portage/dev-python/clang-python-15.0.6/work/clang/bindings/python/tests/cindex/test_translation_unit.py",
line 132, in eq
self.assert_normpaths_equal(expected[0], actual.source.name)
AttributeError: 'NoneType' object has no attribute 'name'
==
FAIL: test_inclusion_directive
(tests.cindex.test_translation_unit.TestTranslationUnit)
--
Traceback (most recent call last):
File
"/var/tmp/portage/dev-python/clang-python-15.0.6/work/clang/bindings/python/tests/cindex/test_translation_unit.py",
line 157, in test_inclusion_directive
self.assert_normpaths_equal(i[0], i[1])
File
"/var/tmp/portage/dev-python/clang-python-15.0.6/work/clang/bindings/python/tests/cindex/test_translation_unit.py",
line 126, in assert_normpaths_equal
self.assertEqual(os.path.normpath(path1),
AssertionError: '/var/tmp/portage/dev-python/clang-python-1[58 chars]r1.h' !=
'/usr/include/gentoo/fortify.h'
-
/var/tmp/portage/dev-python/clang-python-15.0.6/work/clang/bindings/python/tests/cindex/INPUTS/header1.h
+ /usr/include/gentoo/fortify.h
```
Disable using the default Clang configuration files on the system, like
we did for other tests.
Bug: https://bugs.gentoo.org/890204
Differential Revision: https://reviews.llvm.org/D141248
Added:
Modified:
clang/bindings/python/tests/CMakeLists.txt
Removed:
diff --git a/clang/bindings/python/tests/CMakeLists.txt
b/clang/bindings/python/tests/CMakeLists.txt
index 5127512fe312f..c4cd2539e9d6c 100644
--- a/clang/bindings/python/tests/CMakeLists.txt
+++ b/clang/bindings/python/tests/CMakeLists.txt
@@ -1,7 +1,10 @@
# Test target to run Python test suite from main build.
+# Avoid configurations including '-include' from interfering with
+# our tests by setting CLANG_NO_DEFAULT_CONFIG.
add_custom_target(check-clang-python
COMMAND ${CMAKE_COMMAND} -E env
+CLANG_NO_DEFAULT_CONFIG=1
CLANG_LIBRARY_PATH=$
"${Python3_EXECUTABLE}" -m unittest discover
DEPENDS libclang
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: How can Autoconf help with the transition to stricter compilation defaults?
> On 16 Nov 2022, at 15:27, Richard Biener wrote:
>
> On Wed, Nov 16, 2022 at 4:02 PM Michael Matz via Gcc wrote:
>>
>> Hey,
>>
>> On Wed, 16 Nov 2022, Alexander Monakov wrote:
>>
The idea is so obvious that I'm probably missing something, why autoconf
can't use that idiom instead. But perhaps the (historic?) reasons why it
couldn't be used are gone now?
>>>
>>> Ironically, modern GCC and LLVM optimize '&foobar != 0' to '1' even at -O0,
>>> and thus no symbol reference remains in the resulting assembly.
>>
>> Err, right, *head-->table*.
>> Playing with volatile should help:
>>
>> char foobar(void);
>> char (* volatile ptr)(void);
>> int main(void) {
>>ptr = foobar;
>>return ptr != 0;
>> }
>
> using printf for foobar this works even with GCC 2.95.2 and with trunk
> and -Wall diagnoses
>
> t.c:1:6: warning: conflicting types for built-in function 'printf';
> expected 'int(const char *, ...)' [-Wbuiltin-declaration-mismatch]
>1 | char printf(void);
> | ^~
> t.c:1:1: note: 'printf' is declared in header ''
> +++ |+#include
>1 | char printf(void);
>
> so without -Werror this should be fine.
>
Unrelated but I was a bit tempted to ask for throwing in
-Wbuiltin-declaration-mismatch
to default -Werror while Clang 16 was at it, but I suppose we don't want the
world to
burn too much, and it's got a very obvious usecase (this one) whereas implicit
func decls are too hard to justify.
> Richard.
signature.asc
Description: Message signed with OpenPGP
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: How can Autoconf help with the transition to stricter compilation defaults?
> On 13 Nov 2022, at 00:43, Paul Eggert wrote: > > On 2022-11-11 07:11, Aaron Ballman wrote: >> We believe the runtime behavior is sufficiently dangerous to >> warrant a conservative view that any call to a function will be a call >> that gets executed at runtime, hence a definitive signature mismatch >> is something we feel comfortable diagnosing (in some form) by default. > > As long as these diagnostics by default do not cause the compiler to exit > with nonzero status, we should be OK with Autoconf-generated 'configure' > scripts. Although there will be problems with people who run "./configure > CFLAGS='-Werror'", that sort of usage has always been problematic and > unsupported by Autoconf, so we can simply continue to tell people "don't do > that". > Is there somewhere in the autoconf docs we actually say this? I've seen a few instances of folks adding it themselves very early in their configure scripts (which is a pain for distros anyway) which then ends up affecting the rest. signature.asc Description: Message signed with OpenPGP ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: How can Autoconf help with the transition to stricter compilation defaults?
> On 12 Nov 2022, at 03:40, Zack Weinberg wrote: > > Florian Weimer writes: >> based on a limited attempt to get this fixed about three years >> ago, I expect that many of the problematic packages have not had their >> configure scripts regenerated using autoconf for a decade or more. This >> means that as an autoconf maintainer, you unfortunately won't be able to >> help us much. > > I’m sadly not surprised. > > This is definitely more work than I can see myself doing on a volunteer > basis, but a 2.69.1 patch release — nothing that’s not already on trunk, > cherry pick the changes needed to support the newer compilers (and > also newer Perl and Bash and M4) is a thing that could happen. I didn't want to ask you to do this because I felt fortunate enough you were volunteering to handle 2.72, but this would indeed be a help, because then I won't have to try persuade people they should totally upgrade, and it should happen naturally enough with distro upgrades. If you are willing, that would be welcome. Of course, we'll have to go lobby them, but that is what it is :) signature.asc Description: Message signed with OpenPGP ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: How can Autoconf help with the transition to stricter compilation defaults?
> On 10 Nov 2022, at 17:16, Zack Weinberg wrote: > > I’m the closest thing Autoconf has to a lead maintainer at present. > > It’s come to my attention (via https://lwn.net/Articles/913505/ and > https://fedoraproject.org/wiki/Changes/PortingToModernC) that GCC and > Clang both plan to disable several “legacy” C language features by > default in a near-future release (GCC 14, Clang 16) (see the Fedora > wiki link for a list). I understand that this change potentially > breaks a lot of old dusty code, and in particular that > Autoconf-generated configure scripts use constructs that may *silently > give the wrong answer to a probe* when a stricter compiler is in use. Thank you for asking. The fixes in git get us there, I think, as far as you can, with the exception of the stuff you (and I) mention below. > > [...] > > The biggest remaining (potential) problem, that I’m aware of, is that > AC_CHECK_FUNC unconditionally declares the function we’re probing for > as ‘char NAME (void)’, and asks the compiler to call it with no > arguments, regardless of what its prototype actually is. It is not > clear to me whether this will still work with the planned changes to > the compilers. Both GCC 12 and Clang 14 have on-by-default warnings > triggered by ‘extern char memcpy(void);’ (or any other standard > library function whose prototype is coded into the compiler) and this > already causes problems for people who run configure scripts with > CC='cc -Werror'. Unfortunately this is very hard to fix — we would > have to build a comprehensive list of library functions into Autoconf, > mapping each to either its documented prototype or to a header where > it ought to be declared; in the latter case we would also have to make > e.g. AC_CHECK_FUNCS([getaddrinfo]) imply AC_CHECK_HEADERS([sys/types.h > sys/socket.h netdb.h]) which might mess up configure scripts that > aren’t expecting headers to be probed at that point. > > How important do you think it is for this to be fixed? > > Are there any other changes you would like to see in a near-future > Autoconf 2.72 in order to make this transition easier? This might be a WONTFIX but let me mention it just for the record: 1. AC_CHECK_FUNCS is, as you've noticed, very noisy. I would support having a hardcoded list for certain CHOSTs as Rich suggests to reduce noise, but I don't think we can do this accurately very quickly. I think for Gentoo's efforts, I might just build up a set of cache variables for glibc/musl on each arch to reduce the noise in logs. But that's time consuming and brittle still, so I'm not sure. (Note that Gentoo and Fedora are taking two complementary but different approaches here: we're diffing config.logs and other compiler output, in addition to build logs, while Florian for Fedora Is building a list of functions which *we know* are available In a specific environment and patching gcc to spit out logs when something in said list is missing. This mitigates noise for things like functions in libbsd, which I'm finding a bit of a pain.) I'll see what others say. 2. I often have to set the following cache variables to reduce noise in logs: * ac_cv_c_undeclared_builtin_options="none needed" * ac_cv_header_sys_types_h_makedev=no * gl_cv_compiler_check_decl_option="-Werror=implicit-function-declaration" (obviously this is gnulib) * gl_cv_minmax_in_limits_h=no I don't know if we can do anything to make these tests smarter or just leave it as-is. It's fine if we can't, as exporting the cache vars is not a bad workaround for us when doing testing. > > zw > > p.s. GCC and Clang folks: As long as you’re changing the defaults out > from under people, can you please also remove the last few predefined > user-namespace macros (-Dlinux, -Dunix, -Darm, etc) from all the > -std=gnuXX modes? I support this as well. This kind of thing has led to endless bugs in userland, see https://reviews.llvm.org/D137511. signature.asc Description: Message signed with OpenPGP ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libunwind] 32a2af4 - [CMake] Fix -Wstrict-prototypes
Author: Sam James
Date: 2022-11-08T01:37:04Z
New Revision: 32a2af44e1e882f13d1cc2817f0a8d4d8b375d4d
URL:
https://github.com/llvm/llvm-project/commit/32a2af44e1e882f13d1cc2817f0a8d4d8b375d4d
DIFF:
https://github.com/llvm/llvm-project/commit/32a2af44e1e882f13d1cc2817f0a8d4d8b375d4d.diff
LOG: [CMake] Fix -Wstrict-prototypes
Fixes warnings (or errors, if someone injects -Werror in their build system,
which happens in fact with some folks vendoring LLVM too) with Clang 16:
```
+/var/tmp/portage.notmp/portage/sys-devel/llvm-15.0.4/work/llvm_build-abi_x86_64.amd64/CMakeFiles/CMakeTmp/src.c:3:9:
warning: a function declaration without a prototype
is deprecated in all versions of C [-Wstrict-prototypes]
-/var/tmp/portage.notmp/portage/sys-devel/llvm-14.0.4/work/llvm_build-abi_x86_64.amd64/CMakeFiles/CMakeTmp/src.c:3:9:
error: a function declaration without a prototype is
deprecated in all versions of C [-Werror,-Wstrict-prototypes]
int main() {return 0;}
^
void
```
Differential Revision: https://reviews.llvm.org/D137503
Added:
Modified:
compiler-rt/cmake/Modules/CompilerRTDarwinUtils.cmake
compiler-rt/cmake/config-ix.cmake
compiler-rt/lib/builtins/CMakeLists.txt
libcxx/cmake/config-ix.cmake
libcxxabi/cmake/config-ix.cmake
libunwind/cmake/config-ix.cmake
lldb/tools/debugserver/source/CMakeLists.txt
llvm/cmake/config-ix.cmake
llvm/cmake/modules/FindFFI.cmake
llvm/cmake/modules/FindTerminfo.cmake
llvm/cmake/modules/FindZ3.cmake
llvm/cmake/modules/HandleLLVMOptions.cmake
openmp/runtime/cmake/config-ix.cmake
polly/lib/External/CMakeLists.txt
Removed:
diff --git a/compiler-rt/cmake/Modules/CompilerRTDarwinUtils.cmake
b/compiler-rt/cmake/Modules/CompilerRTDarwinUtils.cmake
index e2506872751f9..e372da0d99ba0 100644
--- a/compiler-rt/cmake/Modules/CompilerRTDarwinUtils.cmake
+++ b/compiler-rt/cmake/Modules/CompilerRTDarwinUtils.cmake
@@ -116,7 +116,7 @@ function(darwin_test_archs os valid_archs)
if(NOT TEST_COMPILE_ONLY)
message(STATUS "Finding valid architectures for ${os}...")
set(SIMPLE_C ${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/src.c)
-file(WRITE ${SIMPLE_C} "#include \nint main() { printf(__FILE__);
return 0; }\n")
+file(WRITE ${SIMPLE_C} "#include \nint main(void) {
printf(__FILE__); return 0; }\n")
set(os_linker_flags)
foreach(flag ${DARWIN_${os}_LINK_FLAGS})
diff --git a/compiler-rt/cmake/config-ix.cmake
b/compiler-rt/cmake/config-ix.cmake
index da86bdcdcf169..f6190ee60e3c3 100644
--- a/compiler-rt/cmake/config-ix.cmake
+++ b/compiler-rt/cmake/config-ix.cmake
@@ -224,7 +224,7 @@ set(COMPILER_RT_SUPPORTED_ARCH)
# runtime libraries supported by our current compilers cross-compiling
# abilities.
set(SIMPLE_SOURCE ${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/simple.cc)
-file(WRITE ${SIMPLE_SOURCE} "#include \n#include \nint
main() { printf(\"hello, world\"); }\n")
+file(WRITE ${SIMPLE_SOURCE} "#include \n#include \nint
main(void) { printf(\"hello, world\"); }\n")
# Detect whether the current target platform is 32-bit or 64-bit, and setup
# the correct commandline flags needed to attempt to target 32-bit and 64-bit.
diff --git a/compiler-rt/lib/builtins/CMakeLists.txt
b/compiler-rt/lib/builtins/CMakeLists.txt
index fd3d3956439d2..42015ef8f36d6 100644
--- a/compiler-rt/lib/builtins/CMakeLists.txt
+++ b/compiler-rt/lib/builtins/CMakeLists.txt
@@ -755,7 +755,7 @@ else ()
SOURCE "#if !(__ARM_FP & 0x8)
#error No double-precision support!
#endif
- int main() { return 0; }")
+ int main(void) { return 0; }")
if(NOT COMPILER_RT_HAS_${arch}_VFP_DP)
list(REMOVE_ITEM ${arch}_SOURCES ${arm_Thumb1_VFPv2_DP_SOURCES})
endif()
diff --git a/libcxx/cmake/config-ix.cmake b/libcxx/cmake/config-ix.cmake
index a5ce4745a5f6a..3bae536436835 100644
--- a/libcxx/cmake/config-ix.cmake
+++ b/libcxx/cmake/config-ix.cmake
@@ -98,7 +98,7 @@ if(CMAKE_CXX_COMPILER_ID MATCHES "Clang")
set(CMAKE_REQUIRED_FLAGS "${CMAKE_REQUIRED_FLAGS} -Werror=unknown-pragmas")
check_c_source_compiles("
#pragma comment(lib, \"c\")
-int main() { return 0; }
+int main(void) { return 0; }
" C_SUPPORTS_COMMENT_LIB_PRAGMA)
cmake_pop_check_state()
endif()
diff --git a/libcxxabi/cmake/config-ix.cmake b/libcxxabi/cmake/config-ix.cmake
index ff9a1bf349e52..f4ee8946c1fea 100644
--- a/libcxxabi/cmake/config-ix.cmake
+++ b/libcxxabi/cmake/config-ix.cmake
@@ -81,7 +81,7 @@ if(CMAKE_CXX_COMPILER_ID MATCHES "Clang")
set(CMAKE_REQUIRED_FLAGS "${CMAKE_REQUIRED_FLAGS} -Werror=unknown-pragmas")
check_c_source_compiles("
#pragma comment(lib, \"c\")
-int main() { return 0; }
+int main(void) { return 0; }
" C_SUPPORTS_COMMENT_LIB_PRAGMA)
