On 12/09/17 20:56, Michael Meissner wrote:
> On Tue, Sep 12, 2017 at 05:26:29PM +0200, David Brown wrote:
>> On 12/09/17 16:15, paul.kon...@dell.com wrote:
>>>
On Sep 12, 2017, at 5:32 AM, Jürg Billeter
wrote:
Hi,
To support applications that assume big-endian memory
On 14/09/17 08:22, Eric Botcazou wrote:
>> And there are lots of other problems, I don't have time to document them
>> all, or even remember them all. Personally, I think you are better off
>> trying to fix the application to make it more portable. Fixing the
>> compiler is not a magic solution t
> I seem to remember it being able to attach a big-endian or little-endian
> label to any individual variable (rather than a type), which could be a
> scaler rather than a struct. So it was a bit more flexible than gcc.
Well, the only thing I see in the documentation for "Byte Ordering" is the
r
On Wed, Sep 13, 2017 at 5:08 PM, Allan Sandfeld Jensen
wrote:
> On Mittwoch, 13. September 2017 15:46:09 CEST Jakub Jelinek wrote:
>> On Wed, Sep 13, 2017 at 03:41:19PM +0200, Richard Biener wrote:
>> > On its own -O3 doesn't add much (some loop opts and slightly more
>> > aggressive inlining/unro
On Wed, Sep 13, 2017 at 6:11 PM, Nikos Chantziaras wrote:
> On 12/09/17 16:57, Wilco Dijkstra wrote:
>>
>> [...] As a result users are
>> required to enable several additional optimizations by hand to get good
>> code.
>> Other compilers enable more optimizations at -O2 (loop unrolling in LLVM
>>
On 2017.09.14 at 11:57 +0200, Richard Biener wrote:
> On Wed, Sep 13, 2017 at 6:11 PM, Nikos Chantziaras wrote:
> > On 12/09/17 16:57, Wilco Dijkstra wrote:
> >>
> >> [...] As a result users are
> >> required to enable several additional optimizations by hand to get good
> >> code.
> >> Other comp
> On 14 Sep 2017, at 3:06 AM, Allan Sandfeld Jensen wrote:
>
> On Dienstag, 12. September 2017 23:27:22 CEST Michael Clark wrote:
>>> On 13 Sep 2017, at 1:57 AM, Wilco Dijkstra wrote:
>>>
>>> Hi all,
>>>
>>> At the GNU Cauldron I was inspired by several interesting talks about
>>> improving G
On 09/14/2017 12:07 PM, Markus Trippelsdorf wrote:
> On 2017.09.14 at 11:57 +0200, Richard Biener wrote:
>> On Wed, Sep 13, 2017 at 6:11 PM, Nikos Chantziaras wrote:
>>> On 12/09/17 16:57, Wilco Dijkstra wrote:
[...] As a result users are
required to enable several additional optimi
On Thu, Sep 14, 2017 at 12:18 PM, Martin Liška wrote:
> On 09/14/2017 12:07 PM, Markus Trippelsdorf wrote:
>> On 2017.09.14 at 11:57 +0200, Richard Biener wrote:
>>> On Wed, Sep 13, 2017 at 6:11 PM, Nikos Chantziaras wrote:
On 12/09/17 16:57, Wilco Dijkstra wrote:
>
> [...] As a resu
On Thu, Sep 14, 2017 at 11:24 AM, Richard Biener
wrote:
> On Thu, Sep 14, 2017 at 12:18 PM, Martin Liška wrote:
>> On 09/14/2017 12:07 PM, Markus Trippelsdorf wrote:
>>> On 2017.09.14 at 11:57 +0200, Richard Biener wrote:
On Wed, Sep 13, 2017 at 6:11 PM, Nikos Chantziaras
wrote:
>
On 14/09/17 11:30, Eric Botcazou wrote:
>> I seem to remember it being able to attach a big-endian or little-endian
>> label to any individual variable (rather than a type), which could be a
>> scaler rather than a struct. So it was a bit more flexible than gcc.
>
> Well, the only thing I see in
On 09/14/2017 12:37 PM, Bin.Cheng wrote:
> On Thu, Sep 14, 2017 at 11:24 AM, Richard Biener
> wrote:
>> On Thu, Sep 14, 2017 at 12:18 PM, Martin Liška wrote:
>>> On 09/14/2017 12:07 PM, Markus Trippelsdorf wrote:
On 2017.09.14 at 11:57 +0200, Richard Biener wrote:
> On Wed, Sep 13, 2017
On 13/09/17 15:11, Andreas Schwab wrote:
On Jul 20 2017, Sebastian Huber wrote:
Ok, so why do I get a "error: unrecognizable insn:"? How can I debug a
message like this:
(insn 12 11 13 2 (set (reg:CCFP 126)
(compare:CCFP (reg:TF 123)
(reg:TF 124))) "test-v0.i":5 -1
On Thu, Sep 14, 2017 at 12:42 PM, Martin Liška wrote:
> On 09/14/2017 12:37 PM, Bin.Cheng wrote:
>> On Thu, Sep 14, 2017 at 11:24 AM, Richard Biener
>> wrote:
>>> On Thu, Sep 14, 2017 at 12:18 PM, Martin Liška wrote:
On 09/14/2017 12:07 PM, Markus Trippelsdorf wrote:
> On 2017.09.14 at
On 2017.09.14 at 14:48 +0200, Richard Biener wrote:
> On Thu, Sep 14, 2017 at 12:42 PM, Martin Liška wrote:
> > On 09/14/2017 12:37 PM, Bin.Cheng wrote:
> >> On Thu, Sep 14, 2017 at 11:24 AM, Richard Biener
> >> wrote:
> >>> On Thu, Sep 14, 2017 at 12:18 PM, Martin Liška wrote:
> On 09/14/2
On Thu, Sep 14, 2017 at 3:08 PM, Markus Trippelsdorf
wrote:
> On 2017.09.14 at 14:48 +0200, Richard Biener wrote:
>> On Thu, Sep 14, 2017 at 12:42 PM, Martin Liška wrote:
>> > On 09/14/2017 12:37 PM, Bin.Cheng wrote:
>> >> On Thu, Sep 14, 2017 at 11:24 AM, Richard Biener
>> >> wrote:
>> >>> On T
This is more of a question than a bug report, so I'm trying to send it
to the list rather than filing a bugzilla issue.
I think it's quite common to write for- and while-loops where the
condition is always initially true. A simple example might be
double average (const double *a, size_t n)
{
d
On Thu, 14 Sep 2017, Niels Möller wrote:
This is more of a question than a bug report, so I'm trying to send it
to the list rather than filing a bugzilla issue.
I think it's quite common to write for- and while-loops where the
condition is always initially true. A simple example might be
doubl
Hi,
On 09/14/2017 09:50 PM, Marc Glisse wrote:
On Thu, 14 Sep 2017, Niels Möller wrote:
This is more of a question than a bug report, so I'm trying to send it
to the list rather than filing a bugzilla issue.
I think it's quite common to write for- and while-loops where the
condition is alway
On 09/14/2017 01:28 PM, Niels Möller wrote:
> This is more of a question than a bug report, so I'm trying to send it
> to the list rather than filing a bugzilla issue.
>
> I think it's quite common to write for- and while-loops where the
> condition is always initially true. A simple example might
Snapshot gcc-7-20170914 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/7-20170914/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7
21 matches
Mail list logo
