Hi! I posted this on gcc-help and got no responses, so I'm trying this
list. :)
I downloaded gcc-4.1.0 the other day and the compile went fine. When I
ran "make check" to make sure all went well, I get this error:
Fixed: types/vxTypesBase.h
Fixed: unistd.h
Fixed: wchar.h
Fixed: widec.h
Newly f
Florian Weimer wrote:
* Ben Chelf:
Right now, we're guarding access to the actual defects that we
report for a couple of reasons: (1) We think that you, as developers
of gcc, should have the chance to look at the defects we find to patch
them before random other folks get to see what we fou
On Mar 7, 2006, at 6:12 PM, FX Coudert wrote:
The only sure-fire fix I can think of is to actually build
two static versions of libgfortran -- one threaded and one
not threaded. I'm not sure this is worth the effort, really.
I'd be more inclined to put a couple of checks in such that
the stati
On Wed, Mar 08, 2006 at 12:12:24AM +0100, FX Coudert wrote:
> Hum, there are some platforms where libgfortran (and other target
> libraries) cannot be built as shared libraries. i386-mingw32 is an
> example of that. We've been careful until now to keep static
> libgfortran working even as a stat
The only sure-fire fix I can think of is to actually build
two static versions of libgfortran -- one threaded and one
not threaded. I'm not sure this is worth the effort, really.
I'd be more inclined to put a couple of checks in such that
the static libgfortran only runs non-threaded, and force
p
> From: Richard Henderson <[EMAIL PROTECTED]>
> On Mon, Mar 06, 2006 at 11:32:01AM -0800, Steve Ellcey wrote:
> > | ld: (Warning) Symbol "__udivsi3" is not exported but is imported by a
> > shared library
> > | ld: (Warning) Symbol "__divsi3" is not exported but is imported by a
> > shared libra
Snapshot gcc-3.4-20060307 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20060307/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 3.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Florian,
> * H. J. Lu:
>
> > Here are diffs of SPEC CPU 2K between before and after with gcc 4.1
> > using "-O2 -ffast-math" on Nocona:
>
> And what about Opterons? IOW, how "generic" is the optimization?
The generic code generation should cost a small compromise in performance
relative to
* Ben Chelf:
> Right now, we're guarding access to the actual defects that we
> report for a couple of reasons: (1) We think that you, as developers
> of gcc, should have the chance to look at the defects we find to patch
> them before random other folks get to see what we found and (2) From a
>
On Mon, Mar 06, 2006 at 11:32:01AM -0800, Steve Ellcey wrote:
> | ld: (Warning) Symbol "__udivsi3" is not exported but is imported by a
> shared library
> | ld: (Warning) Symbol "__divsi3" is not exported but is imported by a shared
> library
> | 2 warnings.
Are these being referenced from libgo
On Tue, Mar 07, 2006 at 12:34:05PM -0500, Diego Novillo wrote:
> #0 0x in ?? ()
> #1 0x0804d112 in find_unit_1 (n=6, do_create=1)
The problem here is a combination of factors: static linking
and weak symbol references via gthr.h.
The direct cause is that pthread_mutex_trylock isn't pull
Hi everyone,
I have come across a problem with my port of gcc regarding the way that
shorten_branches interacts with delay slot scheduling.
My port's target processor has two types of conditional branches: long
and short branches. Short branches have a delay slot, and long branches
don't. Th
On Mar 7, 2006, at 12:28 AM, Yang Yang wrote:
Recently, I'm very interested in the inlining model of gcc.I need a
detailed documentation describing how the inlining is implemented in
gcc 4.0. Anybody who has been or is working on it please send me a
documentation. I'd really appreciate your hel
The original SPEC named it x86-64. Since configure treats a "-" as a
separation character, we could not have uname return x86-64 and
therefore used "x86_64". Later AMD renamed "x86-64" to "AMD64"
So, the correct historical usage is "x86-64" but uname/configure use
"x86_64",
Andreas
--
Andrea
When -mtune=generic was added, it was expected that it would go into the
4.2 GCC release, since it clearly missed the 4.1 window for new
features. As desirable for both AMD and Intel that the new behavior be
propagated, I feel like Mark that it should wait for GCC 4.2, since it
clearly is a new fe
On Tue, Mar 07, 2006 at 12:34:05PM -0500, Diego Novillo wrote:
> Richard mentioned similar problems with broken libc versions that
> wouldn't initialize TLS properly, but this particular one doesn't seem
> related. Richard, any ideas?
Huh. No, this one doesn't look like the failure I had before.
On 02/28/06 18:42, FX Coudert wrote:
> Jakuk, Diego? Is this a bug or a feature? :)
>
Looks like a bug, but I'm not really sure what is causing it. I can
reproduce it with one of the tests in libgomp
(libgomp.fortran/appendix-a/a.16.1.f90), but I get a different trace:
-
Joe Buck writes:
> On Tue, Mar 07, 2006 at 10:26:24AM +, Andrew Haley wrote:
> > Our config tools return "x86_64" as an arch. Like this:
>
> They cannot return "x86-64", because that would break target triplets
> (which use "-" as a separator). So while x86-64 is the correct name,
> it
Hi,
On Tue, 7 Mar 2006, Andrew Haley wrote:
> Our config tools return "x86_64" as an arch. Like this:
The canonical name is "x86_64" with underscore ...
> [EMAIL PROTECTED] ~]$ gcc -S add-entropy.c -march=x86_64
> add-entropy.c:1: error: bad value (x86_64) for -march= switch
> [EMAIL PROTECTED
On Tue, Mar 07, 2006 at 10:26:24AM +, Andrew Haley wrote:
> Our config tools return "x86_64" as an arch. Like this:
They cannot return "x86-64", because that would break target triplets
(which use "-" as a separator). So while x86-64 is the correct name,
it cannot be used in contexts where "
My patch to allow defining constraints in the machine description rather
than with tm.h macros has been on mainline for a week now with no serious
problems reported. Now would be a good time to start converting ports.
Conversions are easy, but are best done by port maintainers, as
careful testing
On 07 March 2006 15:38, Neeta Kale wrote:
> I am running a program which is compiled using GCC
> 2.95.3. When I run the program, I get the following
> error :
> Segmentation Fault (core dumped)
Your program is almost certainly buggy. Please send general how-to-program
questions to the gcc-help
On Tue, 2006-03-07 at 08:00 -0500, Richard Kenner wrote:
> if (INTEGRAL_TYPE_P (etype) && TREE_TYPE (etype))
> {
> etype = TREE_TYPE (etype);
> exp = fold_convert (etype, exp);
> low = fold_convert (etype, low);
> value = fold_convert (etype, value);
>
I am running a program which is compiled using GCC
2.95.3. When I run the program, I get the following
error :
Segmentation Fault (core dumped)
When i use the gdb debugger to find the issue, it
gives the following information :
(gdb) break main
Breakpoint 1 at 0x7aad4: file Test.cpp, line 7.
(gdb
if (INTEGRAL_TYPE_P (etype) && TREE_TYPE (etype))
{
etype = TREE_TYPE (etype);
exp = fold_convert (etype, exp);
low = fold_convert (etype, low);
value = fold_convert (etype, value);
}
I gather that we should restrict the transformat
> This sounds like fold is merging the two comparisons above incorrectly into
> the one upper comparison.
Right.
> It can do the merge, but it needs to convert to base types first.
The type at stake is a ENUMERAL_TYPE and those have no base type
constant invariant visited 8>
unit size
On Mon, 2006-03-06 at 11:39 -0700, Jeffrey A Law wrote:
> if Side = Right or else Side = Both then
> while High >= Low and then Source (High) = Wide_Space loop
> High := High - 1;
> end loop;
> end if;
>
>
> side is an enumerated type with the following v
Andrew Haley writes:
>
> So, which is it supposed to be? In general we use "x86_64"
> everywhere, but gcc seems to have decided to use "x86-64". Perhaps we
> should accept "x86_64" as well?
Another example:
[EMAIL PROTECTED] ~]$ arch
x86_64
Confused.
On 07 March 2006 08:27, Yang Yang wrote:
> 1.For the same bunch of optimization options, does it matter if I
> change the order of them? Will that cause a different behavior of
> GCC?
Only if there are any that conflict, in which case the last one on the
command line wins.
> 2.Recently I'
Our config tools return "x86_64" as an arch. Like this:
[EMAIL PROTECTED] ~]$ gcc/trunk/config.guess
x86_64-unknown-linux-gnu
But try it with gcc, and
[EMAIL PROTECTED] ~]$ gcc -S add-entropy.c -march=x86_64
add-entropy.c:1: error: bad value (x86_64) for -march= switch
add-entropy.c:1: error:
Hi,
I'm adding some assembly floating point functions to bfin port. These
functions are much faster than those in fp-bit.c. However, they relax
some IEEE floating point standard rules for checking inputs against
NaN. So I think we'd better to call them only when -ffast-math or
-ffinite-math-only i
Recently, I'm very interested in the inlining model of gcc.I need a
detailed documentation describing how the inlining is implemented in
gcc 4.0. Anybody who has been or is working on it please send me a
documentation. I'd really appreciate your help.
1.For the same bunch of optimization options, does it matter if I
change the order of them? Will that cause a different behavior of
GCC?
2.Recently I've seen a spec2000 config file, where there is one
optimization option written twice in the OPTIMIZE part(thay are not in
a row).Why is it writt
33 matches
Mail list logo
