We noticed this problem when sh(1) started to misbehave. sh objects to a line in a script that looks like foo=$((2 << 29)) Fix: Workarounds: 1) remove 1 of -O2 or -m486 2) modify the offending line in the script to read foo=$((2<<29)) (ie remove the spaces on either side of <<) How-To-Repeat: [make 2.2-STABLE with CFLAGS in /etc/make.conf as above] cd /dev ; ./MAKEDEV
>We noticed this problem when sh(1) started to misbehave. >sh objects to a line in a script that looks like > >foo=$((2 << 29)) > >>How-To-Repeat: > >[make 2.2-STABLE with CFLAGS in /etc/make.conf as above] > >cd /dev ; ./MAKEDEV I can't duplicate this. I guess the bug is actually in sh, and different flags just move it. >Workarounds: >1) remove 1 of -O2 or -m486 These flags should never have been recommended. Use -O2 only if you want to get nonstandard bugs. -m486 is worse than useless except possibly on 486's. >2) modify the offending line in the script to read >foo=$((2<<29)) > (ie remove the spaces on either side of <<) Actually 1<<29. Bruce
State Changed From-To: open->closed -m486 itself ain't broken. It's so simple that its effect can easily be verified in the compiler sources (it uses a default padding of 4 bytes instead of 2, and replaces the `leave' with a mov and a pop instruction -- that's all folks). The bug itself (unles already fixed) is more likely in the shell, but we need a method to reproduce it should it appear again.