On 09/05/2017 01:18 PM, Richard Biener wrote:
> On Tue, Sep 5, 2017 at 12:20 PM, Claudiu Zissulescu
> wrote:
>> Hi guys,
>>
>> I found an ICE when emitting sjlj dispatch table for ARC. Namely, in
>> sjlj_emit_dispatch_table() function, we create a dispatch table where the
>> case elements are ha
Hi,
Apologies if I am coming about this in the wrong way, I am new to the
mailing list. During our preliminary work to upgrade to gcc 7.2 (from
6.3) at my workplace, we have come across a bug that is blocking our
move to C++17. I have raised a bug report here:
https://gcc.gnu.org/bugzilla/show_bug
Hi,
To support applications that assume big-endian memory layout on little-
endian systems, I'm considering adding support for reversing the
storage order to GCC. In contrast to the existing scalar storage order
support for structs, the goal is to reverse the storage order for all
memory operation
On 09/09/2017 08:00 AM, Ramana Radhakrishnan wrote:
There are a few getting started guides in the wiki
(http://gcc.gnu.org/wiki - Look for tutorials) which can help you get
started in terms of reading up on the internals, there are a few Easy
hacks listed in the wiki page here https://gcc.gnu.or
Hi all,
At the GNU Cauldron I was inspired by several interesting talks about improving
GCC in various ways. While GCC has many great optimizations, a common theme is
that its default settings are rather conservative. As a result users are
required to enable several additional optimizations by ha
> On Sep 12, 2017, at 5:32 AM, Jürg Billeter
> wrote:
>
> Hi,
>
> To support applications that assume big-endian memory layout on little-
> endian systems, I'm considering adding support for reversing the
> storage order to GCC. In contrast to the existing scalar storage order
> support for st
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 layout on little-
>> endian systems, I'm considering adding support for reversing the
>> storage order to GCC. In contras
Another one that might be interesting is -funsafe-loop-optimizations.
In most cases people write loops assuming simple finite loops (no
overflow). Crippling optimization for the small amount of people (system
programmers ?) that use such strange loops seems counterproductive. It
would be best if su
On Tue, 12 Sep 2017, Wilco Dijkstra wrote:
> * Make -fno-trapping-math the default - another obvious one. From the docs:
> "Compile code assuming that floating-point operations cannot generate
>user-visible traps."
> There isn't a lot of code that actually uses user-visible traps (if any
.On Tue, Sep 12, 2017 at 8:29 AM, Theodore Papadopoulo
wrote:
> Another one that might be interesting is -funsafe-loop-optimizations.
> In most cases people write loops assuming simple finite loops (no
> overflow). Crippling optimization for the small amount of people (system
> programmers ?) tha
On 09/12/2017 05:32 PM, Andrew Pinski wrote:
> .On Tue, Sep 12, 2017 at 8:29 AM, Theodore Papadopoulo
> wrote:
>> Another one that might be interesting is -funsafe-loop-optimizations.
>> In most cases people write loops assuming simple finite loops (no
>> overflow). Crippling optimization for the
On Tue, 12 Sep 2017, Wilco Dijkstra wrote:
> * Make -fno-math-errno the default - this mostly affects the code generated
> for
> sqrt, which should be treated just like floating point division and not set
> errno by default (unless you explicitly select C89 mode).
>
> * Make -fno-trapping-ma
On Tue, Sep 12, 2017 at 2:32 AM, Jürg Billeter
wrote:
> Hi,
>
> To support applications that assume big-endian memory layout on little-
> endian systems, I'm considering adding support for reversing the
> storage order to GCC. In contrast to the existing scalar storage order
> support for structs,
On Tue, 12 Sep 2017, Wilco Dijkstra wrote:
> * Make -fno-math-errno the default - this mostly affects the code generated
> for
> sqrt, which should be treated just like floating point division and not set
> errno by default (unless you explicitly select C89 mode).
(note that this can be selec
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 layout on little-
> >> endian systems, I'm c
Hi,
Here's a report of a successful build and install of GCC:
$ gcc-7.2.0/config.guess
hppa2.0-unknown-linux-gnu
$ newcompiler/bin/gcc -v
Using built-in specs.
COLLECT_GCC=newcompiler/bin/gcc
COLLECT_LTO_WRAPPER=/home/aaro/gcctest/newcompiler/libexec/gcc/hppa-unknown-linux-gnu/7.2.0/lto-wrapper
On Thu, Sep 07, 2017 at 10:35:18AM -0400, Jeffrey Walton wrote:
> We are using the key and subkey schedule from FIPS 197, Appendix A. We
> are using it because the key schedule is fully specified.
>
> We lack the known answers for a single round using a subkey like one
> specified in FIPS 197. IBM
> To support applications that assume big-endian memory layout on little-
> endian systems, I'm considering adding support for reversing the
> storage order to GCC.
That was also the goal of the scalar_storage_order attribute.
> In contrast to the existing scalar storage order support for structs
On Tue, 12 Sep 2017, Alexander Monakov wrote:
> > * Make -fno-trapping-math the default - another obvious one. From the docs:
> > "Compile code assuming that floating-point operations cannot generate
> >user-visible traps."
> > There isn't a lot of code that actually uses user-visible tra
> 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
> GCC in various ways. While GCC has many great optimizations, a common theme is
> that its default settings are rather conservative. As a resul
Snapshot gcc-5-20170912 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/5-20170912/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5
I confirmed this issue on x86_64 CentOS, and independently here:
https://wandbox.org/permlink/ncWqA9Zu3YEofqri
Also fails on gcc trunk.
Possibly related to bug 81338 "stringstream remains empty after being
moved into multiple times"? Although I see that one is fixed by Mr
Wakely.
Dave
On Tue,
On Tue, Sep 12, 2017 at 08:10:13AM -0400, Nathan Sidwell wrote:
> On 09/09/2017 08:00 AM, Ramana Radhakrishnan wrote:
>
> >There are a few getting started guides in the wiki
> >(http://gcc.gnu.org/wiki - Look for tutorials) which can help you get
> >started in terms of reading up on the internals,
On Wed, Sep 13, 2017 at 09:27:22AM +1200, Michael Clark wrote:
> > Other compilers enable more optimizations at -O2 (loop unrolling in LLVM was
> > mentioned repeatedly) which GCC could/should do as well.
>
> There are some nuances to -O2. Please consider -O2 users who wish use it like
> Clang/LL
> On 13 Sep 2017, at 12:47 PM, Segher Boessenkool
> wrote:
>
> On Wed, Sep 13, 2017 at 09:27:22AM +1200, Michael Clark wrote:
>>> Other compilers enable more optimizations at -O2 (loop unrolling in LLVM was
>>> mentioned repeatedly) which GCC could/should do as well.
>>
>> There are some nuanc
> On 13 Sep 2017, at 1:15 PM, Michael Clark wrote:
>
> - https://rv8.io/bench#optimisation
> - https://rv8.io/bench#executable-file-sizes
>
> -O2 is 98% perf of -O3 on x86-64
> -Os is 81% perf of -O3 on x86-64
>
> -O2 saves 5% space on -O3 on x86-64
> -Os saves 8% space on -Os on x86-64
>
> 1
> * Make -fomit-frame-pointer the default - various targets already do this at
> higher optimization levels, but this could easily be done for all targets.
> Frame pointers haven't been needed for debugging for decades, however if
> there
> are still good reasons to keep it enabled with -O0
27 matches
Mail list logo
