[Bug 780551] Re: incorrect interface in avxintrin.h

[Matthias Kretz]

On Wednesday 25 May 2011 15:18:57 Andrew Stubbs wrote:
> Never ascribe to malice that which can be adequately explained by
> incompetence! I forgot who said (something like) that, but it's
> certainly true in programming.

:) sure. Just checking what you meant by your previous statement.
 
> I know I've done things the lazy way, or misunderstood how to use things
> enough times myself, so I'm not going to trust others to be perfect.

Yeah, I agree with that. But with that argument you can basically shoot down 
any progress, because somebody might not be able to understand and apply it 
correctly. That's why I asked whether you can come up with an example of how 
the availability of a macro, which identifies the distribution, could lead to 
additional bugs. I just can't come up with anything.

> The code is frozen for anything but bug fixes, and even those have to be
> serious ones, I think. Adding a macro to a header is probably OK
> (Matthias?), but updating to 4.5.3 is out of the question.

Yeah, well. It's something I have never really understood about distributions. 
Upstream can be as throrough as they want in doing only bug-fixes in their 
patchlevel releases. Still there's this rule that the version number in 
released distributions may not change, even if it's all bug-fixes. So 
distribution users have to wait for the next distribution version for a fix 
(and new bugs: because often the minor or major version changed in the 
meantime) or use unsupported packages/compile from sources.
 
> I could add some sort of identifier to Linaro GCC, and Ubuntu GCC would
> pick that up.
> 
> But, so would half a dozen other distros (mostly embedded, I think).
> Each then add their own patches on top of that, potentially. These
> patches will fix bugs, add features, add bugs, and change random things
> to taste.
> 
> Does the Linaro identifier now mean anything? No, no more so than the
> GNU macros are working for you now.

Understood. But then I'd just call this badly implemented.

Every release (i.e. an update of a package is a new release; a different 
architecture OTOH is not a different release, because it's a well-defined 
difference) needs to be able to identify itself in some way.

Concrete ideas:
__GNUC_DISTRIBUTOR__: "Ubuntu"
__GNUC_DISTRIBUTOR_VERSION__: "1104"
__GNUC_DISTRIBUTOR_PATCHLEVEL__: "8"

Those macros ideally would become part of GCC proper and the values be 
settable via configure switches. I believe this scheme would solve all my 
problems and be understandable enough to both packagers and developers.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to gcc-4.5 in Ubuntu.
https://bugs.launchpad.net/bugs/780551

Title:
  incorrect interface in avxintrin.h

Status in Linaro GCC:
  New
Status in “gcc-4.5” package in Ubuntu:
  Won't Fix

Bug description:
  Binary package hint: gcc-4.5

  The following code compiles with vanilla GCC:
  __m128 m, x;
  float *mem;
  #if defined(__GNUC__) && __GNUC__ == 4 && (__GNUC_MINOR__ < 5 || (__GNUC_MINOR__ == 5 && __GNUC_PATCHLEVEL__ <= 2))
  _mm_maskstore_ps(mem, m, x);
  #else
  _mm_maskstore_ps(mem, _mm_castps_si128(m), x);
  #endif

  It fails to compile on Ubuntu because the interface of _mm_maskstore_ps was changed to the interface of GCC 4.5.3, but the version number was kept at 4.5.2.
  Which macro does Ubuntu GCC provide to check for this?

  For what it's worth, I believe this patch should be reverted in the
  GCC package, though it's probably too late already. I'd hope the
  updates to the gcc package would be good enough, though. Or consider
  to upgrade to 4.5.3 completely.

  Also, just to add a bit of perspective: I do nightly builds of a
  software project where GCC snapshots between even patch levels often
  exhibit miscompilations. I don't see how a distribution could sensibly
  take any patches from GCC between releases and release that as a given
  GCC package. A distribution has the means to ensure that its own
  packages compile, but that it executes correctly...? In this case you
  broke source compatibility without any means to distinguish the
  interface version. Since it only affects development for AVX it is no
  wonder that you don't notice. That hopefully doesn't imply that you
  don't care...

  ProblemType: Bug
  DistroRelease: Ubuntu 11.04
  Package: gcc 4:4.5.2-1ubuntu3
  ProcVersionSignature: Ubuntu 2.6.38-8.42-generic 2.6.38.2
  Uname: Linux 2.6.38-8-generic x86_64
  NonfreeKernelModules: nvidia
  Architecture: amd64
  Date: Tue May 10 16:13:13 2011
  InstallationMedia: Kubuntu 11.04 "Natty Narwhal" - Release amd64 (20110426.3)
  ProcEnviron:
   LANGUAGE=en_US:en
   PATH=(custom, user)
   LANG=en_US.UTF-8
   SHELL=/bin/zsh
  SourcePackage: gcc-defaults
  UpgradeStatus: No upgrade log present (probably fresh install)