Re: [Mingw-w64-public] _mm_set1_epi64 and friends not declared in this scope for dvec.h

2014-02-25 Thread Adrien Nader 
Hi,

On Wed, Feb 19, 2014, Jacek Caban wrote:
 Hi Adrien,
 
 On 02/17/14 21:18, Adrien Nader wrote:
  On Wed, Feb 12, 2014, Kai Tietz wrote:
  2014-02-12 10:58 GMT+01:00 Jacek Caban ja...@codeweavers.com:
  On 02/12/14 08:57, Adrien Nader wrote:
  Hi,
 
  I recently stumbled on an issue where dvec.h gets included from intrin.h
  and triggers around 140 different not declared in this scope errors.
 
  Basically, there is an #include dvec.h (which is a C++-only header)
  near the top of intrin.h and the function declarations for non-SSE2
  bulds come later on (I guess that if SSE2 is used, the compiler already
  has declarations for them?). Since dvec.h uses functions which are
  declared later on, compilation errors out.
 
 
  Jacek told me over IRC that dvec/fvec/ivec .h probably shouldn't be
  included from intrin.h. I've tried remove them and my build issues went
  away.
  Should that change be commited? Should it also be backported to the
  stable branch?
  IMO we should remove them in trunk, but not stable branch (at least not
  without a delay). We won't know if we're breaking real world code until
  we do that.
 
  Jacek
  For trunk this change seems to be right.  For branches I agree to
  Jacek that we shouldn't do the change.
 
  Kai
  Back from my short vacations, patch would be:
 
diff --git a/trunk/mingw-w64-headers/crt/intrin.h 
  b/trunk/mingw-w64-headers/crt/intrin.h
index 6287610..2348e09 100644
--- a/trunk/mingw-w64-headers/crt/intrin.h
+++ b/trunk/mingw-w64-headers/crt/intrin.h
@@ -147,11 +147,6 @@ extern C {
 }
 #endif
 
-#if defined(__cplusplus)
-#include dvec.h
-#include fvec.h
-#include ivec.h
-#endif
 #endif
 
 #define __MACHINEX64 __MACHINE
 
  I have no idea what the commit message would be however. :P 
 
  Also, I agree that this should only go to trunk, not stable branches
  since it changes behaviour. It is however something I will integrate in
  win-builds.org.
 
 Thanks for the patch. I believe we may consider it as approved. Do you
 need me to commit the patch?
 

Sorry for the delay, I've commited this as rev 6501 intrinsics: don't
include {d,f,i}vec.h from inside intrin.h..

-- 
Adrien Nader

--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis  security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] _mm_set1_epi64 and friends not declared in this scope for dvec.h

2014-02-19 Thread Jacek Caban 
Hi Adrien,

On 02/17/14 21:18, Adrien Nader wrote:
 On Wed, Feb 12, 2014, Kai Tietz wrote:
 2014-02-12 10:58 GMT+01:00 Jacek Caban ja...@codeweavers.com:
 On 02/12/14 08:57, Adrien Nader wrote:
 Hi,

 I recently stumbled on an issue where dvec.h gets included from intrin.h
 and triggers around 140 different not declared in this scope errors.

 Basically, there is an #include dvec.h (which is a C++-only header)
 near the top of intrin.h and the function declarations for non-SSE2
 bulds come later on (I guess that if SSE2 is used, the compiler already
 has declarations for them?). Since dvec.h uses functions which are
 declared later on, compilation errors out.


 Jacek told me over IRC that dvec/fvec/ivec .h probably shouldn't be
 included from intrin.h. I've tried remove them and my build issues went
 away.
 Should that change be commited? Should it also be backported to the
 stable branch?
 IMO we should remove them in trunk, but not stable branch (at least not
 without a delay). We won't know if we're breaking real world code until
 we do that.

 Jacek
 For trunk this change seems to be right.  For branches I agree to
 Jacek that we shouldn't do the change.

 Kai
 Back from my short vacations, patch would be:

   diff --git a/trunk/mingw-w64-headers/crt/intrin.h 
 b/trunk/mingw-w64-headers/crt/intrin.h
   index 6287610..2348e09 100644
   --- a/trunk/mingw-w64-headers/crt/intrin.h
   +++ b/trunk/mingw-w64-headers/crt/intrin.h
   @@ -147,11 +147,6 @@ extern C {
}
#endif

   -#if defined(__cplusplus)
   -#include dvec.h
   -#include fvec.h
   -#include ivec.h
   -#endif
#endif

#define __MACHINEX64 __MACHINE

 I have no idea what the commit message would be however. :P 

 Also, I agree that this should only go to trunk, not stable branches
 since it changes behaviour. It is however something I will integrate in
 win-builds.org.

Thanks for the patch. I believe we may consider it as approved. Do you
need me to commit the patch?

Thanks,
Jacek

--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] _mm_set1_epi64 and friends not declared in this scope for dvec.h

2014-02-17 Thread Adrien Nader 
On Wed, Feb 12, 2014, Kai Tietz wrote:
 2014-02-12 10:58 GMT+01:00 Jacek Caban ja...@codeweavers.com:
  On 02/12/14 08:57, Adrien Nader wrote:
  Hi,
 
  I recently stumbled on an issue where dvec.h gets included from intrin.h
  and triggers around 140 different not declared in this scope errors.
 
  Basically, there is an #include dvec.h (which is a C++-only header)
  near the top of intrin.h and the function declarations for non-SSE2
  bulds come later on (I guess that if SSE2 is used, the compiler already
  has declarations for them?). Since dvec.h uses functions which are
  declared later on, compilation errors out.
 
 
  Jacek told me over IRC that dvec/fvec/ivec .h probably shouldn't be
  included from intrin.h. I've tried remove them and my build issues went
  away.
  Should that change be commited? Should it also be backported to the
  stable branch?
 
  IMO we should remove them in trunk, but not stable branch (at least not
  without a delay). We won't know if we're breaking real world code until
  we do that.
 
  Jacek
 
 For trunk this change seems to be right.  For branches I agree to
 Jacek that we shouldn't do the change.
 
 Kai

Back from my short vacations, patch would be:

  diff --git a/trunk/mingw-w64-headers/crt/intrin.h 
b/trunk/mingw-w64-headers/crt/intrin.h
  index 6287610..2348e09 100644
  --- a/trunk/mingw-w64-headers/crt/intrin.h
  +++ b/trunk/mingw-w64-headers/crt/intrin.h
  @@ -147,11 +147,6 @@ extern C {
   }
   #endif
   
  -#if defined(__cplusplus)
  -#include dvec.h
  -#include fvec.h
  -#include ivec.h
  -#endif
   #endif
   
   #define __MACHINEX64 __MACHINE

I have no idea what the commit message would be however. :P 

Also, I agree that this should only go to trunk, not stable branches
since it changes behaviour. It is however something I will integrate in
win-builds.org.

-- 
Adrien Nader

-- 
Adrien Nader

--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] _mm_set1_epi64 and friends not declared in this scope for dvec.h

2014-02-12 Thread Jacek Caban 
On 02/12/14 08:57, Adrien Nader wrote:
 Hi,

 I recently stumbled on an issue where dvec.h gets included from intrin.h
 and triggers around 140 different not declared in this scope errors.

 Basically, there is an #include dvec.h (which is a C++-only header)
 near the top of intrin.h and the function declarations for non-SSE2
 bulds come later on (I guess that if SSE2 is used, the compiler already
 has declarations for them?). Since dvec.h uses functions which are
 declared later on, compilation errors out.


 Jacek told me over IRC that dvec/fvec/ivec .h probably shouldn't be
 included from intrin.h. I've tried remove them and my build issues went
 away.
 Should that change be commited? Should it also be backported to the
 stable branch?

IMO we should remove them in trunk, but not stable branch (at least not
without a delay). We won't know if we're breaking real world code until
we do that.

Jacek

--
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] _mm_set1_epi64 and friends not declared in this scope for dvec.h

2014-02-12 Thread Kai Tietz 
2014-02-12 10:58 GMT+01:00 Jacek Caban ja...@codeweavers.com:
 On 02/12/14 08:57, Adrien Nader wrote:
 Hi,

 I recently stumbled on an issue where dvec.h gets included from intrin.h
 and triggers around 140 different not declared in this scope errors.

 Basically, there is an #include dvec.h (which is a C++-only header)
 near the top of intrin.h and the function declarations for non-SSE2
 bulds come later on (I guess that if SSE2 is used, the compiler already
 has declarations for them?). Since dvec.h uses functions which are
 declared later on, compilation errors out.


 Jacek told me over IRC that dvec/fvec/ivec .h probably shouldn't be
 included from intrin.h. I've tried remove them and my build issues went
 away.
 Should that change be commited? Should it also be backported to the
 stable branch?

 IMO we should remove them in trunk, but not stable branch (at least not
 without a delay). We won't know if we're breaking real world code until
 we do that.

 Jacek

For trunk this change seems to be right.  For branches I agree to
Jacek that we shouldn't do the change.

Kai

--
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] _mm_set1_epi64 and friends not declared in this scope for dvec.h

2014-02-11 Thread Adrien Nader 
Hi,

I recently stumbled on an issue where dvec.h gets included from intrin.h
and triggers around 140 different not declared in this scope errors.

Basically, there is an #include dvec.h (which is a C++-only header)
near the top of intrin.h and the function declarations for non-SSE2
bulds come later on (I guess that if SSE2 is used, the compiler already
has declarations for them?). Since dvec.h uses functions which are
declared later on, compilation errors out.


Jacek told me over IRC that dvec/fvec/ivec .h probably shouldn't be
included from intrin.h. I've tried remove them and my build issues went
away.
Should that change be commited? Should it also be backported to the
stable branch?

Jacek was also concerned about breakage of current code. I believe the
change is safe because there are probably few C++ codes around which
rely on the automatic inclusion of dvec (which would not work in many
cases anyway). I also believe that the authors of code which use these
headers will also prefer that we don't add a possibly ugly workaround
which would have to remain forever.


Also, I had tried something to fix the issue: move the #include dvec.h
to the bottom of intrin.h and, while fairly ugly, this fixed most of the
errors. The remaining errors[1] are because the declarations have been
commented-out in intrin.h but their use in dvec.h hasn't.
I can see two solutions:
- comment them out too in dvec.h, but then there should also be a way to
  test at compile-time for when these functions are available or not.
- uncomment the in intrin.h but if I've understood correctly, there's a
  concern they're not correct currently.


[1] _mm_shuffle_pd, _mm_slli_epi16, _mm_slli_epi32, _mm_slli_epi64,
_mm_srai_epi16, _mm_srai_epi32, _mm_srli_epi16, _mm_srli_epi32,
_mm_srli_epi64

PS: I will be away for a few days and will not be able to read or write
mails.

-- 
Adrien Nader

--
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public