>> Nor would I relish the prospect of keeping wrapv assumptions out of
>> GCC as other developers make further contributions, as the wrapv
>> assumption is so natural and pervasive.
>
> It's neither natural not pervasive to me! I would never write code
> that way
That's great, but GCC has had man
"Daniel Berlin" <[EMAIL PROTECTED]> writes:
> Just to address the other compiler issue
>>
>> No, they will work on other compilers, since 'configure'
>> won't use -O2 with those other compilers.
>
> icc defaults to -O2 without any options, so unless you are passing
> -O0, it will enable this.
Tha
On 12/29/06, Paul Eggert <[EMAIL PROTECTED]> wrote:
"Seongbae Park" <[EMAIL PROTECTED]> writes:
> On 12/29/06, Paul Eggert <[EMAIL PROTECTED]> wrote:
>> -O2 does not currently imply '-ffast-math'ish optimizations even
>> though the C standard would allow it to.
>
> Can you point me to the releva
On 12/29/06, Paul Eggert <[EMAIL PROTECTED]> wrote:
...
> the much more often reported problems are with
> -fstrict-aliasing, and this one also doesn't get any
> special treatment by autoconf.
That's a good point, and it somewhat counterbalances the
opposing point that -O2 does not currently imp
> But since you asked, I just now did a quick scan of
> gcc-4.3-20061223 (nothing fancy -- just 'grep -r') and the first
> example I found was this line of code in gcc/stor-layout.c's
> excess_unit_span function:
>
> /* Note that the calculation of OFFSET might overflow; we calculate it so
>
> Those questions are more for the opponents of -fwrapv, so
> I'll let them answer them. But why are they relevant?
> Having -fwrapv on by default shouldn't affect your SPEC
> score, since you can always compile with -fnowrapv if the
> application doesn't assume wraparound.
(1) If -fwrapv isn't t
Just to address the other compiler issue
No, they will work on other compilers, since 'configure'
won't use -O2 with those other compilers.
icc defaults to -O2 without any options, so unless you are passing
-O0, it will enable this.
Unless you know of some real-world C compiler that breaks
On 12/29/06, Daniel Berlin <[EMAIL PROTECTED]> wrote:
On 12/29/06, Richard Kenner <[EMAIL PROTECTED]> wrote:
> > I'm not sure what data you're asking for.
>
> Here's the data *I'd* like to see:
>
> (1) What is the maximum performance loss that can be shown using a real
> program (e.g,. one in SPE
On 12/29/06, Richard Kenner <[EMAIL PROTECTED]> wrote:
> I'm not sure what data you're asking for.
Here's the data *I'd* like to see:
(1) What is the maximum performance loss that can be shown using a real
program (e.g,. one in SPEC) and some compiler (not necessarily GCC) when
one assumes wrap
>> GCC itself relies on wrapv semantics. As does glibc. And
>> coreutils. And GNU tar. And Python. I'm sure there are
>> many other significant programs. I don't have time to do a
>> comprehensive survey right now.
>
> Where does GCC rely on that? I don't see it anywhere?
It's not like the
Paul Eggert wrote:
> I don't feel a strong need for 'configure' to default to
> -fstrict-aliasing with GCC. Application code that violates
> strict aliasing assumptions is often unportable in practice
> for other reasons, and needs to be rewritten anyway, even if
> optimization is disabled. So -f
[EMAIL PROTECTED] (Richard Kenner) writes:
> (1) What is the maximum performance loss that can be shown using a real
> program (e.g,. one in SPEC) and some compiler (not necessarily GCC) when
> one assumes wrapping semantics?
>
> (2) In the current SPEC, how many programs benefit from undefined ov
>
> "Daniel Berlin" <[EMAIL PROTECTED]> writes:
>
> > Nobody has yet showed that any significant number of
> > programs actually rely on this undefined behavior.
>
> GCC itself relies on wrapv semantics. As does glibc. And
> coreutils. And GNU tar. And Python. I'm sure there are
> many othe
Perhaps if he gave the specific problems he ran into, with the
actual compiler output.
Indeed. He was just passing along what someone else sent to him. I
expect rms himself does not have any more info :(.
dropped support for the split-buffer code
So Emacs has to have a forked regex
"Seongbae Park" <[EMAIL PROTECTED]> writes:
> On 12/29/06, Paul Eggert <[EMAIL PROTECTED]> wrote:
>> -O2 does not currently imply '-ffast-math'ish optimizations even
>> though the C standard would allow it to.
>
> Can you point me to the relevant section/paragraph in C99 standard
> where it allows
> I'm not sure what data you're asking for.
Here's the data *I'd* like to see:
(1) What is the maximum performance loss that can be shown using a real
program (e.g,. one in SPEC) and some compiler (not necessarily GCC) when
one assumes wrapping semantics?
(2) In the current SPEC, how many prog
> On 12/29/06, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
>> I think it would be a very bad choice for the GNU project to work
>> around itself. If we can't come to an agreement on the list,
>> please ask the Steering Committee. This is a textbook example of
>> what they're for.
The issue doe
> Wrong. Many people have relied on that "feature" because they thought it
> was leagal and haven't had the time to check every piece of code they
> wrote for conformance with the holy standard. And they don't have the time
> now to walk trough the work of their lifetime to see where they did wrong
On 12/29/06, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
On Fri, Dec 29, 2006 at 10:44:02PM +0100, Florian Weimer wrote:
> (BTW, I would be somewhat disappointed if this had to be pampered over
> on the autoconf side. If the GNU project needs -fwrapv for its own
> software by default, this shou
On Fri, Dec 29, 2006 at 10:44:02PM +0100, Florian Weimer wrote:
> (BTW, I would be somewhat disappointed if this had to be pampered over
> on the autoconf side. If the GNU project needs -fwrapv for its own
> software by default, this should be reflected in the compiler's
> defaults.
I absolutely
Ian Lance Taylor wrote:
I fully appreciate that there is a real problem here which needs to be
addressed, but this does not seem like the best solution to me. A
great number of C programs are built using autoconf. If we make this
change, then they will all be built with -fwrapv. That will disa
"Richard Guenther" <[EMAIL PROTECTED]> writes:
> Authors of the affected programs should adjust their makefiles
That is what the proposed patch is for. It gives a way for
developers to adjust their makefiles.
A developer of portable software cannot simply put something
like this into a makefile
Paul Eggert wrote:
In practice, I expect that most C programmers probably
assume wrapv semantics, if only unconsciously. The minimal
C Standard may not entitle them to that assumption, but they
assume it anyway. Part of this is the Java influence no
doubt. Sorry, but that is just the way the
"Daniel Berlin" <[EMAIL PROTECTED]> writes:
[...]
| This is so funny coming from you it's ridiculous.
You have decided to get personal, that certainly will elevate the
debate I suppose.
I don't see what is so funny about you coming and declaring minority
any voice, data that go contrary to you
"Daniel Berlin" <[EMAIL PROTECTED]> writes:
> Nobody has yet showed that any significant number of
> programs actually rely on this undefined behavior.
GCC itself relies on wrapv semantics. As does glibc. And
coreutils. And GNU tar. And Python. I'm sure there are
many other significant progr
On Fri, 29 Dec 2006, Daniel Berlin wrote:
[...]
> OTOH, people who rely on signed overflow being wraparound generally
> *know* they are relying on it.
Wrong. Many people have relied on that "feature" because they thought it
was leagal and haven't had the time to check every piece of code they
wrot
* Daniel Berlin:
> OTOH, people who rely on signed overflow being wraparound generally
> *know* they are relying on it.
> Given this seems to be some small number of people and some small
> amount of code (since nobody has produced any examples showing this
> problem is rampant, in which case i'm
* Andrew Pinski:
>> If what you propose is the only way out, and there is no way to make
>> GCC optimizers reasonable, then I believe Paul's proposal is the next
>> option.
>
> But that still does not address the issue is that this is not just about
> GCC any more since autoconf can be used many
On 12/29/06, Paul Eggert <[EMAIL PROTECTED]> wrote:
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> Does anybody think that Paul's proposed patch to autoconf would be
> better than changing VRP?
I don't.
I haven't noticed anyone else addressing this question,
which I think is a good one.
I don
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> I fully appreciate that there is a real problem here which
> needs to be addressed, but this does not seem like the
> best solution to me.
I agree. It's meant to be a stopgap. I support coming up
with a better solution than the stopgap.
> The resu
On 29 Dec 2006 21:04:08 +0100, Gabriel Dos Reis
<[EMAIL PROTECTED]> wrote:
"Daniel Berlin" <[EMAIL PROTECTED]> writes:
[...]
| Basically, your argument boils down to "all supporting data is wrong,
Really?
Or were you just
# You can have all the sarcasm you want, but maybe instead of sarcasm
On 29 Dec 2006 20:15:01 +0100, Gabriel Dos Reis
<[EMAIL PROTECTED]> wrote:
"Daniel Berlin" <[EMAIL PROTECTED]> writes:
| On 29 Dec 2006 19:33:29 +0100, Gabriel Dos Reis
| <[EMAIL PROTECTED]> wrote:
| > "Daniel Berlin" <[EMAIL PROTECTED]> writes:
| >
| > [...]
| >
| > | In fact, what they told me
On 12/29/06, Robert Dewar <[EMAIL PROTECTED]> wrote:
Daniel Berlin wrote:
> I'm sure no matter what argument i come up with, you'll just explain it away.
> The reality is the majority of our users seem to care more about
> whether they have to write "typename" in front of certain declarations
>
On 29 Dec 2006 19:33:29 +0100, Gabriel Dos Reis
<[EMAIL PROTECTED]> wrote:
"Daniel Berlin" <[EMAIL PROTECTED]> writes:
[...]
| In fact, what they told me was that since they made their change in
| 1991, they have had *1* person who reported a program that didn't
| work.
And GCC made the chan
On 29 Dec 2006 07:55:59 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
Paul Eggert <[EMAIL PROTECTED]> writes:
> * NEWS: AC_PROG_CC, AC_PROG_CXX, and AC_PROG_OBJC now take an
> optional second argument specifying the default optimization
> options for GCC. These optimizati
> For this _specific_ instance of the general problem, C++ users could
> use numeric_limits::max() and get away with it, but I don't
> believe such a solution (or the one you propose or similar I've seen)
> to this specific instance generalizes to portable, readable and
> maintainable solution to t
"Daniel Berlin" <[EMAIL PROTECTED]> writes:
[...]
| Basically, your argument boils down to "all supporting data is wrong,
Really?
Or were you just
# You can have all the sarcasm you want, but maybe instead of sarcasm,
Otherwise, you have a serious problem hearing anything contrary to
your
"Henning Nielsen Lund" <[EMAIL PROTECTED]> writes:
> As 'struct stat' is used in the file_has_acl() prototype of acl.h, would I
> include sys/stat.h.
Thanks, but while we're doing that I noticed also that acl.c isn't
including acl.h first, as is the usual style; also, older hosts
require that you
"Daniel Berlin" <[EMAIL PROTECTED]> writes:
| On 29 Dec 2006 19:33:29 +0100, Gabriel Dos Reis
| <[EMAIL PROTECTED]> wrote:
| > "Daniel Berlin" <[EMAIL PROTECTED]> writes:
| >
| > [...]
| >
| > | In fact, what they told me was that since they made their change in
| > | 1991, they have had *1* pers
Daniel Berlin wrote:
I'm sure no matter what argument i come up with, you'll just explain it away.
The reality is the majority of our users seem to care more about
whether they have to write "typename" in front of certain declarations
than they do about signed integer overflow.
I have no idea
"Daniel Berlin" <[EMAIL PROTECTED]> writes:
[...]
| In fact, what they told me was that since they made their change in
| 1991, they have had *1* person who reported a program that didn't
| work.
And GCC made the change recently and got yy reports. That might say
something about both compiler
Andrew Pinski <[EMAIL PROTECTED]> writes:
| >
| > | > If the above is the only without Autoconf change, I would highly
| > | > recommend Autoconf change if GCC optimizers highly value benchmarks
| > | > over running real world code.
| > |
| > | Which one, mine or Paul's?
| >
| > If what you pro
>
> | > If the above is the only without Autoconf change, I would highly
> | > recommend Autoconf change if GCC optimizers highly value benchmarks
> | > over running real world code.
> |
> | Which one, mine or Paul's?
>
> If what you propose is the only way out, and there is no way to make
> GCC
Andrew Pinski <[EMAIL PROTECTED]> writes:
| >
| > Andrew Pinski <[EMAIL PROTECTED]> writes:
| >
| > | >
| > | > Paul Eggert <[EMAIL PROTECTED]> writes:
| > | >
| > | > > * NEWS: AC_PROG_CC, AC_PROG_CXX, and AC_PROG_OBJC now take an
| > | > > optional second argument specifying the
>
> Andrew Pinski <[EMAIL PROTECTED]> writes:
>
> | >
> | > Paul Eggert <[EMAIL PROTECTED]> writes:
> | >
> | > > * NEWS: AC_PROG_CC, AC_PROG_CXX, and AC_PROG_OBJC now take an
> | > > optional second argument specifying the default optimization
> | > > options for GCC.
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
| Paul Eggert <[EMAIL PROTECTED]> writes:
|
| > * NEWS: AC_PROG_CC, AC_PROG_CXX, and AC_PROG_OBJC now take an
| > optional second argument specifying the default optimization
| > options for GCC. These optimizations now default to "-O2 -fw
Andrew Pinski <[EMAIL PROTECTED]> writes:
| >
| > Paul Eggert <[EMAIL PROTECTED]> writes:
| >
| > > * NEWS: AC_PROG_CC, AC_PROG_CXX, and AC_PROG_OBJC now take an
| > > optional second argument specifying the default optimization
| > > options for GCC. These optimizations now default to "-
>
> Paul Eggert <[EMAIL PROTECTED]> writes:
>
> > * NEWS: AC_PROG_CC, AC_PROG_CXX, and AC_PROG_OBJC now take an
> > optional second argument specifying the default optimization
> > options for GCC. These optimizations now default to "-O2 -fwrapv"
> > instead of to "-O2". This pa
Paul Eggert <[EMAIL PROTECTED]> writes:
> * NEWS: AC_PROG_CC, AC_PROG_CXX, and AC_PROG_OBJC now take an
> optional second argument specifying the default optimization
> options for GCC. These optimizations now default to "-O2 -fwrapv"
> instead of to "-O2". This partly at
Paolo Bonzini <[EMAIL PROTECTED]> writes:
>> Or you can do, since elsewhere in the code you compute time_t_max:
>> for (j = 1; j <= time_t_max / 2 + 1; j *= 2)
>
> No, this does not work. It would work to have:
>
> for (j = 1;;)
> {
> if (j > time_t_max / 2)
> break;
>
50 matches
Mail list logo
