Trac

trac@lists.einsteintoolkit.org

8708 discussions

#2832: possible race condition in LoopControl
by Erik Schnetter 05 Nov '24

05 Nov '24

#2832: possible race condition in LoopControl Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: Comment (by Erik Schnetter): Ah yes, silly me. We should be using `posix_memalign`. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2832/possible-race-con…

1 0

#2832: possible race condition in LoopControl
by Roland Haas 05 Nov '24

05 Nov '24

#2832: possible race condition in LoopControl Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: Comment (by Roland Haas): There’s `alignas` since C\+\+11: [https://en.cppreference.com/w/cpp/language/alignas](https://en.cppreference… though this may not be any different from `CCTK_ATTRIBUTE_ALIGN` and indeed ``` #include <vector> struct alignas(128) aligned_t { volatile int foo; }; std::vector<aligned_t> test_aligned_vector; aligned_t *aligned; void foo() { aligned = new aligned_t(); } ``` gives the same warning when compiled with `g++ -std=gnu++11 -c -Wall` \(only warns about `new` not about `std::vector` but I suspect that `std::vector` also does not align and only hides the issue because it internally uses a `void*` pointer for its storage\). -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2832/possible-race-con…

1 0

#2832: possible race condition in LoopControl
by Roland Haas 05 Nov '24

05 Nov '24

#2832: possible race condition in LoopControl Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: Comment (by Roland Haas): Oh, right. So that won’t quite prevent cache line sharing. Unfortunately I cannot check alignment with a static assert since both types are allocated dynamically \(`lc_thread_info_t` via a `new` the other as part of a `std::vector<lc_fine_thread_comm_t>` \(and I’d have no idea how that one would have interacted with the `CCTK_ATTRIBUTE_ALIGNED(128)`\). So I guess it would have to be using 2\*128 or at least 2 times the cache line size if that one is know at compile time. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2832/possible-race-con…

1 0

#2832: possible race condition in LoopControl
by Erik Schnetter 05 Nov '24

05 Nov '24

#2832: possible race condition in LoopControl Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: Comment (by Erik Schnetter): As you say, your padding doesn’t actually align the struct. The struct may thus be split across two cache lines. Since some architectures have 128-byte cache lines, you should instead pad to 2\*128 bytes. \(Intel CPUs have 64-byte cache lines and thus 128 bytes suffice there.\) You can instead also check the alignment \(see [https://en.cppreference.com/w/c/language/\_Alignof](https://en.cppreference…) with a static assertion. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2832/possible-race-con…

1 0

#2833: Null pointer dereference in AEILocalInterp
by Roland Haas 05 Nov '24

05 Nov '24

#2833: Null pointer dereference in AEILocalInterp Reporter: Erik Schnetter Status: open Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): Yes, I am not claiming it is coding style I would promote outside of AHFinderDirect. I am only asking about this in order to keep the files in AHFinderDirect themselves consistent. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2833/null-pointer-dere…

1 0

#1566: Update Cactus autoconf
by Roland Haas 05 Nov '24

05 Nov '24

#1566: Update Cactus autoconf Reporter: Erik Schnetter Status: new Milestone: Version: development version Type: enhancement Priority: major Component: Cactus Changes (by Roland Haas): responsible: [] (was ) kind: enhancement (was bug) priority: major (was minor) assignee: Roland Haas (was ) We are using autoconf 2.13 for Cactus. This release is by now 15 years old and doesn't support Fortran (nor modern C++ features). It is time to update. **Keyword:** -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1566/update-cactus-aut…

1 0

#1566: Update Cactus autoconf
by Roland Haas 05 Nov '24

05 Nov '24

#1566: Update Cactus autoconf Reporter: Erik Schnetter Status: new Milestone: Version: development version Type: bug Priority: minor Component: Cactus Comment (by Roland Haas): Please review -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1566/update-cactus-aut…

1 0

#1566: Update Cactus autoconf
by Roland Haas 05 Nov '24

05 Nov '24

#1566: Update Cactus autoconf Reporter: Erik Schnetter Status: new Milestone: Version: development version Type: bug Priority: minor Component: Cactus Comment (by Roland Haas): Pull request is here: [https://bitbucket.org/cactuscode/cactus/pull-requests/167](https://bitbucke… -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1566/update-cactus-aut…

1 0

#2818: failing tests with gcc-14
by Roland Haas 05 Nov '24

05 Nov '24

#2818: failing tests with gcc-14 Reporter: Roland Haas Status: open Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Changes (by Roland Haas): status: open (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2818/failing-tests-wit…

1 0

#2833: Null pointer dereference in AEILocalInterp
by Erik Schnetter 05 Nov '24

05 Nov '24

#2833: Null pointer dereference in AEILocalInterp Reporter: Erik Schnetter Status: open Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Erik Schnetter): This coding style is quite peculiar. Did you realize it’s not hierarchical? For example, the indentation does not separate two consecutive loops. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2833/null-pointer-dere…

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac