-
2009.10.28 10:50 "Re: [Tiff] Number of images in a multi-tiff file?", by Brad Hards
-
2009.10.28 16:22 "Re: [Tiff] Number of images in a multi-tiff file?", by Frank Warmerdam
-
2009.10.28 17:47 "Re: [Tiff] Number of images in a multi-tiff file?", by Mark Pereira
-
2009.10.29 17:43 "Re: [Tiff] Tiff Digest, Vol 65, Issue 9", by Richard Nolde
- 2009.10.28 17:46 "Re: [Tiff] extending tags in "a"ppend mode? - solved", by Juergen Buchmueller
- 2009.10.28 22:43 "[Tiff] Libtiff release soon, please advise", by Bob Friesenhahn
- 2009.10.29 18:08 "Re: [Tiff] Tiff Digest, Vol 65, Issue 9", by Bob Friesenhahn
- 2009.10.29 18:21 "Re: [Tiff] Tiff Digest, Vol 65, Issue 9", by Toby Thain
-
2009.10.29 17:43 "Re: [Tiff] Tiff Digest, Vol 65, Issue 9", by Richard Nolde
-
2009.10.28 17:47 "Re: [Tiff] Number of images in a multi-tiff file?", by Mark Pereira
-
2009.10.28 16:22 "Re: [Tiff] Number of images in a multi-tiff file?", by Frank Warmerdam
2009.10.29 02:58 "Re: [Tiff] Libtiff release soon, please advise", by Bob Friesenhahn
On Wed, 28 Oct 2009, Edward Lam wrote:
I only looked at what caught my eye on the list. Bug 2001 seems like important low hanging fruit to do before final release:
http://bugzilla.maptools.org/show_bug.cgi?id=2001
Basically, it is saying that we should be adding -fno-strict-aliasing to the gcc (3+?) compiler options when compiling with -O2. Probably none of libtiff was written with strict aliasing in mind? If so, it sounds like a good and easy thing to do for avoiding potential bad code generation.
I agree that these issues should be avoided, but don't think that -fno-strict-aliasing is the answer since it surely makes the code slower. I did fix many of the aliasing warnings. The CVS HEAD version only produces these from the library code:
libtiff/tif_dirread.c: In function 'TIFFFetchNormalTag':
libtiff/tif_dirread.c:2922: warning: dereferencing pointer 'value.235' does break strict-aliasing rules
libtiff/tif_dirread.c:2922: note: initialized from here
libtiff/tif_dirread.c:2942: warning: dereferencing pointer 'value.239' does break strict-aliasing rules
libtiff/tif_dirread.c:2942: note: initialized from here
Several utilities produce such warnings, and particularly 'tiffcrop' in CVS HEAD spews lots of them.
The libtiff from CVS branch-3-9 (which would be 3.9.2) produces no aliasing warnings from the library, and just a few warnings about uninitialized variables in some of the utilities. I am not sure why tiffcrop in branch-3-9 does not spew the same sort of warnings that it does in CVS HEAD, but I suspect that it was developed against release 3.9.X code.
The GCC (4.4.2) flags used for testing compilation are
-g -O2 -Wall -Winline -W -Wformat-security -Wpointer-arith
-Wdisabled-optimization -Wno-unknown-pragmas
Can you please re-check your builds with CVS libtiff and see if you see similar results?
Bob
--
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/