[clang] Ensure proper NULL macro definition for system include files. (PR #149176)

2025-07-23 Thread Jamie Schmeiser via cfe-commits
jamieschmeiser wrote: > I think it makes sense for Clang to handle the C Standard Library headers > which can introduce `NULL`, but I'm surprised to see us adding new headers > like `dbm.h`, the `sys` directory, and `unistd,h`. These other headers define NULL to 0 on AIX and are included throu

[clang] Ensure proper NULL macro definition for system include files. (PR #149176)

2025-07-17 Thread Jamie Schmeiser via cfe-commits
jamieschmeiser wrote: > > are you saying that you have a strong preference to not handle locale.h > > (for example) for non-AIX environments? > > Yes. > > You know exactly which AIX headers define NULL, and because IBM also ships > the AIX headers, you can ensure no future version of the head

[clang] Ensure proper NULL macro definition for system include files. (PR #149176)

2025-07-17 Thread Jamie Schmeiser via cfe-commits
jamieschmeiser wrote: > What logic did you use to decide which headers should use `#idfdef _AIX`? The headers that exist on AIX that define NULL but are not mandated by the C standard to define NULL are guarded with `#ifdef _AIX`. See previous comment: > For those non-mandated system headers

[clang] Ensure proper NULL macro definition for system include files. (PR #149176)

2025-07-17 Thread Jamie Schmeiser via cfe-commits
@@ -0,0 +1,15 @@ +// There are at least 2 valid C null-pointer constants as defined +// by the C language standard. +// Test that the macro NULL is defined consistently for all platforms by +// those headers that the C standard mandates a macro definition for NULL. + +// RUN: %cla

[clang] Ensure proper NULL macro definition for system include files. (PR #149176)

2025-07-17 Thread Jamie Schmeiser via cfe-commits
jamieschmeiser wrote: > This seems like a very complicated solution. > > If the AIX system headers want to define NULL, should we just let them? Just > `#include_next ` to ensure clang's stddef.h doesn't define NULL in > an inconsistent way. Just doing an `#include_next ` is a dangerous solut

[clang] Ensure proper NULL macro definition for system include files. (PR #149176)

2025-07-17 Thread Jamie Schmeiser via cfe-commits
@@ -39,6 +39,25 @@ set(core_files varargs.h ) +set(aix_wrapper_files + dbm.h + stdio.h + stdlib.h + string.h + time.h + unistd.h + wchar.h + ) jamieschmeiser wrote: Thanks @hubert-reinterpretcast, good catch. I will add it in. https://github.com

[clang] Ensure proper NULL macro definition for system include files. (PR #149176)

2025-07-17 Thread Jamie Schmeiser via cfe-commits
https://github.com/jamieschmeiser updated https://github.com/llvm/llvm-project/pull/149176 >From e50062b48a09bd6e077b86bdeed65c7c1abb2ebe Mon Sep 17 00:00:00 2001 From: Jamie Schmeiser Date: Wed, 16 Jul 2025 15:40:09 -0400 Subject: [PATCH] Ensure proper NULL macro definition for system include

[clang] Ensure proper NULL macro definition for system include files. (PR #149176)

2025-07-16 Thread Jamie Schmeiser via cfe-commits
https://github.com/jamieschmeiser created https://github.com/llvm/llvm-project/pull/149176 The C standard allows for at least 2 valid definitions of a null pointer constant and mandates that several standard headers files define the macro NULL to be a null pointer constant. Ensure that defini

[clang] [clang][modules][deps]Remove -F option from test for clang-scan-deps (PR #141614)

2025-05-29 Thread Jamie Schmeiser via cfe-commits
jamieschmeiser wrote: Our legacy products had different functionality for -F than the current Clang -F functionality. See https://www.ibm.com/docs/en/xl-c-and-cpp-aix/16.1.0?topic=ixcod-f, in particular the note that states that this functionality is different from GCC -F (and therefore diff

[clang] [clang][modules][deps]Remove -F option from test for clang-scan-deps (PR #141614)

2025-05-29 Thread Jamie Schmeiser via cfe-commits
jamieschmeiser wrote: @cyndyishida From https://clang.llvm.org/compatibility.html: `Clang strives to both conform to current language standards (up to C11 and C++11) and also to implement many widely-used extensions available in other compilers, so that most correct code will "just work" when c

[clang] [clang][modules][deps]Remove -F option from test for clang-scan-deps (PR #141614)

2025-05-28 Thread Jamie Schmeiser via cfe-commits
jamieschmeiser wrote: The correct way to enable support for -F is to specify `--target=`, eg `--target=x86_64-apple-macos`. According to https://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html, -F is a darwin extension in g++ so it only makes sense for darwin in clang. Currently, it is quietl

[clang] [clang][modules][deps]Remove -F option from test for clang-scan-deps (PR #141614)

2025-05-28 Thread Jamie Schmeiser via cfe-commits
jamieschmeiser wrote: I am looking into what is done elsewhere. Not relying on -F, as is now the case here, is one way (which doesn't really answer your question...) https://github.com/llvm/llvm-project/pull/141614 ___ cfe-commits mailing list cfe-co

[clang] [clang][modules][deps]Remove -F option from test for clang-scan-deps (PR #141614)

2025-05-28 Thread Jamie Schmeiser via cfe-commits
https://github.com/jamieschmeiser closed https://github.com/llvm/llvm-project/pull/141614 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][modules][deps]Remove -F option from test for clang-scan-deps (PR #141614)

2025-05-27 Thread Jamie Schmeiser via cfe-commits
https://github.com/jamieschmeiser created https://github.com/llvm/llvm-project/pull/141614 Remove the redundant -F option from test because not all platforms support -F, which is a g++ extension. The option is unnecessary because all files in the test have paths specified. >From 213401bebf9c

[clang] [llvm] demangle function names in trace files (PR #87626)

2024-08-02 Thread Jamie Schmeiser via cfe-commits
jamieschmeiser wrote: @rnk It is just a convenience to make things easier to read and should be removed if it is causing compile time issues. I just happened to see this comment now but will be unavailable for about 2 weeks. I will take care of it when I return (I'm not ignoring this...) If

[clang] [llvm] demangle function names in trace files (PR #87626)

2024-07-10 Thread Jamie Schmeiser via cfe-commits
https://github.com/jamieschmeiser closed https://github.com/llvm/llvm-project/pull/87626 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] demangle function names in trace files (PR #87626)

2024-07-10 Thread Jamie Schmeiser via cfe-commits
jamieschmeiser wrote: To directly answer your question: No, deliver this. If you find loop entries in the future, then consider expanding it. Also, the link to that here may help others should then decide to expand this work. https://github.com/llvm/llvm-project/pull/87626 __

[clang] [llvm] demangle function names in trace files (PR #87626)

2024-07-10 Thread Jamie Schmeiser via cfe-commits
jamieschmeiser wrote: @Trass3r, sorry, I didn't realize that you were waiting on me... I had already approved this so you can go ahead and merge it. I was just pointing you at possibly related work that might interest you. Even if you decide to expand this work, I would suggest delivering t

[clang] [llvm] demangle function names in trace files (PR #87626)

2024-05-06 Thread Jamie Schmeiser via cfe-commits
jamieschmeiser wrote: You may want to look at https://github.com/llvm/llvm-project/pull/90756 https://github.com/llvm/llvm-project/pull/87626 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-co

[clang] [llvm] demangle function names in trace files (PR #87626)

2024-05-06 Thread Jamie Schmeiser via cfe-commits
jamieschmeiser wrote: Thanks, I looked over things and they still look good. https://github.com/llvm/llvm-project/pull/87626 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] demangle function names in trace files (PR #87626)

2024-04-18 Thread Jamie Schmeiser via cfe-commits
jamieschmeiser wrote: Yes, the way to proceed is to rebase and resolve the conflicts. As far as the formatting changes, I think you should go with what the formatter wants. Everyone has different opinions about things like spacing, line length, etc and will never agree. The formatter keeps

[clang] [llvm] demangle function names in trace files (PR #87626)

2024-04-09 Thread Jamie Schmeiser via cfe-commits
https://github.com/jamieschmeiser approved this pull request. LGTM, thanks https://github.com/llvm/llvm-project/pull/87626 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] demangle function names in trace files (PR #87626)

2024-04-05 Thread Jamie Schmeiser via cfe-commits
https://github.com/jamieschmeiser edited https://github.com/llvm/llvm-project/pull/87626 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] demangle function names in trace files (PR #87626)

2024-04-05 Thread Jamie Schmeiser via cfe-commits
https://github.com/jamieschmeiser requested changes to this pull request. See comments in response https://github.com/llvm/llvm-project/pull/87626 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/c

[clang] [llvm] demangle function names in trace files (PR #87626)

2024-04-05 Thread Jamie Schmeiser via cfe-commits
@@ -1495,7 +1496,7 @@ void TimeProfilingPassesHandler::registerCallbacks( } void TimeProfilingPassesHandler::runBeforePass(StringRef PassID, Any IR) { - timeTraceProfilerBegin(PassID, getIRName(IR)); + timeTraceProfilerBegin(PassID, demangle(getIRName(IR)));

[clang] 5e3ac79 - Loop names used in reporting can grow very large

2022-09-09 Thread Jamie Schmeiser via cfe-commits
Author: Jamie Schmeiser Date: 2022-09-09T13:45:14-04:00 New Revision: 5e3ac7969039678fc017a5599b051ea2b78075a4 URL: https://github.com/llvm/llvm-project/commit/5e3ac7969039678fc017a5599b051ea2b78075a4 DIFF: https://github.com/llvm/llvm-project/commit/5e3ac7969039678fc017a5599b051ea2b78075a4.dif

[clang] efbf013 - Only issue warning for subtraction involving null pointers on live code paths

2022-06-03 Thread Jamie Schmeiser via cfe-commits
Author: Jamie Schmeiser Date: 2022-06-03T10:10:37-04:00 New Revision: efbf0136b4108692ddd1a852b3f5b232c10d2097 URL: https://github.com/llvm/llvm-project/commit/efbf0136b4108692ddd1a852b3f5b232c10d2097 DIFF: https://github.com/llvm/llvm-project/commit/efbf0136b4108692ddd1a852b3f5b232c10d2097.dif

[clang] c3c1826 - Set TargetCPUName for AIX to default to pwr7.

2021-07-29 Thread Jamie Schmeiser via cfe-commits
Author: Jamie Schmeiser Date: 2021-07-29T09:59:24-04:00 New Revision: c3c1826c310c42244c7cad8d0c6af3a368fcd064 URL: https://github.com/llvm/llvm-project/commit/c3c1826c310c42244c7cad8d0c6af3a368fcd064 DIFF: https://github.com/llvm/llvm-project/commit/c3c1826c310c42244c7cad8d0c6af3a368fcd064.dif

[clang] 9cb00b9 - Reland Produce warning for performing pointer arithmetic on a null pointer.

2021-07-20 Thread Jamie Schmeiser via cfe-commits
Author: Jamie Schmeiser Date: 2021-07-20T10:12:20-04:00 New Revision: 9cb00b9ecbe74d19389a5818d61ddee328afe031 URL: https://github.com/llvm/llvm-project/commit/9cb00b9ecbe74d19389a5818d61ddee328afe031 DIFF: https://github.com/llvm/llvm-project/commit/9cb00b9ecbe74d19389a5818d61ddee328afe031.dif

[clang] 73840f9 - thread_local support for AIX

2021-07-19 Thread Jamie Schmeiser via cfe-commits
Author: Jamie Schmeiser Date: 2021-07-19T10:03:22-04:00 New Revision: 73840f9f81413f21d3c8fab0ed85917aca2b5d34 URL: https://github.com/llvm/llvm-project/commit/73840f9f81413f21d3c8fab0ed85917aca2b5d34 DIFF: https://github.com/llvm/llvm-project/commit/73840f9f81413f21d3c8fab0ed85917aca2b5d34.dif

[clang] 136ced4 - When vector is found as a type or non-type id, check if it is really the altivec vector token.

2021-05-20 Thread Jamie Schmeiser via cfe-commits
Author: Jamie Schmeiser Date: 2021-05-20T12:39:04-04:00 New Revision: 136ced498ba84f6b6126051626e319f18ba740f5 URL: https://github.com/llvm/llvm-project/commit/136ced498ba84f6b6126051626e319f18ba740f5 DIFF: https://github.com/llvm/llvm-project/commit/136ced498ba84f6b6126051626e319f18ba740f5.dif

[clang] dfc1e31 - Produce warning for performing pointer arithmetic on a null pointer.

2021-05-11 Thread Jamie Schmeiser via cfe-commits
Author: Jamie Schmeiser Date: 2021-05-11T11:29:50-04:00 New Revision: dfc1e31d49fe1380c9bab43373995df5fed15e6d URL: https://github.com/llvm/llvm-project/commit/dfc1e31d49fe1380c9bab43373995df5fed15e6d DIFF: https://github.com/llvm/llvm-project/commit/dfc1e31d49fe1380c9bab43373995df5fed15e6d.dif