On 26/10/2007, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> On Fri, 26 Oct 2007, Shawn Walker wrote:
>
> > I've been trying to figure out how to activate the gnu_compat flag
> > that ube apparently supports via cc -Wu,<option here>.
>
> ube is the name of the x86/x64 code generator of sun's compilers.
> And the option you mention is about assembly level compatibility.
Then the correct option would be appreciated, I had to guess since
they're not documented in any way.
> > I suspect that this should fix the problems I'm having compiling code
> > that uses a few common gcc extensions such as range of values
> > initialisation syntax for arrays like:
> >
> > array[ 0 ... 0x80 ] = value;
>
> For such functionality you would need the C, C++ frontends options
> if the functionality is supported by the forntends.
>
> But, what functionality exactly you are talking about?
>
> $cat r.c
> int array[ 0 ... 0x80 ] = 0;
>
> $/gcc r.c
> r.c:1: error: expected ']' before '...' token
>
> $gcc --version
> gcc (GCC) 4.2.0 Copyright (C) 2007 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> So could you please be a little bit more specific about what feature you
> are talking about.
Sorry; I'm talking about this code from regcomp.c that is part of GNU sed:
#ifdef RE_ENABLE_I18N
/* This static array is used for the map to single-byte characters when
UTF-8 is used. Otherwise we would allocate memory just to initialize
it the same all the time. UTF-8 is the preferred encoding so this is
a worthwhile optimization. */
static const bitset_t utf8_sb_map =
{
/* Set the first 128 bits. */
[0 ... 0x80 / BITSET_WORD_BITS - 1] = BITSET_WORD_MAX
};
#endif
> > *rant follows, read only if you work for Sun*
> >
> > Which brings me to a side question of *why the bleepity bleep* would
> > you ship functionality and then not document it at all?
>
> If we document something we intend to support it.
>
> If we dont't support a functionality (say it is only half ready or
> buggy) we don't want to document it.
>
> Unfortunately saying "we don't support so and so hidden option" doesn't help
> at all.
> Anything published brings up questions.
The problem is you have published it; you shipped the functionality
but failed to explain it. So people get hints of it if they dig
enough, but it's just beyond their reach for use.
Why ship functionality you don't plan on actually being able to be
used by the people you distributed it to?
> You starting this thread and me answering is a perfect example, right? :-)
>
> > It isn't very fair to folks that use Sun Studio to be tormented and
> > teased with compiler options that would solve our immediate problems
> > while internal Sun folks are freely available to use them.
>
> The way to publish unsupported options is currently under discussion.
> For now check out
> http://www.genunix.org/wiki/index.php/OpenSolaris_Wizard_Options
That helps some.
--
Shawn Walker, Software and Systems Analyst
[EMAIL PROTECTED] - http://binarycrusader.blogspot.com/
"Beware of bugs in the above code; I have only proved it correct, not
tried it. " --Donald Knuth
_______________________________________________
tools-discuss mailing list
[email protected]
