libgcrypt-1.4.4 unconditionally replaces "-O" with "-O1", potentially breaking other $CFLAGS
Closed, ResolvedPublic


There is a new regression in libgcrypt-1.4.4 (as 1.4.3 compiled cleanly):

The MIPSpro compilers use some flags such as '-OPT:value1:value2' - but it
seems that a broken 'sed' invocation is replacing *every* instance of "-O" with
"-O1" - resulting in this argument being passed as "-O1PT:value1:value2", which
causes the compiler to abort.

The exact error message is:

`echo /opt/portage/bin/bash ../libtool --tag=CC --mode=compile cc
-DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/opt/portage/usr/include
-I/opt/portage/usr/include -c99 -O2 -n32 -mips4 -r14000 -float_const
-use_readonly_const -TARG:isa=mips4:platform=ip35:processor=r14000
-TENV:zeroinit_in_bss=ON -OPT:fast_io=ON:Olimit=8192:reorg_common=ON:swp=ON
-LNO:auto_dist=ON:fusion_peeling_limit=8:gather_scatter=2 -diag_error 1035
-woff 1174,1183,1185,1552,3968,3970 -c ./tiger.c | sed -e 's/-O[2-9s]*/-O1/g' `
cc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/opt/portage/usr/include
-I/opt/portage/usr/include -c99 -O1 -n32 -mips4 -r14000 -float_const
-use_readonly_const -TARG:isa=mips4:platform=ip35:processor=r14000
-TENV:zeroinit_in_bss=ON -O1PT:fast_io=ON:Olimit=8192:reorg_common=ON:swp=ON
-LNO:auto_dist=ON:fusion_peeling_limit=8:gather_scatter=2 -diag_error 1035
-woff 1174,1183,1185,1552,3968,3970 -c ./tiger.c -DPIC -o .libs/tiger.o
cc WARNING: -O1 conflicts with -O; using latter value (-O)
cc ERROR parsing -O1PT:fast_io=ON:Olimit=8192:reorg_common=ON:swp=ON: unknown
make[2]: * [tiger.lo] Error 1
make[2]: Leaving directory
* [all-recursive] Error 1
make[1]: Leaving directory
make: *** [all] Error 2

... note the "sed -e 's/-O[2-9s]*/-O1/g'" in there.

(Thinking about it, is this reduction in optimisation necessary for any compiler
other than GCC?)


srcshelton set Version to 1.4.4.
srcshelton set External Link to
werner added a subscriber: werner.Feb 2 2009, 10:54 AM

I don't think that it is a regression in Libgcrypt because the problematic rule
was not changed. Did you change the CFLAGS passed to configure?

The rule worked for may years and I hesitate to change it to a more complicated
sed expression which might lead to problems with some older sed. A cleaner way
would be to add a configurer switch to chnage the CFLAGS mangling.

Hmm - I can't explain why this would have affected 1.4.4 but not 1.4.3, but that
is my experience.

Perhaps with not such a complex rule, then - but you must admit that the current
method of reducing the level of optimisation is overly broad, and therefore
prone to breakage?

If we work on the assumption that CFLAGS won't contain tabs and that the -O flag
isn't the last item, then I should think that this would suffice:

sed -re 's/-O[2-3s]? /-O1 /g'

werner added a comment.Feb 3 2009, 9:35 AM

Sure, you are right. OTOH this code is in use by gnupg and libgcrypt for many
years without problems (twofish.c used similar code).

BTW, according to POSIX -r is not a standard sed option.

Is it possible to match at most one occurrence of a pattern without the "-r"
option? ("extended regular expression", a GNU extension unfortunately)

It could, of course, be simplified to:

sed -e 's/-O[23s] /-O1 /g ; s/-O /-O1 /g'

... although in GCC at least it does appear that "-O" and "-O1" are synonymous.

Having said that, under the MIPSpro compilers on IRIX, "-O" is actually the same
as "-O2".

Okay, for the development version I implemented a configure option
This is in the SVN trunk, rev 1415.
I believe that is the least intrusive change. Is it important for you; thus
shall I backport it to 1.4.5 which will be released in a few days?

I close the bug;
feel free to open it again if you have problems with that option.

will be in 1.4.5 to be released in a few minutes.

werner closed this task as Resolved.Dec 11 2009, 5:03 PM
werner claimed this task.
werner removed a project: Testing.