Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #38202 > unrolled thread

rhel 7 and kforth

Back to article view | Back to comp.lang.forth

Contents

  rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-15 11:20 -0700
    Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-15 19:09 -0700
    Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 04:13 -0700
      Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 04:55 -0700
        Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-16 12:08 +0000
          Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 05:29 -0700
            Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 07:07 -0700
              Re: rhel 7 and kforth franck.bensusan@gmail.com - 2015-04-16 07:44 -0700
                Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 08:14 -0700
            Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-16 14:02 +0000
              Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 08:12 -0700
        Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 12:25 -0700
          Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 17:02 -0700
            Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 17:06 -0700
              Re: rhel 7 and kforth foxaudioresearch@gmail.com - 2015-04-16 17:24 -0700
                Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 17:39 -0700
                Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-16 17:47 -0700
                  Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 18:44 -0700
                    Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 18:50 -0700
                      Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-16 19:10 -0700
                        Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 19:29 -0700
                          Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 20:10 -0700
                            Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-16 20:27 -0700
                              Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-17 02:04 -0700
                                Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-17 11:41 +0000
                                  Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-17 14:45 -0700
                                    Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-18 14:01 +0000
                                Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-17 07:47 -0700
                                  Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-17 08:35 -0700
                                    Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-17 10:33 -0700
                                      Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-17 11:15 -0700
                                        Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-17 11:47 -0700
                                          Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-17 14:51 -0700
                                          Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-18 14:41 +0000
                                            Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-24 11:42 -0700
                                              Re: rhel 7 and kforth "Elizabeth D. Rather" <erather@forth.com> - 2015-04-24 09:02 -1000
                                              Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-02 10:53 +0000
                                                Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-05-03 17:22 -0700
                                                  Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-04 10:23 +0000
                                          Re: rhel 7 and kforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-22 00:10 +0200
                                            Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-21 17:45 -0700
                                            Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-22 13:08 +0000
                                  Re: rhel 7 and kforth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-17 20:27 +0000
                                    Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-17 14:41 -0700
                                      Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-18 14:11 +0000
                                    Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-17 15:47 -0700
                                    Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-18 14:34 +0000
                                      Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-18 14:09 -0700
                                        Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-19 20:31 -0700
                                          Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-20 11:35 +0000
                                            Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-21 18:07 -0700
                                              Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-22 11:21 +0000
                                                Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-24 19:34 -0700
                                                  Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-25 08:36 +0000
                                                    Re: rhel 7 and kforth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-25 11:36 +0000
                                                      Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-25 16:29 +0000
                              Re: rhel 7 and kforth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-19 10:08 +0000
                                Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-19 20:11 -0700
                                Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-20 12:05 +0000
                                  Re: rhel 7 and kforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-22 01:27 +0200
                                    Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-21 18:18 -0700
                                      Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-22 11:00 +0000
                                        Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-24 11:28 -0700
                                          Re: rhel 7 and kforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-25 01:34 +0200
                                            Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-24 21:07 -0700
                                            Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-25 16:41 +0000
                                              Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-25 10:06 -0700
                                                Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-26 14:56 +0000
                                                  Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-26 20:22 -0700
                                                    Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-27 09:02 +0000
                                                      Re: rhel 7 and kforth mhx@iae.nl - 2015-04-27 03:59 -0700
                                                      Re: rhel 7 and kforth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-27 15:45 +0000
                                                      Re: rhel 7 and kforth "Rod Pemberton" <bork@lllljunkqwer.cpm> - 2015-04-27 18:09 -0400
                                                      Re: rhel 7 and kforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-28 03:55 +0200
                                                      Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-27 19:30 -0700
                                                        Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-27 19:44 -0700
                                                        Re: rhel 7 and kforth "Rod Pemberton" <bork@lllljunkqwer.cpm> - 2015-04-28 02:03 -0400
                                                          Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-28 01:44 -0700
                                                            Re: rhel 7 and kforth Mark Wills <markwills1970@gmail.com> - 2015-04-28 02:44 -0700
                                                            Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-28 16:47 -0700
                                                              Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-28 17:00 -0700
                                                                Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-28 17:14 -0700
                                                                  Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-28 17:59 -0700
                                                                    Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-28 21:41 -0700
                                                                  Re: rhel 7 and kforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-29 03:07 +0200
                                                                    Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-28 18:13 -0700
                                                              Re: rhel 7 and kforth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-29 00:07 +0000
                                                        Re: rhel 7 and kforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-28 22:22 +0200
                                                          Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-28 14:23 -0700
                                                            Re: rhel 7 and kforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-28 23:51 +0200
                                                              Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-28 16:50 -0700
                                                            Re: rhel 7 and kforth David Thompson <dave.thompson2@verizon.net> - 2015-05-10 12:24 -0400
                                                  Re: rhel 7 and kforth mhx@iae.nl - 2015-04-26 22:16 -0700
                                                    Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-27 09:19 +0000
                                                      Re: rhel 7 and kforth mhx@iae.nl - 2015-04-27 04:03 -0700
                                                      Re: rhel 7 and kforth "Rod Pemberton" <bork@lllljunkqwer.cpm> - 2015-04-27 18:21 -0400
                                          Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-01 14:46 +0000
                                      Re: rhel 7 and kforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-23 16:46 +0200
                          Re: rhel 7 and kforth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-17 10:35 +0000
                            Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-17 08:43 -0700
    Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-17 08:41 -0700

Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

#38472

Bernd Paysan <bernd.paysan@gmx.de> writes:
>> looking at the decompilation of VARIABLE in Gforth, VFX, and
>> SwiftForth, the 0 comes from explicit initialization, not by
>> accident.
> There's a reason why all these Forths you looked at zero-initialize 
> variables: It makes the program behave deterministic.  The question is: 
> should we put this into the standard?

Those are all PC-hosted Forths with nothing like the memory constraints
of traditional small-machine Forths.  It looks like Mikael's Flashforth
telnet server isn't around any more, but I looked at the source code to
the Atmega version and while I may have missed something, it looks to me
like variables don't get zeroed when allocated.

Certainly one can argue in favor of standarizing zero-initialization on
determinism grounds.  One can argue, on resource constraint grounds or
in the general spirit of Forth minimalism, that it shouldn't be
standardized and programmers shouldn't rely on it (except through
documented environmental dependencies).  Silliest of all though would be
to not standardize it, but notice that it happens to work anyway in some
particular implementations, and then accuse other implementations of
"miscompiling" even though what they do is allowed by the standard.

[toc] | [prev] | [next] | [standalone]

#38488

Paul Rubin <no.email@nospam.invalid> writes:
>Those are all PC-hosted Forths with nothing like the memory constraints
>of traditional small-machine Forths.

"0 ," costs about the same space as "cell allot", so memory constrains
are not the issue.

>Certainly one can argue in favor of standarizing zero-initialization on
>determinism grounds.  One can argue, on resource constraint grounds or
>in the general spirit of Forth minimalism, that it shouldn't be
>standardized and programmers shouldn't rely on it (except through
>documented environmental dependencies).

Yes, that's the typical discussion.

>Silliest of all though would be
>to not standardize it, but notice that it happens to work anyway in some
>particular implementations, and then accuse other implementations of
>"miscompiling" even though what they do is allowed by the standard.

That's not the usual complaint, so why are you mentioning it?
Spin-doctoring?

The usual complaint is about miscompilation from newer versions of the
same compiler.  And the usual defense of the miscompiler maintainers
is that the program has always been broken, and that they are doing
the right thing by miscompiling it.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

[toc] | [prev] | [next] | [standalone]

#38572

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> "0 ," costs about the same space as "cell allot", so memory constrains
> are not the issue.

Good point, that strengthens the case for standardization.

>>accuse other implementations of "miscompiling" even though what they
>>do is allowed by the standard.
> That's not the usual complaint, so why are you mentioning it?
> Spin-doctoring?

Because we're in a thread involving that complaint being made against C
compilers.  

> The usual complaint is about miscompilation from newer versions of the
> same compiler.

I think you're saying that if you run code that does UB under two
versions of a compiler, the UB should be guaranteed to do the same thing
both times.  But the whole concept of UB is that there is no such
guarantee, even within one compiler version let alone two.  If there
was, it wouldn't be UB any more.  What you really want is to eliminate
UB from the specification.  I'm all in favor of that.  But if you leave
it in and keep it documented as UB, then you should expect the compiler
to actually treat it as UB.

[toc] | [prev] | [next] | [standalone]

#38587

Paul Rubin wrote:
> I think you're saying that if you run code that does UB under two
> versions of a compiler, the UB should be guaranteed to do the same thing
> both times.  But the whole concept of UB is that there is no such
> guarantee, even within one compiler version let alone two.  If there
> was, it wouldn't be UB any more.  What you really want is to eliminate
> UB from the specification.  I'm all in favor of that.  But if you leave
> it in and keep it documented as UB, then you should expect the compiler
> to actually treat it as UB.

Well, in that case, you strongly need IB, for "implementation behavior", and 
you should change a lot of UBs in the C standard to IB.

Example for an IB: overflow of integers.  We can have consistent (but 
different) IB on these, and don't need to mark that UB, IB is sufficient for 
a standard.

Example of UB: writing to an array out of bounds.  There are so many 
unknowns that you have to treat that as UB - it depends on the actual memory 
layout where you write, and therefore, even two different runs of the same 
program (or two different compiles) can lead to different behavior.

In the C standard, UBs can be anything from an implementation defined 
behavior to something close to indeterministic.  A race condition in a 
multithreaded program is UB.

The problem with C maintainers is that they treat all the IBs as non-
deterministic UBs.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#38590

Bernd Paysan <bernd.paysan@gmx.de> writes:
> Well, in that case, you strongly need IB, for "implementation
> behavior", and you should change a lot of UBs in the C standard to IB.

The C standard does specify some IB, like if you say f()+g(), the
functions can be evaluated in either order, iirc.  There is probably
also some UB in the standard for bogus reasons, that could be changed to
IB at no performance cost.  But, lots of UB is there because someone
argued for it on performance grounds.

> Example for an IB: overflow of integers.  We can have consistent (but
> different) IB on these, and don't need to mark that UB, IB is
> sufficient for a standard.

The sensible IB's for int overflow are wrap and trap, and trap has
nontrivial cost unless there's hardware support.  Wrap on the other hand
breaks the invariant that n+1>n for all n, which defeats certain loop
optimizations and makes code run slower in the non-overflow case.  UB
really is what the performance guys wanted.  Maybe it's reasonable to
specify wraparound, generate the slower loop code by default, but have a
pragma that can be applied to specific loops, telling the compiler it
can use the invariant.  OTOH in lots of cases where you want wraparound,
the number won't be negative and you can use an unsigned int.

> The problem with C maintainers is that they treat all the IBs as non-
> deterministic UBs.

I think the issue under dispute isn't what happens if a UB is executed,
but rather whether the compiler should be allowed to presume the absence
of UB and infer other things about the program from that presumption.
For example the famous Linux kernel bug that went something like:

   int x = p->foo;
   if (p == NULL) { handle error case and return }
   ... handle success case ...

Since p is dereferenced, it must not be null, therefore the null check
will always fail, so the check and the error handling are discarded by
dead code elimination, and all cases are treated as successful, whoops.
For some reason the programmer expected the p->foo to be ok since x
wasn't actually used in the error code, and the address of 0->foo (if
that had been valid) was in the kernel address range.  So the code
worked with older compilers, even though it was buggy from the start.

I think compilers are moving towards doing more stuff like that rather
than less.

[toc] | [prev] | [next] | [standalone]

#38596

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Example of UB: writing to an array out of bounds.  There are so many 
>unknowns that you have to treat that as UB - it depends on the actual memory 
>layout where you write, and therefore, even two different runs of the same 
>program (or two different compiles) can lead to different behavior.

Yes, that is probably what the C89 people had in mind when they wrote
"undefined behaviour".  But the interpretation of the GCC maintainers
is different: Their interpretation is: The C standard allows anything
at all to happen if a program performs undefined behaviour, and such a
program is not a standard C program.  Since we are a standard C
compiler, we assume that undefined behaviour does not happen, and
derive optimization "facts" from that, such as "optimizing" the loop
bounds check away, turning the loop into an endless loop.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

[toc] | [prev] | [next] | [standalone]

#38597

On Saturday, April 25, 2015 at 11:49:22 AM UTC-5, Anton Ertl wrote:
> ... But the interpretation of the GCC maintainers
> is different: Their interpretation is: The C standard allows anything
> at all to happen if a program performs undefined behaviour, and such a
> program is not a standard C program.  Since we are a standard C
> compiler, we assume that undefined behaviour does not happen, and
> derive optimization "facts" from that, such as "optimizing" the loop
> bounds check away, turning the loop into an endless loop.
> 

Since the compiler can return warnings of undefined behavior, for example, with the -Wall compiler switch, I don't think they assume undefined behavior does not happen. The compiler knows when undefined behavior happens. What the particular compiler chooses to do with the undefined behavior is the matter in question. I find it ridiculous that it chooses to break prior behavior.

Krishna

[toc] | [prev] | [next] | [standalone]

#38613

krishna.myneni@ccreweb.org writes:
>On Saturday, April 25, 2015 at 11:49:22 AM UTC-5, Anton Ertl wrote:
>> ... But the interpretation of the GCC maintainers
>> is different: Their interpretation is: The C standard allows anything
>> at all to happen if a program performs undefined behaviour, and such a
>> program is not a standard C program.  Since we are a standard C
>> compiler, we assume that undefined behaviour does not happen, and
>> derive optimization "facts" from that, such as "optimizing" the loop
>> bounds check away, turning the loop into an endless loop.
>>=20
>
>Since the compiler can return warnings of undefined behavior, for example, =
>with the -Wall compiler switch, I don't think they assume undefined behavio=
>r does not happen.

I did not claim that their position makes sense, but their optimizer
really does assume that undefined behaviour does not happen.

>The compiler knows when undefined behavior happens.

Not in general.  The "optimize into an endless loop" bug does not work
by the compiler seeing that something is undefined and then choosing
to do funny things, but it goes something like:

Array a has indexes 0-15, and is indexed with a[i], so i can only have
values 0-15 at that point (everything else would be undefined
behaviour).  So obviously i<16 is always true and we can "optimize" it
to true.

The compiler is oblivious to the fact that i<16 controls a loop that
is "optimized" into an endless loop.

The fun thing is that the resulting "optimized" program also does many
more out-of-bounds accesses than if it had been compiled as expected.

> What=
> the particular compiler chooses to do with the undefined behavior is the m=
>atter in question. I find it ridiculous that it chooses to break prior beha=
>vior.

I agree.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

[toc] | [prev] | [next] | [standalone]

#38630

On Sunday, April 26, 2015 at 10:09:38 AM UTC-5, Anton Ertl wrote:
> krishna.myneni@ccreweb.org writes:
...
> >The compiler knows when undefined behavior happens.
> 
> Not in general.  The "optimize into an endless loop" bug does not work
> by the compiler seeing that something is undefined and then choosing
> to do funny things, but it goes something like:
> 
> Array a has indexes 0-15, and is indexed with a[i], so i can only have
> values 0-15 at that point (everything else would be undefined
> behaviour).  So obviously i<16 is always true and we can "optimize" it
> to true.
> 
> The compiler is oblivious to the fact that i<16 controls a loop that
> is "optimized" into an endless loop.
> 
> The fun thing is that the resulting "optimized" program also does many
> more out-of-bounds accesses than if it had been compiled as expected.
> ...

I was trying to reproduce the behavior described above with gcc (v. 4.9.x), but couldn't. Do you have a C code snippet which illustrates this (so I know how to avoid this)?

Krishna

[toc] | [prev] | [next] | [standalone]

#38643

krishna.myneni@ccreweb.org writes:
>On Sunday, April 26, 2015 at 10:09:38 AM UTC-5, Anton Ertl wrote:
>> krishna.myneni@ccreweb.org writes:
>...
>> >The compiler knows when undefined behavior happens.
>> 
>> Not in general.  The "optimize into an endless loop" bug does not work
>> by the compiler seeing that something is undefined and then choosing
>> to do funny things, but it goes something like:
>> 
>> Array a has indexes 0-15, and is indexed with a[i], so i can only have
>> values 0-15 at that point (everything else would be undefined
>> behaviour).  So obviously i<16 is always true and we can "optimize" it
>> to true.
>> 
>> The compiler is oblivious to the fact that i<16 controls a loop that
>> is "optimized" into an endless loop.
>> 
>> The fun thing is that the resulting "optimized" program also does many
>> more out-of-bounds accesses than if it had been compiled as expected.
>> ...
>
>I was trying to reproduce the behavior described above with gcc (v. 4.9.x), but couldn't. Do you have a C code snippet which illustrates this (so I know how to avoid this)?

When they added this to gcc-4.8, it broke one of the few programs they
don't feel free to miscompile (a SPEC benchmark), so they made this
optimization less aggressive.  Bernd Paysan wrote that it still occurs
with the original code from which the benchmark was derived; maybe he
can post the code.  In the meantime, here's a variant not deriving
from "out-of-bounds is undefined behaviour":

extern void foo(int a[]);

int main(int argc, char *argv[]) {
  int i, a[16];
  int x=0;
  do {
    a[i++]=x;
    x+=0x10000000;
  } while (x!=0);
  foo(a);
  return 0;
}

gcc-4.8.2 miscompiles this into:

...
main:
.LFB24:
        .cfi_startproc
        .p2align 4,,10
        .p2align 3
.L2:
        jmp     .L2
...

Do you see why it does this?

As for avoiding it, I think the way to go is to avoid this compiler
and any other where the developers have this mindset.  I don't see any
other good way.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

[toc] | [prev] | [next] | [standalone]

#38646

On Monday, April 27, 2015 at 11:15:37 AM UTC+2, Anton Ertl wrote:
> krishna.myneni@ccreweb.org writes:
> >On Sunday, April 26, 2015 at 10:09:38 AM UTC-5, Anton Ertl wrote:
> >> krishna.myneni@ccreweb.org writes:
[..]
> >I was trying to reproduce the behavior described above with gcc
> (v. 4.9.x), but couldn't. Do you have a C code snippet which
> illustrates this (so I know how to avoid this)?
> 
> When they added this to gcc-4.8, it broke one of the few programs they
> don't feel free to miscompile (a SPEC benchmark), so they made this
> optimization less aggressive.  Bernd Paysan wrote that it still occurs
> with the original code from which the benchmark was derived; maybe he
> can post the code.  In the meantime, here's a variant not deriving
> from "out-of-bounds is undefined behaviour":
> 
> extern void foo(int a[]);
> 
> int main(int argc, char *argv[]) {
>   int i, a[16];
>   int x=0;
>   do {
>     a[i++]=x;
>     x+=0x10000000;
>   } while (x!=0);
>   foo(a);
>   return 0;
> }
> 
> gcc-4.8.2 miscompiles this into:
> 
> ...
> main:
> .LFB24:
>         .cfi_startproc
>         .p2align 4,,10
>         .p2align 3
> .L2:
>         jmp     .L2
> ...

gcc (GCC) 4.9.2 also has it, but at least warns in some cases.

marcel@me-tarzan ~
$ gcc -O2 -fno-exceptions -S undefined.c
undefined.c: In function 'main':
undefined.c:8:12: warning: iteration 7u invokes undefined behavior [-Waggressive-loop-optimizations]
           x+=0x10000000;
            ^
undefined.c:9:8: note: containing loop
        } while (x!=0);
        ^
 
I can't say I like this much :-)

-marcel

[toc] | [prev] | [next] | [standalone]

#38650

In article <2015Apr27.110253@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>krishna.myneni@ccreweb.org writes:
>>On Sunday, April 26, 2015 at 10:09:38 AM UTC-5, Anton Ertl wrote:
>>> krishna.myneni@ccreweb.org writes:
>>...
>>> >The compiler knows when undefined behavior happens.
>>>
>>> Not in general.  The "optimize into an endless loop" bug does not work
>>> by the compiler seeing that something is undefined and then choosing
>>> to do funny things, but it goes something like:
>>>
>>> Array a has indexes 0-15, and is indexed with a[i], so i can only have
>>> values 0-15 at that point (everything else would be undefined
>>> behaviour).  So obviously i<16 is always true and we can "optimize" it
>>> to true.
>>>
>>> The compiler is oblivious to the fact that i<16 controls a loop that
>>> is "optimized" into an endless loop.
>>>
>>> The fun thing is that the resulting "optimized" program also does many
>>> more out-of-bounds accesses than if it had been compiled as expected.
>>> ...
>>
>>I was trying to reproduce the behavior described above with gcc (v.
>4.9.x), but couldn't. Do you have a C code snippet which illustrates
>this (so I know how to avoid this)?
>
>When they added this to gcc-4.8, it broke one of the few programs they
>don't feel free to miscompile (a SPEC benchmark), so they made this
>optimization less aggressive.  Bernd Paysan wrote that it still occurs
>with the original code from which the benchmark was derived; maybe he
>can post the code.  In the meantime, here's a variant not deriving
>from "out-of-bounds is undefined behaviour":
>
>extern void foo(int a[]);
>
>int main(int argc, char *argv[]) {
>  int i, a[16];
>  int x=0;
>  do {
>    a[i++]=x;
>    x+=0x10000000;
>  } while (x!=0);
>  foo(a);
>  return 0;
>}

This make me cringe. You make use of the wrap around
property for x without making it unsigned.

>
>gcc-4.8.2 miscompiles this into:
>
>...
>main:
>.LFB24:
>        .cfi_startproc
>        .p2align 4,,10
>        .p2align 3
>.L2:
>        jmp     .L2
>...
>
>Do you see why it does this?

I don't need assembler code to expect that to go wrong.

>
>As for avoiding it, I think the way to go is to avoid this compiler
>and any other where the developers have this mindset.  I don't see any
>other good way.

In this case the mindset to change is the developers.

>
>- anton
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#38661

On Mon, 27 Apr 2015 05:02:53 -0400, Anton Ertl  
<anton@mips.complang.tuwien.ac.at> wrote:

> extern void foo(int a[]);
>
> int main(int argc, char *argv[]) {
>   int i, a[16];
>   int x=0;
>   do {
>     a[i++]=x;
>     x+=0x10000000;
>   } while (x!=0);
>   foo(a);
>   return 0;
> }
>

Shouldn't GCC warn with -Wall that 'i' is used unitialized?
Was there a typing error here?


Rod Pemberton

-- 
Cars kill more people than guns in the U.S.
Yet, no one is trying to take away your car.

[toc] | [prev] | [next] | [standalone]

#38669

Anton Ertl wrote:

> Bernd Paysan wrote that it still occurs
> with the original code from which the benchmark was derived; maybe he
> can post the code.

Here's the actual patch from x264, which works around the problem:

https://mailman.videolan.org/pipermail/x264-devel/2013-April/009962.html

The h.264 reference is part of the SPEC benchmark (a good choice for a 
benchmark, as h.264 is both complex, difficult to get fast, and important).  
x264 is the implementation people actually use (and with "actually", I mean: 
every Youtube video is re-encoded with x264).  x264 has been derived from 
h.264, so it contains similar, but not exactly identical code.

Small test, it doesn't get converted into an endless loop:

#include <stdio.h>
int main()
{
  int a[16] = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16 };
  int j=0, i;
  for(i=0; a[i]; i++) {
    j += a[i];
  }
  printf("result: %d, got up to %d\n", j, i);
}

This prints 120 for all optimizations except without optimization, where it 
becomes unpredictable; which is understandable, because it should search for 
the first 0 in memory.  There's no zero in a[], and there's no zero around 
it.

It looks like they have now a "defined" out-of-bound value, which reads 0.  
Test:

#include <stdio.h>
int main()
{
  int a[16] = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
  int j=0, i;
  for(i=0; !a[i]; i++) {
    j += a[i];
  }
  printf("result: %d, got up to %d\n", j, i);
}

Yes, gives an infinite loop with optimization.  Stops at 16 with result 0 
without.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#38670

On Monday, April 27, 2015 at 4:15:37 AM UTC-5, Anton Ertl wrote:
...
> extern void foo(int a[]);
> 
> int main(int argc, char *argv[]) {
>   int i, a[16];
>   int x=0;
>   do {
>     a[i++]=x;
>     x+=0x10000000;
>   } while (x!=0);
>   foo(a);
>   return 0;
> }
> 
> gcc-4.8.2 miscompiles this into:
> 
> ...
> main:
> .LFB24:
>         .cfi_startproc
>         .p2align 4,,10
>         .p2align 3
> .L2:
>         jmp     .L2
> ...
> 
> Do you see why it does this?
> 
...

I'm having trouble understanding why the compiler does this. To avoid issues of initialization and such, I modified the example as follows:

int main()
{
        int i=0, a[16];
        int x=0;
        do {
          a[i++] = x;
          x += 1;
        } while (x != 0 );
        printf("%d\n", a[0]);
        return 0;
}


gcc v 4.9.x generates the following, with -S -Wall -O3 :
:
main:
.LFB0:
        .cfi_startproc
        .p2align 4,,10
        .p2align 3
.L2:
        jmp     .L2
        .cfi_endproc
:

Ok, that's an infinite loop, and I can't see why.

Krishna

[toc] | [prev] | [next] | [standalone]

#38671

On Monday, April 27, 2015 at 9:30:44 PM UTC-5, krishna...@ccreweb.org wrote:
...
> I'm having trouble understanding why the compiler does this. To avoid issues of initialization and such, I modified the example as follows:
> 
> int main()
> {
>         int i=0, a[16];
>         int x=0;
>         do {
>           a[i++] = x;
>           x += 1;
>         } while (x != 0 );
>         printf("%d\n", a[0]);
>         return 0;
> }
> 
> 
> gcc v 4.9.x generates the following, with -S -Wall -O3 :
> :
> main:
> .LFB0:
>         .cfi_startproc
>         .p2align 4,,10
>         .p2align 3
> .L2:
>         jmp     .L2
>         .cfi_endproc
> :
> 
> Ok, that's an infinite loop, and I can't see why.
> 

Never mind. It is an infinite loop until it wraps around!

Krishna

[toc] | [prev] | [next] | [standalone]

#38674

On Mon, 27 Apr 2015 22:30:43 -0400, <krishna.myneni@ccreweb.org> wrote:
> On Monday, April 27, 2015 at 4:15:37 AM UTC-5, Anton Ertl wrote:

>> extern void foo(int a[]);
>>
>> int main(int argc, char *argv[]) {
>>   int i, a[16];
>>   int x=0;
>>   do {
>>     a[i++]=x;
>>     x+=0x10000000;
>>   } while (x!=0);
>>   foo(a);
>>   return 0;
>> }
>>
>> gcc-4.8.2 miscompiles this into:
>>
>> ...
>> main:
>> .LFB24:
>>         .cfi_startproc
>>         .p2align 4,,10
>>         .p2align 3
>> .L2:
>>         jmp     .L2
>> ...
>>
>> Do you see why it does this?
>>
> ...
>
> I'm having trouble understanding why the compiler does this. To avoid  
> issues of initialization and such, I modified the example as follows:
>
> int main()
> {
>         int i=0, a[16];
>         int x=0;
>         do {
>           a[i++] = x;
>           x += 1;
>         } while (x != 0 );
>         printf("%d\n", a[0]);
>         return 0;
> }
>
>
> gcc v 4.9.x generates the following, with -S -Wall -O3 :
> :
> main:
> .LFB0:
>         .cfi_startproc
>         .p2align 4,,10
>         .p2align 3
> .L2:
>         jmp     .L2
>         .cfi_endproc
> :
>

Anton said "gcc-4.8.2" introduced this error, but I'm seeing it for
much older GCC versions too.  GCC 3.4.1 (DOS 32-bit) does not generate
an infinite loop for any optimization level.  GCC 4.1.0 (DOS 32-bit)
and GCC 4.7.2 (Linux 64-bit) generate an infinite loop for -O2 and
-O3 levels.  So, the issue is likely with the entire GCC 4.x series
with -O2 optimization or higher.


Rod Pemberton

-- 
Cars kill more people than guns in the U.S.
Yet, no one is trying to take away your car.

[toc] | [prev] | [next] | [standalone]

#38683

On Tuesday, April 28, 2015 at 1:03:01 AM UTC-5, Rod Pemberton wrote:
...
> 
> Anton said "gcc-4.8.2" introduced this error, but I'm seeing it for
> much older GCC versions too.  GCC 3.4.1 (DOS 32-bit) does not generate
> an infinite loop for any optimization level.  GCC 4.1.0 (DOS 32-bit)
> and GCC 4.7.2 (Linux 64-bit) generate an infinite loop for -O2 and
> -O3 levels.  So, the issue is likely with the entire GCC 4.x series
> with -O2 optimization or higher.
> 
> ...

This example is more disturbing. There is never an out of bounds array access, and the compiler issues no warnings, even with -Wall, at any optimization level (-O0 through -O3). However, it executes a finite loop at -O1 and an infinite loop at -O2 or higher.

#include <stdio.h>
int main()
{
        int i=0, a[16];
        int x=0;
        do {
          a[i++] = x;
          x += 1;
          i = i % 16;
        } while (x > 0 );
        for( i = 0; i < 16; i++)
                printf("%d %d\n", i, a[i]);
        return 0;
}


Once again, at -O2 and -O3, the assembler code is,
:
main:
.LFB11:
        .cfi_startproc
        .p2align 4,,10
        .p2align 3
.L2:
        jmp     .L2
        .cfi_endproc
:
But, at -O1, the executable produces the expected output,

0 2147483632
1 2147483633
2 2147483634
3 2147483635
4 2147483636
5 2147483637
6 2147483638
7 2147483639
8 2147483640
9 2147483641
10 2147483642
11 2147483643
12 2147483644
13 2147483645
14 2147483646
15 2147483647

There are no warnings of undefined behavior at any optimization level!

Krishna
 

[toc] | [prev] | [next] | [standalone]

#38685

On Tuesday, 28 April 2015 09:44:54 UTC+1, krishna...@ccreweb.org  wrote:
> On Tuesday, April 28, 2015 at 1:03:01 AM UTC-5, Rod Pemberton wrote:
> ...
> > 
> > Anton said "gcc-4.8.2" introduced this error, but I'm seeing it for
> > much older GCC versions too.  GCC 3.4.1 (DOS 32-bit) does not generate
> > an infinite loop for any optimization level.  GCC 4.1.0 (DOS 32-bit)
> > and GCC 4.7.2 (Linux 64-bit) generate an infinite loop for -O2 and
> > -O3 levels.  So, the issue is likely with the entire GCC 4.x series
> > with -O2 optimization or higher.
> > 
> > ...
> 
> This example is more disturbing. There is never an out of bounds array access, and the compiler issues no warnings, even with -Wall, at any optimization level (-O0 through -O3). However, it executes a finite loop at -O1 and an infinite loop at -O2 or higher.
> 
> #include <stdio.h>
> int main()
> {
>         int i=0, a[16];
>         int x=0;
>         do {
>           a[i++] = x;
>           x += 1;
>           i = i % 16;
>         } while (x > 0 );
>         for( i = 0; i < 16; i++)
>                 printf("%d %d\n", i, a[i]);
>         return 0;
> }
> 
> 
> Once again, at -O2 and -O3, the assembler code is,
> :
> main:
> .LFB11:
>         .cfi_startproc
>         .p2align 4,,10
>         .p2align 3
> .L2:
>         jmp     .L2
>         .cfi_endproc
> :
> But, at -O1, the executable produces the expected output,
> 
> 0 2147483632
> 1 2147483633
> 2 2147483634
> 3 2147483635
> 4 2147483636
> 5 2147483637
> 6 2147483638
> 7 2147483639
> 8 2147483640
> 9 2147483641
> 10 2147483642
> 11 2147483643
> 12 2147483644
> 13 2147483645
> 14 2147483646
> 15 2147483647
> 
> There are no warnings of undefined behavior at any optimization level!
> 
> Krishna

I'm so glad I don't write C code any more. I am DONE with that s**t!

C compilers that don't compile properly? Have a nice day, I'm outta
here! :-)

[toc] | [prev] | [next] | [standalone]

#38700

krishna.myneni@ccreweb.org writes:
>         int x=0;
>         do {
>           a[i++] = x;
>           x += 1;
>           i = i % 16;
>         } while (x > 0 );

Signed integer overflow is undefined behaviour in C, so that the
compiler can assume the invariant x+1 > x for all signed ints x,
allowing some loops to run faster (less tests) in the expected case of
no overflow.  That is not an accident artifact of the compiler writers
relying on some tricky unintended interpretation of the standard.  From
what I can tell, the standard was written that way on purpose, to enable
that optimization.  So it is that way for a reason--whether it's a GOOD
reason is debatable, but it's a reason.

[toc] | [prev] | [next] | [standalone]

Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

Back to top | Article view | comp.lang.forth

csiph-web