Cryptic compiler error

Factual Questions
1

I’m trying to compile some code (using g77, on a PowerPC Mac OSX 10.4), and it’s failing with the following error messages:


/var/tmp//ccXtd3UB.s:34201:Parameter syntax error (parameter 2)
/var/tmp//ccXtd3UB.s:34203:Parameter syntax error (parameter 2)

The ccXtd3UB part varies each time I try to run the compiler (the cc seems to be constant, but the rest appears to be randomly generated), but all the rest of the error message appears to be consistent. On the basis that ccXtd3UB.s looks like a filename (maybe a temporary file that’s created in the course of compilation?), I tried searching my computer for anything with that name, but came up empty (and I’m not sure what the double slash would be for in the path, anyway). Googling for “Parameter syntax error (parameter 2)” gives a number of hits for people who appear to have the same problem (although their *.s parts appear to be nonrandom), but I can’t find any solutions.

Any help?

2

I don’t suppose you could post the relevant code?

3

GCC uses the “.s” suffix for the object code generated before it inputs them into the assembler (you can output them directly by putting a -S flag).

Beyond that, I got nuthin’.

4

I think your compiler is using opcodes your hardware doesn’t know. GCC has flags to change what architecture is targeted (or at least block it from using problematic subsets of instruction sets), so you might be able to fix it by using those.

Do PowerPC’s still have their own (not x86) instruction sets?

5

Err…replace “object code” with “assembly code” in that post.

Sorry for triple post.

6

You could try gfortran and see if you get anything less cryptic. I know they have precompiled binaries for 10.5 ppc, but not sure if you can get 10.4 ppc to work for you.

7

Yes, it’s a completely different architecture.

Chronos - the randomly-generated temp directory is where gcc is storing files before they are assembled and/or linked. The double-slash is irrelevant (it means the same thing as a single slash; it’s usually the result of something concatenating a directory path with a subpath and not paying attention to the slashes. In any case, Unix filesystem semantics ignore extra slashes.)

But you’re probably going to have to look at the actual code or compiler settings to figure out what’s going on. PowerPC is not a particularly popular architecture these days, so it can cause problems.

8

Indistinguishable, the code is somewhere in the vicinity of 200 pages long, and I can’t tell which particular piece of it is causing this problem.

Simplicio, I’ll try digging up those architecture flags, and see if that helps.

iamnotbatman, gfortran apparently adheres to a slightly different standard than g77, which causes it to throw a whole host of other errors. I know that I really should change things to be more generally compliant, but I’m having a hard enough time getting this old dinosaur compliant with one standard.

Tomorrow I’ll try just generating the assembly code, and seeing if I can make any sense of lines 34201 and 34203 (I assume that those are line numbers).

9

The firs thing I would try is compiling “Hello World.”
If that fails, then you have in incompatible version of GCC installed, or one of the zillions of switches set incorrectly.
Do you have Xcode installed?

10

As has been described, the compiler is generating assembly code that has en error. These can be a real pain to sort out. Especially as it in on line 34201. Those occasions where I have been beset with similar issues I have simply resorted to the divide and conquer technique. Just keep removing things from the source code to try to isolate the part of the the code that triggers the problem. In general I have found that it is often a slightly unusual use of the source language that is tripping the compiler up. Often you can end up with a very small program that exhibits the problem, and find that a trivial rearraingment of the code will solve it. I have seen problems solved with little more than changing the order of two lines, or changing a perfectly legal, if unusual use of the language to an equivalent but different expression. YMMV.

11

To clarify, the previous version of the code, in all its glory, compiled just fine. I’ve made some pretty widespread changes since that point, but none of the changes use any exotic language features; there are just a lot of them. I suppose I could try the older version again, just in case it’s something in the compiler that got broken.

The tricky thing here is that all of the changes I’ve made since the last working version all depend on each other-- I can’t think of any way to undo only some of the changes, without the compiler running into errors before the assembly stage.

12

If it’s any help, if you send me the code, I’ll dump it into Xcode 3.2.6 and have it spit out a Universal Binary (or see if it fails to compile).

13

By divide and conquer I mean a pretty brutal approach. Simply delete half the code. If you have function dependencies, just leave the function header and remove all the internal code. It becomes a binary search. 200 pages of code takes 8 splits to get you down to 1 page.

If you look in the assembly listing however you should be able to locate the function the error occurs in. (Hoping it is in a function and not in some static initialisation code.) In that case you have a very good start on how to whittle down the program to find the errant code. Just do a binary split on the function code. That should locate it to a line or expression pretty quickly.

14

No idea. I last used Fortan in the mid-1970’s.

[SPOILER]An Othello-playing program, written for fun, IIRC. The inner loops were written in 370 Assembler. (Later, in the early 1980’s I was asked to port a statistics package, written in Fortran III using, e.g. Overlay, to a Fortran I/II compiler [and to do so essentially for free]. Yes I know Fort.II was well obsolete then. I turned down the project.)

And the last time I worked with Mac internals was rewriting its ROm routines in the 1980’s.[/SPOILER]

Is there something about g77 that prevents source modulization? The only single .c files I’ve written with that length were mostly just data initializations.

Anyway, as others suggested, a simple gcc option will yield the .s file that assembles with the error message.

15

Thanks for the offer, but I’m continually having to edit this code and recompile it. Unless you think this might give some insight into the problem?

I can break it up into a separate file for each subroutine, but I’m not sure how helpful that is. Would it generate a separate assembly file for each input file?

Anyway, I double-checked that the previous version of the code still works, and I’ve poked around in the assembly file. The two problematic lines appear to be


        stwx r2,32760(r30)
        stwx r3,32760(r30)

The opcode stwx (which appears to mean “Store Word Indexed”) appears a few other places in the assembly file, but never with that same syntax. From grep, every place where it appears:


        stwx r2,32760(r30)
        stwx r3,32760(r30)
        stwx r2,r30,r0
        stwx r3,r30,r0
        stwx r2,r30,r0
        stwx r3,r30,r0
        stwx r2,r30,r0
        stwx r3,r30,r0
        stwx r2,r30,r0
        stwx r3,r30,r0

I also note that 32760 is suspiciously close to 32768, though I’m not sure what significance that has.

And I was also able to tell which subroutine this fragment comes from, and approximately where in that subroutine, but haven’t pinned it down to a single line yet (it’s unfortunately one of the larger subroutines).

16

What compiler options/optimization level are you using?

I am eating lunch and reading this on my phone, will look more closely when I get back to my office

17

Whatever the defaults are. I’d be more than willing to give up some optimization if it meant that it worked-- My computer is several thousand times more powerful than what this program was written for.

18

Curiouser and curiouser: I realized that the subroutine where the problem was occurring, despite being a long one, was actually one that had been modified very little from the previous working version. The only changes I made were to comment out a few lines for variables that weren’t being used, and added two lines. One of the added lines was a DIMENSION statement without which that subroutine won’t agree with the others, and the other one, when I commented it out, I still got the same problem.

19

When you say you are using the default compile options, do you mean you are directly invoking g77 and providing no options? Or are you using the options provided by someone else’s build script?

In any case, try it again using the “-O0 -g” flags. Make sure you are not providing an architecture using the -march or -mcpu flags.

20

No options specified. And I just tried -O0 -g , and it still didn’t work. :frowning: