sys-apps/sed-4.2.1-r1 builds an inferior executable which does not support POSIX character classes such as [:space:] if both -O3 and -DNDEBUG are used as compiler flags with gcc-4.7.3. This makes other package builds fail, for example dev-libs/elfutils. Reproducible: Always Steps to Reproduce: 1. Include -O3 in CFLAGS and -DNDEBUG in CPPFLAGS in make.conf 2. Emerge sys-apps/sed. No errors are reported. 3. Try command: echo before after | sed -e 's/[[:space:]]/x/g' Actual Results: sed: -e expression #1, char 17: Unmatched [ or [^ Expected Results: beforexafter ANSI C allows to define the NBDEBUG preprocessor flag which expands all assert() macro invocations as no-op statements. Combined with -O3 this creates highly-optimized high-speed executables with assert()-runtime checks effectively removed. A correct executable should behave identically whether assert() checks are removed or not. sed-4.2.1 is broken: It supports POSIX character classes when built with -O2 or without -DNDEBUG, but it does no longer recognize POSIX character classes if built with both -O3 and -DNDEBUG. Recommendation: Filter out -O* flags and always use -O2 until upstream has fixed this bug. I will report the bug upstream as well.
can't reproduce. we don't filter flags in ebuilds either. you must post `emerge --info` in every bug report as an attachment. a full build log is also useful.
Created attachment 370580 [details] Output of emerge --info
Created attachment 370582 [details] configure log from the sandboxed build environment
(In reply to SpanKY from comment #1) > can't reproduce. we don't filter flags in ebuilds either. I know, that's the problem here. Of course this is an upstream bug, but upstream has been un-cooperative so far (seems to be stressed out by Gentoo users). The bug is somehow linked to improper use of assert() and only surfaces with -O3 optimizations when the assert()s are removed (-DNDEBUG). Filtering out optimization levels larger than 2 seem to avoid the bug. Also note that I have an amd64 system; perhaps the bug does not show on x86. > you must post `emerge --info` in every bug report as an attachment. a full > build log is also useful. I have attached both.
i can reproduce with 4.2.1, but not 4.2.2. so i don't see the point in spending any time on this.
(In reply to SpanKY from comment #5) > i can reproduce with 4.2.1, but not 4.2.2. so i don't see the point in > spending any time on this. That's good news! Seems a good idea to stabilize 4.2.2 then, because 4.2.1 is the newest stable version... "stable" being a relative term in this case. Until then, I'll unmask 4.2.2. Thanks!
