Bug 31677

Summary: FYI: cairo-bentley-ottmann.c triggers bug in GCC 3.4.6 on Solaris/sparc
Product: cairo Reporter: Jörn Clausen <joern.clausen>
Component: generalAssignee: Carl Worth <cworth>
Status: RESOLVED NOTOURBUG QA Contact: cairo-bugs mailing list <cairo-bugs>
Severity: normal    
Priority: medium CC: jeff.martin
Version: 1.10.0   
Hardware: SPARC   
OS: Solaris   
Whiteboard:
i915 platform: i915 features:

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.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.