RTEMS has networking functions but they are not available at this stage
during the build. You only have the .h files provided with newlib. So
this patch is needed to make *-rtems compile again. OK to commit?
Please post the corresponding ChangeLog so that this patch can be reviewed
and
Daniel Berlin [EMAIL PROTECTED] wrote:
Thanks for woking on this. Any specific reason why using the LLVM
bytecode wasn't taken into account?
It was.
A large number of alternatives were explored, including CIL, the JVM,
LLVM, etc.
It is proven to be stable, high-level enough to
perform
Hello everybody
As you may already know the code that supports cirrus arm processors
with maverick crunch floating point unit (-mfpu=maverick), which
is included in gcc 4.x, is nearly complete but, as of now, broken.
So I'm going to spend some time in fixing it, but I'm pretty new
in gcc
On Thu, 2005-11-17 at 10:23, Dario Massarin wrote:
I would like to start with this bug report:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24861
Could you give me some hints on where is the problem?
It just happens that I fixed that last night :-)
R.
On Thu, 2005-11-17 at 10:23, Dario Massarin wrote:
I would like to start with this bug report:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24861
Could you give me some hints on where is the problem?
It just happens that I fixed that last night :-)
Wow! Really? So fast? Thanks!
On Thu, 2005-11-17 at 01:27, Mark Mitchell wrote:
Richard Henderson wrote:
In Requirement 4, you say that the function F from input files a.o and
b.o should still be named F in the output file. Why is this requirement
more than simply having the debug information reflect that both names
Hello,
I am working on a private GCC port. Currently I am trying to move it
from 3.3.2
to 4.1.x. I have some strange constructs in the expansion of the va_arg
macro.
In 3.3.2 I used two unspec RTL constructs to solve that problem. Now
va_arg
has to be transformed to GIMPLE. So my question: is
On Nov 17, 2005 01:11 PM, Unruh, Erwin
[EMAIL PROTECTED] wrote:
is there some
equivalent.
No, there isn't. You are not being very specific about the problem you
are trying to solve. You'll have to tell more before anyone can give
you a more helpful answer.
Gr.
Steven
On Thursday 17 November 2005 07:11, Unruh, Erwin wrote:
Now va_arg has to be transformed to GIMPLE. So my question: is there
some equivalent.
There isn't one. Have you looked at gimplify_va_arg_expr? What is it in
your construct that cannot be expressed in trees? There are several
targets
On Thu, 17 Nov 2005, Peter S. Mazinger wrote:
On Wed, 16 Nov 2005, Richard Henderson wrote:
On Wed, Nov 16, 2005 at 10:32:45PM +0100, Peter S. Mazinger wrote:
what happens w/ -fstack-protector-all -fstack-protector (in this order) ?
do we have (2) or (1)
We have 1.
so now
Ian Lance Taylor wrote:
In section 3.4 (Linker) I have the same comment: for non-GNU targets,
the native linker is sometimes required, so modifying the linker
should not be a requirement. And the exact handling of .a files is
surprisingly target dependent, so while it would be easy to code
OK, here are the details:
first, I have a PDImode pointer and do not want to have general arithmetic on
that. So I invented a special RTL instruction to align a pointer. Within the
va_arg sometimes I need to align the pointer. In 3.3.2 the code snippet in
EXPAND_BUILTIN_VA_ARG looked like
On Wed, 2005-11-16 at 20:33 -0700, Jeffrey A Law wrote:
Our understanding was that the debugger actually uses the symbol table,
in addition to the debugging information, in some cases. (This must be
true when not running with -g, but I thought it was true in other cases
as well.) It
Doing an overnight build of all rtems targets, I can across this
new breakage for m68k-rtems4.7. I last built this target on Nov 3
from the head and it compiled then.
/home/joel/gcc-work/head/b-m68k-rtems4.7/./gcc/xgcc
-B/home/joel/gcc-work/head/b-m68k-rtems4.7/./gcc/ -nostdinc
hi,
Daniel Berlin wrote:
I discovered this when deep hacking into the symbol code of GDB a while
ago. Apparently, some people enjoy breakpointing symbols by using the
fully mangled name, which appears (nowadays) mainly in the minsym table.
This sort of hack is often used to work around
../../../gcc-head-test/libiberty/regex.c: In function
'byte_common_op_match_null_string_p':
../../../gcc-head-test/libiberty/regex.c:7724: error: insn does not
satisfy its constraints:
(insn 158 85 159 8
../../../gcc-head-test/libiberty/regex.c:7699 (set
From: Paul Brook [EMAIL PROTECTED]
Date: Thu, 17 Nov 2005 15:12:50 +
../../../gcc-head-test/libiberty/regex.c:7699 (set (reg:SI 2 %d2)
(sign_extend:SI (reg:HI 1 %d1 [59]))) 65 {*68k_extendhisi2} (nil)
(nil))
On Thursday 17 November 2005 15:20, Hans-Peter Nilsson wrote:
From: Paul Brook [EMAIL PROTECTED]
Date: Thu, 17 Nov 2005 15:12:50 +
../../../gcc-head-test/libiberty/regex.c:7699 (set (reg:SI 2 %d2)
(sign_extend:SI (reg:HI 1 %d1 [59]))) 65 {*68k_extendhisi2}
(nil) (nil))
hello, I have a problem when I try to instantiate static members. this code
works with gcc-3.4.5 but not with gcc-4.0.2 (debian sid).
here a test case with 3 files :
/ main.cpp
#include iostream
#include Test.h
int main(int argc, char **argv)
{
std::cout TestInt::member
Steven Bosscher [EMAIL PROTECTED] wrote on 11/16/2005 10:39:24 PM:
On Wednesday 16 November 2005 15:35, Dorit Naishlos wrote:
We'd like to suggest a few new tree-codes/optabs in order to express
the
extraction and merging of elements from/to vectors.
Watch out for tree code starvation:
Paul Brook [EMAIL PROTECTED] wrote on 11/16/2005 05:03:47 PM:
On Wednesday 16 November 2005 14:35, Dorit Naishlos wrote:
We're going to commit to autovect-branch vectorization support for
non-unit-stride accesses.
We'd like to suggest a few new tree-codes/optabs in order to express
the
On Wed, Nov 16, 2005 at 02:26:28PM -0800, Mark Mitchell wrote:
http://gcc.gnu.org/projects/lto/lto.pdf
Section 4.2
What is the rationale for using a stack-based representation rather
than a register-based representation? A infinite register based
solution would seem to map
On Thursday 17 November 2005 16:51, Dorit Naishlos wrote:
only thing I can suggest in the context of the vectorizer is to use an
extra argument to save a few tree-codes:
I don't think that this is a good idea. If we are going to need
more tree codes, we're just going to have to figure out a
Mark Mitchell [EMAIL PROTECTED] writes:
http://gcc.gnu.org/projects/lto/lto.pdf
Section 4.2 (Executable Representation) describes the GVM as a stack
machine, and mentions load, store, duplicate, and swap operations.
But it also discusses having registers which correspond to GIMPLE
local
Thanks for woking on this. Any specific reason why using the LLVM
bytecode wasn't taken into account?
It was.
A large number of alternatives were explored, including CIL, the JVM,
LLVM, etc.
It is proven to be stable, high-level enough to
perform any kind of needed optimization,
On Wed, Nov 16, 2005 at 02:26:28PM -0800, Mark Mitchell wrote:
http://gcc.gnu.org/projects/lto/lto.pdf
Section 4.2
What is the rationale for using a stack-based representation rather
than a register-based representation? A infinite register based
solution would seem to
It must be the season for this sort of thing :-)
I have been contemplating building a GCC register allocator from scratch
for some time. To that end, I have put together a bit of a document
given a high level overview of the various components I think would
benefit GCC, and a rough description
Ok. I've just checked the gcc-4_0-branch but trying to compile with
--with-cpu=ep9312 and --with-fpu=maverick still fails (but this is a different
problem).
I've reported this bug here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24914
On Thu, Nov 17, 2005 at 08:17:07AM +0100, Peter S. Mazinger wrote:
-fstack-protector-all (all protection) being superset of -fstack-protector
(random protection) it should also define __SSP__ 1
The IBM patch that I followed did exactly what I implemented.
I see no compelling reason to change
On Thu, Nov 17, 2005 at 01:11:08PM +0100, Unruh, Erwin wrote:
So my question: is there some equivalent.
A builtin function.
r~
cedric wrote:
hello, I have a problem when I try to instantiate static members. this code
works with gcc-3.4.5 but not with gcc-4.0.2 (debian sid).
here a test case with 3 files :
/ main.cpp
#include iostream
#include Test.h
int main(int argc, char **argv)
{
std::cout
Hi folks.
In this PR we are emitting a value computed is not used warning for the
following code (via some fancy macro expansion in the Linux kernel):
unsigned long t(void);
void apic_write_atomic(unsigned long reg, unsigned int v)
{
((__typeof__(*((volatile
Hi all,
on PowerPC G4 with MacOS-X 10.3.9 (powerpc-apple-darwin7.9.0 )
build from :
Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
Thread model: posix
gcc version 3.3 20040913 (GNAT for Mac OS X build 1650)
with Apple's cctools 525
New 4.0.2 gcc -v output :
Using built-in specs.
Richard Earnshaw [EMAIL PROTECTED] writes:
We spend a lot of time printing out the results of compilation as
assembly language, only to have to parse it all again in the assembler.
Given some of the problems this proposal throws up I think we should
seriously look at bypassing as much of
Ulrich Weigand [EMAIL PROTECTED] writes:
Conversely, I don't know much we are going to care about speed here,
but I assume that we are going to care a bit. For the linker to
determine which files to pull in from an archive, it is going to have
to read the symbol tables of all the input
Aldy Hernandez [EMAIL PROTECTED] writes:
this reduces to:
int f(void);
void g(void)
{ (unsigned) f(); }
Which was made to deliberately warn by Joseph's patch here:
http://gcc.gnu.org/ml/gcc-patches/2005-08/msg00275.html
I closed the bug as a WONTFIX, but Ian
On a similar note than PR debug/21391...
In PR23336 we have the same thing happen with enums:
enum something { JTI_PROMOTED_BYTE_TYPE_NODE, etc };
use JTI_PROMOTED_BYTE_TYPE_NODE
JTI_PROMOTED_BYTE_TYPE_NODE and something get pruned even though we
use it. I see two
* Joel Sherrill [EMAIL PROTECTED], 2005-11-16 :
RTEMS has networking functions but they are not available at this stage
during the build.
I am not sure I understand how this can happen (I am not familiar at all
with the RTEMS build process). If the network functions are available on
RTEMS,
Thomas Quinot wrote:
* Joel Sherrill [EMAIL PROTECTED], 2005-11-16 :
RTEMS has networking functions but they are not available at this stage
during the build.
I am not sure I understand how this can happen (I am not familiar at all
with the RTEMS build process). If the network functions
Snapshot gcc-4.0-20051117 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20051117/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.0 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Thu, Nov 17, 2005 at 02:01:56PM -0800, Ian Lance Taylor wrote:
We traditionally do not warn about not using the value returned by a
function. And I don't see why adding a cast should change that.
Intuitively, a cast by itself is not a computation.
In many cases is certainly is -- it's a
On Thu, Nov 17, 2005 at 02:54:48PM -0800, Richard Henderson wrote:
On Thu, Nov 17, 2005 at 02:01:56PM -0800, Ian Lance Taylor wrote:
We traditionally do not warn about not using the value returned by a
function. And I don't see why adding a cast should change that.
Intuitively, a cast by
Is there some reason gcc hasn't been or can't be enhanced to provide output for
a cross-referencing
programs?
Paul Albrecht
On Thu, Nov 17, 2005 at 06:08:35PM -0400, Aldy Hernandez wrote:
On a similar note than PR debug/21391...
In PR23336 we have the same thing happen with enums:
enum something { JTI_PROMOTED_BYTE_TYPE_NODE, etc };
use JTI_PROMOTED_BYTE_TYPE_NODE
JTI_PROMOTED_BYTE_TYPE_NODE
Ian Lance Taylor wrote:
We spend a lot of time printing out the results of compilation as
assembly language, only to have to parse it all again in the assembler.
I never like arguments which have loaded words like lot without
quantification. Just how long *is* spent in this step, is it
Richard Henderson [EMAIL PROTECTED] writes:
On Thu, Nov 17, 2005 at 02:01:56PM -0800, Ian Lance Taylor wrote:
We traditionally do not warn about not using the value returned by a
function. And I don't see why adding a cast should change that.
Intuitively, a cast by itself is not a
On Thu, Nov 17, 2005 at 03:00:42PM -0800, Joe Buck wrote:
As in the example, these cases will usually arise in macros, where under
some circumstances some computation will be wasted.
Which is no different from f()+1, for which no one is arguing
that the warning we give is incorrect. If you've
Paul Albrecht wrote:
Is there some reason gcc hasn't been or can't be enhanced to provide output for
a cross-referencing
programs?
Paul Albrecht
No reason why it can't be, and the reason it hasn't is that
no one has done it. Actually strictly you don't mean gcc
here, you are referring to
On Thu, Nov 17, 2005 at 03:18:00PM -0800, Ian Lance Taylor wrote:
I don't think you should get a warning for not using the return value of a
function, at least not under -Wunused.
For this, I agree. Except that we're not talking about the
return value of the function directly, we're talking
Robert Dewar [EMAIL PROTECTED] writes:
Ian Lance Taylor wrote:
We spend a lot of time printing out the results of compilation as
assembly language, only to have to parse it all again in the
assembler.
I never like arguments which have loaded words like lot without
quantification. Just
Hi all,
on PowerPC G4 with MacOS-X 10.3.9 (powerpc-apple-darwin7.9.0 )
build from :
Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
Thread model: posix
gcc version 3.3 20040913 (GNAT for Mac OS X build 1650)
with gcc cctools 576
same test with gcc cctools 590.12
$
On Thursday 17 November 2005 16:55, Steven Bosscher wrote:
On Thursday 17 November 2005 16:51, Dorit Naishlos wrote:
only thing I can suggest in the context of the vectorizer is to use an
extra argument to save a few tree-codes:
I don't think that this is a good idea. If we are going to
From: Robert Dewar [EMAIL PROTECTED]
Paul Albrecht wrote:
Is there some reason gcc hasn't been or can't be enhanced to provide output
for a
cross-referencing programs?
No reason why it can't be, and the reason it hasn't is that no one has done
it. Actually strictly
you don't mean
Paul Albrecht wrote:
Is there some reason gcc hasn't been or can't be enhanced to provide output for
a cross-referencing
programs?
FYI, there are a number of tools available for producing
cross-referencing info. See for instance
http://www.gnu.org/software/global/links.html
and try
A stronger case for changing this would be that gcc version
n-1 didn't warn. As discussed elsewhere, some modicum of
stability in warnings is desirable from the user's perspective.
I don't know whether or not this applies in this case.
Well, as I mentioned in the PR, macro writers can wrap
From: Jim Wilson [EMAIL PROTECTED]
Paul Albrecht wrote:
Is there some reason gcc hasn't been or can't be enhanced to provide output
for
cross-referencing programs?
FYI, there are a number of tools available for producing
cross-referencing info. See for instance
On Thu, Nov 17, 2005 at 08:42:19PM -0400, Aldy Hernandez wrote:
Well, as I mentioned in the PR, macro writers can wrap the whole thing
in a statement expression and avoid the warning. Can't we suggest this
and keep (almost) everybody happy?
I think so.
r~
On Fri, Nov 18, 2005 at 01:19:14AM +0100, Steven Bosscher wrote:
BTW the gomp-branch adds 22 (!) new tree codes, just like that,
for all languages. This is IMHO very unfair to other projects
in need of extra tree codes.
Yeah, well, I don't see any way around it. We'll have to
solve the bit
Rafael Ávila de Espíndola wrote:
Thank you very much for showing that the problem was in the comment.
I've checked in a patch to fix the comment typo.
--
Jim Wilson, GNU Tools Support, http://www.specifix.com
Gabriel Dos Reis wrote:
This is the fifth or so message from me, within the last few days,
that gets rejected. What is up?
Hmm, I don't see this in the overseers archive. I don't think it
reached them. Maybe it triggered the spam filter for having too many
capital letters in the subject
On Thu, Nov 17, 2005 at 03:42:29PM -0800, Ian Lance Taylor wrote:
I just tried a simple unoptimized compile. -ftime-report said that
final took 5% of the time (obviously final does more than formatting),
and the assembler took 4% of the total user time, and system time took
16% of wall clock
On Nov 17, 2005, at 3:09 PM, Robert Dewar wrote:
Richard Earnshaw wrote:
We spend a lot of time printing out the results of compilation as
assembly language, only to have to parse it all again in the
assembler.
I never like arguments which have loaded words like lot without
quantification.
Jim Wilson wrote:
Gabriel Dos Reis wrote:
This is the fifth or so message from me, within the last few days,
that gets rejected. What is up?
Hmm, I don't see this in the overseers archive.
Because it is sourceware.org not sourceware.com. I should have noticed
that before I made the same
Andrew MacLeod wrote:
It must be the season for this sort of thing :-)
I have not yet read the entire document, but I would very much like to
applaud both the goal of improving register allocation, and the spirit
in which you've approached it: in particular, posting a design and
getting comments
On Nov 17, 2005, at 21:33, Dale Johannesen wrote:
When I arrived at Apple around 5 years ago, I was told of some recent
measurements that showed the assembler took around 5% of the time.
Don't know if that's still accurate. Of course the speed of the
assembler
is also relevant, and our stubs
On Thu, Nov 17, 2005 at 11:53:31AM -0500, Andrew MacLeod wrote:
The document is intended as a starting point and consists mostly of my
thoughts at the moment. By the time the underlying RTL bits are done, I
would like it to have evolved to include input from others. The more
useful comments
Richard Henderson wrote:
On Thu, Nov 17, 2005 at 08:42:19PM -0400, Aldy Hernandez wrote:
Well, as I mentioned in the PR, macro writers can wrap the whole thing
in a statement expression and avoid the warning. Can't we suggest this
and keep (almost) everybody happy?
I think so.
FWIW, I
Richard Henderson wrote:
A solution that comes to mind is to have the front-end add dummy
TYPE_DECL nodes to the BLOCK_VARS list of the function's outer-most
BLOCK. If the TYPE_DECL node were marked DECL_ARTIFICIAL and had
no DECL_NAME, it'd be easy for us to notice that we shouldn't
--- Comment #2 from jb at gcc dot gnu dot org 2005-11-17 08:26 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01271.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24909
--- Comment #3 from reichelt at gcc dot gnu dot org 2005-11-17 09:40
---
The compiler already crashes with g++ -O -finline-functions -g,
i.e. without explicitly specifying -fno-unit-at-a-time.
--
reichelt at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from jb at gcc dot gnu dot org 2005-11-17 10:00 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01277.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24862
--- Comment #5 from reichelt at gcc dot gnu dot org 2005-11-17 10:02
---
Here's a shorter testcase without templates:
==
void foo()
{
#pragma omp parallel
{
int i, N;
#pragma omp for schedule (dynamic)
for (i=0; iN; ++i) ;
--- Comment #3 from saurabh dot verma at codito dot com 2005-11-17 10:05
---
Adding myself to CC list, as the offending patch was given by me
--
saurabh dot verma at codito dot com changed:
What|Removed |Added
--- Comment #1 from reichelt at gcc dot gnu dot org 2005-11-17 10:39
---
Confirmed.
The following code snippet causes an ICE since 2.95.3
with the exception of 4.0.0 - 4.0.2:
==
templateint struct A
{
static int i;
A() { ++i; }
};
templateint
--- Comment #6 from reichelt at gcc dot gnu dot org 2005-11-17 11:08
---
The following testcase crashes since GCC 2.95.3 except 3.1 and 3.2:
===
templatetypename T struct A
{
A() : T(0) {}
};
Aint* a;
===
The error message
--- Comment #2 from guerby at gcc dot gnu dot org 2005-11-17 11:13 ---
Subject: Bug 24857
Author: guerby
Date: Thu Nov 17 11:13:18 2005
New Revision: 107116
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107116
Log:
2005-11-17 Laurent GUERBY [EMAIL PROTECTED]
PR
--- Comment #14 from reichelt at gcc dot gnu dot org 2005-11-17 11:24
---
This is not really a regression, since evn with 2.95.3 we get an ICE
(with --enable-checking):
bug.cc: In function `int main()':
bug.cc:4: converting to `void' from `int'
bug.cc:4: void value not ignored as it
--- Comment #18 from rguenth at gcc dot gnu dot org 2005-11-17 11:35
---
Subject: Bug 24851
Author: rguenth
Date: Thu Nov 17 11:35:00 2005
New Revision: 107117
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107117
Log:
2005-11-16 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #19 from rguenth at gcc dot gnu dot org 2005-11-17 11:36
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2005-11-17 11:42 ---
So I guess being able to hunt it confirms it.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rguenth at gcc dot gnu dot org 2005-11-17 11:47 ---
Btw., this also happens on armv4l compiling NX:
gcc -c -O3 -fsigned-char -I. -I../../exports/include/freetype2
-I../../extras/freetype2/src-I../../extras/freetype2/src/base
--- Comment #7 from reichelt at gcc dot gnu dot org 2005-11-17 11:59
---
Here's a sightly simpler testcase.
If I remove the copy-ctor from A, I get the failure from PR24606.
=
templatetypename F void foo(F f)
{
f();
}
struct A
{
A();
--- Comment #2 from reichelt at gcc dot gnu dot org 2005-11-17 12:04
---
I think this is a duplicate of PR 24602.
The only difference is the missing copy-ctor here.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rakdver at gcc dot gnu dot org 2005-11-17 12:33 ---
Patch:
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01283.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #22 from thebohemian at gmx dot net 2005-11-17 12:39 ---
Created an attachment (id=10262)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10262action=view)
lazy linking - part 2
This is the same patch as above but corrects the behavior in case that the
static field of a
--- Comment #4 from uweigand at gcc dot gnu dot org 2005-11-17 12:45
---
It looks like the simplify-rtx patch is not really the cause of the problem,
it simply exposes a pre-existing bug in combine and/or flow.
Before combine, we have a situation that looks like (simplified):
insn
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2005-11-17 12:47
---
Subject: Bug 24892
Author: fxcoudert
Date: Thu Nov 17 12:46:57 2005
New Revision: 107119
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107119
Log:
PR fortran/24892
* io/io.h (unit_access):
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2005-11-17 12:51
---
Subject: Bug 20811
Author: fxcoudert
Date: Thu Nov 17 12:51:41 2005
New Revision: 107120
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107120
Log:
PR fortran/20811
* scanner.c
--- Comment #34 from rakdver at gcc dot gnu dot org 2005-11-17 13:35
---
It behaves somewhat erratically on SPEC2000 (it increases the overall score,
but there are some significant regressions). And, it also causes us to produce
worse code for this testcase at the moment, due to a
--- Comment #23 from aph at gcc dot gnu dot org 2005-11-17 13:46 ---
mm, I was wrong about static fields.
The problem is that a JV_CONSTANT_Fieldref constant pool entry points to a
JV_CONSTANT_Class, and at the present time we attempt to resolve that
JV_CONSTANT_Class reference at link
--- Comment #8 from pcarlini at suse dot de 2005-11-17 13:50 ---
I have got additional evidence that __sync_fetch_and_add does not work
correctly. If, for example, in this code, stressed in the testcase
12658_thread-1.cc, and using atomic operations:
const locale
--- Comment #8 from mark at gcc dot gnu dot org 2005-11-17 14:03 ---
Subject: Bug 23183
Author: mark
Date: Thu Nov 17 14:03:22 2005
New Revision: 107121
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107121
Log:
2005-11-17 Mark Wielaard [EMAIL PROTECTED]
*
--- Comment #3 from andreast at gcc dot gnu dot org 2005-11-17 14:37
---
Unfortunately it does not werk :(
I found this message in the libtool archive:
http://lists.gnu.org/archive/html/libtool-patches/2004-08/msg2.html
Currently we have this 'whole_archive_flag_spec='-all_load
--- Comment #35 from rakdver at gcc dot gnu dot org 2005-11-17 15:09
---
Created an attachment (id=10263)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10263action=view)
Patch
After some playing with fold, I arrived to the following patch, that almost
works. With the patch, the
--- Comment #2 from charlet at gcc dot gnu dot org 2005-11-17 15:15 ---
Works fine on mainline as of today.
Arno
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2005-11-17 15:16 ---
Not a frontend bug. P3.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from charlet at gcc dot gnu dot org 2005-11-17 15:17 ---
Closing.
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2005-11-17 15:17 ---
Not a fortran frontend bug, but IVOPTs one. P3.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from dje at watson dot ibm dot com 2005-11-17 15:17 ---
Subject: Re: [4.0 Regression] Python miscompilation - TOC reload
Reliably is the wrong word. The patch will fix the problem reliably for
the default case; it will not fix it for a particular set of options.
The
--- Comment #1 from charlet at gcc dot gnu dot org 2005-11-17 15:23 ---
The minimum requirement is not out of date.
There has indeed always been a different requirement for cross compilers
where you need to first have a native compiler using the exact same
version, and that should
1 - 100 of 205 matches
Mail list logo
