Hi:
When I was using g++, I found a problem, maybe which is a bug or not. It is
about the order of object files needed to link, if you change the order of
files, the result is different. I can duplicate the problem, and I have write
an example, whose git address is:
https://github.com/Erician/p
On 05/31/2018 04:39 AM, Alan Hayward wrote:
> (Missed this thread initially due to incorrect email address)
Sorry. Good to hear your're still interested in figuring this out.
>
>> On 29 May 2018, at 11:05, Richard Sandiford
>> wrote:
>>
>> Jeff Law writes:
>>> Now that we're in stage1 I do wa
On 05/29/2018 04:05 AM, Richard Sandiford wrote:
> Jeff Law writes:
>> Now that we're in stage1 I do want to revisit the CLOBBER_HIGH stuff.
>> When we left things I think we were trying to decide between
>> CLOBBER_HIGH and clobbering the appropriate subreg. The problem with
>> the latter is the
On 06/11/2018 01:20 PM, Martin Sebor wrote:
> On 06/11/2018 12:34 PM, David Malcolm wrote:
>> On Mon, 2018-06-11 at 12:19 -0600, Martin Sebor wrote:
>>> I've been noticing a number of failures in LTO (and some other)
>>> tests in my x86_64-builds most of which don't appear in results
>>> reported o
On 06/11/2018 12:34 PM, David Malcolm wrote:
On Mon, 2018-06-11 at 12:19 -0600, Martin Sebor wrote:
I've been noticing a number of failures in LTO (and some other)
tests in my x86_64-builds most of which don't appear in results
reported on gcc-testresults (all those on lines that start with
with
> On Jun 11, 2018, at 3:04 PM, Jeff Law wrote:
>
> On 06/04/2018 09:02 AM, Paul Koning wrote:
>>
>> ...
>>
>> By "multiple memory operands" do you mean both source and dest in
>> memory?
> Yes and no :-) I suspect no real thought was given to what happens when
> there's more than one auto-
On 06/08/2018 06:05 AM, Andrew Jenner wrote:
> On 08/06/2018 12:43, Dennis Luehring wrote:
is the patch already integrated into mainline?
>>> No, it's not.
>>
>> will that ever happen?
>
> Hard to say. There's no reason in principle why it couldn't happen, but
> there's not a big demand for i
On 06/04/2018 09:02 AM, Paul Koning wrote:
>
>
>> 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 des
On Mon, Jun 11, 2018 at 07:50:32PM +0200, Florian Weimer wrote:
> On 06/11/2018 04:50 PM, Rich Felker wrote:
> >On Tue, Feb 27, 2018 at 11:01:23AM +0100, Florian Weimer wrote:
> >>I think it would be a nice addition to the toolchain if it were
> >>possible to programatically initialize data in the
On Mon, 2018-06-11 at 12:19 -0600, Martin Sebor wrote:
> I've been noticing a number of failures in LTO (and some other)
> tests in my x86_64-builds most of which don't appear in results
> reported on gcc-testresults (all those on lines that start with
> with the '!' below) and that I don't recall
I've been noticing a number of failures in LTO (and some other)
tests in my x86_64-builds most of which don't appear in results
reported on gcc-testresults (all those on lines that start with
with the '!' below) and that I don't recall seeing before.
The LTO tests seem to fail with errors like th
On 06/11/2018 04:50 PM, Rich Felker wrote:
On Tue, Feb 27, 2018 at 11:01:23AM +0100, Florian Weimer wrote:
I think it would be a nice addition to the toolchain if it were
possible to programatically initialize data in the RELRO section.
We do this in glibc, but I don't think this is currently su
On Tue, Feb 27, 2018 at 11:01:23AM +0100, Florian Weimer wrote:
> I think it would be a nice addition to the toolchain if it were
> possible to programatically initialize data in the RELRO section.
> We do this in glibc, but I don't think this is currently supported
> for general use.
>
> One impo
Hi Steve,
On Fri, Jun 08 2018, Steve Ellcey wrote:
> On Thu, 2018-06-07 at 12:01 +0200, Richard Biener wrote:
>>
>> When we do our own comparisons of GCC vs. ICC on benchmarks
>> like SPEC CPU 2006/2017 ICC doesn't have a big lead over GCC
>> (in fact it even trails in some benchmarks) unless you
On 06/08/2018 07:16 PM, Hrishikesh Kulkarni wrote:
> Hi,
>
> -fdump-lto-body=foo
> will dump gimple body of the function foo
>
> foo (int a, int b)
> {
>[local count: 1073741825]:
> _3 = a_1(D) + b_2(D);
> return _3;
>
> }
>
> Please find the diff file attached herewith.
>
> Regards,
>
15 matches
Mail list logo
