Hi,
On Sat, 8 Dec 2007, J.C. Pizarro wrote:
On 2007/12/07, Linus Torvalds [EMAIL PROTECTED] wrote:
SHA1 is almost totally insignificant on x86. It hardly shows up. But
we have a good optimized version there.
If SHA1 is slow then why dont he contribute adding Haval160 (3 rounds)
that
Hi,
I am trying to enable delayed branch scheduling on our port of Gcc for
picochip (16-bit VLIW DSP). I understand that delayed-branch is run as a
seperate pass after the DFA scheduling is done. We basically depend on
the TImode set on the cycle-start instructions to decide what
instructions
J.C. Pizarro wrote:
In GPLed GCC-4.1 branch appears a notice of BSD license
gcc/config/i386/gmon-sol2.c
* Copyright (c) 1991 The Regents of the University of California.
* All rights reserved.
No doubt. And in the mean time I'm listening to:
Title: Bach: Prelude and Fugue in C, BWV 531
On Sat, 8 Dec 2007, J.C. Pizarro wrote:
1. Don't compress this repo but compact this uncompressed repo
using minimal spanning forest and deltas
2. After, compress this whole repo with LZMA (e.g. 48MiB) from 7zip
before
burning it to DVD for backup reasons or before
On Sat, Dec 08, 2007 at 12:31:43PM +0100, J.C. Pizarro wrote:
In GPLed GCC-4.1 branch appears a notice of BSD license
gcc/config/i386/gmon-sol2.c
* Copyright (c) 1991 The Regents of the University of California.
* All rights reserved.
And why are you sending this to both gcc and gcc-help?
On Dec 8, 2007 8:53 PM, Joe Buck [EMAIL PROTECTED] wrote:
Mr. Pizarro has endless ideas, and he'll give you some new ones every day.
That's true.
He thinks that no one else knows any computer science, and he will attempt
to teach you what he knows,
It's not the only one ;-) is in good and
Has anyone faced a similar problem before? Are there targets for which
both VLIW and DBR are enabled? Perhaps ia64?
I did something similar a few months ago.
The problem is that haifa and the delayed branch scheduling passes don't
really fit together. delayed branch scheduling happily undoes
Having observed the bug while building a native, SJLJ version of
libgnat on x86_64, I have filed PR ada/34400 for this.
--
Ludovic Brenta.
Where did have you read this ? I missed that part.
When you object
that he's wasting your time, he'll start talking about freedom of speech.
Actually he never spoke like that (probably I missed that part too).
Read gcc mailing list archives, if you have a lot of time on your hands.
Hi Alexander,
We would like to ask people interested in SMS performance on PowerPC and
Cell SPU to conduct tests with this patch. Any feedback is greatly
appreciated.
I intend to perform testing with this patch (on ppc and SPU), after
resolving the miscompilation issues mentioned above.
--- Comment #4 from baldrick at gcc dot gnu dot org 2007-12-08 09:53
---
This is fixed on trunk.
--
baldrick at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from baldrick at gcc dot gnu dot org 2007-12-08 09:42
---
I don't see any valgrind messages or other failure using svn head,
when compiling at -O0 or -O2.
--
baldrick at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-08 09:25 ---
This is a bug in objdump.
We have the source information, I think it just does not take into account
DW_AT_comp_dir:
DW_AT_name: t12/t.c
DW_AT_comp_dir: /home/peshtigo/pinskia
Report
gcc -g -c ./src/hello.c -o ./obj/hello.o
cd obj
objdump -S hello.o
No source debugging information can be seen in hello.o
hello.o: file format elf32-i386
Disassembly of section .text:
main:
0: 55 push %ebp
1: 89 e5 mov%esp,%ebp
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-12-08 13:12 ---
From looking at code elsewhere the usual pattern is to do the renaming.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from mueller at gcc dot gnu dot org 2007-12-08 12:55 ---
this seems to be readding the warning with relatively low false positive rate
(e.g. didn't find a false one yet).
--- cp/typeck.c (revision 130658)
+++ cp/typeck.c (working copy)
@@ -5269,11 +5268,16 @@
The vectorizer currently ICEs for ppc64 and vect-27.c (and other testcases)
beacuse at the point it generates pointers for the vector accesses from the
static variable it does not set up pointer alias information correctly:
bb 6:
ib.20_12 = (__vector signed int *) ib;
vect_pib.19_11 = ib.20_12 +
This assumes that the patch http://gcc.gnu.org/ml/fortran/2007-12/msg00075.html
has been applied. It fixes most PR 34342, PR 34345, PR 18026 and PR 29471.
Missing:
-std=f2003 does not detect most invalid BOZ, only (i) BOZ for non-integers in
DATA statements and (ii) in assignments () are
--- Comment #2 from burnus at gcc dot gnu dot org 2007-12-08 15:52 ---
FIXED on the trunk (4.3.0).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-12-08 14:52 ---
Subject: Bug 34391
Author: rguenth
Date: Sat Dec 8 14:51:59 2007
New Revision: 130707
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130707
Log:
2007-12-08 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-12-08 14:52 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-12-08 15:45
---
Not standard and probably requires quite some work to get it working; closing
as WONTFIX, as per http://gcc.gnu.org/ml/fortran/2007-10/msg00263.html. If
someone comes up with a patch, it'll be of course be
--- Comment #1 from burnus at gcc dot gnu dot org 2007-12-08 15:52 ---
Subject: Bug 34319
Author: burnus
Date: Sat Dec 8 15:51:52 2007
New Revision: 130708
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130708
Log:
2007-12-08 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2007-12-08 17:16
---
Brooks, are you still working this one?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610
--- Comment #9 from charlet at adacore dot com 2007-12-08 17:22 ---
Subject: Re: Bug box, Program_Error at sinput.adb:404, derived fixed-point
type
good catch, I forgot to send the message to gcc-patches with the content and
the ack indication. The patch was acked by Robert by mail
--- Comment #10 from charlet at gcc dot gnu dot org 2007-12-08 17:52
---
removing myself from cc: since I'm subscribed to gcc-bugs
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-12-08 18:30
---
Thomas, is this patch the final on this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32972
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu
|org
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu
|org
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu
|org
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu
|org
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu
|org
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu
|org
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-12-08 18:59
---
On x86-64 (gfc = gfortran)
$ gfc -m32 demo1.f
$ time ./a.out
result = -0.69068092664140723
real0m0.552s
user0m0.551s
sys 0m0.001s
$ gfc -m64 demo1.f
$ time ./a.out
result =
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-12-08 19:04
---
Note in comment #5 the g77 wrong result when using -m32. Not a good thing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34128
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-08 19:59 ---
Yes it is done in the 48bit type:
D.2022 = this-a;
D.2023 = D.2022 16;
D.2024 = D.2023 16;
D.2021 = (long long int) D.2024;
But the good question why does it work at -O0. We have the same IR for both
-O0
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-12-08 20:07 ---
unnamed-unsigned:24 D.2020;
bb 2:
sv.f1 = 0;
sv.f2 = 16777215;
fn (16777215, 16777215);
D.2020 = sv.f2 + 1;
sv.f2 = D.2020;
fn ((int) D.2020, 0);
So this is a middle-end issue of not doing an AND
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-12-08 20:11 ---
Fixed so closing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-08 20:23 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from tkoenig at gcc dot gnu dot org 2007-12-08 20:26 ---
(In reply to comment #6)
Thomas, is this patch the final on this?
Hi Jerry,
we could make specific versions of all those intrinsic that
currently use memcpy(), including pack.
Should we leave this bug open for
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-12-08 20:29 ---
Actually this is the anonymous namespace issue which means this is a duplicate
of PR 10591 which was fixed for 4.2.0.
*** This bug has been marked as a duplicate of 10591 ***
--
pinskia at gcc dot gnu dot org
--- Comment #28 from pinskia at gcc dot gnu dot org 2007-12-08 20:29
---
*** Bug 34309 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
On powerpc Darwin9, gcc.c-torture/compile/20071117-1.c gives an ICE:
/opt/gcc/_gcc-clean/gcc/testsuite/gcc.c-torture/compile/20071117-1.c: In
function 'foo':
/opt/gcc/_gcc-clean/gcc/testsuite/gcc.c-torture/compile/20071117-1.c:13: error:
unrecognizable insn:
(insn 29 28 30 3
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-08 20:32 ---
Just a quick note, I think @ should be treated the same as L (and the
u/U ones) is with respect of string concatenation.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34033
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-08 20:35 ---
(mem/c:SI (mem/f/c/i:SI
that is just wrong.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34393
The C++ frontend issues a broken diagnostic for the following invalid
testcase since GCC 3.1:
==
extern double fabs(double);
void foo(double x)
{
fabs(x)();
}
==
bug.cc: In function 'void foo(double)':
bug.cc:5: error: '#'abs_expr' not
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-12-08 20:38 ---
This is fixed on the trunk already.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-08 20:39 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
The C++ frontend issues a broken diagnostic for the following invalid
testcase on mainline:
===
templateint... N void foo(int... x[N])
{
struct A
{
A() { x; }
};
}
===
bug.cc: In constructor 'foo(int
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34395
--- Comment #8 from dominiq at lps dot ens dot fr 2007-12-08 20:43 ---
Now works as advertized without regression on i686-apple-darwin9.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31487
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-08 20:44 ---
Confirmed.
Full error messages in C++98 mode:
t.cc:1: error: ISO C++ does not include variadic templates
t.cc:1: error: ISO C++ does not include variadic templates
t.cc: In constructor 'foo(int [N]...)::A::A()':
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-12-08 20:47 ---
(In reply to comment #1)
And the same with __typeof__ instead of __decltype. Since 3.4.
Why is this considered an regression?
Well 3.3 rejected the incomplete __typeof__ so this is a regression for that.
--- Comment #2 from reichelt at gcc dot gnu dot org 2007-12-08 20:50
---
Trivially modified versions of the testcase - using T or T() instead of T* -
still fail:
templatetypename... struct A;
templatetypename...T struct AT
{
void
--- Comment #3 from jakub at gcc dot gnu dot org 2007-12-08 21:00 ---
Subject: Bug 34359
Author: jakub
Date: Sat Dec 8 21:00:06 2007
New Revision: 130712
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130712
Log:
PR fortran/34359
* gfortran.h (gfc_file): Remove
The following code
program array_char
implicit none
integer :: i
character (len=5) :: x, y
character (len=5) :: z(2)
x = a
y = cd
z =
z = (/y(1:len(trim(y))), x(1:len(trim(x)))/)
print *, |, z(1), | |, z(2), |
print '(99i4)', ichar ( [ (z(1)(i:i), i=1,5) ] )
print '(99i4)', ichar ( [
--- Comment #4 from jakub at gcc dot gnu dot org 2007-12-08 21:02 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #7 from dominiq at lps dot ens dot fr 2007-12-08 20:45 ---
Now works as advertized without regression on i686-apple-darwin9.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32129
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34394
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-12-08 21:30
---
(In reply to comment #7)
we could make specific versions of all those intrinsic that
currently use memcpy(), including pack.
Thomas, your patch for this bug produces warnings when building libgfortran
(see the
--- Comment #7 from burnus at gcc dot gnu dot org 2007-12-08 21:47 ---
Subject: Bug 34345
Author: burnus
Date: Sat Dec 8 21:46:56 2007
New Revision: 130713
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130713
Log:
2007-12-08 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #3 from burnus at gcc dot gnu dot org 2007-12-08 21:47 ---
Subject: Bug 34342
Author: burnus
Date: Sat Dec 8 21:46:56 2007
New Revision: 130713
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130713
Log:
2007-12-08 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #10 from burnus at gcc dot gnu dot org 2007-12-08 21:47 ---
Subject: Bug 29471
Author: burnus
Date: Sat Dec 8 21:46:56 2007
New Revision: 130713
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130713
Log:
2007-12-08 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #16 from burnus at gcc dot gnu dot org 2007-12-08 21:47 ---
Subject: Bug 18026
Author: burnus
Date: Sat Dec 8 21:46:56 2007
New Revision: 130713
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130713
Log:
2007-12-08 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #2 from jakub at gcc dot gnu dot org 2007-12-08 21:53 ---
Related to PR33984, most probably caused by the same patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33819
--- Comment #4 from burnus at gcc dot gnu dot org 2007-12-08 21:56 ---
Mark as FIXED on the trunk (4.3.0).
Most parts are fixed; missing is:
-std=f2003 does not diagnose invalid use of BOZ, see PR 34392.
--
burnus at gcc dot gnu dot org changed:
What|Removed
--- Comment #9 from jvdelisle at verizon dot net 2007-12-08 21:57 ---
Subject: Re: performance of pack/unpack
tkoenig at gcc dot gnu dot org wrote:
we could make specific versions of all those intrinsic that
currently use memcpy(), including pack.
Should we leave this bug open
--- Comment #8 from burnus at gcc dot gnu dot org 2007-12-08 21:59 ---
FIXED on the trunk (4.3.0).
gfortran now transfers
DATA DMACH(2) / Z'7FEF' /
bitwise for real/complex variables. Note: For -std=f95/f2003 this is rejected.
For details how non-standard BOZ are (now)
--- Comment #11 from burnus at gcc dot gnu dot org 2007-12-08 22:08 ---
FIXED on the trunk (4.3.0).
Fortran 95: Only in DATA and only integer
Fortran 2003: Only in DATA or as argument of INT, REAL, DBLE, CMPLX
Fortran 2003 BOZ are now properly supported.
For -std=f95 full
--- Comment #17 from burnus at gcc dot gnu dot org 2007-12-08 22:09 ---
Fixed on the trunk (4.3.0).
gfortran now transfers the BOZ in
DATA inf / Z'7FF0' /
DATA nan / Z'FFF8' /
bitwise to the real/complex variables (contrary to g77 without needing an
--- Comment #12 from burnus at gcc dot gnu dot org 2007-12-08 22:09 ---
Mark really as FIXED.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-12-08 22:29 ---
We really need a self contained testcase to reproduce this.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-08 22:31 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-12-08 22:36 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
The following invalid code snippet triggers an ICE on mainline:
=
templatetypename T, int = T()[0] struct A
{
typedef AT B;
};
=
bug.cc:3: internal compiler error: Segmentation fault
Please submit a
With the changes for BOZ literals (cf. also PR 34392), some range checks got
disabled.
Example:
DOUBLE PRECISION inf
DATA inf / Z'7FF0' /
--
Summary: BOZ literals: Range checks
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-12-08 22:51 ---
bar in the context of the base class is dependent so the code is invalid.
That is the base class of fooT::baz is depdentent.
Note you can declare a specialization of fooT::bar which shows that the code
is really
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-08 22:52 ---
I don't get an ICE with the trunk as of today:
Sat Dec 8 19:47:21 UTC 2007 (revision 130710)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34397
--- Comment #2 from burnus at gcc dot gnu dot org 2007-12-08 22:53 ---
FIXED by checking in the mentioned patch.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-12-08 22:53 ---
If I add:
Aint a;
The code is rejected:
t.cc:7: error: subscripted value is neither array nor pointer
t.cc:7: error: template argument 2 is invalid
t.cc:7: error: invalid type in declaration before ';' token
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-08 23:00 ---
*** This bug has been marked as a duplicate of 34391 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-12-08 23:00 ---
*** Bug 34375 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from reichelt at gcc dot gnu dot org 2007-12-08 23:01
---
Well, I'm using the version from 2007-12-06, and since then nothing C++ related
has been checked in.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|ICE in December 6 version of|[4.3 Regression] ICE in
|gfortran when compiling a
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.3.0 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34397
--- Comment #1 from burnus at gcc dot gnu dot org 2007-12-08 23:02 ---
According to NAG f95 the program is invalid; it prints at run time:
Unequal character lengths (1 and 2) in array constructor
Program terminated by fatal error
In ARRAY_CHAR, line 9 of aaa.f90
I actually would
The following invalid code snippet triggers an ICE on mainline:
=
templateint... struct A
{
void foo();
};
struct B
{
templateint N friend void AN::A::foo();
};
=
bug.cc:8: internal compiler
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34399
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-08 23:08 ---
Confirmed, the only regression here is the error recovery one.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from dominiq at lps dot ens dot fr 2007-12-08 23:08 ---
I actually would expect gfortran to diagnose this with -fbounds-check.
Me too, but this works only if the lengths are correctly computed. The test
case pass the bounds check.
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-12-08 23:12 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-12-08 23:22 ---
unused1.C is PR 33429.
so all other issuses are known already so closing as invalid.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-12-08 23:24 ---
Any news on this issue?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-08 23:26 ---
-Os disables copy loop header which would have done some parts of this opt.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34064
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-12-08 23:27 ---
-Os disables copy loop header which would have done some parts of this opt.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||zadeck at gcc dot gnu dot
|
The thread starts here: http://gcc.gnu.org/ml/gcc/2007-11/msg00791.html
In addition, I observe the same behaviour when building a native, SJLJ version
of libgnat on x86_64.
Krister Walfridsson says: The problem was introduced by revision 125624 (the
dataflow merge)..
--
Summary:
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.3 |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31360
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-09 02:06 ---
use -Wvolatile-register-var
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34351
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-09 02:09 ---
I think this is the same issue as PR 16306.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34378
1 - 100 of 111 matches
Mail list logo
