This is kind of stream-of-conciousness but I swear there's an
interesting new bit about 8 paragraphs down. :)
On 04/20/2016 07: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
Snapshot gcc-6-20160421 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/6-20160421/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-6
That basic tutorial code was last updated 3 years ago. I think we've
established pretty clearly that gcc does _not_ have full support of
what intel calls cilk plus. Offload not supported, and the 3 year old
basic introductory tutorial code from the cilkplus.org website doesn't
compile. I'm likely t
As I start to allow integer modes into vector registers, I need to revisit
MODES_TIEABLE_P. I'm wondering if MODES_TIEABLE_P is transitive?
For example, with the current Power8 system
1) Anything can go in GPRs
2) Currently, SFmode/DFmode/KFmode, and vectors can go in VSX registers
2016-04-21 7:09 GMT+03:00 Hal Ashburner :
> 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
On 21 April 2016 at 17:47, Jason Merrill wrote:
> On Thu, Apr 21, 2016 at 11:57 AM, Jonathan Wakely
> wrote:
>>
>> I once tried to write a gcc plugin that would check all names defined
>> by libstdc++ and ensure they were either in the reserved namespace, or
>> were in a whitelist of allowed names
On Thu, Apr 21, 2016 at 12:47 PM, Jason Merrill wrote:
> On Thu, Apr 21, 2016 at 11:57 AM, Jonathan Wakely
> wrote:
>>
>> I once tried to write a gcc plugin that would check all names defined
>> by libstdc++ and ensure they were either in the reserved namespace, or
>> were in a whitelist of allow
On 21 April 2016 at 15:32, Joel Sherrill wrote:
>> Those rules belong in a POSIX binding for C++, not in the C++
>> standard, but unfortunately the group working on that has been
>> inactive for some time.
>>
>> (In the absence of an official binding, I think a reasonable rule that
>> would work fo
On 4/21/2016 8:20 AM, Jonathan Wakely wrote:
On 21 April 2016 at 13:33, Szabolcs Nagy wrote:
On 21/04/16 12:52, Jonathan Wakely wrote:
On 21 April 2016 at 12:11, Szabolcs Nagy wrote:
the root cause is c++: c++ headers include random libc headers with
_GNU_SOURCE ftm so all sorts of unexpecte
On 21 April 2016 at 13:33, Szabolcs Nagy wrote:
> On 21/04/16 12:52, Jonathan Wakely wrote:
>> On 21 April 2016 at 12:11, Szabolcs Nagy wrote:
>>> the root cause is c++: c++ headers include random libc headers with
>>> _GNU_SOURCE ftm so all sorts of unexpected symbols are defined/declared.
>>
>> Y
Richard, thanks for explanation. I found an option
-fmerge-all-constants, which can help me work around for now.
BIngfeng
On Thu, Apr 21, 2016 at 11:15 AM, Richard Biener
wrote:
> On Thu, Apr 21, 2016 at 11:39 AM, Jonathan Wakely
> wrote:
>> On 21 April 2016 at 03:41, lh_mouse wrote:
>>> See t
On Thu, Apr 21, 2016 at 8:33 AM, Szabolcs Nagy wrote:
> On 21/04/16 12:52, Jonathan Wakely wrote:
>> On 21 April 2016 at 12:11, Szabolcs Nagy wrote:
>>> the root cause is c++: c++ headers include random libc headers with
>>> _GNU_SOURCE ftm so all sorts of unexpected symbols are defined/declared.
Hi,
On Thu, 21 Apr 2016, Szabolcs Nagy wrote:
> there is also , , usage and go-system.h is special.
> (and gmp.h includes when built with c++)
>
> so i can prepare a patch with INCLUDE_{MAP,SET,LIST} and remove the
> explicit libc/libstdc++ includes.
This.
> >> auto-profile.c
> >> diagnost
On 21/04/16 12:52, Jonathan Wakely wrote:
> On 21 April 2016 at 12:11, Szabolcs Nagy wrote:
>> the root cause is c++: c++ headers include random libc headers with
>> _GNU_SOURCE ftm so all sorts of unexpected symbols are defined/declared.
>
> Yes, I'd really like to be able to stop defining _GNU_S
On 21 April 2016 at 12:11, Szabolcs Nagy wrote:
> the root cause is c++: c++ headers include random libc headers with
> _GNU_SOURCE ftm so all sorts of unexpected symbols are defined/declared.
Yes, I'd really like to be able to stop defining _GNU_SOURCE
unconditionally. It needs some libstdc++ and
On 21/04/16 12:36, Richard Biener wrote:
> On Thu, Apr 21, 2016 at 1:11 PM, Szabolcs Nagy wrote:
>> building gcc6 using musl based gcc6 fails with symbol poisoning error
>> (details at the end of the mail).
>>
>> the root cause is c++: c++ headers include random libc headers with
>> _GNU_SOURCE ft
On Thu, Apr 21, 2016 at 1:11 PM, Szabolcs Nagy wrote:
> building gcc6 using musl based gcc6 fails with symbol poisoning error
> (details at the end of the mail).
>
> the root cause is c++: c++ headers include random libc headers with
> _GNU_SOURCE ftm so all sorts of unexpected symbols are defined
building gcc6 using musl based gcc6 fails with symbol poisoning error
(details at the end of the mail).
the root cause is c++: c++ headers include random libc headers with
_GNU_SOURCE ftm so all sorts of unexpected symbols are defined/declared.
since it's unlikely the c++ standard gets fixed (to
On Thu, Apr 21, 2016 at 11:39 AM, Jonathan Wakely wrote:
> On 21 April 2016 at 03:41, lh_mouse wrote:
>> See this example: http://coliru.stacked-crooked.com/a/048b4aa5046da11b
>>
>> In this example the function is called recursively.
>
> See the original email you replied to:
>
> "I understand if
This is the wrong mailing list for such questions, the gcc-help list
would be appropriate.
On 21 April 2016 at 02:11, 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
On 21 April 2016 at 03:41, lh_mouse wrote:
> See this example: http://coliru.stacked-crooked.com/a/048b4aa5046da11b
>
> In this example the function is called recursively.
See the original email you replied to:
"I understand if this function is recursive and pointer of the array
is involved, GCC
I agree with you on this example.
But in my original code, as Jonathan pointed out, is not recursive and
the address of "a" does not escape the function in any way. I believe
it is valid transformation.
BTW, LLVM compiles your example still by moving const array to rodata,
which I think is wrong
22 matches
Mail list logo
