Pike-devel

pike-devel@lists.lysator.liu.se

3 participants
3048 discussions

Start a nNew thread

gcc 3.2
by Martin Stjernholm, Roxen IS ＠ Pike developers forum 12 Dec '02

12 Dec '02

But then you better use --without-machine-code too, since valgrind gets very confused when machine code is overwritten.

6 8

Pike 7.4
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 12 Dec '02

12 Dec '02

I have a suggestion: Before committing changes to the compiler in the stable version of Pike, check that "make verify" passes.

4 12

gcc 3.2
by Mirar ＠ Pike developers forum 12 Dec '02

12 Dec '02

Maybe I should throw away -mcpu and -march with --without-copt?

5 9

lurigt
by Mirar ＠ Pike developers forum 12 Dec '02

12 Dec '02

Sorry, I'll translate: Recursion seems to behave funny in a normal-optimized Pike. I run the test I wrote earlier on 1) my valgrind-deoptimized Pike and 2) my normal optimized one: test 1) 2) Pike start overhead........ 0.000s 0.000s Ackermann.................. 1.172s 0.576s Array & String Juggling.... 0.693s 0.636s Compile.................... 1.393s 1.010s Compile & Exec............. 1.383s 1.018s Matrix multiplication...... 0.968s 0.407s Loops Nested............... 0.762s 0.292s Loops Recursed............. 1.090s 1.625s <- Why is the normal one *that* slow? The funniest of it all is that Ackermann isn't slow at all.

1 0

lurigt
by Mirar ＠ Pike developers forum 12 Dec '02

12 Dec '02

Rekursion verkar lite lurigt i en normal Pike. Jag körde tested jag gjorde tidigare på min valgrind-deoptimerade pike och min normala: test 1) 2) Pike start overhead........ 0.000s 0.000s Ackermann.................. 1.172s 0.576s Array & String Juggling.... 0.693s 0.636s Compile.................... 1.393s 1.010s Compile & Exec............. 1.383s 1.018s Matrix multiplication...... 0.968s 0.407s Loops Nested............... 0.762s 0.292s Loops Recursed............. 1.090s 1.625s <- Varför är den normala *så* långsam där? Det lurigaste är att Ackermann inte alls är lika långsam.

1 0

gcc 3.2
by Mirar ＠ Pike developers forum 11 Dec '02

11 Dec '02

Now gcc 3.2 bit me and allowed code before declaration. Any flags you can add to CFLAGS to not allow that sort of evilness?

10 44

Removed need for cflags_make_conf kludge.
by Mirar ＠ Pike developers forum 11 Dec '02

11 Dec '02

Never mind, I solved it using the optimize/cflags split loop to only use the first mentioned -O, -march and -mcpu.

1 0

Removed need for cflags_make_conf kludge.
by Mirar ＠ Pike developers forum 11 Dec '02

11 Dec '02

Without the "kludge", I get CFLAGS (misc)... -march=athlon-xp -mcpu=athlon-xp -mcpu=i686 ^^^^^^^^^ ^^^^

1 0

Removed need for cflags_make_conf kludge.
by Mirar ＠ Pike developers forum 11 Dec '02

11 Dec '02

Or did you find some magical way of skipping CPU optimizations without it?

1 0

Removed need for cflags_make_conf kludge.
by Mirar ＠ Pike developers forum 11 Dec '02

11 Dec '02

Would you mind putting it back again? 1) make.conf should be used per default if existant 2) warnings should be there even if make.conf is used Forcing use of --enable-make-conf does not solve 2) in any way. make.conf should not be seen as a replacement for using CFLAGS=.

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pike-devel