mpiler group
so do not know and cannot comment on their plans.)
--
-Alan Coopersmith- alan.coopersmith at sun.com
Oracle Solaris Platform Engineering: X Window System
running OpenSolaris).
An updated version of the Studio compilers is being worked on for
the IPS repository, but I don't know when they'll publish it - maybe
the compiler team members on tools-compilers know or have a workaround?
--
-Alan Coopersmith- alan.coop
d the binaries produced by the gcc 4.x backend were usable though,
nor do I know of anyone making sure all the other consolidations were
buildable with gcc 4.x, though those based on external open source (SFW,
X, Desktop) are likely okay, at least in the components that are up to
date with
ms
that use the Fujitsu CPU's as well.
--
-Alan Coopersmith- alan.coopersmith at sun.com
Sun Microsystems, Inc. - X Window System Engineering
x27;s no problem at all for apps that only run
on Solaris 10 & OpenSolaris.
--
-Alan Coopersmith- alan.coopersmith at sun.com
Sun Microsystems, Inc. - X Window System Engineering
anted medialib bugs to appear there, you could
work with website-discuss to add them.
--
-Alan Coopersmith- alan.coopersmith at sun.com
Sun Microsystems, Inc. - X Window System Engineering
sed
depends on if you're using a pre-release or official release version.
(I just have both always set in my .cshrc & build scripts.)
--
-Alan Coopersmith- alan.coopersmith at sun.com
Sun Microsystems, Inc. - X Window System Engineering
This was reported via the OpenSolaris bugzilla, but seems to be
a Studio dbx bug:
<http://defect.opensolaris.org/bz/show_bug.cgi?id=12677>
--
-Alan Coopersmith- alan.coopersmith at sun.com
Sun Microsystems, Inc. - X Window System Engineering
stick to Standards ... not make it easy
> for them to write non-portable code.
Wouldn't it be more consistent to follow the libc model, where all the
functions, both standard and non-standard, are in the same .so, but the
function prototypes are visible or hidden based on the #defines set?
alog.
> Try relaxing the pattern, refreshing and/or examining the catalogs:
> SUNWgcc.p5i
Don't include the .p5i when specifying the package name on the command line,
you just want:
pfexec pkg install SUNWgcc
--
-Alan Coopersmith- alan.coopersmith at sun
cles/libumem_library.html
http://blogs.sun.com/ahl/entry/solaris_10_top_11_20
http://blogs.sun.com/quenelle/entry/using_dbx_and_libumem_to
--
-Alan Coopersmith- alan.coopersmith at sun.com
Sun Microsystems, Inc. - X Window System Engineering
l this release, which
> is why the value for __SUNPRO_C is different.
0x510 < 0x590 - you didn't really make the version number go backwards did you?
That will break existing code that checks for __SUNPRO_C >= 0x550
and such.
--
-Alan Coopersmith- alan.coopersmith at sun.com
Sun Microsystems, Inc. - X Window System Engineering
The best place on opensolaris.org to ask questions like this is the
tools-compilers mailing list/forum, since that's where the compiler
team members are found.
-Alan Coopersmith- alan.coopersmith at sun.com
Sun Microsystems, Inc. - X Window System Engineering
Vi
g to another hash method for identifying files.)
--
-Alan Coopersmith- alan.coopersmith at sun.com
Sun Microsystems, Inc. - X Window System Engineering
not have SSE support. So older
> MMX-only machines won't be able to run the code.
That's why the commit shown includes a mapfile that resets the hwcap flags
to just "FPU", since the library calls getisax() at runtime to determine
if it should call the MMX or SSE fastpath
Joerg Schilling wrote:
> Alan Coopersmith wrote:
>
>> While not a stopper, since we can easily fix every time we hit it, it would
>> be amazingly nice if Sun Studio learned how to ignore \r at the end of lines,
>> so that those of us working on cross-platform open so
checks in code with
Windows linebreaks. gcc seems to manage to ignore them properly. (Including
not treating it as the escaped character when a line ends in \\r\n and breaking
line continuations.)
--
-Alan Coopersmith- alan.coopersmith at sun.com
Sun Microsystems, Inc. - X Window System Engineering
, and that -xbuiltin=%all makes sense
mostly in the cases where you know the exact target platform, much like
-xtarget=native or -fast (which includes -xbuiltin=%all).
--
-Alan Coopersmith- alan.coopersmith at sun.com
Sun Microsystems, Inc. - X Window System Engineering
#if defined(__GNUC__) && (__GNUC__ >= 4)
# define EXTERN_TUNABLE __attribute__((visibility("hidden")))
#elif defined(__SUNPRO_C) && (__SUNPRO_C >= 0x550)
# define EXTERN_TUNABLE _hidden
#else
# define EXTERN_TUNABLE /* Do not make static */
#endif
--
-Al
few megs - reducing
Mesa's footprint by 29Mb met my goal of not being the cause of that in
future builds. It doesn't need to be the smallest possible - I'm not going
to strip symbol tables to make it smaller at the cost of debuggability for
instance - just smaller than it w
to today with -xspace,
and have a lot more pressing things to solve right now.
--
-Alan Coopersmith- alan.coopersmith at sun.com
Sun Microsystems, Inc. - X Window System Engineering
ns, as in:
http://cgit.freedesktop.org/xorg/lib/libpciaccess/tree/src/common_interface.c#n39
I believe the versions are somewhat optimized, due to
CR 6729208: Optimize BSWAP_* and BE_* macros in sys/byteorder.h to use inline
amd64 assembly
--
-Alan Coopersmith- alan.coopersmith at sun.com
Sun Microsystems, Inc. - X Window System Engineering
Fedor Sergeev wrote:
> On Mon, Nov 17, 2008 at 02:01:23PM -0800, Alan Coopersmith wrote:
>> No, -m64 indicates "compile in 64-bit mode", not "Use exactly the original v9
>> ISA with no later extensions."
>
> Oh, come on.
> -xarch=v9 means "compi
No, -m64 indicates "compile in 64-bit mode", not "Use exactly the original v9
ISA with no later extensions."
-Alan Coopersmith- alan.coopersmith at sun.com
Sun Microsystems, Inc. - X Window System Engineering
Fedor Sergeev wrote:
> On Mon, Nov
Is there any replacement for -xarch=v9 to indicate "Don't use any SPARC ISA
extensions so this runs on all sun4u/sun4v machines" that doesn't result in
Sun Studio issuing obnoxious "We obsoleted your flags" warnings for every
file compiled?
-Alan Coopersmith-
is Express they
are in /usr/bin.
--
-Alan Coopersmith- alan.coopersmith at sun.com
Sun Microsystems, Inc. - X Window System Engineering
a weak foo
>> #endif
>
> Just FYI.
> Our C compiler is able to comprehend weak attribute starting with Sun Studio
> 12.
So that should become:
#if defined(__ELF__) && ( (defined(__GNUC__) && (__GNUC__ >= 3)) ||
(defined(__SUNPRO_C) && (__SUNPRO_C >= 0x59
RO_C >= 0x550)
# define EXPORT __global
# define HIDDEN __hidden
# define INTERNAL __hidden
#else /* not gcc >= 4 and not Sun Studio >= 8 */
# define EXPORT
# define HIDDEN
# define INTERNAL
#endif /* GNUC >= 4 */
- Weak symbols:
#if defined(__ELF__) &&
for __STDC_VERSION__).
Do I just need to add something like:
#elif defined(__SUNPRO_C) && (__SUNPRO_C > 0x0550)
and if so is there any list of what versions support what features
without having to manually compare the last 10 versions worth of compiler
docs on docs.sun.com?
--
pilers and all
the relevant developer packages, such as most of the system headers.
--
-Alan Coopersmith- alan.coopersmith at sun.com
Sun Microsystems, Inc. - X Window System Engineering
alan pae wrote:
> Can't find Sun Studio or gcc.
>
> How did this happen?
Try "pkg install ss-dev" or "pkg install gcc-dev" - the package
gui doesn't categorize them properly so they don't show up under
development tools.
--
-Alan Cooper
sktop.org/xorg/xserver/log/hw/xfree86/xf1bpp/Makefile.am
)
--
-Alan Coopersmith- alan.coopersmith at sun.com
Sun Microsystems, Inc. - X Window System Engineering
submitted
somewhere on http://developer.sun.com/
-Alan Coopersmith- alan.coopersmith at sun.com
Sun Microsystems, Inc. - X Window System Engineering
Andy Armstrong wrote:
> (I hope this is the right place for the report - I couldn't find the
> compiler listed as a
y implement the common ones. I'm not sure we have time to do them
> all. :-(
> Is this one widely used?
I had to modify the X.Org builds a while ago to work around the lack of
-include, instead creating .c files in the builds that included the
necessary .h files.
--
-Alan Co
sted a
sponsor, and been ignored for months or longer (the first one on the list
from him is now over a year old).
Given our poor track record, it seems more likely we'll just migrate to
Studio 13 first, which will have -xstrconst on by default.
--
-Alan Coopersmith- alan.coo
en only if they're
functions exposed to other applications/modules/etc.
--
-Alan Coopersmith- alan.coopersmith at sun.com
Sun Microsystems, Inc. - X Window System Engineering
36 matches
Mail list logo
