On 06/01/2018 08:59 PM, Hrishikesh Kulkarni wrote:
> Hi,
> I have pushed the changes to github
> (https://github.com/hrisearch/gcc). Added a command line option for
> specific dumps of variables and functions used in IL e.g.
> -fdump-lto-list=foo will dump:
> Call Graph:
>
> foo/1 (foo)
> Type:
Hi
That should be 'adding to valgrind' which I mentioned in the following
paragraph.
A+
Paul
Original message
From: Jonathan Wakely
Date:2018/06/03 23:34 (GMT+01:00)
To: Paul Floyd
Cc: gcc@gcc.gnu.org
Subject: Re: Solaris issues
On 2 June 2018 at 11:29, Paul Floy
The internals manual in its description of the "matching constraint" says that
it works for cases where the in and out operands are somewhat different, such
as *p++ vs. *p. Obviously that is meant to cover post_inc side effects.
The curious thing is that auto-inc-dec.c specifically avoids doing
On 06/04/2018 07:31 AM, Paul Koning wrote:
> The internals manual in its description of the "matching constraint" says
> that it works for cases where the in and out operands are somewhat different,
> such as *p++ vs. *p. Obviously that is meant to cover post_inc side effects.
>
> The curious t
> On Jun 4, 2018, at 9:51 AM, Jeff Law wrote:
>
> On 06/04/2018 07:31 AM, Paul Koning wrote:
>> The internals manual in its description of the "matching constraint" says
>> that it works for cases where the in and out operands are somewhat
>> different, such as *p++ vs. *p. Obviously that i
On 06/04/2018 08:06 AM, Paul Koning wrote:
>
>
>> On Jun 4, 2018, at 9:51 AM, Jeff Law wrote:
>>
>> On 06/04/2018 07:31 AM, Paul Koning wrote:
>>> The internals manual in its description of the "matching constraint" says
>>> that it works for cases where the in and out operands are somewhat
>>
Hi Paul,
> I’ve been having 2 issues with GCC head on Solaris. Firstly. The build is
> currently broken
>
> gmake[3]: Leaving directory `/export/home/paulf/scratch/gcc/build'
> Comparing stages 2 and 3
> warning: gcc/cc1obj-checksum.o differs
> Bootstrap comparison failure!
> i386-pc-solaris2.11/
Hi Jonathan,
> On 2 June 2018 at 11:29, Paul Floyd wrote:
>> Secondly I’ve been doing some work on adding support for C++14 and C++17
>> sized/aligned new and delete operators.
>
> Aren't they already supported? I thought Solaris had aligned_alloc
> and/or posix_memalign?
posix_memalign had alre
> On Jun 4, 2018, at 10:09 AM, Jeff Law wrote:
>
> On 06/04/2018 08:06 AM, Paul Koning wrote:
>>
>>
>>> On Jun 4, 2018, at 9:51 AM, Jeff Law wrote:
>>>
>>> On 06/04/2018 07:31 AM, Paul Koning wrote:
The internals manual in its description of the "matching constraint" says
that i
On Fri, Jun 1, 2018 at 10:38 PM Andrew MacLeod wrote:
>
> On 06/01/2018 05:48 AM, Richard Biener wrote:
>
> On Wed, May 30, 2018 at 1:53 AM Andrew MacLeod wrote:
bah, gmail now completely mangles quoting :/
>
> This allows queries for a range on an edge, on entry to a block, as an
> operand on
On Mon, Jun 4, 2018 at 5:17 PM Richard Biener
wrote:>
> On Fri, Jun 1, 2018 at 10:38 PM Andrew MacLeod wrote:
> >
> > On 06/01/2018 05:48 AM, Richard Biener wrote:
> >
> > On Wed, May 30, 2018 at 1:53 AM Andrew MacLeod wrote:
>
> bah, gmail now completely mangles quoting :/
Ah no, you sent a mu
Hi all,
clang and VS2017 already support the Coroutines TS extensions.
For which gcc release is going to be foreseen the support for the
Coroutines TS extension?
Looking forward to your kind feedback about this extremely important aspect
of gcc.
Marco
On 4 June 2018 at 18:32, Marco Ippolito wrote:
> Hi all,
>
> clang and VS2017 already support the Coroutines TS extensions.
> For which gcc release is going to be foreseen the support for the
> Coroutines TS extension?
This has been discussed recently, search the mailing list.
It will be supporte
Hi!
Apologies if this isn't the right place for asking. For the problem
statement, I'll simply steal Ard's writeup [1]:
> KVM on ARM refuses to decode load/store instructions used to perform
> I/O to emulated devices, and instead relies on the exception syndrome
> information to describe the oper
Hi,
-fdump-lto-list will dump all the symbol list
-fdump-lto-list -demangle will dump all the list with symbol names demangled
-fdump-lto-symbol=foo will dump details of foo
The output(demangled) will be in tabular form like nm:
Symbol Table
Name Type Visibility
I am pleased to announce that the GCC Steering Committee has
appointed Martin Liska as GCOV co-maintainer.
Please join me in congratulating Martin on his new role.
Martin, please update your listing in the MAINTAINERS file.
Happy hacking!
David
> On 4 Jun 2018, at 16:50, Rainer Orth wrote:
>
> Hi Jonathan,
>
>> On 2 June 2018 at 11:29, Paul Floyd wrote:
>>> Secondly I’ve been doing some work on adding support for C++14 and C++17
>>> sized/aligned new and delete operators.
>>
>> Aren't they already supported? I thought Solaris had
On 06/04/2018 08:22 PM, David Edelsohn wrote:
I am pleased to announce that the GCC Steering Committee has
appointed Martin Liska as GCOV co-maintainer.
Hello.
I'm pleased to become co-maintainer of the GCOV infrastructure.
Thank you for the trust.
Please join me in congratu
On 06/04/2018 08:13 PM, Hrishikesh Kulkarni wrote:
Hi,
-fdump-lto-list will dump all the symbol list
I see extra new lines in the output:
$ lto1 -fdump-lto-list main.o
[..snip..]
Symbol Table
NameTypeVisibility
fwrite/15function
- Original Message -
> Hi Paul,
>
[Build issue on Solaris]
>
> this is PR target/85994. For the moment, you can just touch compare
> and
> resume the build. Trivial patch forthcoming...
Hi Rainer
This worked a treat, thanks.
A+
Paul
Is there a bug in __builtin_isnormal or am I just confused as to what it
means? There doesn't seem to be any actual definition/documentation for
the function. __builtin_isnormal(0.0) is returning false. That seems
wrong to me, 0.0 is a normal (as opposed to a denormalized) number isn't
it? Or i
On Mon, Jun 4, 2018 at 1:44 PM Steve Ellcey wrote:
>
> Is there a bug in __builtin_isnormal or am I just confused as to what it
> means? There doesn't seem to be any actual definition/documentation for
> the function. __builtin_isnormal(0.0) is returning false. That seems
> wrong to me, 0.0 is
GCC silently (without -Wpedantic) accepts declarations of zero
length arrays that are followed by other members in the same
struct, such as in:
struct A { char a, b[0], c; };
Is it intended that accesses to elements of such arrays that
alias other members be well-defined?
In my tests, GCC ass
On Thu, 31 May 2018 07:23:22 PDT (-0700), matthew.fort...@mips.com wrote:
Palmer Dabbelt writes:
On Tue, 29 May 2018 11:02:58 PDT (-0700), Jim Wilson wrote:
> On 05/26/2018 06:04 AM, Sebastian Huber wrote:
>> Why is the default multilib and a variant identical?
>
> This is supposed to be a sing
在 2018/6/5 4:44, Steve Ellcey 写道:
Is there a bug in __builtin_isnormal or am I just confused as to what it
means? There doesn't seem to be any actual definition/documentation for
the function. __builtin_isnormal(0.0) is returning false. That seems
wrong to me, 0.0 is a normal (as opposed to a
On 4 June 2018 at 20:10, Laszlo Ersek wrote:
> Hi!
>
> Apologies if this isn't the right place for asking. For the problem
> statement, I'll simply steal Ard's writeup [1]:
>
>> KVM on ARM refuses to decode load/store instructions used to perform
>> I/O to emulated devices, and instead relies on t
26 matches
Mail list logo
