[
https://issues.apache.org/jira/browse/TS-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741026#comment-13741026
]
Phil Sorber edited comment on TS-302 at 8/15/13 2:57 PM:
---------------------------------------------------------
[~i.galic], I could definitely use those in ClusterHandler and ClusterMachine.
The others I would have to test. For instance, the code makes a lot of
assumptions about INK_MD5 members that's why I had to make that an anonymous
union and we kept 'b' in there. We could definitely clean that up too, but
probably in a different patch.
Also, those two instances in ClusterHandler and ClusterMachine should be using
more generic network functions to output the IP too. As they are right now,
they don't support IPv6.
was (Author: psudaemon):
[~i.galic], I could definitely use those in ClusterHandler and
ClusterMachine. The others I would have to test. For instance, the code makes a
lot of assumptions about INK_MD5 members that's why I had to make that an
anonymous union and we kept 'b' in there. We could definitely clean that up
too, but probably in a different patch.
> -fstrict-aliasing optimizer generates bad code
> ----------------------------------------------
>
> Key: TS-302
> URL: https://issues.apache.org/jira/browse/TS-302
> Project: Traffic Server
> Issue Type: Improvement
> Components: Cleanup
> Reporter: Miles Libbey
> Assignee: Phil Sorber
> Priority: Minor
> Fix For: 3.5.2
>
> Attachments: no-no-fstrict-alias.patch, ts-302.patch
>
>
> (moving from yahoo bug 525119)
> Original description
> by Leif Hedstrom 4 years ago at 2005-12-16 08:41
> Not sure if this is a compiler bug or a code issue on our side, but enabling
> the
> -fstrict-aliasing optimization option generates faulty code. This optimization
> technique is enabled implicitly with -Os, -O2 and -O3, so for now I'm
> explicitly
> turning it off with
> -O3 -fno-strict-aliasing
> This solves the problem where the traffic server would return data of 0 or 1
> length out of the cache. This initially looked like the cache corruption
> problem, but is completely different and unrelated. The cache corruption
> problem
> has been fixed and closed.
> I'm opening this bug as a reminder, at some point we should isolate which code
> triggers the strict-aliasing problem, and confirm if it's a compiler bug or a
> problem in our code.
>
>
> Comment 1
> by Michael Bigby 4 years ago at 2005-12-16 09:07:40
> I'm recommending that we get Ed's input on this. He may some insight compiler
> issues...
>
>
> Comment 2
> by Leif Hedstrom 4 years ago at 2005-12-16 10:02:07
> That'd be great!
> We haven't had a chance yet to review the code that might be affecting this,
> it's obviously something with unions and how the compiler handles
> storage/alignment on the members.
>
>
> Comment 3
> by Ed Hall 4 years ago at 2006-03-03 11:46:52
> This is with gcc 2.95.3, correct? There have been a number of complaints
> around
> the 'net about problems with -fstrict-aliasing. I've not really looked very
> deeply into it, though I should mention that certain C code was known at the
> time to malfunction when by-the-standard aliasing rules were enforced
> (starting
> with the Linux kernel).
> In essense, the -fstrict-aliasing optimizations assume that any particular
> part
> of memory accessed via a specific type of pointer won't be accessed as another
> type. There are a set of optimizations that are safe only when it can be
> guaranteed that a given bit of memory hasn't been manipulated via pointer; if
> the compiler assumes that the rather arcane C aliasing rules have been
> followed
> ("aliasing" in this case meaning accessing a given bit of memory with more
> than
> one type of pointer), there are more situations where such optimizations can
> be
> applied. Code which uses type casts where unions might be more appropriate is
> the most likely to break aliasing rules.
> In any case, gcc 3/4 is less aggressive (and perhaps less buggy) in applying
> the
> C aliasing rules, and has added warnings for obvious violations. It's never
> been clear to me if gcc 2.95.3 was actually broken or not, or if there simply
> was a lot of code out there that ran afoul of the standard.
>
>
> Comment 4
> by Leif Hedstrom 4 years ago at 2006-03-03 12:50:22
> Actually, the problem only occured after we converted the code from gcc-2.9x
> to
> gcc-3.4.4. We have since cleared out a *lot* of compiler warnings (thousands
> and
> thousands), so maybe we should try again to compile without the
> -fno-strict-aliasing, and see if gcc will point us to some places where we do
> dangerous things. The code does some very scary things manipulating objects
> directly, by byte-offsets for instance.
> I think it's pretty easy to reproduce the problem, it basically renders the
> cache completely useless, returning objects of size 0 or 1.
>
>
> Comment 5
> by Ed Hall 4 years ago at 2006-03-03 16:44:04
> Ah, that makes sense. I just checked, and the -fstrict-aliasing option wasn't
> part of the -O2 optimizations on gcc 2.95, but got added sometime during gcc 3
> development.
>
>
> Comment 6
> by Ed Hall 4 years ago at 2006-03-03 16:46:43
> (Just to be clear, -fstrict-aliasing was *available* with gcc 2.95.3, it just
> wasn't activated by the -O optimization flags.)
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
