Thread overview
really stupid error
Apr 01, 2023
d007
Apr 01, 2023
user456
Apr 14, 2023
d007
Apr 14, 2023
Basile B.
Apr 14, 2023
Johan
Re: really stupid bug
Apr 01, 2023
user456
April 01, 2023
printf("test(v[0]=%p, v[1]=%p, v[2]=%p)\n", &(arr[0][0]), &(arr[0][1]), &(arr[0][2]));
ubyte RR = 0;
printf("test(v[0]=%p, v[1]=%p, v[2]=%p)\n", &(arr[RR][0]), &(arr[RR][1]), &(arr[RR][2]));

first line you get the write output, 3 diff value.

the seconds line you get 3 same value. change ubyte RR = 0 into emum RR = 0 fix the problem.

test with ldc2 1.32.0

April 01, 2023

On 4/1/23 5:37 AM, d007 wrote:

>
printf("test(v[0]=%p, v[1]=%p, v[2]=%p)\n", &(arr[0][0]), &(arr[0][1]), &(arr[0][2]));
ubyte RR = 0;
printf("test(v[0]=%p, v[1]=%p, v[2]=%p)\n", &(arr[RR][0]), &(arr[RR][1]), &(arr[RR][2]));

first line you get the write output, 3 diff value.

the seconds line you get 3 same value. change ubyte RR = 0 into emum RR = 0 fix the problem.

test with ldc2 1.32.0

Do you have a complete test case? If so, please file a bug report.

https://issues.dlang.org

-Steve

April 01, 2023

On Saturday, 1 April 2023 at 09:37:49 UTC, d007 wrote:

>
printf("test(v[0]=%p, v[1]=%p, v[2]=%p)\n", &(arr[0][0]), &(arr[0][1]), &(arr[0][2]));
ubyte RR = 0;
printf("test(v[0]=%p, v[1]=%p, v[2]=%p)\n", &(arr[RR][0]), &(arr[RR][1]), &(arr[RR][2]));

first line you get the write output, 3 diff value.

the seconds line you get 3 same value. change ubyte RR = 0 into emum RR = 0 fix the problem.

test with ldc2 1.32.0

I can confirm, it's a regression from v1.30 to v1.31, reported here https://github.com/ldc-developers/ldc/issues/4362.

April 01, 2023

On Saturday, 1 April 2023 at 18:18:21 UTC, Steven Schveighoffer wrote:

>

On 4/1/23 5:37 AM, d007 wrote:

>
printf("test(v[0]=%p, v[1]=%p, v[2]=%p)\n", &(arr[0][0]), &(arr[0][1]), &(arr[0][2]));
ubyte RR = 0;
printf("test(v[0]=%p, v[1]=%p, v[2]=%p)\n", &(arr[RR][0]), &(arr[RR][1]), &(arr[RR][2]));

first line you get the write output, 3 diff value.

the seconds line you get 3 same value. change ubyte RR = 0 into emum RR = 0 fix the problem.

test with ldc2 1.32.0

Do you have a complete test case? If so, please file a bug report.

https://issues.dlang.org

-Steve

I have created this https://godbolt.org/z/ePxshnvvc but I dont know if DMD is affected. That seems to be a bug specific to LDC.

April 14, 2023

On Saturday, 1 April 2023 at 18:41:26 UTC, user456 wrote:

>

I have created this https://godbolt.org/z/ePxshnvvc but I dont know if DMD is affected. That seems to be a bug specific to LDC.

Thanks.

thewilsonator from github suggestion turn on opaque pointers, it cause ldc crashed:

0  ldc2                     0x0000000108e41b37 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 39
1  ldc2                     0x0000000108e409e6 llvm::sys::RunSignalHandlers() + 198
2  ldc2                     0x0000000108e42190 SignalHandler(int) + 288
3  libsystem_platform.dylib 0x00007ff80ae11c1d _sigtramp + 29
4  libsystem_platform.dylib 0x0000000000000008 _sigtramp + 18446603370398409736
5  ldc2                     0x00000001086f9592 (anonymous namespace)::AccessAnalysis::createCheckForAccess(llvm::RuntimePointerChecking&, llvm::PointerIntPair<llvm::Value*, 1u, bool, llvm::PointerLikeTypeTraits<llvm::Value*>, llvm::PointerIntPairInfo<llvm::Value*, 1u, llvm::PointerLikeTypeTraits<llvm::Value*> > >, llvm::DenseMap<llvm::Value const*, llvm::Value*, llvm::DenseMapInfo<llvm::Value const*, void>, llvm::detail::DenseMapPair<llvm::Value const*, llvm::Value*> > const&, llvm::DenseMap<llvm::Value*, unsigned int, llvm::DenseMapInfo<llvm::Value*, void>, llvm::detail::DenseMapPair<llvm::Value*, unsigned int> >&, llvm::Loop*, unsigned int&, unsigned int, bool, bool) + 642
6  ldc2                     0x00000001086f7063 (anonymous namespace)::AccessAnalysis::canCheckPtrAtRT(llvm::RuntimePointerChecking&, llvm::ScalarEvolution*, llvm::Loop*, llvm::DenseMap<llvm::Value const*, llvm::Value*, llvm::DenseMapInfo<llvm::Value const*, void>, llvm::detail::DenseMapPair<llvm::Value const*, llvm::Value*> > const&, bool) + 867
7  ldc2                     0x00000001086f65df llvm::LoopAccessInfo::analyzeLoop(llvm::AAResults*, llvm::LoopInfo*, llvm::TargetLibraryInfo const*, llvm::DominatorTree*) + 6287
8  ldc2                     0x00000001086f86be llvm::LoopAccessAnalysis::run(llvm::Loop&, llvm::AnalysisManager<llvm::Loop, llvm::LoopStandardAnalysisResults&>&, llvm::LoopStandardAnalysisResults&) + 46
9  ldc2                     0x000000010732ebd8 llvm::detail::AnalysisPassModel<llvm::Loop, llvm::LoopAccessAnalysis, llvm::PreservedAnalyses, llvm::AnalysisManager<llvm::Loop, llvm::LoopStandardAnalysisResults&>::Invalidator, llvm::LoopStandardAnalysisResults&>::run(llvm::Loop&, llvm::AnalysisManager<llvm::Loop, llvm::LoopStandardAnalysisResults&>&, llvm::LoopStandardAnalysisResults&) + 40
10 ldc2                     0x00000001086fd0d2 llvm::AnalysisManager<llvm::Loop, llvm::LoopStandardAnalysisResults&>::getResultImpl(llvm::AnalysisKey*, llvm::Loop&, llvm::LoopStandardAnalysisResults&) + 722
11 ldc2                     0x00000001081e2015 llvm::LoopAccessInfo const& llvm::function_ref<llvm::LoopAccessInfo const& (llvm::Loop&)>::callback_fn<llvm::LoopLoadEliminationPass::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&)::$_0>(long, llvm::Loop&) + 101
12 ldc2                     0x00000001081df0ec eliminateLoadsAcrossLoops(llvm::Function&, llvm::LoopInfo&, llvm::DominatorTree&, llvm::BlockFrequencyInfo*, llvm::ProfileSummaryInfo*, llvm::ScalarEvolution*, llvm::AssumptionCache*, llvm::function_ref<llvm::LoopAccessInfo const& (llvm::Loop&)>) + 1452
13 ldc2                     0x00000001081dea29 llvm::LoopLoadEliminationPass::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) + 569
14 ldc2                     0x0000000107347f72 llvm::detail::PassModel<llvm::Function, llvm::LoopLoadEliminationPass, llvm::PreservedAnalyses, llvm::AnalysisManager<llvm::Function> >::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) + 18
15 ldc2                     0x0000000108ba00a8 llvm::PassManager<llvm::Function, llvm::AnalysisManager<llvm::Function> >::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) + 392
16 ldc2                     0x00000001070eb512 llvm::detail::PassModel<llvm::Function, llvm::PassManager<llvm::Function, llvm::AnalysisManager<llvm::Function> >, llvm::PreservedAnalyses, llvm::AnalysisManager<llvm::Function> >::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) + 18
17 ldc2                     0x0000000108ba40af llvm::ModuleToFunctionPassAdaptor::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) + 447
18 ldc2                     0x00000001070eb312 llvm::detail::PassModel<llvm::Module, llvm::ModuleToFunctionPassAdaptor, llvm::PreservedAnalyses, llvm::AnalysisManager<llvm::Module> >::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) + 18
19 ldc2                     0x0000000108b9eb89 llvm::PassManager<llvm::Module, llvm::AnalysisManager<llvm::Module> >::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) + 441
20 ldc2                     0x00000001092a4442 writeModule(llvm::Module*, char const*) + 8418
21 ldc2                     0x000000010929f1e0 ldc::CodeGenerator::writeAndFreeLLModule(char const*) + 1360
22 ldc2                     0x00000001092bc58f codegenModules(Array<Module*>&) + 7631
23 ldc2                     0x00000001091c6540 mars_mainBody(Param&, Array<char const*>&, Array<char const*>&) + 5136
April 14, 2023

On Friday, 14 April 2023 at 05:58:16 UTC, d007 wrote:

>

On Saturday, 1 April 2023 at 18:41:26 UTC, user456 wrote:

>

I have created this https://godbolt.org/z/ePxshnvvc but I dont know if DMD is affected. That seems to be a bug specific to LDC.

Thanks.

thewilsonator from github suggestion turn on opaque pointers, it cause ldc crashed:

Yeah I've discovered to my great surprise the other day that opaque pointers are not enabled yet but optionally supported. By coincidence at the same time I was just celebrating the transition to opaque pointers of another compiler... For LDC this is more complicated because (I believe) the LLVM IR is generated from another intermediate IR so the relationship with the original AST is not so obvious.

Anyway, no matter if the reg was caused by the initial support for opque ptrs, LLVM GEPs were generally more simple with typed pointers.

April 14, 2023

On Friday, 14 April 2023 at 07:22:13 UTC, Basile B. wrote:

>

On Friday, 14 April 2023 at 05:58:16 UTC, d007 wrote:

>

On Saturday, 1 April 2023 at 18:41:26 UTC, user456 wrote:

>

I have created this https://godbolt.org/z/ePxshnvvc but I dont know if DMD is affected. That seems to be a bug specific to LDC.

Thanks.

thewilsonator from github suggestion turn on opaque pointers, it cause ldc crashed:

Yeah I've discovered to my great surprise the other day that opaque pointers are not enabled yet but optionally supported. By coincidence at the same time I was just celebrating the transition to opaque pointers of another compiler... For LDC this is more complicated because (I believe) the LLVM IR is generated from another intermediate IR so the relationship with the original AST is not so obvious.

Anyway, no matter if the reg was caused by the initial support for opque ptrs, LLVM GEPs were generally more simple with typed pointers.

The problem was caused by invalid AST coming from the frontend (https://godbolt.org/z/ae7G8hccz).

Martin has changed LDC such that it can deal with such invalid AST here: https://github.com/ldc-developers/ldc/pull/4365

-Johan