How many of such platforms are available and known to work in the FSF
tree?
Strange question. The answer is all the platforms currently known to
work with Ada (too many to be listed here).
One alternative is to have an s-auxdec-empty and use that
on platforms where s-auxdec is known to pose
Romain Failliot writes:
2005/11/13, Florian Weimer [EMAIL PROTECTED]:
There is a GCC front end, but it has zero chance of being integrated
into FSF GCC at this stage. The run-time library license contains
this little gem:
* (ii) Any derived versions of this software
I've received several requests to remove the '-branch' suffix from the IA64
improvements branch.
Since the branch is brand new, this shouldn't affect too many folks, so I
renamed the branch to 'ia64-improvements' and updated the web page.
On Tuesday 15 November 2005 21:17, Branko Čibej wrote:
Now that GCC has switched to SVN, and tag and branch names are for all
practical purposes in different namespaces, you could drop the -branch
suffix from new branch names.
Sure. Done.
(You could also rename old branches, but then old
On Wed, 16 Nov 2005, Diego Novillo wrote:
On Tuesday 15 November 2005 21:17, Branko Äibej wrote:
Now that GCC has switched to SVN, and tag and branch names are for all
practical purposes in different namespaces, you could drop the -branch
suffix from new branch names.
Sure. Done.
On Wednesday 16 November 2005 08:35, Osku Salerma wrote:
Not sure what you mean by have the branches locally (SVK?), but a
plain rename of a branch doesn't force new check-outs, people can use
svn switch to point their working copies at the new branch name.
Same thing. It forces people to do
On Nov 16, 2005 02:35 PM, Osku Salerma [EMAIL PROTECTED] wrote:
Not sure what you mean by have the branches locally (SVK?), but a
plain rename of a branch doesn't force new check-outs, people can use
svn switch to point their working copies at the new branch name.
But some people have those
Date: Wed, 16 Nov 2005 03:20:54 -0500
From: Doug Graham [EMAIL PROTECTED]
To: Frank Ch. Eigler [EMAIL PROTECTED]
Subject: Question about mudflap
Hi,
Not sure whether I should report this as a bug or not, because there
might be something going on that I don't understand.
What I'm wondering is
Hi -
What I'm wondering is whether or not mudflap should instrument accesses
to globals that it doesn't know the size of. In the following code:
[...]
printf(%d\n, global[3]);
[...] Mudflap does not emit any __mf_check calls.
It is probably kicking in an optimization that says that if
On 11/16/05, Frank Ch. Eigler [EMAIL PROTECTED] wrote:
Hi -
What I'm wondering is whether or not mudflap should instrument accesses
to globals that it doesn't know the size of. In the following code:
[...]
printf(%d\n, global[3]);
[...] Mudflap does not emit any __mf_check calls.
Arnaud Charlet wrote:
How many of such platforms are available and known to work in the FSF
tree?
Strange question. The answer is all the platforms currently known to
work with Ada (too many to be listed here).
One alternative is to have an s-auxdec-empty and use that
on platforms where
On Wed, Nov 16, 2005 at 08:48:43AM -0500, Frank Ch. Eigler wrote:
Hi -
What I'm wondering is whether or not mudflap should instrument accesses
to globals that it doesn't know the size of. In the following code:
[...]
printf(%d\n, global[3]);
[...] Mudflap does not emit any
Balaji V. Iyer [EMAIL PROTECTED] writes:
I have a question about finding register names from the instruction.
I am porting GCC for a propriatery architecture and the thing is that,
I want to group instructions whose destination registers are between
0-15 into one cluster and 16-31 in
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
extraction and merging of elements from/to vectors.
Background:
Hi,
I'm using gcc-4.0.1 on both a UltraSparc3 and UltraSparc3cu systems. When
I compile code on the UltraSparc3 system using -mcpu=ultrasparc3 and run
the file command on the executable I get
hello: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+
Required, UltraSPARC1 Extensions
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Compiler version: 4.1.0 20051112 (experimental)
Platform: x86_64-unknown-linux-gnu
configure flags:
- --prefix=/SCRATCH/gcc-build/Linux/x86_64-unknown-linux-gnu/install
- --with-gnu-as
-
On 11/16/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hi,
I'm using gcc-4.0.1 on both a UltraSparc3 and UltraSparc3cu systems. When
I compile code on the UltraSparc3 system using -mcpu=ultrasparc3 and run
the file command on the executable I get
hello: ELF 32-bit MSB executable
Hi,
I'm using gcc-4.0.1 on both a UltraSparc3 and UltraSparc3cu systems.
When
I compile code on the UltraSparc3 system using -mcpu=ultrasparc3 and run
the file command on the executable I get
hello: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+
Required, UltraSPARC1
First, this question is more suited to gcc-help mailinglist. Second, the
switch you want to use is -march=ultrasparc3 which changes the used
instruction-set. -mcpu only tunes for ultrasparc3 without using
instructions that are not available for the default cpu used.
No, you're thinking in
I'm using gcc-4.0.1 on both a UltraSparc3 and UltraSparc3cu systems. When
I compile code on the UltraSparc3 system using -mcpu=ultrasparc3 and run
the file command on the executable I get
hello: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+
Required, UltraSPARC1 Extensions
A while back I asked whether gcc provided a cross-reference utility and the
answer was NO so I
prototyped my own cross-referencing program using gcc and tcl/tk. I'd like to
get some feedback--for
example, usability of the program relative to other cross-referencing
programs--so I have
On Tue, 2005-11-15 at 13:31 -0800, Joe Buck wrote:
On Tue, Nov 15, 2005 at 02:15:44PM -0700, Jeffrey A Law wrote:
So, is it just me or does execute/930529-1.c invoke undefined or
implementation defined behavior due to its reliance upon overflow
behavior for signed types?
In
On Tue, Nov 15, 2005 at 09:01:21PM +0100, Peter S. Mazinger wrote:
I meant exactly this, gcc supports -fno-stack-protector (although gcc
defaults to no-ssp), so -fno-stack-protector-all should be there too
Why? What option would it perform?
r~
On Wed, Nov 09, 2005 at 07:19:45PM +0100, mathieu lacage wrote:
Since the cvs version of gas supports extensions for the dwarf2
basic_block location information, I thought I could try to add support
to gcc for this feature.
I had been working on this, but got distracted. I hope to get
back
On Wed, 16 Nov 2005, Richard Henderson wrote:
On Tue, Nov 15, 2005 at 09:01:21PM +0100, Peter S. Mazinger wrote:
I meant exactly this, gcc supports -fno-stack-protector (although gcc
defaults to no-ssp), so -fno-stack-protector-all should be there too
Why? What option would it perform?
On Sat, Nov 12, 2005 at 09:57:10PM +0100, Gabriel Dos Reis wrote:
| http://gcc.gnu.org/ml/gcc-patches/2004-08/msg01463.html
That simply means GCC got it wrong.
The world is not all C++, Gaby.
r~
On Sun, Nov 13, 2005 at 02:26:31PM -0700, Jeffrey A Law wrote:
On Sun, 2005-11-13 at 22:20 +0100, Steven Bosscher wrote:
On Sunday 13 November 2005 22:02, Jeffrey A Law wrote:
No great insights on how to make dbr_schedule CFG aware -- just
remember that a filled delay slot can represent 3
Richard Henderson [EMAIL PROTECTED] writes:
| On Sat, Nov 12, 2005 at 09:57:10PM +0100, Gabriel Dos Reis wrote:
| | http://gcc.gnu.org/ml/gcc-patches/2004-08/msg01463.html
|
| That simply means GCC got it wrong.
|
| The world is not all C++, Gaby.
But that wasn't the point.
-- Gaby
On Wed, Nov 16, 2005 at 08:40:11PM +0100, Peter S. Mazinger wrote:
On Wed, 16 Nov 2005, Richard Henderson wrote:
On Tue, Nov 15, 2005 at 09:01:21PM +0100, Peter S. Mazinger wrote:
I meant exactly this, gcc supports -fno-stack-protector (although gcc
defaults to no-ssp), so
On Wed, Nov 16, 2005 at 09:15:33PM +0100, Gabriel Dos Reis wrote:
Richard Henderson [EMAIL PROTECTED] writes:
| On Sat, Nov 12, 2005 at 09:57:10PM +0100, Gabriel Dos Reis wrote:
| | http://gcc.gnu.org/ml/gcc-patches/2004-08/msg01463.html
|
| That simply means GCC got it wrong.
|
|
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:
$ ~/devel/gomp-branch/gcc grep ^DEFTREECODE *.def | wc
181 908
As of this morning, Ada no longer compiles for *-rtems.
I think this change broke it.
2005-11-14 Thomas Quinot [EMAIL PROTECTED]
* socket.c (__gnat_get_h_errno): New function to retrieve h_errno, the
hosts database last error code.
RTEMS has networking functions but they are not
On Wed, 16 Nov 2005, Richard Henderson wrote:
On Wed, Nov 16, 2005 at 08:40:11PM +0100, Peter S. Mazinger wrote:
On Wed, 16 Nov 2005, Richard Henderson wrote:
On Tue, Nov 15, 2005 at 09:01:21PM +0100, Peter S. Mazinger wrote:
I meant exactly this, gcc supports -fno-stack-protector
On Wed, Nov 16, 2005 at 10:02:23PM +0100, Peter S. Mazinger wrote:
On Wed, 16 Nov 2005, Richard Henderson wrote:
On Wed, Nov 16, 2005 at 08:40:11PM +0100, Peter S. Mazinger wrote:
On Wed, 16 Nov 2005, Richard Henderson wrote:
On Tue, Nov 15, 2005 at 09:01:21PM +0100, Peter S.
On Wed, 16 Nov 2005, Osku Salerma wrote:
Not sure what you mean by have the branches locally (SVK?), but a
plain rename of a branch doesn't force new check-outs, people can use
svn switch to point their working copies at the new branch name.
As far as I can experienced, svn switch does have a
Is this valid C or C++? I am getting a syntax error when
compiled as C++ but not C.
int f()
{
int x, y, ;
}
--
Joel Sherrill, Ph.D. Director of Research Development
[EMAIL PROTECTED] On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL
Is this valid C or C++? I am getting a syntax error when
compiled as C++ but not C.
int f()
{
int x, y, ;
}
I am getting a syntax error with the C front-end but not with the
C++ front-end. This is definitely a bug as this is invalid C++ also.
This is a regression from at least 3.4.0
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 it does
-fstack-protector #define __SSP__ 1 ; #undef __SSP_ALL__
-fstack-protector-all #define __SSP_ALL__ 2
Andrew Pinski wrote:
Is this valid C or C++? I am getting a syntax error when
compiled as C++ but not C.
int f()
{
int x, y, ;
}
I am getting a syntax error with the C front-end but not with the
C++ front-end. This is definitely a bug as this is invalid C++ also.
This is a regression from
On Sun, 2005-11-13 at 17:55 +0100, Laurent GUERBY wrote:
There are other PR filed for ACATS code but with other flags than -O2,
or on platforms with lots of failures (hppa, ia64).
After the latest commit, ia64-linux is now in the same shape Ada wise
than x86 x86_64:
x86 x86_64 ia64
22333:
On Wed, Nov 16, 2005 at 04:38:29PM -0500, Andrew Pinski wrote:
Is this valid C or C++? I am getting a syntax error when
compiled as C++ but not C.
int f()
{
int x, y, ;
}
I am getting a syntax error with the C front-end but not with the
C++ front-end. This is definitely
The GCC community has talked about link-time optimization for some time.
In addition to results with other compilers, Geoff Keating's work on
inter-module optimization has demonstrated the potential for improved
code-generation from applying optimizations across translation units.
Some of us (Dan
The GCC community has talked about link-time optimization for some time.
In addition to results with other compilers, Geoff Keating's work on
inter-module optimization has demonstrated the potential for improved
code-generation from applying optimizations across translation units.
Our
4. An entirely new basic block on its own.
When can option 4 happen??
IIRC it occurs when there was only 1 insn in either the target
or fall-thru block.When it gets sucked into the delay
slot of a branch, then it is effectively its own basic
block.
When the fall-through is ended
Some of us (Dan Berlin, David Edelsohn, Steve Ellcey, Shin-Ming Liu,
Tony Linthicum, Mike Meissner, Kenny Zadeck, and myself) have developed
a high-level proposal for doing link-time optimization in GCC. At this
point, this is just a design sketch. We look forward to jointly
developing this
On Wed, 2005-11-16 at 12:06 -0800, Richard Henderson wrote:
On Sun, Nov 13, 2005 at 02:26:31PM -0700, Jeffrey A Law wrote:
On Sun, 2005-11-13 at 22:20 +0100, Steven Bosscher wrote:
On Sunday 13 November 2005 22:02, Jeffrey A Law wrote:
No great insights on how to make dbr_schedule CFG
The GCC community has talked about link-time optimization for some time.
In addition to results with other compilers, Geoff Keating's work on
inter-module optimization has demonstrated the potential for improved
code-generation from applying optimizations across translation units.
I don't
The GCC community has talked about link-time optimization for some time.
In addition to results with other compilers, Geoff Keating's work on
inter-module optimization has demonstrated the potential for improved
code-generation from applying optimizations across translation units.
One thing
Mark Mitchell [EMAIL PROTECTED] wrote:
Thoughts?
Thanks for woking on this. Any specific reason why using the LLVM bytecode
wasn't taken into account? It is proven to be stable, high-level enough to
perform any kind of needed optimization, and already features interpreters,
JITters and
On Thu, 2005-11-17 at 01:26 +0100, Giovanni Bajo wrote:
Mark Mitchell [EMAIL PROTECTED] wrote:
Thoughts?
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,
On 11/16/05, Steven Bosscher [EMAIL PROTECTED] wrote:
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:
$
Hi Anton,
On Tue, 18 Oct 2005, Anton Titov wrote:
I've set up a new gcc mirror in Sofia, Bulgaria
ftp://mirrors.host.bg/gnu/ftp/gnu/gcc/
http://mirrors.host.bg/gnu/ftp/gnu/gcc/
as far as I can see this is a mirror of ftp.gnu.org, not gcc.gnu.org?
Note that on our mirror lists we only
Andrew == Andrew Pinski [EMAIL PROTECTED] writes:
Andrew One thing not mentioned here is how are you going to repesent
Andrew different eh personality functions between languages, because
Andrew currently we cannot even do different ones in the same
Andrew compiling at all.
I think that is
Daniel Berlin Wrote:
It [LLVM] is proven to be stable, high-level enough to
perform any kind of needed optimization,
This is not true, unfortunately. That's why it is called low
level virtual machine.
It doesn't have things we'd like to do high level optimizations
on, like
On Wed, Nov 16, 2005 at 02:26:28PM -0800, Mark Mitchell wrote:
http://gcc.gnu.org/projects/lto/lto.pdf
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
Richard Henderson wrote:
In general, I'm going to just collect comments in a folder for a while,
and then try to reply once the dust has settled a bit. I'm interested
in seeing where things go, and my primary interest is in getting *some*
consensus, independent of a particular one.
But, I'll
On Wed, Nov 16, 2005 at 05:27:58PM -0800, Mark Mitchell 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
were
Mark Mitchell [EMAIL PROTECTED] writes:
| The GCC community has talked about link-time optimization for some time.
| In addition to results with other compilers, Geoff Keating's work on
| inter-module optimization has demonstrated the potential for improved
| code-generation from applying
Some more comments (this time section by section and a little more thought out):
2.1:
Requirement 1: a good question is how does ICC or even XLC
do this without doing anything special? Or do they keep around
an on-the-side database.
(Requirements 2-4 assume Requirement 1)
Requirement 5: is
The document is on the web here:
http://gcc.gnu.org/projects/lto/lto.pdf
The LaTeX sources are in htdocs/projects/lto/*.tex.
Thoughts?
It may be worth mentioning that this type of optimization
applies mainly to one given type of output: a non-symbolic
a.out. When the output it a shared
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 might be true for other tools, too.
I can't offhand recall if
Mark Mitchell [EMAIL PROTECTED] writes:
http://gcc.gnu.org/projects/lto/lto.pdf
Section 2.2.1 (Variables and Functions) mentions C++ inline functions.
It should also mention gcc's C language extern inline functions.
The same section should consider common symbols. These appear as
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 it does
-fstack-protector #define __SSP__ 1 ; #undef
--- Comment #10 from steven at gcc dot gnu dot org 2005-11-16 08:52 ---
Re. comment #9
GCSE store motion is very broken, and it's really been like that for a long
time. And it doesn't really do much, either, when you turn it on. Sadly we
have nothing to replace it right now except
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2005-11-16 09:09
---
Patch submitted for review.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
To reproduce:
Compile the three files with:
f951 timeinterval.f90
f951 time.f90
f951 fold.f90
clockadvance
fold_convert.f90:13: internal compiler error: in fold_convert, at fold.c:2028
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html
--- Comment #1 from krebbel at gcc dot gnu dot org 2005-11-16 09:36 ---
Created an attachment (id=10246)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10246action=view)
testcase part 1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24887
--- Comment #2 from krebbel at gcc dot gnu dot org 2005-11-16 09:36 ---
Created an attachment (id=10247)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10247action=view)
testcase part 2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24887
--- Comment #3 from krebbel at gcc dot gnu dot org 2005-11-16 09:37 ---
Created an attachment (id=10248)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10248action=view)
testcase part 3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24887
--- Comment #16 from rguenth at gcc dot gnu dot org 2005-11-16 09:39
---
Is the second reduced testcase not fine from a standards POV? I.e.
void abort(void);
int main()
{
int a[10], *p, *q;
q = a[1];
p = q[-1];
if (p = a[9])
abort ();
return 0;
}
or does array in the
--- Comment #17 from paolo dot bonzini at lu dot unisi dot ch 2005-11-16
09:41 ---
Subject: Re: [4.1 Regression] f2c miscompilation
rguenth at gcc dot gnu dot org wrote:
--- Comment #16 from rguenth at gcc dot gnu dot org 2005-11-16 09:39
---
Is the second reduced testcase
--- Comment #33 from steven at gcc dot gnu dot org 2005-11-16 09:42 ---
Zdenek, any news about your patch from comment #30?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19923
--- Comment #4 from krebbel at gcc dot gnu dot org 2005-11-16 09:46 ---
My posting was a bit corrupted - sorry.
fold_convert.f90:13: internal compiler error: in fold_convert, at fold.c:2028
fold.f90:13: internal compiler error: in fold_convert, at fold-const.c:2028
Please submit a
For the testcase:
/home/razya/mainline_new_3/gcc/gcc/testsuite/gcc.c-torture/execute/2002-1.c,
when using fipa-cp, a new vfersion is created
for aim_callhandler(). the static variable is copied twice into the
unexpanded_var_list of the versioned function.
Looking at this test, even without
--- Comment #3 from tobi at gcc dot gnu dot org 2005-11-16 10:58 ---
Subject: Bug 24357
Author: tobi
Date: Wed Nov 16 10:58:41 2005
New Revision: 107078
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107078
Log:
PR 24357
* doc/invoke.texi: Distinguish between free
--- Comment #4 from tobi at gcc dot gnu dot org 2005-11-16 11:00 ---
Fixed on the trunk, 4.0 is still waiting for approval.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from amodra at bigpond dot net dot au 2005-11-16 11:03
---
The testcase in comment #2 is invalid. You can't trash part of a function
pointer (the toc pointer) and expect everything to be rosy. However, the
testcase in comment #1 does indeed show the problem you
--- Comment #2 from guerby at gcc dot gnu dot org 2005-11-16 11:17 ---
Subject: Bug 24855
Author: guerby
Date: Wed Nov 16 11:17:47 2005
New Revision: 107079
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107079
Log:
2005-11-16 Joel Sherrill [EMAIL PROTECTED]
PR
--- Comment #4 from amodra at bigpond dot net dot au 2005-11-16 11:29
---
The problem here is late forcing of fp constants to memory. The first
scheduling pass has merrily moved an insn loading a fp constant in amongst the
function pointer load sequence, after r2 has been loaded.
--
Summary: ICE
Product: gcc
Version: 3.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
--- Comment #1 from igodard at pacbell dot net 2005-11-16 11:36 ---
Created an attachment (id=10249)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10249action=view)
compiler output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24889
--- Comment #2 from igodard at pacbell dot net 2005-11-16 11:37 ---
Created an attachment (id=10250)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10250action=view)
source code (compressed)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24889
--- Comment #3 from amodra at bigpond dot net dot au 2005-11-16 11:42
---
I analysed one of these failures quite a while ago. The conclusion I came to
was that the errors were due to excess precision. gcc-4.1 makes more use of
multiply-accumulate instructions. You could try
--- Comment #3 from rguenth at gcc dot gnu dot org 2005-11-16 11:43 ---
This is fixed in 3.4.5. And btw, your code is invalid:
/home/ivan/ootbc/common/include/bitPointer.hh: In member function
bitPointerT, bitWidth, ordering bitPointerT, bitWidth,
ordering::operator=(const
--- Comment #4 from amodra at bigpond dot net dot au 2005-11-16 11:44
---
Marking as invalid given my previous analysis, and that the errors are all
1ulp.
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-11-16 11:46 ---
try dumping with -fdump-tree-*-uid, they are probably different copies. You
can
try http://gcc.gnu.org/ml/gcc-patches/2005-08/msg00314.html to avoid having
unused versions dumped.
--
--- Comment #5 from rakdver at gcc dot gnu dot org 2005-11-16 12:13 ---
A patch is here (only the ivopts and get_tmr_operands parts). I am retesting
it now.
http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01608.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24793
--- Comment #6 from christian dot joensson at gmail dot com 2005-11-16
12:18 ---
I may be getting this still for sparc/sparc64 linux, see, e.g., for 4.0
http://gcc.gnu.org/ml/gcc-testresults/2005-11/msg00778.html and for 4.2
http://gcc.gnu.org/ml/gcc-testresults/2005-11/msg00759.html
--- Comment #7 from christian dot joensson at gmail dot com 2005-11-16
12:21 ---
(In reply to comment #6)
http://gcc.gnu.org/ml/gcc-testresults/2005-11/msg00778.html and for 4.2
http://gcc.gnu.org/ml/gcc-testresults/2005-11/msg00759.html
sorry, that should have been 4.1 and not
--- Comment #2 from razya at il dot ibm dot com 2005-11-16 12:45 ---
(In reply to comment #1)
try dumping with -fdump-tree-*-uid, they are probably different copies. You
can
try http://gcc.gnu.org/ml/gcc-patches/2005-08/msg00314.html to avoid having
unused versions dumped.
It
--- Comment #16 from reichelt at gcc dot gnu dot org 2005-11-16 13:03
---
Subject: Bug 23797
Author: reichelt
Date: Wed Nov 16 13:03:13 2005
New Revision: 107081
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107081
Log:
Backport from mainline:
2005-10-12 Nathan
--- Comment #17 from reichelt at gcc dot gnu dot org 2005-11-16 13:05
---
Now also fixed on the 3.4 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from fxcoudert at gcc dot gnu dot org 2005-11-16 13:19
---
(In reply to comment #19)
There are only two choices: either __imag__ is an lvalue, and the code in
Comment #1 is valid, or __imag__ is not an lvalue, and the compiler should
issue an error.
For the
--- Comment #22 from pinskia at gcc dot gnu dot org 2005-11-16 13:36
---
(In reply to comment #21)
For the libgfortran issue (libgfortran uses __imag__ as a lvalue) what should
be done? Who can decide whether __imag__ is or isn't a lvalue? Sorry to ask
for
the obvious, but I'm
--
giovannibajo at libero dot it changed:
What|Removed |Added
Summary|Python miscompilation - TOC |[4.0 Regression] Python
|reload
--- Comment #12 from steven at gcc dot gnu dot org 2005-11-16 14:12 ---
Is this bug going anywhere???
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23109
--- Comment #3 from danglin at gcc dot gnu dot org 2005-11-16 14:16 ---
Affects hpux as well as linux.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
GCC
--- Comment #13 from rguenth at gcc dot gnu dot org 2005-11-16 14:16
---
Nobody reviewed the patch AFAIK. Still the patch hasn't caused any problems
sofar in the SUSE compiler.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #23 from schwab at suse dot de 2005-11-16 14:20 ---
(In reply to comment #22)
Note I never said __imag__ a should not act like an lvalue. I just said that
__imag__ a = b; acts like a = COMPLEXREALa, b which is just like what
a = (a0x)|(b0x) does.
IMHO it
Please consider the following program.
int i;
int i;
int main() {
return 1;
}
Compiler does not reports redecleration error for i.
--
Summary: Problem with unintitalized global variables.
Product: gcc
Version: 3.3.2
Status: UNCONFIRMED
1 - 100 of 227 matches
Mail list logo
