[cfe-users] Binary instruction operand type - Fast-math-flags - Vectorized IR code

[Simona Simona via cfe-users]

Hello,

I'm using LLVM 3.4 and noticed that some of the IR binary instructions have
the following format:
 = frem [fast-math flags]*  ,  ; yields
ty:result

I'm mainly interested in extracting the type of the operands, regardless of
whether the fast-math-flags are set or not.
In the case above, that would be floating-point or vector.

Q1. I was just wondering if doing I.getOperand(0)->getType() would be
sufficient to extract the operands type.

Q2. Moreover, how can you extract the fast-math-flags?

Q3. I'd also appreciate it if someone could tell me what C/C++ source
code should I use to generate IR code that
includes some binary operation(s) with vector operands.

Many thanks,
Simona
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

[cfe-users] Anyway to prevent this code from compiling?

[Brian Cole via cfe-users]

Since switching over to clang C++11 on OS X, we had this weird C++ oddity 
surface while writing some new code. The problem is that ‘mutex’ is no longer a 
variable, it is a class type that can be interpreted as a function argument. 
That is, the following line of code can be interpreted as a function 
declaration now:

OELock lock(mutex);

Instead of a scoped lock acquisition as has been convention for some time now. 
The full code to recreate the subtle bug is as follows:

#include 

using namespace std;

struct OEMutex
{
  void Acquire() {}
  void Release() {}
};

static OEMutex _mutex;

class OELock
{
  OEMutex &_mutex;
  OELock();
  OELock(const OELock&);
  OELock& operator=(const OELock&);

public:
  OELock(OEMutex &mutex) : _mutex(mutex) { _mutex.Acquire(); }
  ~OELock() { _mutex.Release(); }
};

int main()
{
  OELock lock(mutex);
}

Ideally, we would like the compilation to fail and tell the user the ‘mutex’ 
variable can not be found. Any clever C++ trick to do that? We’ve tried 
declaring the move constructors of OELock to be private, but it still compiles 
(maybe that’s SFINAE?).

Thanks,
Brian

___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

Re: [cfe-users] Anyway to prevent this code from compiling?

[don hinton via cfe-users]

Try using initialization list syntax.  That way the parser won't think you
are declaring a function.

OELock lock{mutex};



On Mon, Feb 29, 2016 at 12:02 PM, Brian Cole via cfe-users <
cfe-users@lists.llvm.org> wrote:

> Since switching over to clang C++11 on OS X, we had this weird C++ oddity
> surface while writing some new code. The problem is that ‘mutex’ is no
> longer a variable, it is a class type that can be interpreted as a function
> argument. That is, the following line of code can be interpreted as a
> function declaration now:
>
> OELock lock(mutex);
>
> Instead of a scoped lock acquisition as has been convention for some time
> now. The full code to recreate the subtle bug is as follows:
>
> #include 
>
> using namespace std;
>
> struct OEMutex
> {
>   void Acquire() {}
>   void Release() {}
> };
>
> static OEMutex _mutex;
>
> class OELock
> {
>   OEMutex &_mutex;
>   OELock();
>   OELock(const OELock&);
>   OELock& operator=(const OELock&);
>
> public:
>   OELock(OEMutex &mutex) : _mutex(mutex) { _mutex.Acquire(); }
>   ~OELock() { _mutex.Release(); }
> };
>
> int main()
> {
>   OELock lock(mutex);
> }
>
> Ideally, we would like the compilation to fail and tell the user the
> ‘mutex’ variable can not be found. Any clever C++ trick to do that? We’ve
> tried declaring the move constructors of OELock to be private, but it still
> compiles (maybe that’s SFINAE?).
>
> Thanks,
> Brian
>
>
> ___
> cfe-users mailing list
> cfe-users@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
>
>
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

Re: [cfe-users] Anyway to prevent this code from compiling?

[Brian Cole via cfe-users]

Was hoping for something that would be C++03 compatible as well since we still 
have C++03 compilers to target as well.

From: don hinton mailto:hinto...@gmail.com>>
Date: Monday, February 29, 2016 at 10:38 AM
To: Brian L Cole mailto:co...@eyesopen.com>>
Cc: "cfe-users@lists.llvm.org" 
mailto:cfe-users@lists.llvm.org>>
Subject: Re: [cfe-users] Anyway to prevent this code from compiling?

Try using initialization list syntax.  That way the parser won't think you are 
declaring a function.

OELock lock{mutex};



On Mon, Feb 29, 2016 at 12:02 PM, Brian Cole via cfe-users 
mailto:cfe-users@lists.llvm.org>> wrote:
Since switching over to clang C++11 on OS X, we had this weird C++ oddity 
surface while writing some new code. The problem is that ‘mutex’ is no longer a 
variable, it is a class type that can be interpreted as a function argument. 
That is, the following line of code can be interpreted as a function 
declaration now:

OELock lock(mutex);

Instead of a scoped lock acquisition as has been convention for some time now. 
The full code to recreate the subtle bug is as follows:

#include 

using namespace std;

struct OEMutex
{
  void Acquire() {}
  void Release() {}
};

static OEMutex _mutex;

class OELock
{
  OEMutex &_mutex;
  OELock();
  OELock(const OELock&);
  OELock& operator=(const OELock&);

public:
  OELock(OEMutex &mutex) : _mutex(mutex) { _mutex.Acquire(); }
  ~OELock() { _mutex.Release(); }
};

int main()
{
  OELock lock(mutex);
}

Ideally, we would like the compilation to fail and tell the user the ‘mutex’ 
variable can not be found. Any clever C++ trick to do that? We’ve tried 
declaring the move constructors of OELock to be private, but it still compiles 
(maybe that’s SFINAE?).

Thanks,
Brian


___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users


___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

Re: [cfe-users] Anyway to prevent this code from compiling?

[don hinton via cfe-users]

you could try adding an extra set of parentheses, but you won't get as good
an error message.

OELock lock((mutex));

On Mon, Feb 29, 2016 at 1:15 PM, Brian Cole  wrote:

> Was hoping for something that would be C++03 compatible as well since we
> still have C++03 compilers to target as well.
>
> From: don hinton 
> Date: Monday, February 29, 2016 at 10:38 AM
> To: Brian L Cole 
> Cc: "cfe-users@lists.llvm.org" 
> Subject: Re: [cfe-users] Anyway to prevent this code from compiling?
>
> Try using initialization list syntax.  That way the parser won't think you
> are declaring a function.
>
> OELock lock{mutex};
>
>
>
> On Mon, Feb 29, 2016 at 12:02 PM, Brian Cole via cfe-users <
> cfe-users@lists.llvm.org> wrote:
>
>> Since switching over to clang C++11 on OS X, we had this weird C++ oddity
>> surface while writing some new code. The problem is that ‘mutex’ is no
>> longer a variable, it is a class type that can be interpreted as a function
>> argument. That is, the following line of code can be interpreted as a
>> function declaration now:
>>
>> OELock lock(mutex);
>>
>> Instead of a scoped lock acquisition as has been convention for some time
>> now. The full code to recreate the subtle bug is as follows:
>>
>> #include 
>>
>> using namespace std;
>>
>> struct OEMutex
>> {
>>   void Acquire() {}
>>   void Release() {}
>> };
>>
>> static OEMutex _mutex;
>>
>> class OELock
>> {
>>   OEMutex &_mutex;
>>   OELock();
>>   OELock(const OELock&);
>>   OELock& operator=(const OELock&);
>>
>> public:
>>   OELock(OEMutex &mutex) : _mutex(mutex) { _mutex.Acquire(); }
>>   ~OELock() { _mutex.Release(); }
>> };
>>
>> int main()
>> {
>>   OELock lock(mutex);
>> }
>>
>> Ideally, we would like the compilation to fail and tell the user the
>> ‘mutex’ variable can not be found. Any clever C++ trick to do that? We’ve
>> tried declaring the move constructors of OELock to be private, but it still
>> compiles (maybe that’s SFINAE?).
>>
>> Thanks,
>> Brian
>>
>>
>> ___
>> cfe-users mailing list
>> cfe-users@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
>>
>>
>
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

Re: [cfe-users] Anyway to prevent this code from compiling?

[don hinton via cfe-users]

Or use initialization list with assignment:

OELock lock = {mutex};

On Mon, Feb 29, 2016 at 1:22 PM, don hinton  wrote:

> you could try adding an extra set of parentheses, but you won't get as
> good an error message.
>
> OELock lock((mutex));
>
> On Mon, Feb 29, 2016 at 1:15 PM, Brian Cole  wrote:
>
>> Was hoping for something that would be C++03 compatible as well since we
>> still have C++03 compilers to target as well.
>>
>> From: don hinton 
>> Date: Monday, February 29, 2016 at 10:38 AM
>> To: Brian L Cole 
>> Cc: "cfe-users@lists.llvm.org" 
>> Subject: Re: [cfe-users] Anyway to prevent this code from compiling?
>>
>> Try using initialization list syntax.  That way the parser won't think
>> you are declaring a function.
>>
>> OELock lock{mutex};
>>
>>
>>
>> On Mon, Feb 29, 2016 at 12:02 PM, Brian Cole via cfe-users <
>> cfe-users@lists.llvm.org> wrote:
>>
>>> Since switching over to clang C++11 on OS X, we had this weird C++
>>> oddity surface while writing some new code. The problem is that ‘mutex’ is
>>> no longer a variable, it is a class type that can be interpreted as a
>>> function argument. That is, the following line of code can be interpreted
>>> as a function declaration now:
>>>
>>> OELock lock(mutex);
>>>
>>> Instead of a scoped lock acquisition as has been convention for some
>>> time now. The full code to recreate the subtle bug is as follows:
>>>
>>> #include 
>>>
>>> using namespace std;
>>>
>>> struct OEMutex
>>> {
>>>   void Acquire() {}
>>>   void Release() {}
>>> };
>>>
>>> static OEMutex _mutex;
>>>
>>> class OELock
>>> {
>>>   OEMutex &_mutex;
>>>   OELock();
>>>   OELock(const OELock&);
>>>   OELock& operator=(const OELock&);
>>>
>>> public:
>>>   OELock(OEMutex &mutex) : _mutex(mutex) { _mutex.Acquire(); }
>>>   ~OELock() { _mutex.Release(); }
>>> };
>>>
>>> int main()
>>> {
>>>   OELock lock(mutex);
>>> }
>>>
>>> Ideally, we would like the compilation to fail and tell the user the
>>> ‘mutex’ variable can not be found. Any clever C++ trick to do that? We’ve
>>> tried declaring the move constructors of OELock to be private, but it still
>>> compiles (maybe that’s SFINAE?).
>>>
>>> Thanks,
>>> Brian
>>>
>>>
>>> ___
>>> cfe-users mailing list
>>> cfe-users@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
>>>
>>>
>>
>
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

Re: [cfe-users] Anyway to prevent this code from compiling?

[Brian Cole via cfe-users]

Anything that can be added to the OELock class to make it uncompilable in that 
context? Getting users to change how they initialize a scoped lock won’t be 
easy.

A “just as easy” solution is to remove the ‘using namespace std’. I guess this 
is why Google banned ‘using namespace foo;’ in their style guide: 
https://google.github.io/styleguide/cppguide.html#Namespaces

From: don hinton mailto:hinto...@gmail.com>>
Date: Monday, February 29, 2016 at 11:22 AM
To: Brian L Cole mailto:co...@eyesopen.com>>
Cc: "cfe-users@lists.llvm.org" 
mailto:cfe-users@lists.llvm.org>>
Subject: Re: [cfe-users] Anyway to prevent this code from compiling?

you could try adding an extra set of parentheses, but you won't get as good an 
error message.

OELock lock((mutex));

On Mon, Feb 29, 2016 at 1:15 PM, Brian Cole 
mailto:co...@eyesopen.com>> wrote:
Was hoping for something that would be C++03 compatible as well since we still 
have C++03 compilers to target as well.

From: don hinton mailto:hinto...@gmail.com>>
Date: Monday, February 29, 2016 at 10:38 AM
To: Brian L Cole mailto:co...@eyesopen.com>>
Cc: "cfe-users@lists.llvm.org" 
mailto:cfe-users@lists.llvm.org>>
Subject: Re: [cfe-users] Anyway to prevent this code from compiling?

Try using initialization list syntax.  That way the parser won't think you are 
declaring a function.

OELock lock{mutex};



On Mon, Feb 29, 2016 at 12:02 PM, Brian Cole via cfe-users 
mailto:cfe-users@lists.llvm.org>> wrote:
Since switching over to clang C++11 on OS X, we had this weird C++ oddity 
surface while writing some new code. The problem is that ‘mutex’ is no longer a 
variable, it is a class type that can be interpreted as a function argument. 
That is, the following line of code can be interpreted as a function 
declaration now:

OELock lock(mutex);

Instead of a scoped lock acquisition as has been convention for some time now. 
The full code to recreate the subtle bug is as follows:

#include 

using namespace std;

struct OEMutex
{
  void Acquire() {}
  void Release() {}
};

static OEMutex _mutex;

class OELock
{
  OEMutex &_mutex;
  OELock();
  OELock(const OELock&);
  OELock& operator=(const OELock&);

public:
  OELock(OEMutex &mutex) : _mutex(mutex) { _mutex.Acquire(); }
  ~OELock() { _mutex.Release(); }
};

int main()
{
  OELock lock(mutex);
}

Ideally, we would like the compilation to fail and tell the user the ‘mutex’ 
variable can not be found. Any clever C++ trick to do that? We’ve tried 
declaring the move constructors of OELock to be private, but it still compiles 
(maybe that’s SFINAE?).

Thanks,
Brian


___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users



___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

Re: [cfe-users] Anyway to prevent this code from compiling?

[don hinton via cfe-users]

Yes, get ride of using namespace std.

The problem is the parsing.  Since mutex is a type, OELock lock(mutex) is
function declaration, i.e., returns an OELock and takes a mutex as a
parameter.

Could you use factory function instead?

lass OELock
{
  OEMutex &_mutex;
  OELock();
  //OELock(const OELock&); // is this a problem for you???
  OELock& operator=(const OELock&);
  OELock(OEMutex &_mutex) : _mutex(_mutex) { _mutex.Acquire(); }
public:
  static OELock makeLock(OEMutex &mutex) { return OELock(mutex);}

  ~OELock() { _mutex.Release(); }
};

OELock lock(mutex);

int main()
{
  OELock lock = OELock::makeLock(mutex);
}



On Mon, Feb 29, 2016 at 1:28 PM, Brian Cole  wrote:

> Anything that can be added to the OELock class to make it uncompilable in
> that context? Getting users to change how they initialize a scoped lock
> won’t be easy.
>
> A “just as easy” solution is to remove the ‘using namespace std’. I guess
> this is why Google banned ‘using namespace foo;’ in their style guide:
> https://google.github.io/styleguide/cppguide.html#Namespaces
>
> From: don hinton 
> Date: Monday, February 29, 2016 at 11:22 AM
>
> To: Brian L Cole 
> Cc: "cfe-users@lists.llvm.org" 
> Subject: Re: [cfe-users] Anyway to prevent this code from compiling?
>
> you could try adding an extra set of parentheses, but you won't get as
> good an error message.
>
> OELock lock((mutex));
>
> On Mon, Feb 29, 2016 at 1:15 PM, Brian Cole  wrote:
>
>> Was hoping for something that would be C++03 compatible as well since we
>> still have C++03 compilers to target as well.
>>
>> From: don hinton 
>> Date: Monday, February 29, 2016 at 10:38 AM
>> To: Brian L Cole 
>> Cc: "cfe-users@lists.llvm.org" 
>> Subject: Re: [cfe-users] Anyway to prevent this code from compiling?
>>
>> Try using initialization list syntax.  That way the parser won't think
>> you are declaring a function.
>>
>> OELock lock{mutex};
>>
>>
>>
>> On Mon, Feb 29, 2016 at 12:02 PM, Brian Cole via cfe-users <
>> cfe-users@lists.llvm.org> wrote:
>>
>>> Since switching over to clang C++11 on OS X, we had this weird C++
>>> oddity surface while writing some new code. The problem is that ‘mutex’ is
>>> no longer a variable, it is a class type that can be interpreted as a
>>> function argument. That is, the following line of code can be interpreted
>>> as a function declaration now:
>>>
>>> OELock lock(mutex);
>>>
>>> Instead of a scoped lock acquisition as has been convention for some
>>> time now. The full code to recreate the subtle bug is as follows:
>>>
>>> #include 
>>>
>>> using namespace std;
>>>
>>> struct OEMutex
>>> {
>>>   void Acquire() {}
>>>   void Release() {}
>>> };
>>>
>>> static OEMutex _mutex;
>>>
>>> class OELock
>>> {
>>>   OEMutex &_mutex;
>>>   OELock();
>>>   OELock(const OELock&);
>>>   OELock& operator=(const OELock&);
>>>
>>> public:
>>>   OELock(OEMutex &mutex) : _mutex(mutex) { _mutex.Acquire(); }
>>>   ~OELock() { _mutex.Release(); }
>>> };
>>>
>>> int main()
>>> {
>>>   OELock lock(mutex);
>>> }
>>>
>>> Ideally, we would like the compilation to fail and tell the user the
>>> ‘mutex’ variable can not be found. Any clever C++ trick to do that? We’ve
>>> tried declaring the move constructors of OELock to be private, but it still
>>> compiles (maybe that’s SFINAE?).
>>>
>>> Thanks,
>>> Brian
>>>
>>>
>>> ___
>>> cfe-users mailing list
>>> cfe-users@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
>>>
>>>
>>
>
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

Re: [cfe-users] Anyway to prevent this code from compiling?

[Jim Porter via cfe-users]

On 2/29/2016 12:15 PM, Brian Cole via cfe-users wrote:

Was hoping for something that would be C++03 compatible as well since we
still have C++03 compilers to target as well.


If you're #including , haven't you locked yourself into C++11 (or 
better) anyway? In that case, you should use curly braces for your 
initializer (or at least stop saying `using namespace std;`).


For existing code where `mutex` is a global variable, you'll be fine. If 
you add


  #include 
  using namespace std;

to existing code, you'll get a compiler error because the name `mutex` 
is now ambiguous.


If you wanted to warn about this in *all* cases, you'd need an 
additional warning to detect function declarations in local scope, since 
that's what C++ would treat this as. Clang doesn't have such a warning, 
but perhaps you could convince someone to add it.


- Jim


___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users