|Anonymous | Login | Signup for a new account||2022-01-25 15:33 CET|
|Main | My View | View Issues|
|Viewing Issue Advanced Details|
|ID||Category||Severity||Reproducibility||Date Submitted||Last Update|
|0000092||[libFirm] API||tweak||have not tried||2011-11-09 04:21||2011-12-24 03:47|
|ETA||none||Fixed in Version||Product Version||development|
|Summary||0000092: Register classes have a NULL mode|
Actually, I don't know whether it's bad or not, but I tracked a bug down to this point, and I don't know what to do next.
The bug appears when I build a 'main' function, itself calling a 'print' function, and then returning 0. See the attachement 'main.png' to see the corresponding graph.
The bug does not happen during the construction, but during the translation to ASM code, because of 'be_main'. In 'adjust_call' at ir/be/beabi:724, an assert occurs when a node is created for the register 'vf7' of class 'ia32_vfp', which has a NULL mode. That leads to the assert in 'new_ir_node' at ir/ir/irnode:147, which requires that the mode must be non-null.
Maybe I'm just doing it wrong. But I don't understand right now why IR nodes are created in the backend.
|Steps To Reproduce|
|Tags||No tags attached.|
main.png [^] (56,955 bytes) 2011-11-09 04:21
dump.png [^] (71,874 bytes) 2011-11-09 04:22
|The firm-graph looks fine to me. It looks like the backend isn't initialized properly. Do you have a be_opt_register() call before ir_init()? It shouldn't be necessary but I think I spotted a bug in libfirm where it fails when the call isn't there.|
I tried to add be_opt_register() before (or even after) ir_init(), it fails anyway.
But then, discovering the be.h file, I read about be_lower_for_target(), which was not in the Neuestutorial. Adding this function just before be_main() solved the problem.
I then removed be_opt_register() and it still works.
I can't say whether it's the behavior you would expect.
By the way, my intention with this code was to update the Neuestutorial. Now it seems to work, I will send you the link soon.
Hmm interesting... We should probably change the backend to call be_lower_for_target() if the user hasn't done so before (it's after all just a tool for users who want to control when this lowering happens, if they don't care they shouldn't have to call it).
BTW: After your bugreport I also looked at the Neuestutorial wikipage again, and wondered how we can maintain this easily to keep up with new firm versions. I started transforming the wikipage into a literate program which compiles but doesn't work yet ( http://pp.info.uni-karlsruhe.de/git/firm-tutorial/ [^] ), if you are about to fix the code anyway, I'll just wait for your changes ;-)
|Well, if you automatically call be_lower_for_target(), there is no need to provide it via the API ;)|
The API is there for controlling when the graph is lowered. There are valid reasons that the frontend wants to perform further optimisations on the lowered graph before passing it to the backend.
Nonetheless if you don't care you shouldn't have to call be_lower_for_target.
|fixed in 5609f2c7223b8482d8c2d9d79163608e6eec7cc0|
|2011-11-09 04:21||Bloutiouf||New Issue|
|2011-11-09 04:21||Bloutiouf||File Added: main.png|
|2011-11-09 04:22||Bloutiouf||File Added: dump.png|
|2011-11-09 13:49||Matze||Note Added: 0000134|
|2011-11-09 14:27||Bloutiouf||Note Added: 0000135|
|2011-11-09 15:22||Matze||Note Added: 0000136|
|2011-11-10 00:58||Bloutiouf||Note Added: 0000137|
|2011-11-10 16:27||Matze||Note Added: 0000138|
|2011-11-10 16:35||Bloutiouf||Note Added: 0000139|
|2011-11-10 17:01||Matze||Note Added: 0000140|
|2011-11-10 17:01||Matze||Assigned To||=> Matze|
|2011-11-10 17:01||Matze||Status||new => resolved|
|2011-11-10 17:01||Matze||Resolution||open => fixed|
|2011-12-24 03:47||Matze||Status||resolved => closed|
|Mantis 1.1.5[^] Copyright © 2000 - 2008 Mantis Group|