On 23 February 2016 at 22:11, Marek Polacek wrote:
> On Tue, Feb 23, 2016 at 09:49:37PM +0530, Prathamesh Kulkarni wrote:
>
>> diff --git a/gcc/tree-vectorizer.c b/gcc/tree-vectorizer.c
>> index 2b25b45..a6af535 100644
>> --- a/gcc/tree-vectorizer.c
>> +++ b/gcc/tree-vectorizer.c
>> @@ -794,6 +794
We thank you for spreading malware via Office VBA macros.
Sincerly,
Le 24/02/2016 12:07, Abigail Jones a écrit :
Please see attached
On Tue, Feb 23, 2016 at 8:38 PM, Torvald Riegel wrote:
> I'd like to know, based on the GCC experience, how important we consider
> optimizations that may turn data dependencies of pointers into control
> dependencies. I'm thinking about all optimizations or transformations
> that guess that a po
Thanks Prathamesh and Joseph for your suggestions.
Here is my updated patch :
for test cases:
const int array[5] = {1, 2, 3};
const int array1[3] = {1, 2, 3, 6};
const int array2[4] = {1, 2, 3, 6, 89};
const int array3[5] = {1, 2, 3, 6, 89, 193};
const int array4[3] = {1, 2,
After discussion with the ARM port maintainers we have decided that now
is probably the right time to deprecate support for versions of the ARM
Architecture prior to ARMv4t. This will allow us to clean up some of
the code base going forwards by being able to assume:
- Presence of half-word data ac
On Wed, 24 Feb 2016, Richard Earnshaw (lists) wrote:
> After discussion with the ARM port maintainers we have decided that now
> is probably the right time to deprecate support for versions of the ARM
> Architecture prior to ARMv4t. This will allow us to clean up some of
Should this include -mar
Consider this example (derived from gcc.c-torture/execute/920726-1.c):
extern int a(int a, int b, int c, int d, int e, int f, const char *s1, const
char *s2) __attribute__((pure));
int
foo()
{
if (a(0,0,0,0,0,0,"abc","def") || a(0,0,0,0,0,0,"abc","ghi"))
return 0;
return 1
$ cat z.c && /home/msebor/build/gcc-trunk-svn/gcc/xgcc
-B/home/msebor/build/gcc-trunk-svn/gcc -Wall -Wextra -Wpedantic -xc z.c
struct S { unsigned i: 31; } s;
int i = _Generic (s.i, unsigned: 1);
z.c:2:19: error: ‘_Generic’ selector of type ‘unsigned int:31’ is not
compatible with any association
On Wed, 24 Feb 2016, DJ Delorie wrote:
> The real question is: are stack arguments call-clobbered or
> call-preserved? Does the answer depend on the "pure" attribute?
Stack area holding stack arguments should belong to the callee for tail-calls
to work (the callee will trash that area when laying
On 02/24/2016 01:42 PM, Alexander Monakov wrote:
On Wed, 24 Feb 2016, DJ Delorie wrote:
The real question is: are stack arguments call-clobbered or
call-preserved? Does the answer depend on the "pure" attribute?
Stack area holding stack arguments should belong to the callee for tail-calls
to
Hi,
A quick note to see if you would be interested in a discussion about RSA List
and the benefits it can bring your organization for your Marketing Initiatives.
Every contact will include: Company Name, Web Address, Contact Name, Verified
Email, Job Title, Application Type, Complete Mailing
On Wed, 24 Feb 2016, Martin Sebor wrote:
> > That can be avoided simply by using unary + in the controlling expression
> > of _Generic (just as using unary + will avoid an error from sizeof, if you
> > want to be able to apply that to expressions that might be bit-fields) -
> > or any of the other
Snapshot gcc-4.9-20160224 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20160224/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.9 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
See comment on (c) below
On Wed, Feb 24, 2016 at 1:53 PM Joseph Myers wrote:
>
> On Wed, 24 Feb 2016, Martin Sebor wrote:
>
> > > That can be avoided simply by using unary + in the controlling expression
> > > of _Generic (just as using unary + will avoid an error from sizeof, if you
> > > want t
On Wed, 24 Feb 2016, Wink Saville wrote:
> > (c) nothing defines semantics of conversion of out-of-range values to
> > bit-fields other than treating the width as part of the type (or in the
> > case of _Bool bit-fields, having the special wording to make it explicit
> > that those have the semant
On Wed, Feb 24, 2016 at 3:38 PM, Joseph Myers wrote:
> On Wed, 24 Feb 2016, Wink Saville wrote:
>
>> > (c) nothing defines semantics of conversion of out-of-range values to
>> > bit-fields other than treating the width as part of the type (or in the
>> > case of _Bool bit-fields, having the specia
16 matches
Mail list logo
