Another cilk plus question:
Is op_ostream also considered to be outside of cilk plus?
https://www.cilkplus.org/docs/doxygen/include-dir/group___reducers_ostream.html
I am trying to compile the basic "Cilk Plus Tutorial Sources" code as
supplied at http://cilkplus.org/download
reducer-ostream-demo.c
See this example: http://coliru.stacked-crooked.com/a/048b4aa5046da11b
In this example the function is called recursively.
During each call a pointer to that local areay is appended to a static array of
pointers.
Should a new instance of that local array of const int be created every time,
abort
On 4/20/2016 7:18 PM, Andrew Pinski wrote:
On Thu, Apr 21, 2016 at 9:11 AM, Zan Lynx wrote:
I would like someone to look at this and tell me this is an already
fixed bug. Or that recent GCC patches may have fixed it. :-)
Or it would also be great to get some advice on building a reproducer
wit
On Thu, Apr 21, 2016 at 9:11 AM, Zan Lynx wrote:
> I would like someone to look at this and tell me this is an already
> fixed bug. Or that recent GCC patches may have fixed it. :-)
>
> Or it would also be great to get some advice on building a reproducer
> without needing to include many megabyte
I would like someone to look at this and tell me this is an already
fixed bug. Or that recent GCC patches may have fixed it. :-)
Or it would also be great to get some advice on building a reproducer
without needing to include many megabytes of proprietary code plus Boost.
I've been using Fedora 2
Thank you Ilya,
I now understand that gcc has full support for only the _language_
extensions of cilk plus. Perhaps the release notes might be updated to
note this.
Intel market #pragma offload(gfx) as a cilk plus feature. For example
slides 12-15 here:
https://meetingcpp.com/tl_files/mcpp/2015/ta
Snapshot gcc-4.9-20160420 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20160420/
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
On 20 April 2016 at 18:31, lh_mouse wrote:
> I tend to say clang is wrong here.
If you can't detect the difference then it is a valid transformation.
> Your identifier 'a' has no linkage. Your object designated by 'a' does not
> have a storage-class specifier.
> So it has automatic storage durat
H.J. Lu wrote:
On Tue, Apr 19, 2016 at 7:06 AM, Michael Matz wrote:
Hi,
On Tue, 19 Apr 2016, Richard Biener wrote:
So with all this it sounds that current protected visibility is just
broken and we should forgo with it, making it equal to default
visibility?
Like how? You mean in GCC regar
I tend to say clang is wrong here.
Quoting the standard:
ISO/IEC WG14 Draft N1570 (Programming languages — C):
[quote]
6.2.2 Linkages of identifiers
6 The following identifiers have no linkage: an identifier declared to be
anything other than
an object or a function; an identifier declared to be
On Wed, Apr 20, 2016 at 4:54 PM, Szabolcs Nagy wrote:
> On 13/04/16 14:01, Cristina Georgiana Opriceana wrote:
>> I bring to your attention SafeStack, part of a bigger research project
>> - CPI/CPS [1], which offers complete protection against stack-based
>> control flow hijacks.
>
> i think it do
Hi,
I came across the following issue.
int foo (int N)
{
const int a[10] = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9};
return a[N];
}
Compile with x86 O2
foo:
.LFB0:
.cfi_startproc
movslq %edi, %rdi
movl $0, -56(%rsp)
movl $1, -52(%rsp)
movl $2, -48(%rsp)
movl $3, -44(%rsp)
movl $4, -40(%rsp)
movl $5,
On 13/04/16 14:01, Cristina Georgiana Opriceana wrote:
> I bring to your attention SafeStack, part of a bigger research project
> - CPI/CPS [1], which offers complete protection against stack-based
> control flow hijacks.
i think it does not provide complete protection.
it cannot instrument the c
On Wed, 13 Apr 2016, Cristina Georgiana Opriceana wrote:
> Hello,
>
> I bring to your attention SafeStack, part of a bigger research project
> - CPI/CPS [1], which offers complete protection against stack-based
> control flow hijacks. I am interested in developing SafeStack for GCC
> and I would
One more question about block-scoped static objects:
>From compiled assembly I have learned that GCC uses a 64-bit integer guard to
>ensure once-initialization of static objects with block scopes.
Code in gcc/libstdc++-v3/libsupc++/guard.cc uses a global mutex to protect
multiple threads from ra
15 matches
Mail list logo
