436525 - Treehydra 'make check' failures on x86-64

Status: RESOLVED FIXED

(Developer Infrastructure :: Source Code Analysis, defect)

Description

[Benjamin Smedberg]

The following test fails when building treehydra on x86-64:

Test Failure: 

    Test command: /builds/gcc-dehydra/gcc-obj/gcc/cc1plus -quiet -fplugin=../gcc_dehydra.so -o /dev/null -fplugin-arg=test_intlit.js intlit.cc

    Failure msg: Expected 'OK' output; got 'ERR  TestCase   Error: 77ull != 9223372036854775885ull'

Test Failure: 

    Test command: /builds/gcc-dehydra/gcc-obj/gcc/cc1plus -quiet -fplugin=../gcc_dehydra.so -o /dev/null -fplugin-arg=test_numinfo.js numinfo.cc

    Failure msg: Expected 'OK' output; got 'ERR  TestCase   Error: 0ul != 0ull'


I'm happy to take suggestions... perhaps "long" and "long long" are the same type on x86-64 by default?

Comment 1

[David Mandelin [:dmandelin]]

See dehydra_intCstToString in dehydra.c. I see that the Mac version already has to deal with 64-bit values in the int constant fields, so it might as simple as enabling that code for x86-64.

Comment 2

[Vlad Sukhoy]

I concur with David. gcc's integers pretty-printer code is broken in different ways across different versions and platforms so we might as well settle with what we did on mac (the precondition is that  TREE_INT_CST_LOW(int_cst) is 64-bit int). IIRC 64-bit int support is an extension of printf, but I don't think it is a problem.

Comment 3

[Benjamin Smedberg]

Attachment: Fix for the first issue

This patches fixes one testcase but not the other. I'm still getting Error: 0ul != 0ull

Comment 4

[David Mandelin [:dmandelin]]

Looks like the remaining error is related to the ending part of the method, which incidentally is not controlled by the ifdef:

  if (type == long_integer_type_node || type == long_unsigned_type_node)
    strcat(buf, "l");
  else if (type == long_long_integer_type_node ||
           type == long_long_unsigned_type_node)
    strcat(buf, "ll");

Looks like:

- test case is looking for min value of uint64_t
- test case expects that to end in ull
- on your machine uint64_t is long?

I think the test case is probably what needs fixing.

Comment 5

[Benjamin Smedberg]

The test is "unsigned long long t = 0;" matches '0ull' I think... my current guess is that on 64-bit *targets* (not compiler!), "long" and "long long" are the exact same type, and it doesn't use the long_long_unsigned_type_node... but I haven't written the testcase to prove it yet.

Comment 6

[Vlad Sukhoy]

(In reply to comment #5)
> The test is "unsigned long long t = 0;" matches '0ull' I think... 
numinfo test needs fixing (probably just ignore suffixes), but I am not sure about the type nodes as intlit.cc apparently passes which wouldn't be the case if the nodes matched for all constants.

Comment 7

[Michael Kohler [:mkohler]]

This is a mass change. Every comment has "assigned-to-new" in it.

I didn't look through the bugs, so I'm sorry if I change a bug which shouldn't be changed. But I guess these bugs are just bugs that were once assigned and people forgot to change the Status back when unassigning.

Comment 8

[(dormant account)]

this was fixed a long time ago.