Libtiff release soon, please advise

[Bob Friesenhahn]

I plan to cut new libtiff releases soon.  While I don't intend to fix
all existing (or many) known bugs before those releases are cut (and
there are many bugs listed in libtiff bugzilla), this would be a good
time to remind of any dire issues known to exist which should
definitely be fixed before a libtiff release.

The bug tracker for libtiff is here:

   http://bugzilla.maptools.org/buglist.cgi?product=libtiff

Thanks,

Bob
--
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
_______________________________________________
Tiff mailing list: Tiff@...
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/

[Edward Lam]

Bob Friesenhahn wrote:
> I plan to cut new libtiff releases soon.  While I don't intend to fix
> all existing (or many) known bugs before those releases are cut (and
> there are many bugs listed in libtiff bugzilla), this would be a good
> time to remind of any dire issues known to exist which should
> definitely be fixed before a libtiff release.

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.

Regards,
-Edward
_______________________________________________
Tiff mailing list: Tiff@...
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/

[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@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
_______________________________________________
Tiff mailing list: Tiff@...
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/

[Edward Lam]

Bob Friesenhahn wrote:

> 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
>>
> 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:
> ... <snip> ...

That's fine if someone has/will look at these to determine if they're
real problems. I haven't. :)

> Several utilities produce such warnings, and particularly 'tiffcrop' in
> CVS HEAD spews lots of them.

It's probably easy to introduce unless we build with the extra
-Wstrict-aliasing=2 compiler?

> 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.  

Sorry, I had somehow mistakenly thought that we were looking at a 4.0
release. :embarrassed:

> Can you please re-check your builds with CVS libtiff and see if you see
> similar results?

I'm not sure if this is directed to me in particular. I had not checked
in the first place since my usual development platform is on Win64. I
trust your results are correct. :)

Regards,
-Edward

_______________________________________________
Tiff mailing list: Tiff@...
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/

[Bob Friesenhahn]

On Wed, 28 Oct 2009, Edward Lam wrote:

> It's probably easy to introduce unless we build with the extra
> -Wstrict-aliasing=2 compiler?

I am not familiar with that one yet.

>> 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.
>
> Sorry, I had somehow mistakenly thought that we were looking at a 4.0
> release. :embarrassed:

To clarify, I expect to cut a release from both HEAD and branch-3-9,
but the HEAD release would be just another beta.  It is not fair doing
one without the other and they both include similar improvements.

> I'm not sure if this is directed to me in particular. I had not checked in
> the first place since my usual development platform is on Win64. I trust your
> results are correct. :)

I did see a couple of bug reports about warnings under Win64 and think
they are still open.  Since I don't have it, I don't test on it.

Bob
--
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
_______________________________________________
Tiff mailing list: Tiff@...
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/

[Bob Friesenhahn]

I added -Wstrict-aliasing=2 to the libtiff build options and I see
that many more warnings are produced.  I am not sure how afraid we
should be of these warnings since the software has continued to work.

Bob
--
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
_______________________________________________
Tiff mailing list: Tiff@...
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/

[Edward Lam]

Bob Friesenhahn wrote:
> I added -Wstrict-aliasing=2 to the libtiff build options and I see that
> many more warnings are produced.  I am not sure how afraid we should be
> of these warnings since the software has continued to work.

Yes, it's probably fine. The gcc manual says that -Wstrict-aliasing=2
can give false positives.

FWIW, I just tried compiling CVS HEAD with gcc 4.3.3 and compiler
options "-g -O2 -Wall -Wstrict-aliasing=2" and there were no aliasing
warnings. I did get some 64-bit warnings in tif_unix.c though. Looks
like gcc 4.4 has changed warning behaviour in this regard?

I should also note that for Visual Studio 2005, there's no such thing as
a strict pointer aliasing compiler option. I think we're compiling
libtiff on Windows assuming pointer aliasing.

To bring up a side issue since you're willing to look at warnings. Bug
2068 is a one line fix. :)

Cheers,
-Edward
_______________________________________________
Tiff mailing list: Tiff@...
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/