Hi,
On 1/10/21 3:56 PM, Martin Sebor wrote:
Sure. I was confirming that based on the GCC dump there is no risk
of an overflow in the translation unit, and so there is no warning.
OK. :) I didn't understand the GCC dump. Despite having commit privs,
I'm not actually a compiler guru.
It can
On 1/10/21 12:28 PM, Bruce Korb wrote:
Hi Martin,
On 1/10/21 11:01 AM, Martin Sebor wrote:
On 1/8/21 12:38 PM, Bruce Korb via Gcc wrote:
This is the code that must be confusing to GCC. "def_str" points to
the second character in the 520 byte buffer. "def_scan" points to a
character that we al
Hi Martin,
On 1/10/21 11:01 AM, Martin Sebor wrote:
On 1/8/21 12:38 PM, Bruce Korb via Gcc wrote:
This is the code that must be confusing to GCC. "def_str" points to
the second character in the 520 byte buffer. "def_scan" points to a
character that we already know we're going to copy into the
On 1/8/21 12:38 PM, Bruce Korb via Gcc wrote:
$ bash cc.sh
+ wrn+=' -Werror=format-overflow'
+ gcc -DHAVE_CONFIG_H -I. -I.. -I../autoopts
-Wno-format-contains-nul -Wall -Werror -Wcast-align
-Wmissing-prototypes -Wpointer-arith -Wshadow -Wstrict-prototypes
-Wwrite-strings -
On 1/8/21 10:39 AM, Bruce Korb via Gcc wrote:
> Hi,
>
> You are supposed to be able to post once you've subscribed.
>
> Also, GCC's code analysis is wrong. "name_bf" contains *NO MORE* than
> MAXNAMELEN characters. That is provable.
>
> "def_str" points into a buffer of size ((MAXNAMELEN * 2) +
TL-MS Contractor
Sent: Friday, January 8, 2021 12:32 AM
To: autogen-us...@lists.sourceforge.net
Subject: Problems with compiling autogen with GCC8 or newer versions
Dear Sir:
When compiling autogen-5.18.16 with gcc8 or newer, I am getting format overflow errors
like the following during the "make&q
, 8 Aug 2020 at 23:01, Soul Studios wrote:
Hi all,
recently have been working on a new version of the plf::colony container
(plflib.org) and found GCC9 was giving 10-12% worse performance on a
given benchmark than GCC8.
Previous versions of the colony container did not experience this
performance
Studios wrote:
Hi all,
recently have been working on a new version of the plf::colony container
(plflib.org) and found GCC9 was giving 10-12% worse performance on a
given benchmark than GCC8.
Previous versions of the colony container did not experience this
performance loss going from GCC8 to GCC9
und GCC9 was giving 10-12% worse performance on a
> given benchmark than GCC8.
>
> Previous versions of the colony container did not experience this
> performance loss going from GCC8 to GCC9.
> However Clang 6 and MSVC2019 show no performance loss going from the old
> colony versi
Hi all,
recently have been working on a new version of the plf::colony container
(plflib.org) and found GCC9 was giving 10-12% worse performance on a
given benchmark than GCC8.
Previous versions of the colony container did not experience this
performance loss going from GCC8 to GCC9.
However
On Sun, Jun 24, 2018 at 5:45 PM, Jerome Huck wrote:
> Private communication. If someone has clues/hints...Thanks in advance !!!
>
> Hi.
>
> I just have a new small laptop with N4200 proc. In the past I have one
> N3470.
>
> With GCC , a couple of years ago, I used the Linpack(Fortran) in single
Private communication. If someone has clues/hints...Thanks in advance !!!
Hi.
I just have a new small laptop with N4200 proc. In the past I have one
N3470.
With GCC , a couple of years ago, I used the Linpack(Fortran) in single
precision to have an idea of the proc capabilities.
I attache
On Wed, Apr 18, 2018 at 3:34 AM, Jakub Jelinek wrote:
> On Wed, Apr 18, 2018 at 12:30:03PM +0200, Richard Biener wrote:
>> On Wed, 18 Apr 2018, Uros Bizjak wrote:
>>
>> > Hello!
>> >
>> > Currently, CET is enabled by default for linux if target supports
>> > multi-byte NOPs and if assembler suppor
On Wed, Apr 18, 2018 at 12:30:03PM +0200, Richard Biener wrote:
> On Wed, 18 Apr 2018, Uros Bizjak wrote:
>
> > Hello!
> >
> > Currently, CET is enabled by default for linux if target supports
> > multi-byte NOPs and if assembler supports CET insn. Effectively, with
> > newer binutils, CET suppor
On Wed, 18 Apr 2018, Uros Bizjak wrote:
> Hello!
>
> Currently, CET is enabled by default for linux if target supports
> multi-byte NOPs and if assembler supports CET insn. Effectively, with
> newer binutils, CET support is an opt-out feature.
>
> I don't think this should be the case, and I pro
Hello!
Currently, CET is enabled by default for linux if target supports
multi-byte NOPs and if assembler supports CET insn. Effectively, with
newer binutils, CET support is an opt-out feature.
I don't think this should be the case, and I propose to consider CET
as an opt-in feature. Multi-byte N
Hi,
On Thu, Sep 14, 2017 at 11:55:21AM +0200, Richard Biener wrote:
> 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 d
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
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 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 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 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 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 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 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 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 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 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 September 13, 2017 6:24:21 PM GMT+02:00, Jan Hubicka wrote:
>> >I don't see static profile prediction to be very useful here to find
>> >"really
>> >hot code" - neither in current implementation or future. The problem
>of
>> >-O2 is that we kind of know that only 10% of code somewhere matters
>
> >I don't see static profile prediction to be very useful here to find
> >"really
> >hot code" - neither in current implementation or future. The problem of
> >-O2 is that we kind of know that only 10% of code somewhere matters for
> >performance but we have no way to reliably identify it.
>
> It
On September 13, 2017 5:35:11 PM GMT+02:00, Jan Hubicka wrote:
>> On Wed, Sep 13, 2017 at 3:46 PM, 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/unrolling
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 was
mentioned repeatedly) which GCC could/should do as well.
[...]
I'd welco
> On Wed, Sep 13, 2017 at 3:21 AM, Michael Clark wrote:
> >
> >> 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
> >>
>
> On Wed, Sep 13, 2017 at 3:46 PM, 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/unrolling), so whatever it does we
> >> should consider doing at -O2 eventuall
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/unrolling), so whatever it does we
> > should consider doing at -O2 even
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 GCC in various ways. While GCC has many great optimizations, a
> >
On Wed, Sep 13, 2017 at 3:46 PM, 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/unrolling), so whatever it does we
>> should consider doing at -O2 eventually.
>
> Wel
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/unrolling), so whatever it does we
> should consider doing at -O2 eventually.
Well, -O3 adds vectorization, which we don't enable at -O2 by defa
On Wed, Sep 13, 2017 at 9:43 AM, Janne Blomqvist
wrote:
> On Tue, Sep 12, 2017 at 4:57 PM, Wilco Dijkstra
> wrote:
>> These are just a few ideas to start. What do people think? I'd welcome
>> discussion
>> and other proposals for similar improvements.
>
> What about the default behavior if no o
On Wed, Sep 13, 2017 at 3:21 AM, Michael Clark wrote:
>
>> 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 Tue, Sep 12, 2017 at 4:57 PM, 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 result
> * 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
> 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
> 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 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 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
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 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, 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 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, 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 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
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
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
54 matches
Mail list logo
