Re: GCC 3.2 transition
> My concern is that locally compiled apps built against C++ libraries > other than libstdc++ will silently stop working on upgrade. This is > certainly not the most important issue facing us in the transition, but > so far it seems to me that people are regarding it as so *un*important > that it's not worth discussing at all. Having been surprised by 64-bit stuff ceasing to work on sparc after the libc6 security upgrade, and then the additional amusement of no longer being able to compile anything 64-bit, I imagine the C++ breakage would be a whole lot less painless.
cpp oddness
The output of "cpp test.c" on the attached file:
# 1 "test.c"
# 1 ""
# 1 ""
# 1 "test.c"
test.c:5:2: warning: #warning TEST_FIVE defined
test.c:8:2: warning: #warning TEST_NINE defined
# 15 "test.c"
test.c:25:2: warning: #warning 4 and 7 claim to be equal
enum __stuff { TEST_FOUR = 4, TEST_SEVEN = 7 };
# 28 "test.c"
test.c:33:2: warning: #warning TEST_THREE defined
test.c:36:2: warning: #warning TEST_EIGHT defined
test.c:40:2: warning: #warning 3 and 8 claim to be equal
enum __stuffandnonsense { TEST_THREE = 3, TEST_EIGHT = 8 };
Is this correct or buggy behavior? If correct, how can I test whether
or not the RLIMIT_ enumerations in are equal to one
another?
#define TEST_FIVE 5
#define TEST_NINE 9
#ifdef TEST_FIVE
#warning TEST_FIVE defined
#endif
#ifdef TEST_NINE
#warning TEST_NINE defined
#endif
#if (TEST_FIVE == TEST_NINE)
#warning 5 and 9 claim to be equal
#endif
enum __stuff { TEST_FOUR = 4, TEST_SEVEN = 7 };
#ifdef TEST_FOUR
#warning TEST_FOUR defined
#endif
#ifdef TEST_SEVEN
#warning TEST_SEVEN defined
#endif
#if (TEST_FOUR == TEST_SEVEN)
#warning 4 and 7 claim to be equal
#endif
enum __stuffandnonsense { TEST_THREE = 3, TEST_EIGHT = 8 };
#define TEST_THREE TEST_THREE
#define TEST_EIGHT TEST_EIGHT
#ifdef TEST_THREE
#warning TEST_THREE defined
#endif
#ifdef TEST_EIGHT
#warning TEST_EIGHT defined
#endif
#if (TEST_THREE == TEST_EIGHT)
#warning 3 and 8 claim to be equal
#endif
Re: cpp oddness
> The output of "cpp test.c" on the attached file:
And cpp -Wundef test.c:
# 1 "test.c"
# 1 ""
# 1 ""
# 1 "test.c"
test.c:5:2: warning: #warning TEST_FIVE defined
test.c:8:2: warning: #warning TEST_NINE defined
# 15 "test.c"
test.c:24:6: warning: "TEST_FOUR" is not defined
test.c:24:19: warning: "TEST_SEVEN" is not defined
test.c:25:2: warning: #warning 4 and 7 claim to be equal
enum __stuff { TEST_FOUR = 4, TEST_SEVEN = 7 };
# 28 "test.c"
test.c:33:2: warning: #warning TEST_THREE defined
test.c:36:2: warning: #warning TEST_EIGHT defined
test.c:39:6: warning: "TEST_THREE" is not defined
test.c:39:20: warning: "TEST_EIGHT" is not defined
test.c:40:2: warning: #warning 3 and 8 claim to be equal
enum __stuffandnonsense { TEST_THREE = 3, TEST_EIGHT = 8 };
Note the contradiction.
Re: cpp oddness
> Any identifier without a definition is considered to be 0 in an #if. > Macro substitution is performed on TEST_THREE, which converts it to the > identifier TEST_THREE - still not #define'd. So it's 0. So, to be clear, it's impossible to compare RLIMIT defines in the preprocessor, then?
Re: glibc_2.3.1-16_sparc64.changes ACCEPTED
> That's right. If new gcc package has ability to handle sparc64 -m64 > (currently both gcc-3.3 and gcc-snapshot have not come), it should be > duploaded with appropriate changes for glibc source package. glibc_2.3.2-1 builds libc6-sparc64 and libc6-dev-sparc64 just fine with the following patch if gcc-3.3 is built with the sparc64-build and sparc-config-ml patches enabled. diff -ur glibc-2.3.2/debian/packages.d/sparc64.mk gtemp/debian/packages.d/sparc64.mk --- glibc-2.3.2/debian/packages.d/sparc64.mk2003-03-25 18:40:55.0 + +++ gtemp/debian/packages.d/sparc64.mk 2003-03-25 13:07:57.0 + @@ -8,7 +8,7 @@ flags_64 = -g0 -O2 -Wall -finline-limit=3000 -MYCC = gcc-3.2 -m64 +MYCC = gcc-3.3 -m64 ifeq ($(log_build),/dev/tty) log_build_64 = /dev/tty diff -ur glibc-2.3.2/debian/rules gtemp/debian/rules --- glibc-2.3.2/debian/rules2003-03-25 18:40:54.0 + +++ gtemp/debian/rules 2003-03-25 13:07:39.0 + @@ -174,7 +174,7 @@ include $(package_rules)/glibc-doc.mk include $(package_rules)/optimized.mk ifeq ($(DEB_HOST_GNU_CPU),sparc) -#include $(package_rules)/sparc64.mk +include $(package_rules)/sparc64.mk endif ifeq ($(DEB_HOST_GNU_CPU),s390) include $(package_rules)/s390x.mk diff -ur glibc-2.3.2/debian/sysdeps/linux.mk gtemp/debian/sysdeps/linux.mk --- glibc-2.3.2/debian/sysdeps/linux.mk 2003-03-25 18:40:55.0 + +++ gtemp/debian/sysdeps/linux.mk 2003-03-25 13:14:53.0 + @@ -13,9 +13,9 @@ as_flags_$(OPT) = endif -#ifeq ($(DEB_HOST_GNU_CPU),sparc) -# arch_packages += $(libc)-sparc64 $(libc)-dev-sparc64 -#endif +ifeq ($(DEB_HOST_GNU_CPU),sparc) + arch_packages += $(libc)-sparc64 $(libc)-dev-sparc64 +endif ifeq ($(DEB_HOST_GNU_CPU),s390) arch_packages += $(libc)-s390x $(libc)-dev-s390x
Re: glibc_2.3.1-16_sparc64.changes ACCEPTED
> issue. If gcc 3.3 will be back to -m64 aware, we re-enable these > configurations. Do you know the status of gcc-3.3 which is ready for > -m64? gcc-3.3 3.3-0pre3, currently in sid, builds -m64 binaries that work.
Re: Processed: reassign 499142 to fakeroot
On Thu, Nov 06, 2008 at 06:06:03AM +, Debian Bug Tracking System wrote: > > reassign 499142 fakeroot > Bug#499142: hangs while building eclipse > Bug reassigned from package `gij-4.3' to `fakeroot'. Are threads involved? Does fakeroot-tcp avoid the problem? If neither, has the file being fstat'd been access previously under fakeroot or is this the initial "contact"? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#533010: lib32g2c0: /emul/ia32-linux deprecated
Package: lib32g2c0 Version: 1:3.4.6-9 On amd64, files in /emul/ia32-linux should be moved to /usr/lib32. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#533009: lib32ffi5: /emul/ia32-linux deprecated
Package: lib32ffi5 Version: 3.0.7-1 On amd64, files in /emul/ia32-linux should be moved to /usr/lib32. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#533010: Bug#533015: lib32z1: /emul/ia32-linux deprecated
On Sat, Jun 13, 2009 at 08:15:36PM +0100, Mark Brown wrote: > Might be worth putting a reference to the decision making process or > something in these reports - this change doesn't appear to have been > announced anywhere terribly widely and appears to be in very early > stages so your report was somewhat surprising and created a bit of an > "oh, really?" reaction. On Mon, Jun 15, 2009 at 06:09:51PM +0200, Matthias Klose wrote: > I assume you want these changes in other gcc packages as well. please could > you > point me to a summary of any ML discussion, or help with conflicts needed with > this change? Mailing list discussions: http://lists.debian.org/debian-devel/2009/03/msg00597.html http://lists.debian.org/debian-devel/2009/05/msg00168.html -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#582787: gcc-4.4: [hppa] Test tstdiomisc fails when multiplication of NAN by -1 results in NAN again.
Package: gcc-4.4
Version: 4.4.4-2
- Forwarded message from Carlos O'Donell -
Date: Sat, 22 May 2010 22:58:18 -0400
From: Carlos O'Donell
To: John David Anglin ,
Debian HPPA Port List ,
libc-po...@sourceware.org
Subject: Test tstdiomisc fails when multiplication of NAN by -1 results in NAN
again.
Dave,
The following testcase is an example of code used in a glibc testcase.
I'm trying hard to shake out the bugs in the glibc testsuite for
debian, and one testsuite failure looks like a compiler issue.
The expected behaviour is for the testcase to print the raw IEEE754
value of -NAN.
The observed behaviour, when -DALT is on the command line, is that the
testcase prints the incorrect raw value e.g. NAN.
GCC 4.4.3 in debian doesn't compile this code correctly. Could you
have a loot at my analysis and tell me if you have seen this before?
cat >> tst-mul-nan.c <
#include
#ifdef ALT
volatile double nanval;
#else
#define nanval NAN
#endif
int
main ()
{
#ifdef ALT
nanval = NAN;
#endif
printf ("0x%llx\n", -nanval);
return 0;
}
EOF
gcc -g3 -O0 -save-temps -o test-mul-nan-OK test-mul-nan.c; ./test-mul-nan-OK
0xfff7
This is the correct result e.g. -NAN. In the correct case the compiler
has already computer -NAN and it's loaded directly from the local
symbol e.g.
.LC1:
.word -524289
.word -1
This is the case that is not working correctly:
gcc -g3 -O0 -save-temps -DALT -o test-mul-nan-NG test-mul-nan.c;
./test-mul-nan-NG
0x7ff7
That result is not -NAN, it is NAN. This is incorrect.
In the incorrect compilation the compiler loads NAN from a local constant:
.LC0:
.word 2146959359
.word -1
This is 0x7ff7 e.g. NAN.
Then it loads something which I assume *should* be -1, but isn't:
.LC2:
.word -1074790400
.word 0
What is this value, it's 0xbff0 e.g. -1.875. Should it be
0xbf80 e.g. -1.0 exactly, but it's not? Is this a mistake?
In the incorrect case the compiler tries to multiply this value by NAN
to get a result of -NAN.
addil LR'nanval-$global$,%r27
copy %r1,%r19
ldo RR'nanval-$global$(%r19),%r19
fldds 0(%r19),%fr23
ldil LR'.LC2,%r19
ldo RR'.LC2(%r19),%r19
fldds 0(%r19),%fr22
fmpy,dbl %fr23,%fr22,%fr22
It seems like it should work (even if fr22 is -1.875), since the sign
of the output NAN is the XOR of the signs of the inputs, therefore "-
XOR + = -" and the the result should be -NAN, but it's not, it's NAN?
Why?
PA-RISC 2.0 Architecture, Floating Coprocessor 8-23 "Operations With
NaNs", and 8-24 "Sign Bit" can be referenced for information on NANs.
After the multiplication fr22 still contains NAN, and that is what is
printed instead of the expected result of -NAN.
Any idea what is going on here? Thanks for your help.
Cheers,
Carlos.
- End forwarded message -
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100523164117.ga13...@scru.org
Bug#337861: fakeroot: [m68k] FTBFS with 1 of 7 tests failed
> please recheck with gcc-4.1. Looks to me like it builds. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#370248: 4.0/4.1 alpha regression affecting qdbm build
severity 370248 serious tags 370248 + patch quit There is a patch listed at http://gcc.gnu.org/PR27891 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#370248: 4.0/4.1 alpha regression affecting qdbm build
> Did you test it? I'm not convinced it can be easily backported without > breaking anything. I'll ask the author. No, I don't have access to any alpha machines. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#440259: java-gcj-compat-dev: /usr/lib/jvm/java-gcj/bin/java is a dangling symlink
Package: java-gcj-compat-dev Version: 1.0.76-5 /usr/lib/jvm/java-gcj/bin/java points to /usr/bin/ecj, which is not provided by any of the dependencies. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#202746: gcc: -O2 causes bogutil to segfault
Package: gcc Version: multiple Severity: normal The bogofilter test suite fails on m68k, hppa, mips, mipsel, and arm due to a segfault in bogoutil. On hppa, at least, compiling with -O0 or -O1 results in a working binary. Therefore I assume an optimization bug. (This was tested with gcc-3.3 3.3.1-0pre0)
Bug#202746: gcc: -O2 causes bogutil to segfault
[this message only refers to testing that was only done on hppa] > - does it work with gcc-3.2? > - does it work with gcc-snapshot? No, with -O2 it breaks on gcc-3.23.2.3-6 gcc-3.33.3.1-0rc1 gcc-snapshot 20030722-1 > - can you identify the file beeing miscompiled? No, I don't seem to be able to do that. If I compile with -O1, it works. If I compile with -O2, it segfaults. If I compile all objects -O2 except the ones that seem to be relevant in the backtrace, it still segfaults. (Also tried with various random .c files that didn't seem relevant).
Bug#202746: gcc: -O2 causes bogutil to segfault
> > - can you identify the file beeing miscompiled? > > No, I don't seem to be able to do that. If I compile with -O1, it > works. If I compile with -O2, it segfaults. If I compile all objects > -O2 except the ones that seem to be relevant in the backtrace, it still > segfaults. (Also tried with various random .c files that didn't seem > relevant). I take that back. If all files are compiled with -O2 except for datastore_db.c (compiled with -O0), it works.
Bug#202746: gdb backtrace
- Forwarded message from Clint Adams <[EMAIL PROTECTED]> -
Date: Wed, 23 Jul 2003 08:35:00 -0400
From: Clint Adams <[EMAIL PROTECTED]>
To: Matthias Andree <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: Re: bogoutil segfaults
> Does SPARC support unaligned access?
Not as far as I know.
> Unfortunately, we don't see a stack backtrace. It should be printed
> automatically when gdb is available.
On hppa:
Making check in bogoutil
make[3]: Entering directory `/tmp/obj/src/tests/bogoutil'
make check-TESTS
make[4]: Entering directory `/tmp/obj/src/tests/bogoutil'
cmp: EOF on ./checks.1487.20030723T083159/output-dl-1.txt
>>> Using core file "./core".
Cannot access memory at address 0x1603c
>>> Using exec file "../../bogoutil".
>>> Running command: gdb -nw -r -batch -n -x script.gdb.1543 -silent
>>> ../../bogoutil ./core ,
userdata=0x0) at ../../bogofilter-0.14.0/src/datastore_db.c:528
528 break;
<<< SIMPLE BACKTRACE <<<
#0 0x0001603c in db_foreach (vhandle=0x29098, hook=0x28096 <__JCR_LIST__+6>,
userdata=0x0) at ../../bogofilter-0.14.0/src/datastore_db.c:528
#1 0x00011730 in db_oper (path=0xc33c4022 ,
open_mode=DB_READ, funct=0x28096 <__JCR_LIST__+6>, userdata=0x0) at
../../bogofilter-0.14.0/src/bogoutil.c:163
#2 0x0001179c in dump_file (db_file=0x1317e4f ) at ../../bogofilter-0.14.0/src/bogoutil.c:178
#3 0x401c7b94 in __libc_start_main () from /lib/libc.so.6
#4 0x00011298 in _start ()
<<< FULL BACKTRACE <<<
#0 0x0001603c in db_foreach (vhandle=0x29098, hook=0x28096 <__JCR_LIST__+6>,
userdata=0x0) at ../../bogofilter-0.14.0/src/datastore_db.c:528
i = 0
ret = 0
#1 0x00011730 in db_oper (path=0xc33c4022 ,
open_mode=DB_READ, funct=0x28096 <__JCR_LIST__+6>, userdata=0x0) at
../../bogofilter-0.14.0/src/bogoutil.c:163
dbh = (void *) 0x29098
#2 0x0001179c in dump_file (db_file=0x1317e4f ) at ../../bogofilter-0.14.0/src/bogoutil.c:178
rc = 1076871996
#3 0x401c7b94 in __libc_start_main () from /lib/libc.so.6
No symbol table info available.
#4 0x00011298 in _start ()
No symbol table info available.
>>> Done.
FAIL: t.dump.load
../../../../bogofilter-0.14.0/src/tests/bogoutil/t.nonascii.replace: line 29:
1586 Segmentation fault (core dumped) $BOGOUTIL -d ${WORDLIST}
>${TMPDIR}/output.1
>>> Using core file "./core".
Cannot access memory at address 0x1603c
>>> Using exec file "../../bogoutil".
>>> Running command: gdb -nw -r -batch -n -x script.gdb.1587 -silent
>>> ../../bogoutil ./core ,
userdata=0x0) at ../../bogofilter-0.14.0/src/datastore_db.c:528
528 break;
<<< SIMPLE BACKTRACE <<<
#0 0x0001603c in db_foreach (vhandle=0x29098, hook=0x28096 <__JCR_LIST__+6>,
userdata=0x0) at ../../bogofilter-0.14.0/src/datastore_db.c:528
#1 0x00011730 in db_oper (path=0xc33c4022 ,
open_mode=1076871996, funct=0x28096 <__JCR_LIST__+6>, userdata=0x0) at
../../bogofilter-0.14.0/src/bogoutil.c:163
#2 0x0001179c in dump_file (db_file=0x131a35f ) at ../../bogofilter-0.14.0/src/bogoutil.c:178
#3 0x401c7b94 in __libc_start_main () from /lib/libc.so.6
#4 0x00011298 in _start ()
<<< FULL BACKTRACE <<<
#0 0x0001603c in db_foreach (vhandle=0x29098, hook=0x28096 <__JCR_LIST__+6>,
userdata=0x0) at ../../bogofilter-0.14.0/src/datastore_db.c:528
i = 0
ret = 0
#1 0x00011730 in db_oper (path=0xc33c4022 ,
open_mode=1076871996, funct=0x28096 <__JCR_LIST__+6>, userdata=0x0) at
../../bogofilter-0.14.0/src/bogoutil.c:163
dbh = (void *) 0x29098
#2 0x0001179c in dump_file (db_file=0x131a35f ) at ../../bogofilter-0.14.0/src/bogoutil.c:178
rc = 1076871996
#3 0x401c7b94 in __libc_start_main () from /lib/libc.so.6
No symbol table info available.
#4 0x00011298 in _start ()
No symbol table info available.
>>> Done.
FAIL: t.nonascii.replace
===
2 of 2 tests failed
===
make[4]: *** [check-TESTS] Error 1
make[4]: Leaving directory `/tmp/obj/src/tests/bogoutil'
make[3]: *** [check-am] Error 2
make[3]: Leaving directory `/tmp/obj/src/tests/bogoutil'
make[2]: *** [check-recursive] Error 1
make[2]: Leaving directory `/tmp/obj/src/tests'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory `/tmp/obj/src'
make: *** [check-recursive] Error 1
-
FAQ: http://bogofilter.sourceforge.net/bogofilter-faq.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For summary digest subscription: [EMAIL PROTECTED]
For more commands, e-mail: [EMAIL PROTECTED]
- End forwarded message -
Bug#202746: gcc: -O2 causes bogutil to segfault
> > No, with -O2 it breaks on > > gcc-3.23.2.3-6 > > gcc-3.33.3.1-0rc1 > > gcc-snapshot 20030722-1 > > but it did work with gcc-2.95? There is no 2.95 on hppa.
Bug#202746: slightly more info for bogoutil segfault
http://buildd.debian.org/build.php?arch=&pkg=bogofilter * 0.14.1.1-1 (arm) (latest build at Aug 1 21:45: maybe-failed) * 0.14.1.1-1 (mipsel) (latest build at Aug 1 21:40: maybe-failed) * 0.14.1.1-1 (mips) (latest build at Aug 1 21:58: maybe-failed) * 0.14.1.1-1 (hppa) (latest build at Aug 1 22:06: maybe-failed) * 0.14.1.1-1 (m68k) (latest build at Aug 1 23:02: maybe-failed) These logs contain gdb backtraces (except when gdb wasn't happy).
Re: Bug#203980: fakeroot doesn't build on sparc
> In file included from /usr/lib/gcc-lib/sparc-linux/3.2.3/include/stdio.h:683, > from ../faked.cc:80: > /usr/include/bits/stdio.h: In function `int getchar()': > /usr/include/bits/stdio.h:42: declaration of `int getchar()' throws different >exceptions > /usr/lib/gcc-lib/sparc-linux/3.2.3/include/stdio.h:394: than previous >declaration `int getchar() throw ()' Looks to me as though g++ 1:3.2.3-7 isn't happy with libc6 2.3.2-1.
Bug#221282: /usr/bin/gcc: sparc wrapper is annoying
Package: gcc Version: 4:3.3.1-2 File: /usr/bin/gcc Please make the sparc gcc wrapper optional for those of us who would prefer a symlink to gcc-3.3.
Bug#221282: /usr/bin/gcc: sparc wrapper is annoying
On Mon, Nov 17, 2003 at 08:56:05PM +0100, Matthias Klose wrote: > why is it annoying? it just works. It just works the opposite of the way I want it to work. It also confuses the hell out of users who just want to compile something. > Yes, but sparc32-jailing builds is both non-obvious, tedious and easy > to forget. If there was a global way to disable the "64-bit by > default" I think people would be less offended by the wrappper? > e.g. [ -f /etc/gcc/i-luv-32-bit ] or something ;) Maybe add gcc-3.3 and sparc-gcc-wrapper as /usr/bin/gcc alternatives. Seems wasteful to fork the wrapper each time just so that it can check for a file and then behave itself properly. Or perhaps a separate, optional binary package for the wrapper.
Bug#221282: /usr/bin/gcc: sparc wrapper is annoying
> Actually, it works just like it is supposed to work. That may not be the > same as in the past, but it's the way it should be. Granted the surprise > is something the users will have to adjust to, but that doesn't mean > things shouldn't work properly. > > On a 64-bit machine, one should expect to get 64-bit binaries by > default. Users have always complained about that. Now that sparc64 is > moving into a working state, that reality will happen and become the > norm. Ignoring the fact that gcc gives me 32-bit binaries by default on every bi-arch system I've ever seen, you're not wrapping binutils, so, poor naive programs expecting consistency between gcc and ld are SOL. I'm not saying this isn't your intention. I'm saying I want a convenient way to permanently disable this on every sparc64 system I have. I imagine that I will also want to disable this on x86-64 and s390x if this wrapper migrates there. Should I ITP a diversion package?
Re: C01arith.ztst
> The string stored at ptr, after ptr is no longer equal to optr, changes > from "" to "\020" when checkunary() is called. I'm going to try again > with gcc -O0 to see if the same thing happens. The test passes with no optimization; I guess this means it's a gcc bug specific to mips.
Re: C01arith.ztst
> I missed the beginning of this thread. What gcc version? Do you have a > small test program? How about "-O2 -fwritable-strings"? ii gcc3.3.3-2The GNU C compiler No. "-O2 -fwritable-strings" produces the same behavior as "-O2".
Re: C01arith.ztst
> "-O2 -fwritable-strings" produces the same behavior as "-O2". It's fine with -O0 and -O1. Should I be trying -fwritable-strings with one of those?
