Bug 31677 - FYI: cairo-bentley-ottmann.c triggers bug in GCC 3.4.6 on Solaris/sparc
FYI: cairo-bentley-ottmann.c triggers bug in GCC 3.4.6 on Solaris/sparc
Status: RESOLVED NOTOURBUG
Product: cairo
Classification: Unclassified
Component: general
1.10.0
SPARC Solaris
: medium normal
Assigned To: Carl Worth
cairo-bugs mailing list
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-11-17 04:20 UTC by Jörn Clausen
Modified: 2012-04-04 06:20 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jörn Clausen 2010-11-17 04:20:08 UTC
Just for information, I don't really expect a fix (but please, surprise me):

Compiling cairo 1.10.0 on Solaris/sparc using GCC 3.4.6 triggers a bug in GCC:

  CC     cairo-bentley-ottmann.lo
cairo-bentley-ottmann.c: In function `edges_compare_x_for_y_general':
cairo-bentley-ottmann.c:425: internal compiler error: in expand_mult, at expmed.c:2653

The actual bug is probably hit in _cairo_int32x32_64_mul or _cairo_uint32x32_64_mul.

I try to build cairo within pkgsrc and at the moment cannot switch to another compiler. I don't think that bugs in such old versions of GCC get fixed. So if there is any possibility to fix this problem here, that would be great.

NB: Only Sparc is affected. GCC 3.4.6 on i386 compiles this without any errors.
Comment 1 Andrea Canciani 2010-11-25 01:15:55 UTC
(In reply to comment #0)
> Just for information, I don't really expect a fix (but please, surprise me):
> 
> Compiling cairo 1.10.0 on Solaris/sparc using GCC 3.4.6 triggers a bug in GCC:
> 
>   CC     cairo-bentley-ottmann.lo
> cairo-bentley-ottmann.c: In function `edges_compare_x_for_y_general':
> cairo-bentley-ottmann.c:425: internal compiler error: in expand_mult, at
> expmed.c:2653

Could you provide the full compiler output and the preprocessed file?

http://gcc.gnu.org/bugs/ explains how to do it (basically add "-v -save-temps"
to your CFLAGS).

This could make it possible to (try to) provide a workaround to the compiler bug.
Comment 2 M Joonas Pihlaja 2010-11-25 02:52:27 UTC
We were aware of this bug but in the final rush to 1.10 decided it wasn't really worth pursuing internal compiler errors further, especially for gcc that old.  Having looked at it some more now, it seems that the problem stems from gcc 3.4's buggy support for the __uint128_t datatype.  The following code triggers the bug as well:


#include <stdlib.h>
#include <inttypes.h>

int
main(int argc, char **argv)
{ 
  __uint128_t a = atol(argv[1]);
  a *= a;
  return 0;
}


As a workaround, you could disable using intrinsic 128 bit arithmetic in the cairo-wideint-type-private.h header by commenting out the block following the comment "/* gcc has a non-standard name */".  The problem had been fixed in later gcc releases, but I'm told gcc 4.5 has regressed.  A more robust fix (probably a link test for the wideint code) is needed avoid future regressions.