Hahnfeld (Jonas Hahnfeld)
User

Projects

User does not belong to any projects.

User Details

User Since
Apr 2 2015, 4:52 AM (181 w, 1 d)
RWTH Aachen University

Recent Activity

Today

Hahnfeld added a comment to D52259: [CUDA] Rearrange search path ordering to fix two test case failures.

IMO the current logic makes sense for the end user, prioritizing the environment guess over default paths. I think the tests should be fixed using --cuda-path-ignore-env, I remember I added this parameter to fix the failing tests when I wrote the code.

Fri, Sep 21, 6:07 AM · Restricted Project

Mon, Sep 10

Hahnfeld added a comment to D51875: [OPENMP][NVPTX] Add support for lastprivates/reductions handling in SPMD constructs with lightweight runtime..

I already described it - it breaks the compatibility with other outlined regions and breaks the whole design of the OpenMP implementation.

First that's a general statement without any explanation. Second I'm not asking about the scratchpad pointer solution in ibm-devel but rather why we can't pass RequiresDataSharing = true to __kmpc_spmd_kernel_init. Which will give us the data sharing in existing buffers.

First, stop talking like this. I don't owe you anything.

Mon, Sep 10, 1:53 PM
Hahnfeld added inline comments to D51875: [OPENMP][NVPTX] Add support for lastprivates/reductions handling in SPMD constructs with lightweight runtime..
Mon, Sep 10, 1:39 PM
Hahnfeld added a comment to D51875: [OPENMP][NVPTX] Add support for lastprivates/reductions handling in SPMD constructs with lightweight runtime..

I really, really dislike adding even more global buffers. 4096 * 32 * 56 are another 7MiB that are not usable for applications. What's wrong with using the existing ones?

Can you upload the CodeGen patch for reductions somewhere? I thought we need a global scratchpad buffer that is adressable for all teams?

I really, really dislike an implementation in ibm-devel, the scratchpad solution will never be added to the trunk. The existing ones cannot be reused, as they are allocated only if the full runtime is used.

What's the overhead of initializing it? The whole libomptarget-nvptx is already a pretty much mess, see my thread on openmp-dev.

It is not the runtime issue, it is the problem with the compiler itself. It breaks compatibility with the other outlined regions and, thus, it cannot be committed to trunk.

Can you please describe the problems? Again, maybe posting the patch may help.

I already described it - it breaks the compatibility with other outlined regions and breaks the whole design of the OpenMP implementation.

Mon, Sep 10, 1:35 PM
Hahnfeld added a comment to D51875: [OPENMP][NVPTX] Add support for lastprivates/reductions handling in SPMD constructs with lightweight runtime..

I really, really dislike adding even more global buffers. 4096 * 32 * 56 are another 7MiB that are not usable for applications. What's wrong with using the existing ones?

Can you upload the CodeGen patch for reductions somewhere? I thought we need a global scratchpad buffer that is adressable for all teams?

I really, really dislike an implementation in ibm-devel, the scratchpad solution will never be added to the trunk. The existing ones cannot be reused, as they are allocated only if the full runtime is used.

What's the overhead of initializing it? The whole libomptarget-nvptx is already a pretty much mess, see my thread on openmp-dev.

It is not the runtime issue, it is the problem with the compiler itself. It breaks compatibility with the other outlined regions and, thus, it cannot be committed to trunk.

Mon, Sep 10, 1:25 PM
Hahnfeld added a comment to D51875: [OPENMP][NVPTX] Add support for lastprivates/reductions handling in SPMD constructs with lightweight runtime..

I really, really dislike adding even more global buffers. 4096 * 32 * 56 are another 7MiB that are not usable for applications. What's wrong with using the existing ones?

Can you upload the CodeGen patch for reductions somewhere? I thought we need a global scratchpad buffer that is adressable for all teams?

I really, really dislike an implementation in ibm-devel, the scratchpad solution will never be added to the trunk. The existing ones cannot be reused, as they are allocated only if the full runtime is used.

Mon, Sep 10, 1:16 PM
Hahnfeld added a reviewer for D51875: [OPENMP][NVPTX] Add support for lastprivates/reductions handling in SPMD constructs with lightweight runtime.: Hahnfeld.

I really, really dislike adding even more global buffers. 4096 * 32 * 56 are another 7MiB that are not usable for applications. What's wrong with using the existing ones?

Mon, Sep 10, 1:04 PM

Sat, Sep 8

Hahnfeld committed rOMP341748: [libomptarget-nvptx] Remove last mentions of __kmpc_print_*.
[libomptarget-nvptx] Remove last mentions of __kmpc_print_*
Sat, Sep 8, 5:12 AM
Hahnfeld committed rL341748: [libomptarget-nvptx] Remove last mentions of __kmpc_print_*.
[libomptarget-nvptx] Remove last mentions of __kmpc_print_*
Sat, Sep 8, 5:12 AM

Fri, Sep 7

Hahnfeld added a dependent revision for D51786: [libomptarget-nvptx] Add tests for nested parallelism: D51787: [libomptarget-nvptx] Fix ancestor_thread_num and team_size (non-SPMD).
Fri, Sep 7, 6:35 AM
Hahnfeld added a dependency for D51787: [libomptarget-nvptx] Fix ancestor_thread_num and team_size (non-SPMD): D51786: [libomptarget-nvptx] Add tests for nested parallelism.
Fri, Sep 7, 6:35 AM
Hahnfeld added a dependency for D51785: [libomptarget-nvptx] Ignore calls to dynamic API: D51687: [libomptarget-nvptx] Add testing infrastructure.
Fri, Sep 7, 6:35 AM
Hahnfeld added a dependency for D51786: [libomptarget-nvptx] Add tests for nested parallelism: D51687: [libomptarget-nvptx] Add testing infrastructure.
Fri, Sep 7, 6:35 AM
Hahnfeld added a dependent revision for D51687: [libomptarget-nvptx] Add testing infrastructure: D51786: [libomptarget-nvptx] Add tests for nested parallelism.
Fri, Sep 7, 6:35 AM
Hahnfeld added a dependent revision for D51687: [libomptarget-nvptx] Add testing infrastructure: D51783: [libomptarget-nvptx] Fix number of threads in parallel.
Fri, Sep 7, 6:35 AM
Hahnfeld created D51786: [libomptarget-nvptx] Add tests for nested parallelism.
Fri, Sep 7, 6:35 AM
Hahnfeld added a dependency for D51783: [libomptarget-nvptx] Fix number of threads in parallel: D51687: [libomptarget-nvptx] Add testing infrastructure.
Fri, Sep 7, 6:35 AM
Hahnfeld added a dependent revision for D51687: [libomptarget-nvptx] Add testing infrastructure: D51785: [libomptarget-nvptx] Ignore calls to dynamic API.
Fri, Sep 7, 6:35 AM
Hahnfeld created D51787: [libomptarget-nvptx] Fix ancestor_thread_num and team_size (non-SPMD).
Fri, Sep 7, 6:35 AM
Hahnfeld created D51785: [libomptarget-nvptx] Ignore calls to dynamic API.
Fri, Sep 7, 6:31 AM
Hahnfeld created D51783: [libomptarget-nvptx] Fix number of threads in parallel.
Fri, Sep 7, 6:30 AM
Hahnfeld updated the diff for D51687: [libomptarget-nvptx] Add testing infrastructure.

Split testing infrastructure from bugfix.

Fri, Sep 7, 6:29 AM

Thu, Sep 6

Hahnfeld added a comment to D51107: [LIBOMPTARGET] Add support for mapping of lambda captures..

I think it's more consistent to handle all data mapping in a single loop (in target_data_begin) as discussed before.

I think this is a different problem that should be solved separately. It requires a redesign of the existing solution, while I'm just trying to implement a new feature.

I think I agree with Alexey here. I favor letting support for lambda captures in and later on we can redesign the way libomptarget handles mappings. Is there any objection?

Thu, Sep 6, 10:11 AM
Hahnfeld committed rOMP341563: [libomptarget] Remove two unneeded includes, NFCI..
[libomptarget] Remove two unneeded includes, NFCI.
Thu, Sep 6, 10:06 AM
Hahnfeld added inline comments to D51226: [OpenMP][libomptarget] rework of fatal error reporting.
Thu, Sep 6, 10:05 AM
Hahnfeld committed rL341563: [libomptarget] Remove two unneeded includes, NFCI..
[libomptarget] Remove two unneeded includes, NFCI.
Thu, Sep 6, 10:02 AM
Hahnfeld added inline comments to D51226: [OpenMP][libomptarget] rework of fatal error reporting.
Thu, Sep 6, 3:54 AM

Wed, Sep 5

Hahnfeld added inline comments to D51687: [libomptarget-nvptx] Add testing infrastructure.
Wed, Sep 5, 8:17 AM
Hahnfeld added a dependent revision for D51686: [OpenMP] Improve search for libomptarget-nvptx: D51687: [libomptarget-nvptx] Add testing infrastructure.
Wed, Sep 5, 8:13 AM
Hahnfeld added a dependency for D51687: [libomptarget-nvptx] Add testing infrastructure: D51686: [OpenMP] Improve search for libomptarget-nvptx.
Wed, Sep 5, 8:13 AM
Hahnfeld created D51687: [libomptarget-nvptx] Add testing infrastructure.
Wed, Sep 5, 8:13 AM
Hahnfeld created D51686: [OpenMP] Improve search for libomptarget-nvptx.
Wed, Sep 5, 8:12 AM
Hahnfeld committed rOMP341448: [libomptaret][test] Announce compiler features.
[libomptaret][test] Announce compiler features
Wed, Sep 5, 12:27 AM
Hahnfeld committed rL341448: [libomptaret][test] Announce compiler features.
[libomptaret][test] Announce compiler features
Wed, Sep 5, 12:27 AM

Tue, Sep 4

Hahnfeld added a comment to D51107: [LIBOMPTARGET] Add support for mapping of lambda captures..

BTW, the main problem here is that there is no mapping between host pointer and device pointer for the firstprivates, just like for the mapped data. We just need to rework the way we allocate the memory for the firstprivate to make MEMBER_OF to work.

I don't see this path taken in the latest patch. Is there a major drawback of doing this?

I did it using new tgtArgsPositions, which handles mappings between the firstprivates and the corresponding target pointers.

Tue, Sep 4, 11:53 PM
Hahnfeld accepted D51653: [libomptarget] Remove `Devices` from `RTLInfoTy`.

LG, but please revise the summary to say that the variable was unused. I think that's enough of motivation, no need to refer to "potential problems" or other patches.

Tue, Sep 4, 1:13 PM
Hahnfeld added a comment to D51623: [libomptarget] PR38704: Fix erase of ShadowPtrMap.

Not related to this patch, but I think there is one more potentially incorrect use of containers in RTLsTy::RegisterLib(). This function may increase size of the global vector Devices when it initializes a new RTL that has not been yet used (see rtl.cpp line 219). This may result in memory reallocation and thus all pointers to the Devices elements that are stored in RTLs (see rtl.cpp line 228) would become invalid. I am not sure if these pointers are really used by RTLs now, but if yes, than it is a problem. RTLsTy::RegisterLib may be called more than once and each call may potentially initialize new RTLs.

Tue, Sep 4, 10:43 AM
Hahnfeld added a comment to D51107: [LIBOMPTARGET] Add support for mapping of lambda captures..

BTW, the main problem here is that there is no mapping between host pointer and device pointer for the firstprivates, just like for the mapped data. We just need to rework the way we allocate the memory for the firstprivate to make MEMBER_OF to work.

Tue, Sep 4, 10:11 AM
Hahnfeld committed rOMP341372: [libomptarget][CUDA] Use cuDeviceGetAttribute, NFCI..
[libomptarget][CUDA] Use cuDeviceGetAttribute, NFCI.
Tue, Sep 4, 8:15 AM
Hahnfeld committed rOMP341371: [libomptarget] PR38704: Fix erase of ShadowPtrMap.
[libomptarget] PR38704: Fix erase of ShadowPtrMap
Tue, Sep 4, 8:15 AM
Hahnfeld committed rOMP341370: [libomptarget][NVPTX] Drop dead code and data structures, NFCI..
[libomptarget][NVPTX] Drop dead code and data structures, NFCI.
Tue, Sep 4, 8:15 AM
Hahnfeld committed rL341372: [libomptarget][CUDA] Use cuDeviceGetAttribute, NFCI..
[libomptarget][CUDA] Use cuDeviceGetAttribute, NFCI.
Tue, Sep 4, 8:14 AM
Hahnfeld closed D51624: [libomptarget][CUDA] Use cuDeviceGetAttribute, NFCI..
Tue, Sep 4, 8:14 AM
Hahnfeld committed rL341371: [libomptarget] PR38704: Fix erase of ShadowPtrMap.
[libomptarget] PR38704: Fix erase of ShadowPtrMap
Tue, Sep 4, 8:14 AM
Hahnfeld committed rL341370: [libomptarget][NVPTX] Drop dead code and data structures, NFCI..
[libomptarget][NVPTX] Drop dead code and data structures, NFCI.
Tue, Sep 4, 8:14 AM
Hahnfeld closed D51623: [libomptarget] PR38704: Fix erase of ShadowPtrMap.
Tue, Sep 4, 8:14 AM
Hahnfeld closed D51622: [libomptarget][NVPTX] Drop dead code and data structures, NFCI..
Tue, Sep 4, 8:14 AM
Hahnfeld added inline comments to D51622: [libomptarget][NVPTX] Drop dead code and data structures, NFCI..
Tue, Sep 4, 8:12 AM
Hahnfeld added a comment to D51623: [libomptarget] PR38704: Fix erase of ShadowPtrMap.

Good catch, thanks for the fix!

Tue, Sep 4, 8:07 AM
Hahnfeld added inline comments to D51622: [libomptarget][NVPTX] Drop dead code and data structures, NFCI..
Tue, Sep 4, 7:30 AM
Hahnfeld added inline comments to D51624: [libomptarget][CUDA] Use cuDeviceGetAttribute, NFCI..
Tue, Sep 4, 6:27 AM
Hahnfeld added a comment to D45691: [mips] Use libatomic instead of GCC intrinsics for 64bit.

Sorry for the delay!

Tue, Sep 4, 6:23 AM
Hahnfeld updated the summary of D51623: [libomptarget] PR38704: Fix erase of ShadowPtrMap.
Tue, Sep 4, 6:05 AM
Hahnfeld created D51624: [libomptarget][CUDA] Use cuDeviceGetAttribute, NFCI..
Tue, Sep 4, 6:04 AM
Hahnfeld created D51622: [libomptarget][NVPTX] Drop dead code and data structures, NFCI..
Tue, Sep 4, 6:04 AM
Hahnfeld created D51623: [libomptarget] PR38704: Fix erase of ShadowPtrMap.
Tue, Sep 4, 6:04 AM
Hahnfeld added a comment to D51501: [CUDA] Fix CUDA compilation broken by D50845.

Not needed anymore after the reverts in rC341115 and rC341118, right?

Tue, Sep 4, 6:03 AM
Hahnfeld added a comment to D51446: [OpenMP][bugfix] Add missing macros for Power.

Not needed anymore after the reverts in rC341115 and rC341118, right? Maybe we should revive the test to make sure we don't break this in the future?

Tue, Sep 4, 6:03 AM
Hahnfeld removed a reviewer for D51285: Fix a build issue on Debian Jessie: Hahnfeld.
Tue, Sep 4, 6:03 AM

Mon, Sep 3

Hahnfeld committed rOMP341328: [libomptarget][NVPTX] Fix __kmpc_spmd_kernel_deinit.
[libomptarget][NVPTX] Fix __kmpc_spmd_kernel_deinit
Mon, Sep 3, 10:36 AM
Hahnfeld added inline comments to D51222: [OPENMP][NVPTX] Lightweight runtime support for SPMD mode..
Mon, Sep 3, 10:33 AM
Hahnfeld added inline comments to D51222: [OPENMP][NVPTX] Lightweight runtime support for SPMD mode..
Mon, Sep 3, 10:26 AM
Hahnfeld committed rL341328: [libomptarget][NVPTX] Fix __kmpc_spmd_kernel_deinit.
[libomptarget][NVPTX] Fix __kmpc_spmd_kernel_deinit
Mon, Sep 3, 10:25 AM
Hahnfeld added inline comments to D51222: [OPENMP][NVPTX] Lightweight runtime support for SPMD mode..
Mon, Sep 3, 10:01 AM
Hahnfeld added inline comments to D51222: [OPENMP][NVPTX] Lightweight runtime support for SPMD mode..
Mon, Sep 3, 9:55 AM

Thu, Aug 30

Hahnfeld added a comment to D50845: [CUDA/OpenMP] Define only some host macros during device compilation.

removing InitializePredefinedAuxMacros and the new test completely should do.

Yep they also contain D51312 in case you're rolling back individual commits.

Thu, Aug 30, 1:21 PM
Hahnfeld added a comment to D50845: [CUDA/OpenMP] Define only some host macros during device compilation.
In D50845#1219853, @tra wrote:

Ok, the top preprocessor condition for that function is #ifndef __SSE2_MATH__ - the exact same macro that was part of the motivation. Can you please test compiling a simple C file (including math.h) with -mno-sse? My guess would be that this is broken as well.
If yes I'm fine with reverting because I need to teach Clang to allow anonymous unions in type specifiers to make that weird system header work with this patch.

It compiles fine. The code that causes the problem is also conditional on !defined __NO_MATH_INLINES and it's always defined for X86, so compilation only breaks for when we compile for NVPTX.

Thu, Aug 30, 1:11 PM
Hahnfeld added a comment to D50845: [CUDA/OpenMP] Define only some host macros during device compilation.
In D50845#1219746, @tra wrote:

In our case the headers from a relatively old glibc and compiler errors out on this:

/* This function is used in the `isfinite' macro.  */
__MATH_INLINE int
__NTH (__finite (double __x))
{
  return (__extension__
	  (((((union { double __d; int __i[2]; }) {__d: __x}).__i[1]
	     | 0x800fffffu) + 1) >> 31));
}

expanded to this:

extern __inline __attribute__ ((__always_inline__)) __attribute__ ((__gnu_inline__)) int
 __finite (double __x) throw ()
{
  return (__extension__
   (((((union { double __d; int __i[2]; }) {__d: __x}).__i[1]
      | 0x800fffffu) + 1) >> 31));
}

The error:

.../include/bits/mathinline.h:945:9: error: '(anonymous union at .../include/bits/mathinline.h:945:9)' cannot be defined in a type specifier
          (((((union { double __d; int __i[2]; }) {__d: __x}).__i[1]
               ^
.../include/bits/mathinline.h:945:55: error: member reference base type 'void' is not a structure or union
          (((((union { double __d; int __i[2]; }) {__d: __x}).__i[1]
             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~

Also, whatever macros we generate do not prevent headers from using x86 inline assembly. I see quite a few inline asm code in preprocessed output. The headers are from libc ~2.19.

Thu, Aug 30, 12:21 PM
Hahnfeld added a comment to D50845: [CUDA/OpenMP] Define only some host macros during device compilation.
In D50845#1219797, @tra wrote:

I've sent out D51501. It unbreaks CUDA compilation and keeps OpenMP unchanged.

Thu, Aug 30, 12:10 PM
Hahnfeld added a comment to D50845: [CUDA/OpenMP] Define only some host macros during device compilation.

In general, it looks like this patch leads to some host macros having to be defined again for the auxiliary triple case. It is not clear to me how to exhaustively identify the missing macros, so far it's been just trial and error.

Thu, Aug 30, 11:38 AM
Hahnfeld added a comment to D50845: [CUDA/OpenMP] Define only some host macros during device compilation.

Do you have invocations or headers that don't work? The problem is that the previous code defined all macros unconditionally, so it will afterwards be hard to find the necessary macros...

Thu, Aug 30, 11:27 AM
Hahnfeld requested changes to D51446: [OpenMP][bugfix] Add missing macros for Power.

Please also update the test.

Thu, Aug 30, 4:28 AM
Hahnfeld added a comment to D51378: [OPENMP] Add support for nested 'declare target' directives.

We should just go with generating an error if the DeclareTargetNestingLevel is not 0 at the end of compilation unit.
Hard to detect if user accidentally forgot to have end declare in header file and had it in the include file or it was intentional.

Thu, Aug 30, 4:22 AM

Tue, Aug 28

Hahnfeld committed rT340829: [test-suite, CUDA] Fix some CMake problems.
[test-suite, CUDA] Fix some CMake problems
Tue, Aug 28, 8:30 AM
Hahnfeld committed rL340829: [test-suite, CUDA] Fix some CMake problems.
[test-suite, CUDA] Fix some CMake problems
Tue, Aug 28, 8:02 AM
Hahnfeld closed D51256: [test-suite, CUDA] Fix some CMake problems.
Tue, Aug 28, 8:02 AM

Mon, Aug 27

Hahnfeld added a comment to D51285: Fix a build issue on Debian Jessie.

Should be fixed in rL340767

Mon, Aug 27, 11:29 AM
Hahnfeld added inline comments to D50774: [OMPT] Update types according to TR7.
Mon, Aug 27, 11:15 AM
Hahnfeld accepted D51303: [OpenMP][Fix] Conditional compilation leaves variables unused.

LG

Mon, Aug 27, 11:15 AM
Hahnfeld added a comment to D50522: [OpenMP][libomptarget] Bringing up to spec with respect to OMP_TARGET_OFFLOAD env var.

Yes, see D51226 which will replace the varargs function by a macro.

Mon, Aug 27, 10:46 AM
Hahnfeld added inline comments to D51232: [OpenMP] Initial implementation of OMP 5.0 Memory Management routines.
Mon, Aug 27, 9:49 AM · Restricted Project
Hahnfeld requested changes to D51303: [OpenMP][Fix] Conditional compilation leaves variables unused.

The call must not be put into conditional compilation. As discussed in D50774 there are two options:

  1. Guard the variable definition and assignment (the first line) by preprocessor guards.
  2. Add a (void) *_status; to silence the warning.
Mon, Aug 27, 9:42 AM
Hahnfeld accepted D51312: [OpenMP][NVPTX] Use appropriate _CALL_ELF macro when offloading.

LGTM. Can you add a comment to InitializePredefinedAuxMacros explaining that the macro is used in gnu/stubs.h and add a check to the test?

Mon, Aug 27, 9:38 AM
Hahnfeld accepted D51226: [OpenMP][libomptarget] rework of fatal error reporting.

LGTM. One very minor comment inline, I leave it up to you whether you want to make that change - it's more important that we unbreak the build.

Mon, Aug 27, 9:31 AM
Hahnfeld updated subscribers of D51285: Fix a build issue on Debian Jessie.

Yeah, sorry for break. Alex is currently favoring to rewrite the varargs functions into macros: D51226

Mon, Aug 27, 12:35 AM
Hahnfeld added inline comments to D51226: [OpenMP][libomptarget] rework of fatal error reporting.
Mon, Aug 27, 12:14 AM
Hahnfeld requested changes to D51226: [OpenMP][libomptarget] rework of fatal error reporting.

No, that's completely different from what I asked.

Mon, Aug 27, 12:09 AM

Sun, Aug 26

Hahnfeld abandoned D50939: [WIP][OpenMP] Propagate 'declare target' information to device.

It doesn't work for C++ yet because the LLVM function names are already mangled, so we need to do the same when checking in Sema. I think the tricky thing will be templates: Because we don't know which specialization will eventually be emitted we might need to check all of them if a template is referenced in device code. Thoughts?

I expected a lot of problems with C++ and I don't think we will be able to resolve this, especially with the templates. We need to try some other solutions.

Sun, Aug 26, 6:16 AM
Hahnfeld abandoned D50938: [WIP][OpenMP] Move reading of OpenMPHostIR to ASTContext.
Sun, Aug 26, 6:07 AM

Sat, Aug 25

Hahnfeld created D51256: [test-suite, CUDA] Fix some CMake problems.
Sat, Aug 25, 6:52 AM
Hahnfeld committed rC340681: [CUDA/OpenMP] Define only some host macros during device compilation.
[CUDA/OpenMP] Define only some host macros during device compilation
Sat, Aug 25, 6:45 AM
Hahnfeld committed rL340681: [CUDA/OpenMP] Define only some host macros during device compilation.
[CUDA/OpenMP] Define only some host macros during device compilation
Sat, Aug 25, 6:45 AM
Hahnfeld closed D50845: [CUDA/OpenMP] Define only some host macros during device compilation.
Sat, Aug 25, 6:45 AM
Hahnfeld added a comment to D50845: [CUDA/OpenMP] Define only some host macros during device compilation.
In D50845#1212643, @tra wrote:

Please keep an eye on CUDA buildbot http://lab.llvm.org:8011/builders/clang-cuda-build.
It runs fair amount of tests with libc++ and handful of libstdc++ versions and may a canary if these changes break something.

Sat, Aug 25, 6:42 AM
Hahnfeld updated the diff for D50845: [CUDA/OpenMP] Define only some host macros during device compilation.

Based on libc++ I guessed some more macros that may be needed on macOS and Windows. As I can't test myself if somebody else could report if this change is regressing CUDA support on these platforms.

Sat, Aug 25, 6:32 AM
Hahnfeld accepted D51226: [OpenMP][libomptarget] rework of fatal error reporting.

As long as we don't need to change back to the current way of doing things next week, I think I'm also fine with the macro if you think it's better. Please address the inline comment about do { ... } while (0) before committing.

Sat, Aug 25, 1:16 AM
Hahnfeld added inline comments to D51232: [OpenMP] Initial implementation of OMP 5.0 Memory Management routines.
Sat, Aug 25, 1:12 AM · Restricted Project

Fri, Aug 24

Hahnfeld updated subscribers of D51226: [OpenMP][libomptarget] rework of fatal error reporting.

@ABataev what's wrong with cstdarg?

Fri, Aug 24, 11:49 AM
Hahnfeld added a comment to D51226: [OpenMP][libomptarget] rework of fatal error reporting.

I don't understand this: In the last review you said that we need the complicated FatalMessage and now you are reverting that?!?

I am reimplementing this because it needs an include that may be fragile on some platforms (D51219)

Fri, Aug 24, 10:56 AM
Hahnfeld added a comment to D51226: [OpenMP][libomptarget] rework of fatal error reporting.

I don't understand this: In the last review you said that we need the complicated FatalMessage and now you are reverting that?!?

Fri, Aug 24, 10:44 AM