Norcroft compiler error

I was trying to compile the webp library (Google’s new web image format) and one of the source files has thrown up an error I have never seen before. I reproduce the compiler output.

cc -c -fahi -depend !Depend -throwback -memaccess -L22-S22-L41 -IC: -o o.quant c.quant
Norcroft RISC OS ARM C vsn 5.69 [27 Mar 2011]
“h.bit_writer”, line 55: Warning: lower precision in wider context: ‘+’
“c.quant”, line 445: Warning: lower precision in wider context: ‘*’
“c.quant”, line 721: Warning: lower precision in wider context: ‘>>’
“c.quant”, line 738: Fatal internal error: corrupted register 111 (used but not set)

Internal inconsistency: either resource shortage or compiler fault. If you cannot alter your program to avoid this failure, please contact your supplier
AMU: * exit (1) *

AMU: * ‘all’ not re-made because of errors *

Before I start bu****ing around with code that I do not fully understand, has anyone any hint on what to look for in the code. The original paper manual is very brief on possible cause. Apart from doing things like increasing wimp slot, it doesn’t offer much.

I am calling amu from a taskobey file simply with the -f makefilename argument.

Thanks in advance to anyone who can throw me a lifeline before I get out of my depth.

“Fatal internal error: corrupted register” sounds like a compiler bug to me.

Which version of the webp sources are you using? I’ve had a quick look at the latest sources and the error line numbers don’t seem to match up with the code, so I guess you’re using a slightly different version than what’s in their git repo. (I suspect the bug will still be there with the latest code – but without trying it myself I was just curious to see the exact code that’s causing it to trip up)

Thanks for the reply, Jeffrey.

The version I downloaded was libwebp-0/2/1 via the tar.gz archive.

The error line number corresponds to the closing brace of a function. Just this function is below (apologies for clogging up the forum).

static void PickBestIntra16(VP8EncIterator* const it, VP8ModeScore* const rd) {
  const VP8Encoder* const enc = it->enc_;
  const VP8SegmentInfo* const dqm = &enc->dqm_[it->mb_->segment_];
  const int lambda = dqm->lambda_i16_;
  const int tlambda = dqm->tlambda_;
  const uint8_t* const src = it->yuv_in_ + Y_OFF;
  VP8ModeScore rd16;
  int mode;

  rd->mode_i16 = -1;
  for (mode = 0; mode < 4; ++mode) {
    uint8_t* const tmp_dst = it->yuv_out2_ + Y_OFF;  // scratch buffer
    int nz;

    // Reconstruct
    nz = ReconstructIntra16(it, &rd16, tmp_dst, mode);

    // Measure RD-score
    rd16.D = VP8SSE16x16(src, tmp_dst);
    rd16.SD = tlambda ? MULT_8B(tlambda, VP8TDisto16x16(src, tmp_dst, kWeightY)) : 0;
    rd16.R = VP8GetCostLuma16(it, &rd16);
    rd16.R += VP8FixedCostsI16[mode];

    // Since we always examine Intra16 first, we can overwrite *rd directly.
    SetRDScore(lambda, &rd16);
    if (mode == 0 || rd16.score < rd->score) {
      CopyScore(rd, &rd16);
      rd->mode_i16 = mode;
      rd->nz = nz;
      memcpy(rd->y_ac_levels, rd16.y_ac_levels, sizeof(rd16.y_ac_levels));
      memcpy(rd->y_dc_levels, rd16.y_dc_levels, sizeof(rd16.y_dc_levels));
      SwapOut(it);
    }
  }
  SetRDScore(dqm->lambda_mode_, rd);   // finalize score for mode decision.
  VP8SetIntra16Mode(it, rd->mode_i16);
}

Line 721 is the rd16.SD = tlambda ? MULT…. line and 738 is the closing brace.

Did you ever get to the bottom of this? I just tried to compile SQLite and got a similar error:

"c.sqlite3", line 16442: Fatal internal error: genpointer1

Internal inconsistency: either resource shortage or compiler fault. If you
cannpot alter your program to avoid this failure, please contact your supplier
AMU: *** exit (1) ***

At first I thought that this was due to SQLite’s huge code file (155867 lines!) but it also happens if I use the “split” version which is spread over 100-or-so files.

Here’s the function where it’s falling over:

SQLITE_PRIVATE void sqlite3RegisterDateTimeFunctions(void){
  static SQLITE_WSD FuncDef aDateTimeFuncs[] = {
#ifndef SQLITE_OMIT_DATETIME_FUNCS
    FUNCTION(julianday,        -1, 0, 0, juliandayFunc ),
    FUNCTION(date,             -1, 0, 0, dateFunc      ),
    FUNCTION(time,             -1, 0, 0, timeFunc      ),
    FUNCTION(datetime,         -1, 0, 0, datetimeFunc  ),
    FUNCTION(strftime,         -1, 0, 0, strftimeFunc  ),
    FUNCTION(current_time,      0, 0, 0, ctimeFunc     ),
    FUNCTION(current_timestamp, 0, 0, 0, ctimestampFunc),
    FUNCTION(current_date,      0, 0, 0, cdateFunc     ),
#else
    STR_FUNCTION(current_time,      0, "%H:%M:%S",          0, currentTimeFunc),
    STR_FUNCTION(current_date,      0, "%Y-%m-%d",          0, currentTimeFunc),
    STR_FUNCTION(current_timestamp, 0, "%Y-%m-%d %H:%M:%S", 0, currentTimeFunc),
#endif
  };
  int i;
  FuncDefHash *pHash = &GLOBAL(FuncDefHash, sqlite3GlobalFunctions);
  FuncDef *aFunc = (FuncDef*)&GLOBAL(FuncDef, aDateTimeFuncs);

  for(i=0; i<ArraySize(aDateTimeFuncs); i++){
    sqlite3FuncDefInsert(pHash, &aFunc[i]);
  }
}

Line 16442 is the line just after the #ifndef.

FUNCTION itself is defined elsewhere (beginning on line 11307) and I don’t want to clutter the forum up too much so I’ll just leave a link to the source.

GCC may handle this a little better; I haven’t tried it yet.

GCC may handle this a little better; I haven’t tried it yet.

I compiled the source you linked to with native GCC 4.1.2
*gcc -c -static -sqlite3.c -osqlite3.o
*gcc -c -static shell.c -o shell.o
*gcc -static shell.o sqlite3.o -o sqlite -ldl
No errors, I dont understand why ldl is needed, I told someone not long ago that it doesn’t get used with static :-( It’s obviously needed in this case.
Edit: Using the option -DSQLITE_OMIT_LOAD_EXTENSION bypasses dlfcn.h and lets things link without ldl. For a static binary, I dont think they can dynamically load libraries so this is possibly the better way. The other option would be to go the full shared build way, making a libsqlite3.so and use the !SharedLibs app. I found one example
stating that -rdynamic would be used with -ldl

sqlite -version is a bit strange
3.8.10.2 2015-05-20 18:17:19 2ef4f3a5b1d1d0c4338f8243d40a2452cc1f7fe4
Edit: But that is right, it is the source ID (sqlite3.h)
but I’m not familiar with sqlite to test it further.
I did the same again with -DHAVE_READLINE and linking with lreadline, interactive now has line editing.
The default would be to drop through to #define SHELL_USE_LOCAL_GETLINE 1
Does that give any line editing when Norcroft is used?

Thanks for that. Interestingly it won’t compile under GCC 4.7.4 (it fills a DA up to 32 MB then crashes with an out of memory error) so I’m downloading 4.1.2 now.

The SQLite docs suggest using -DSQLITE_OMIT_LOAD_EXTENSION to avoid having to use -ldl although this results in a couple of features not working (admittedly ones that I’m not likely to use anyway).

It certainly looks like it could be a compiler bug. It’s best to file this in the bug tracker or email it to (ctools at riscosopen.org) as we can’t guarantee to monitor all the forums for bug reports.

It would be most helpful if you could try chopping pieces out of the function until you find the simplest code sequence which will generate the bug. In any case, we would need you to provide a preprocessed version of the source code (cc -E) as well as the command line used to ensure that we can reproduce it correctly.

I’ve begun trimming it down – I’ve knocked about 145000 lines out so far :)

Hopefully I’ll be able to get it down to just a few lines, but since I’m completely unfamiliar with the code I’m basically having to do a “chop out this chunk, compile, see whether it fails” so it might take me a little while!

Well, I managed to get to down to 18 lines (including whitespace) so I feel like I’ve accomplished that, it least :)

The bug tracker appears to be down at the moment (doesn’t load past a blank page) so I’ll try it again in the morning. If there’s no luck there then I’ll email it through.

For the curious, I’ve put the trimmed code here. [Edit: Forgot to say that I’ve also added a simple main() stub so that it’s actually a valid app].

The bug tracker appears to be down at the moment

Mmm, I’ve been getting this some times recently (today the bug tracker, the other day the forum when I clicked on Save Reply…):

This website is under heavy load
We’re sorry, too many people are accessing this website at the same time. We’re working on this problem. Please try again later.

Lame DDOS or RISC OS is now insanely popular?

I’m getting that message now too, but it was just “loading infinitely” a few hours ago.

I’m getting that message now too, but it was just “loading infinitely” a few hours ago.

I’ve seen that delay before but not for some months.

For what it’s worth, I saw a similar compiler issue when working on SharpEye a couple of weeks ago. I have just been sorting out permission to distribute the appropriate code. I haven’t succeeded in making it compile in any 5.68+ version of CC. However, it did compile with older Castle-era versions (5.5x?) and the -memaccess stuff, which ultimately allowed me to get a working alignment-safe version of SharpEye.

I guess one for Ben when he has some spare time (!!).

Bug tracker still isn’t behaving so I’ve emailed it.

Crisis averted! After closer investigation of the original code, it’s actually doing the wrong thing. The following is simplified, to make the problem obvious:

#if !defined(__GNUC__)
# define SQLITE_INT_TO_PTR(X)  ((void*)&((char*)0)[X])
#else
# define SQLITE_INT_TO_PTR(X)  ((void*)(X))
#endif

The second #define works correctly so it looks like a logic error in figuring out which compiler is being used (there are actually four cases in the original code but those two are the relevant ones). I’ll play with it a bit more when I get home.

The second #define works correctly so it looks like a logic error

You may get that right by defining __PTRDIFF_TYPE__ then it would bypass that logic. (line 8302 sqlite3.c)
Looking at that, without __PTRDIFF__ defined, nothing would be defined, quite confusing for sure.
Or perhaps just comment out everything in that block except for line 8312 and 8313.
# define SQLITE_INT_TO_PTR(X) ((void*)(X))
# define SQLITE_PTR_TO_INT(X) ((int)(X))
Have you tried the ANSI headers version? (HAVE_STDINT_H)
# define SQLITE_INT_TO_PTR(X) ((void*)(intptr_t)(X))
# define SQLITE_PTR_TO_INT(X) ((int)(intptr_t)(X))

Edit:If line 8305 was altered to exclude Norcroft as well as GNUC you would then drop through to line 8312 OK I think. I dont know what the macro for Norcroft is but
#elif !defined(__GNUC__) && !defined(__NORC__)
type of thing.

((void*)&((char*)0)[X])

The compiler probably shouldn’t crash, even on dodgy code, but still…
File this under “Reasons why we love C”! That sort of thing makes my brain¹ hurt.

¹ Contrary to popular belief, I do actually have one…err…somewhere <rummage><rummage>

Defining PTRDIFF and/or HAVE_STDINT_H were on my to-do list :)

Hopefully there’s a macro for Norcroft too; the code’s a bit odd as it’ll catch “not GNUC” before checking for STDINT! I’m home in 4 hours…

As for the code itself, yup, it makes my brain hurt too (I’m fairly sure that I have one!)

#elif !defined(__GNUC__) && !defined(__CC_NORCROFT)

does the trick :)

Now to handle all the other errors (which aren’t crashing the compiler!)

That looks correct, but we /are/ assuming Norcroft cannot do GNUC functions across the board, if it could, (I have no idea) then it would be more correct to define GNUC if CC_NORCROFT is present.
Otherwise there may be other instances where you have to compliment the check for GNUC.

That change is the only one required; it compiles with no other changes. I know that I mentioned “other errors” but those ended up being fixable by adding “CDEFINES = -DSQLITE_THREADSAFE=0 -DSQLITE_OS_OTHER” to the makefile.