Discussion:
regex.c value out of range on Solaris compiler
Gavin Smith
2017-04-14 21:27:45 UTC
Permalink
Hello,

When I try to compile a program using the 'regex' module on Solaris 10,
I get the output

/opt/solarisstudio12.3/bin/c99 -Xc -D_XPG6 -DHAVE_CONFIG_H -I. -I../..
-D_REENTRANT -I/opt/csw/include -c -o regex.o regex.c
"regex_internal.h", line 105: warning: macro redefined: gettext
"regex_internal.h", line 734: warning: token-less macro argument
Assembler: "/tmp/yabeAAAiUaidC", line 19010 : Value out of range
"/tmp/yabeAAAiUaidC", line 19031 : Value out of range
Failure in /opt/solarisstudio12.3/prod/bin/fbe, status = 0x7f00
Fatal Error exec'ing /opt/solarisstudio12.3/prod/bin/fbe
c99: acomp failed for regex.c

The warnings about macros are harmless, but the "Value out of range"
errors are fatal.

I re-ran with the -S option to get assembler output:

/opt/solarisstudio12.3/bin/c99 -Xc -D_XPG6 -DHAVE_CONFIG_H -I. -I../..
-D_REENTRANT -I/opt/csw/include -c -o regex.o regex.c -S

Then if I try to compile the regex.o file:

mv regex.o regex.S
/opt/solarisstudio12.3/bin/c99 -Xc -D_XPG6 -DHAVE_CONFIG_H -I. -I../.. -D_REENTRANT -I/opt/csw/include -c -o regex.o regex.S
Assembler: "regex.S", line 21273 : Value out of range
"regex.S", line 21294 : Value out of range
c99: fbe failed for regex.S

Line 21273 is
subl $4294967296,%eax

Line 21294 is
subl $4294967296,%eax

I think the error is that these constants are too large. 4,294,967,296
is 2 ** 32 which is too big a value to fit in 32 bits.

When I try again with the Gnulib from 2016-12-15, this file compiles OK,
but when I apply the patch from

http://lists.gnu.org/archive/html/emacs-devel/2016-12/msg00666.html

the problem occurs. I believe that the faulty code is coming from the
use of INT_ADD_WRAPV from intprops.h. I haven't investigated how exactly
this macro leads to the faulty code. Hopefully I am on the right track
here and someone will have an idea of how to fix it. If not, I will have
to study what this macro does and why it is being used here.

Thanks,
Gavin

PS please keep me CC'd in any responses
Gavin Smith
2017-04-14 22:08:19 UTC
Permalink
Post by Gavin Smith
Line 21273 is
subl $4294967296,%eax
Line 21294 is
subl $4294967296,%eax
the problem occurs. I believe that the faulty code is coming from the
use of INT_ADD_WRAPV from intprops.h. I haven't investigated how exactly
this macro leads to the faulty code.
The macro expands to a lot of code, but I simplified the code that gives
the same error:

$ cat tmp.c
int main (void)
{
int length1 = 0, length2 = 0;

if ( ( int ) ( ( ( unsigned int ) ( length1 ) + ( unsigned int ) ( length2 ) ) - ( ( - 2147483647 - 1 ) ) ) + ( ( - 2147483647 - 1 ) ) )
1;
}

$ /opt/solarisstudio12.3/bin/c99 -Xc -D_XPG6 -DHAVE_CONFIG_H -I. -I../.. -D_REENTRANT tmp.c
Assembler: "/tmp/yabeAAAUsaiac", line 23 : Value out of range
Failure in /opt/solarisstudio12.3/prod/bin/fbe, status = 0x7f00
Fatal Error exec'ing /opt/solarisstudio12.3/prod/bin/fbe
c99: acomp failed for tmp.c

The same
subl $4294967296,%eax
line occurs in the assembly output.

Can this be fixed in intprops.h?
Paul Eggert
2017-04-15 02:00:06 UTC
Permalink
Thanks for reporting the problem.
Post by Gavin Smith
/opt/solarisstudio12.3/bin/c99 -Xc -D_XPG6 -DHAVE_CONFIG_H -I. -I../..
-D_REENTRANT -I/opt/csw/include -c -o regex.o regex.c
"regex_internal.h", line 105: warning: macro redefined: gettext
That's odd. Where was the gettext macro originally defined?
Post by Gavin Smith
"regex_internal.h", line 734: warning: token-less macro argument
This warns about the use of a C99-ism in code that is protected by "#if
199901L <= __STDC_VERSION__", so it must be a false alarm, and you're
right tno not worry about it.
Post by Gavin Smith
Assembler: "/tmp/yabeAAAiUaidC", line 19010 : Value out of range
"/tmp/yabeAAAiUaidC", line 19031 : Value out of range
Ouch. This appears to be a compiler bug, as a compiler should never
generate invalid assembly-language code. I cannot reproduce the problem
on Solaris 10 sparc (32-bit) with Oracle Developer Studio 12.5. You are
on Solaris 10 x86 (32-bit) and are using 12.3. Do you observe the same
compiler bug with 12.5 or 12.6 beta? If so, I suggest reporting it as a
bug to Oracle.

What happens if you compile with -xO2?

Although I cannot reproduce the problem in my environment, I think I see
why it's happening. I installed the attached patches into Gnulib; do
they fix your problem?
Gavin Smith
2017-04-15 09:10:58 UTC
Permalink
Post by Paul Eggert
Post by Gavin Smith
/opt/solarisstudio12.3/bin/c99 -Xc -D_XPG6 -DHAVE_CONFIG_H -I. -I../..
-D_REENTRANT -I/opt/csw/include -c -o regex.o regex.c
"regex_internal.h", line 105: warning: macro redefined: gettext
That's odd. Where was the gettext macro originally defined?
/opt/csw/include/libintl.h, line 132: #define gettext libintl_gettext

(I got this using the -xdumpmacros=defs,loc option.)
Post by Paul Eggert
Post by Gavin Smith
Assembler: "/tmp/yabeAAAiUaidC", line 19010 : Value out of range
"/tmp/yabeAAAiUaidC", line 19031 : Value out of range
Ouch. This appears to be a compiler bug, as a compiler should never generate
invalid assembly-language code. I cannot reproduce the problem on Solaris 10
sparc (32-bit) with Oracle Developer Studio 12.5. You are on Solaris 10 x86
(32-bit) and are using 12.3. Do you observe the same compiler bug with
12.5 or 12.6 beta? If so, I suggest reporting it as a bug to Oracle.
I only have access to 12.4 on the system I am using, but that appears to
compile the test file I posted without error. Solaris Studio 12.2 gives
the same error as 12.3.
Post by Paul Eggert
What happens if you compile with -xO2?
The errors from the assembler do not occur and the compilation finishes
successfully.
Post by Paul Eggert
Although I cannot reproduce the problem in my environment, I think I see why
it's happening. I installed the attached patches into Gnulib; do they fix
your problem?
Yes, the error goes away with the change you made. It's good that you
managed to fix this.
Paul Eggert
2017-04-15 21:40:49 UTC
Permalink
Post by Gavin Smith
Post by Paul Eggert
Post by Gavin Smith
/opt/solarisstudio12.3/bin/c99 -Xc -D_XPG6 -DHAVE_CONFIG_H -I. -I../..
-D_REENTRANT -I/opt/csw/include -c -o regex.o regex.c
"regex_internal.h", line 105: warning: macro redefined: gettext
That's odd. Where was the gettext macro originally defined?
/opt/csw/include/libintl.h, line 132: #define gettext libintl_gettext
Sorry, I don't understand how this could be. regex_internal.h's "#define
gettext(msgid) msgid" line is in the else-part of the #if that #includes
libintl.h in its then-part, so how can libintl.h's #define for gettext be active
when regex_internal's #define is processed?
Post by Gavin Smith
I only have access to 12.4 on the system I am using, but that appears to
compile the test file I posted without error. Solaris Studio 12.2 gives
the same error as 12.3.
Thanks, I installed the attached (comment-only) patches to try to explain this
better. The first just fixes a typo. The 2nd has a messed-up commit message that
I didn't discover until after pushing - oh well, the ChangeLog file is right.
Gavin Smith
2017-04-16 08:15:06 UTC
Permalink
Post by Paul Eggert
Sorry, I don't understand how this could be. regex_internal.h's "#define
gettext(msgid) msgid" line is in the else-part of the #if that #includes
libintl.h in its then-part, so how can libintl.h's #define for gettext be
active when regex_internal's #define is processed?
libintl.h is being included via a system header, /usr/include/locale.h.
The system header is included from gnulib's locale.h. locale.h is
included at the beginning of regex_internal.h. locale.h is generated
from locale.in.h. There's a chance there is something wrong with the
way I am compiling because headers under /opt/csw/include are being
checked as well as /usr/share/include. The log at

https://buildfarm.opencsw.org/buildbot/builders/texinfo-solaris10-i386/builds/1263/steps/shell_2/logs/stdio

doesn't have the same warning, and that is more likely to have been done
with a correct environment for compiling. The other logs at
https://buildfarm.opencsw.org/buildbot/waterfall?category=texinfo
don't have the warning either, so it is probably okay.
Paul Eggert
2017-04-16 19:44:58 UTC
Permalink
Thanks for the explanation; I installed the attached further patch.
Loading...