Skip to content

Handling of std::conditional by Cling in ROOT 6.32.02. #16119

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
1 task done
ktf opened this issue Jul 26, 2024 · 8 comments · May be fixed by #19032
Open
1 task done

Handling of std::conditional by Cling in ROOT 6.32.02. #16119

ktf opened this issue Jul 26, 2024 · 8 comments · May be fixed by #19032
Assignees
Labels

Comments

@ktf
Copy link
Contributor

ktf commented Jul 26, 2024

Check duplicate issues.

  • Checked for duplicates

Description

When running with 6.32.02 the ALICE reconstruction we were plagued by errors like the following:

./itstpcMatch.log[16548:itstpc-track-writer]: Error in TStreamerInfo::Build: o2::dataformats::AbstractRef<25,5,2>, unknown type: typename std::conditional<(32> mRef

which were not there when using 6.30.0. We have since been able to workaround this by doing:

https://github.com/AliceO2Group/AliceO2/pull/13310/files

however I was wondering if this is not some more serious issue. In particular I am puzzled by the "(32" template argument, which seems to indicate some weird memory overwrite / macro expansion of NBIT.

Reproducer

I do not have a simple reproducer.

ROOT version

6.32.02

Installation method

aliBuild

Operating system

Linux

Additional context

No response

@ktf ktf added the bug label Jul 26, 2024
@dpiparo
Copy link
Member

dpiparo commented Jul 26, 2024

I quickly tried to see whether the name normalisation had a bug, and that is not obvious

template<int NBIT>
struct S {
  using type = typename std::conditional<(NBIT > 32), uint64_t, typename std::conditional<(NBIT > 16), uint32_t, typename std::conditional<(NBIT > 8), uint16_t, uint8_t>::type>::type>;
};

void a(){
  using T = typename S<32>::type;
  auto c = TClass::GetClass(typeid(T));
  cout << c->GetName() << endl;
  // gives conditional<false,ULong64_t,unsigned int>
}

@ktf
Copy link
Contributor Author

ktf commented Jul 26, 2024

Indeed, that I tried as well and I can confirm it works also for us ... It looks like you need the whole parent class.

@ktf
Copy link
Contributor Author

ktf commented Aug 23, 2024

Ok, I have a very trivial reproducer. In our environment, when running the following on the root prompt:

root [19] TClassEdit::GetNormalizedName(foo, "std::conditional<(NBIT > 32), uint64_t, typename std::conditional<(NBIT > 16), uint32_t, typename std::conditional<(NBIT > 8), uint16_t, uint8_t>::type>::type>::type")

I get:

root [20] foo
(std::string &) "conditional<(NBIT>"

@ktf
Copy link
Contributor Author

ktf commented Aug 23, 2024

actually, even easier:

root [23] TClassEdit::GetNormalizedName(foo, "std::conditional<1 > 32, int, float>")
root [24] foo
(std::string &) "conditional<1>"

@ktf
Copy link
Contributor Author

ktf commented Aug 25, 2024

For the record, I confirm also that your example works for me a well. However I also have:

root [4] TClassEdit::GetNormalizedName(foo, "std::conditional<(1 > 32), int, float>")
root [5] foo
(std::string &) "conditional<(1>"

which is exactly the wrong behaviour I originally reported...

@ktf
Copy link
Contributor Author

ktf commented Aug 25, 2024

BTW, TClassEdit::GetNormalizedName is also broken in 6.30.01, so I suspect the issue we had is due to the way it is being used by TStreamerInfo::Build.

@ktf
Copy link
Contributor Author

ktf commented Sep 4, 2024

Any news on this issue? Do you need anything else on my side? Apparently my workaround prevents reading old data, so we might have to go back to the version which breaks.

@ktf
Copy link
Contributor Author

ktf commented Oct 31, 2024

Any update on this?

@dpiparo dpiparo assigned dpiparo and unassigned pcanal Jun 15, 2025
silverweed pushed a commit to silverweed/root that referenced this issue Jun 16, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants