Michoo <m...@v...pl> napisał(a):

> On 02.04.2012 17:31, Michoo wrote:
> > On 02.04.2012 17:11, M.M. wrote:
> >> W wewnętrznej pętli zmienną oznaczyłem symbolem "j" i też
> >> nie zatrzymuje się. Mój GCC ma znowu jakiegoś buga :(
> > 4.6? Kompilowane z 02?
> > Wygląda na to, że optymalizator doszedł do wniosku, że to pętla
> > nieskończona....
> I co ciekawe kod wynikowy jest zgodny ze standardem - występuje integer
> overflow a ten jest niezdefiniowany. Co równie ciekawe zmiana t na
> unsigned pomaga.

Zmiana na float i double też pomaga.
Pozdrawiam


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

Dnia Mon, 02 Apr 2012 16:51:12 +0000, M.M. napisal:

> Michoo <m...@v...pl> napisał(a):
>
>> On 02.04.2012 17:31, Michoo wrote:
>> > On 02.04.2012 17:11, M.M. wrote:
>> >> W wewnętrznej pętli zmienną oznaczyłem symbolem "j" i też
>> >> nie zatrzymuje się. Mój GCC ma znowu jakiegoś buga :(
>> > 4.6? Kompilowane z 02?
>> > Wygląda na to, że optymalizator doszedł do wniosku, że to pętla
>> > nieskończona....
>> I co ciekawe kod wynikowy jest zgodny ze standardem - występuje integer
>> overflow a ten jest niezdefiniowany. Co równie ciekawe zmiana t na
>> unsigned pomaga.
>
> Zmiana na float i double też pomaga.

Pomaga też -fwrapv (signed overflow przechodzi na min, czyli ujemne)
albo -fno-strict-overflow (wyłącza założenie, że overflow nie występuje).

Edek

do góry

W dniu 2012-04-02 19:25, Edek Pienkowski pisze:
> Dnia Mon, 02 Apr 2012 16:51:12 +0000, M.M. napisal:
>
>> Michoo<m...@v...pl> napisał(a):
>>
>>> On 02.04.2012 17:31, Michoo wrote:
>>>> On 02.04.2012 17:11, M.M. wrote:
>>>>> W wewnętrznej pętli zmienną oznaczyłem symbolem "j" i też
>>>>> nie zatrzymuje się. Mój GCC ma znowu jakiegoś buga :(
>>>> 4.6? Kompilowane z 02?
>>>> Wygląda na to, że optymalizator doszedł do wniosku, że to pętla
>>>> nieskończona....
>>> I co ciekawe kod wynikowy jest zgodny ze standardem - występuje integer
>>> overflow a ten jest niezdefiniowany. Co równie ciekawe zmiana t na
>>> unsigned pomaga.
>>
>> Zmiana na float i double też pomaga.
>
> Pomaga też -fwrapv (signed overflow przechodzi na min, czyli ujemne)
> albo -fno-strict-overflow (wyłącza założenie, że overflow nie występuje).


Na O2 kompilator próbuje policzyć samemu ta pętlę (i patrząc
w asm udaje mu się to dla unsigned i Twoich flag). Na int
'nie wie' jak przepełniać i się gubi. OK. Ale dlaczego
akurat wynikiem jest nieskończona pętla? Jeśli sobie nie
radzi z optymalizacją nie powinien raczej zostawić kodu
w spokoju i go nie optymalizować?

pzdr
bartekltg

do góry

bartekltg <b...@g...com> napisał(a):

> Na O2 kompilator próbuje policzyć samemu ta pętlę (i patrząc
> w asm udaje mu się to dla unsigned i Twoich flag). Na int
> 'nie wie' jak przepełniać i się gubi. OK. Ale dlaczego
> akurat wynikiem jest nieskończona pętla? Jeśli sobie nie
> radzi z optymalizacją nie powinien raczej zostawić kodu
> w spokoju i go nie optymalizować?

No właśnie nie wiem. Rozumiem żeby wpisał bzdury do zmiennej, bo
może sobie sam wybrać sposób obsługi przepełnienia. Ale dlaczego
się nie kończy to mnie zdumiewa.
Pozdrawiam



--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

On 04.04.2012 16:13, M.M. wrote:
> bartekltg<b...@g...com> napisał(a):
>
>> Na O2 kompilator próbuje policzyć samemu ta pętlę (i patrząc
>> w asm udaje mu się to dla unsigned i Twoich flag). Na int
>> 'nie wie' jak przepełniać i się gubi. OK. Ale dlaczego
>> akurat wynikiem jest nieskończona pętla? Jeśli sobie nie
>> radzi z optymalizacją nie powinien raczej zostawić kodu
>> w spokoju i go nie optymalizować?
>
> No właśnie nie wiem. Rozumiem żeby wpisał bzdury do zmiennej, bo
> może sobie sam wybrać sposób obsługi przepełnienia. Ale dlaczego
> się nie kończy to mnie zdumiewa.
Bo pętla nieskończona to jedyna zgodna ze standardem sytuacja w której
wyliczanie takiego wyrażenia zakończy się błędem. (A jak się powie
kompilatorowi, że ma ignorować standard to generuje kod zgodny z
oczekiwaniami.)

--
Pozdrawiam
Michoo

do góry