--- Comment #2 from j at uriah dot heep dot sax dot de 2007-12-09 07:37
---
> use -Wvolatile-register-var
Could we have that at least as part of one of the "standard"
warning switch combinations, either -Wall or -Wextra? I
remember a statement from the developer who introduced the
cha
--- Comment #1 from tbm at cyrius dot com 2007-12-09 07:26 ---
typedef unsigned char uint8_t;
typedef uint8_t uint8;
typedef long unsigned int size_t;
class csVector2
{
public:float x;
};
class csBox2
{
};
struct iBase
{
};
struct iClipper2D:public virtual iBase
{
};
template < class Cla
With 4.3.0 20071207:
(sid)2522:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -c -O
crystalspac-polyclip.cc
crystalspac-polyclip.cc: In member function 'virtual uint8
csBoxClipper::Clip(csVector2*, size_t, csVector2*, size_t&)':
crystalspac-polyclip.cc:72: error: verify_flow_info: Wrong frequ
The initialization in following test case should be diagnosed as an error:
$ cat nocomp7.f90
module nocomp7
implicit none
type bad_t
real, allocatable :: x(:)
end type
! The following is illegal!
type (bad_t) :: bad = bad_t ( (/ 1., 3., 5., 7., 9. /) )
end module
$
$ gfortran --ver
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed
--- Comment #3 from jv244 at cam dot ac dot uk 2007-12-09 06:20 ---
changing into:
z = (/y(1:len(trim(y))), x(1:len(trim(x)))//"e"/)
makes this valid and shows the same issue on valid code
--
jv244 at cam dot ac dot uk changed:
What|Removed |Adde
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-09 05:25 ---
Just fixed today.
*** This bug has been marked as a duplicate of 34359 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-12-09 05:25 ---
*** Bug 34401 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
This occurs on a MacPro 10.4 (Tiger) system compiling netcdf with the very
latest 20071207 drop of gcc. It occurs compiling netcdf-3.6.2 which is
available from:
http://www.unidata.ucar.edu/downloads/netcdf/netcdf-3_6_2/index.jsp
Let me know if you need any additional help obtaining the code. T
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-09 02:16 ---
(define_insn "x86_movdicc_0_m1_rex64"
[(set (match_operand:DI 0 "register_operand" "=r")
(if_then_else:DI (match_operand 1 "ix86_carry_flag_operator" "")
(const_int -1)
(const_int 0)))
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34378
--- 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
--- 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
--
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
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||zadeck at gcc dot gnu dot
|
--- 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
-
--- 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:24 ---
Any news on this issue?
--
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
---
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: [
--- 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
Severity|norma
--- 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.
--
http://gcc.gnu.org/bugzilla/sho
--- 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
--
--
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
The following invalid code snippet triggers an ICE on mainline:
=
template struct A
{
void foo();
};
struct B
{
template friend void A::A::foo();
};
=
bug.cc:8: internal compiler error: Segmentati
--- 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 expect
--
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
--
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
--- 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
-
--- 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 #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 #2 from pinskia at gcc dot gnu dot org 2007-12-08 22:53 ---
If I add:
A 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
--
ht
--- 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 #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 #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 foo::baz is depdentent.
Note you can declare a specialization of foo::bar which shows that the code
is really depen
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
The following invalid code snippet triggers an ICE on mainline:
=
template struct A
{
typedef A B;
};
=
bug.cc:3: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
--- 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
Status|UNCON
--- 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
Status|UNCON
--- 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 #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
St
--- 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
o
--- 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 diagnost
--- 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) i
--- 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 #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 #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 #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=gcc&view=rev&rev=130713
Log:
2007-12-08 Tobias Burnus <[EMAIL PROTECTED]>
PR for
--- 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=gcc&view=rev&rev=130713
Log:
2007-12-08 Tobias Burnus <[EMAIL PROTECTED]>
PR for
--- 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=gcc&view=rev&rev=130713
Log:
2007-12-08 Tobias Burnus <[EMAIL PROTECTED]>
PR fort
--- 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=gcc&view=rev&rev=130713
Log:
2007-12-08 Tobias Burnus <[EMAIL PROTECTED]>
PR fort
--- 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 th
--- 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
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 #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=gcc&view=rev&rev=130712
Log:
PR fortran/34359
* gfortran.h (gfc_file): Remove
--- 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:
template struct A;
template struct A
{
void foo();
};
template void 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.
Confi
--- 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
--- 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()':
t.cc
--- 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
--
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
The C++ frontend issues a broken diagnostic for the following invalid
testcase on mainline:
===
template void foo(int... x[N])
{
struct A
{
A() { x; }
};
}
===
bug.cc: In constructor 'foo(int [N]...)::A::A()
--- 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|
--- 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
--
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
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 su
--- 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
--- 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
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
/opt/gcc/_gcc-clean/gc
--- 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
-
--- 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 ch
--- 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 t
--- 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
Status|UNCON
--- 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
Statu
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-12-08 20:07 ---
D.2020;
:
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 and then a sign extend.
--- 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
--- 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 #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 = -0.690680921077
--- 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 #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 #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 #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
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 detected
--- 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 #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=gcc&view=rev&rev=130708
Log:
2007-12-08 Tobias Burnus <[EMAIL PROTECTED]>
PR fort
--- 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 conside
--- 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 #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=gcc&view=rev&rev=130707
Log:
2007-12-08 Richard Guenther <[EMAIL PROTECTED]>
PR
--- 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
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:
:
ib.20_12 = (__vector signed int *) &ib;
vect_pib.19_11 = ib.20_12 + 4;
v
--- 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 @@ build_reint
--- 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
1 - 100 of 101 matches
Mail list logo
