dwitte@gmail.com Reporter
	Description • 15 years ago

STR: for the c code (in test.c)

typedef struct  {
  unsigned char   classID;
  unsigned char   reserveLen;
  unsigned char   shiftout_MinHB;
} uShiftOutCell;

typedef const uShiftOutCell uShiftOutTable;

void foo(uShiftOutTable shift) { }


and the js script (in test.js)

require({ after_gcc_pass: "cfg" });
include('unstable/lazy_types.js'); // for flatten_chain()

function process_tree(fn) {
  print("FUNCTION: " + fn._decl_as_string.str);

  let type = TREE_TYPE(fn);
  let args = TYPE_ARG_TYPES(type);
  let params = [ type_string(TREE_VALUE(pt))
                 for (pt in flatten_chain(args)) 
                   if (TREE_CODE(TREE_VALUE(pt)) != VOID_TYPE) ];
  print("PARAMS " + params);
}


and the compiler invocation
/path/to/gcc -fplugin=/path/to/gcc_treehydra.so -fplugin-arg=/path/to/test.js /path/to/test.c


one gets:
FUNCTION: foo
/home/dwitte/builds/gcc-dehydra/dehydra/libs/gcc_print.js:45: JS Exception: c_common_type_for_mode failed
:0:	#0: Error("c_common_type_for_mode failed")
/home/dwitte/builds/gcc-dehydra/dehydra/libs/gcc_print.js:45:	#1: type_string((void 0))
/home/dwitte/builds/gcc-dehydra/dehydra/test/test.js:9:	#2: process_tree([object GCCNode])

(note that I'm running with a slightly patched gcc_print.js to produce that error message - see patch attached - to make the bug more evident). The problem is that TYPE_NAME(type) for the argument to foo() should give you a |const uShiftOutTable|, but it's instead null, and the wrong codepath is followed in type_string(). (The TREE_CODE of the arg is RECORD_TYPE, which is correct.) Instead, TYPE_NAME(type) should do the right thing, and the |type_decl && TREE_CODE(type_decl) == TYPE_DECL| codepath should be followed.

If g++ is invoked instead, the testcase works. If one or two of the |unsigned char|s from |struct uShiftOutCell| is removed, to make the struct fit into a short int or char respectively, it works. (Likewise if two are added.) If the |const| in |typedef const uShiftOutCell uShiftOutTable;| is removed, it works. So this is as minimal a testcase as I've found.

This could well be a quirk, or bug, in gcc itself.

	dwitte@gmail.com Reporter
	Comment 1 • 15 years ago

Er, I meant if one |unsigned char| is added, it works, because it fits in a long. If two are added, it still fails.

	dwitte@gmail.com Reporter
	Comment 2 • 15 years ago

The C and C++ prettyprinters seem to be doing the same thing here, so I'm thinking it's not an issue of disparity between the two.

	dwitte@gmail.com Reporter
	Comment 3 • 15 years ago

This is almost certainly a bug in the C frontend. For the gory details, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41172. I probably won't spend the time patching it, since we hit this instance precisely twice in our codebase. We can work around it, sort of, by crawling the variant chain to find the originating type.

	dwitte@gmail.com Reporter
	Comment 4 • 15 years ago

Worked around per bug 512887. So I'll call this fixed on our end.