2024-10-16 00:10 AEDT

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000354mercuryBugpublic2014-08-30 08:55
Reporterchemoelectric 
Assigned Tozs 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformAMD64OSGentoo LinuxOS Versionnot applicable
Product Version 
Target VersionFixed in Version 
Summary0000354: Building mercury_cairo fails in version 14.01
DescriptionWhenever I attempt to build mercury_cairo with Mercury 14.01 I get a failure as follows:

Installing grade reg.gc.decldebug.stseg
Making Mercury/reg.gc.decldebug.stseg/x86_64-unknown-linux-gnu/Mercury/cs/cairo.c
Uncaught Mercury exception:
Software Error: transform_hlds.table_gen: predicate `transform_hlds.table_gen.type_save_category'/2: Unexpected: unexpected category
** Error making `Mercury/reg.gc.decldebug.stseg/x86_64-unknown-linux-gnu/Mercury/cs/cairo.c'.
Steps To Reproducemmc --make libmercury_cairo.install
Additional InformationI have tried both gcc-4.8.3 and gcc-4.9.1. My C library is glibc 2.19. My Cairo is version 1.12.16 and is located in /usr. (I adjusted Cairo.options to suit.)
TagsNo tags attached.
Attached Files
  • ? file icon bug354.m (2,632 bytes) 2014-08-24 23:14

-Relationships
+Relationships

-Notes

~0000763

juliensf (administrator)

The problem also occurs on the current master branch. I have uploaded a minimal test case for it.
Affected grades seem to be all those containing a debug or decldebug component.

~0000764

zs (developer)

I/O tabling has two main purposes. The first and more important is to allow the debugger to replay parts of the program execution for the programmer, which requires making I/O operations idempotent (so that we get the same results on the second, third etc "execution" as on the first). The second purpose is to let the person using the debugger actually see a list of the I/O actions, and their results.

I believe that the root of the problem here is that the compiler can do the second part only if it has access to the type_infos describing the types of the arguments of the I/O action. With the current infrastructure for representing typeclass information, this is not always possible in the presence of typeclass constraints on I/O action predicates. The reason is that polymorphism.m can hide the typeinfo for a type variable that is subject to a typeclass constraint arbitrarily deep inside the typeclass_info for that constraint, but the RTTI can encode such locations only up to a fixed depth (currently only the shallowest embedded is encodable). Rather than allow I/O tabling for SOME typeclass-constrained predicates but not others, the current system consistently does not allow it for any. Of course, the error indication could be better.

When I designed the I/O tabling system, I did NOT design it for I/O actions whose types include typeclass constraints. There were two reasons for this. First, none of the I/O actions in the Mercury standard library have typeclass constraints; second, I/O actions are written in languages like C, which themselves have no class system.

While fully fixing this limitation would be desirable, it would also be a huge amount of work. However, there are two possible short term fixes.

The first fix is actually a simple workaround. I haven't tested it with mercury_cairo, but it works with bug354.m: simply compile the module with the mmc flag --trace-table-io-only-retry. This tells the compiler to generate I/O tabling code that serves only the first purpose I mentioned above (making I/O actions idempotent in mdb), but not the second (printing those actions in mdb).
chemoelectric, please enable this flag for all the modules of mercury_cairo, and tell us what happens.

The second possible fix, which I will look into in the next few days, would make this unnecessary by automatically imposing the effect of --trace-table-io-only-retry on any I/O predicates that have typeclass constraints on them.

~0000765

juliensf (administrator)

The first workaround also works for the full mercury_cairo library. I'll add that workaround to the 14.01 branch.

~0000767

chemoelectric (reporter)

The workaround works for me, too.

~0000768

zs (developer)

Fix committed 2014 aug 30.
+Notes

-Issue History
Date Modified Username Field Change
2014-08-24 09:16 chemoelectric New Issue
2014-08-24 23:14 juliensf File Added: bug354.m
2014-08-24 23:15 juliensf Note Added: 0000763
2014-08-24 23:15 juliensf Assigned To => juliensf
2014-08-24 23:15 juliensf Status new => confirmed
2014-08-25 01:46 zs Assigned To juliensf => zs
2014-08-25 01:46 zs Status confirmed => assigned
2014-08-25 02:45 zs Note Added: 0000764
2014-08-25 03:30 juliensf Note Added: 0000765
2014-08-26 04:00 chemoelectric Note Added: 0000767
2014-08-30 08:55 zs Note Added: 0000768
2014-08-30 08:55 zs Status assigned => resolved
2014-08-30 08:55 zs Resolution open => fixed
+Issue History