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

[Andrew Stubbs]

On 25/05/11 13:43, Matthias Kretz wrote:
> I agree that it is much nicer to be able to use feature tests/macros
> instead of compiler-version ifdefs. But library headers really don't
> have any other way to work around compiler bugs or use new compiler
> features. One can not expect from library users that they will correctly
> define all required feature macros.

I meant that the header files that declare the functions should define 
the macros. They don't, and there's not much we can do about it.

> Regarding the development of distri compiler specifc code: I don't
> believe the macro would get much use other than the __GNUC_PATCHLEVEL__
> macro gets. Are you afraid of developers trying to cripple a distri they
> don't like? Can you come up with a scenario where a developer would make
> use of a distri specific define resulting in breakage on other distris?
> I find this very hard to imagine. (Yes, there are developers that do
> lots of stupid things, but the only thing to keep them from breaking
> stuff is to have them stop programming. ;-) )

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.

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.

> I understood you don't want to change the gcc 4.5.2 package at all? I'd
> be happy for any, whatsoever small update to Natty gcc-4.5 that makes it
> possible to work around the bug. So if you were to add the
> _MM_MASKSTORE_PS_NEEDS_NATTY_WORKAROUND define that would be a welcome
> help. I don't care much for how bad the ifdefs become. I can put that
> logic in an extra code section which defines my feature macros...

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.

> But I'd hate for these things to only be fixable after a lengthy
> discussion on a bugtracker, which is why I'd really like to have a macro
> do determine the differences from the vanilla GCC release. These kind of
> incompatibilities happened before and will happen again.

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.

Sorry, but for these reasons and the reasons I gave before, I really 
don't like the idea.

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