--- Comment #12 from pinskia at gcc dot gnu dot org 2008-03-28 07:28
---
Subject: Bug 31334
Author: pinskia
Date: Fri Mar 28 07:27:11 2008
New Revision: 133674
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133674
Log:
2008-03-28 Andrew Pinski <[EMAIL PROTECTED]>
PR
--- Comment #13 from pinskia at gcc dot gnu dot org 2008-03-28 07:30
---
The original issue has now been fixed, the rest is registered as PR 32107 and
PR 32110.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from pault at gcc dot gnu dot org 2008-03-28 08:33 ---
(In reply to comment #3)
> 1) If I am not mistaken, the first change is within a commented block (look at
> the last line in the diff.:
> ' } */')
Yes, indeed - the comment has been made consistent with the inte
--- Comment #9 from nickc at redhat dot com 2008-03-28 08:43 ---
Hi Jeff,
Thanks - I have checked the patch in.
Cheers
Nick
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31110
--- Comment #10 from nickc at gcc dot gnu dot org 2008-03-28 08:43 ---
Subject: Bug 31110
Author: nickc
Date: Fri Mar 28 08:42:36 2008
New Revision: 133675
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133675
Log:
PR target/31110
* config/mn10300/mn10300.c (mn10300_secondary
--- Comment #11 from mstein dot lists at googlemail dot com 2008-03-28
08:54 ---
Can the patch be applied to the 4.3 branch too?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31110
The following code produces an ICE with GCC-4.3.0 when compiled with g++ and
-O. Removing -O or using gcc removes the ICE.
#include
int moo(void)
{
unsigned char msg[] = { 0, 0 };
unsigned char data[2];
memcpy(data, msg, sizeof (msg));
return memcmp(data, msg, sizeof (data)) != 0;
}
Also, c
--- Comment #5 from mstein dot lists at googlemail dot com 2008-03-28
08:56 ---
Can the patch be applied to the 4.3 branch too?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31232
Currently, only libcpp and the compilers ("gcc") use gettext for localized
error messages.
libgfortran should do the same.
Note: Besides the actual change, the libgfortran.pot file needs also to
uploaded at http://translationproject.org. I don't know where this is
documented, but the release mana
--- Comment #1 from davids at webmaster dot com 2008-03-28 09:24 ---
#include
int moo(void)
{
unsigned char msg1[] = { 0, 0 };
unsigned char msg2[] = { 0, 0 };
memcpy(msg1, msg2, 2);
return memcmp(msg1, msg2, 2) != 0;
}
With this code, changing the sizes in both memcpy and memcmp
--- Comment #12 from nickc at gcc dot gnu dot org 2008-03-28 09:30 ---
Subject: Bug 31110
Author: nickc
Date: Fri Mar 28 09:30:05 2008
New Revision: 133676
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133676
Log:
PR target/31110
* config/mn10300/mn10300.c (mn10
--- Comment #13 from nickc at redhat dot com 2008-03-28 09:31 ---
Subject: Re: Problem while compiling gcc for mn10300-elf
Hi Mike,
> Can the patch be applied to the 4.3 branch too?
Done.
Cheers
Nick
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31110
--- Comment #6 from nickc at redhat dot com 2008-03-28 09:33 ---
Subject: Re: Problem while compiling gcc for xstormy16-elf
Hi Mike,
> Can the patch be applied to the 4.3 branch too?
Done.
Cheers
Nick
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31232
--- Comment #7 from nickc at gcc dot gnu dot org 2008-03-28 09:33 ---
Subject: Bug 31232
Author: nickc
Date: Fri Mar 28 09:33:01 2008
New Revision: 133677
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133677
Log:
PR target/31232
* config/stormy16/stormy16.c (xstormy16_legiti
--- Comment #17 from rguenth at gcc dot gnu dot org 2008-03-28 10:13
---
Note this is only fixed because we run inlining "twice". It isn't fixed
properly in that the new inlining opportunity should be exposed during the
first inlining pass.
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-03-28 10:15 ---
Hm, interesting. Do we not remove unused functions after final inlining?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-03-28 10:26 ---
Confirmed. RTL loop invariant motion moves the volatile load out of the
function.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #8 from mstein dot lists at googlemail dot com 2008-03-28
10:30 ---
Fixed :)
--
mstein dot lists at googlemail dot com changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-03-28 10:30 ---
*** This bug has been marked as a duplicate of 35526 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-03-28 10:30 ---
*** Bug 35730 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #14 from mstein dot lists at googlemail dot com 2008-03-28
10:31 ---
Fixed :)
--
mstein dot lists at googlemail dot com changed:
What|Removed |Added
--- Comment #14 from burnus at gcc dot gnu dot org 2008-03-28 10:32 ---
(In reply to comment #13)
> Created an attachment (id=15374)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15374&action=view) [edit]
> Patch padding for constant character lengths
I assume that you have not bo
--- Comment #14 from carlos at codesourcery dot com 2008-03-28 11:39
---
With the patch in comment #9, a glibc cvs head build completes successfully.
The test results show some regressions, but this is almost always the case when
switching to a new gcc branch.
--
http://gcc.gnu.org
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-03-28 12:21 ---
Subject: Bug 30317
Author: rguenth
Date: Fri Mar 28 12:20:09 2008
New Revision: 133680
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133680
Log:
2008-03-28 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #44 from rguenth at gcc dot gnu dot org 2008-03-28 12:21
---
Subject: Bug 30911
Author: rguenth
Date: Fri Mar 28 12:20:09 2008
New Revision: 133680
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133680
Log:
2008-03-28 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-03-28 12:21 ---
Subject: Bug 34793
Author: rguenth
Date: Fri Mar 28 12:20:09 2008
New Revision: 133680
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133680
Log:
2008-03-28 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #1 from joseph at codesourcery dot com 2008-03-28 12:48 ---
Subject: Re: New: libfortran should use gettext to for
localized error messages
On Fri, 28 Mar 2008, burnus at gcc dot gnu dot org wrote:
> Currently, only libcpp and the compilers ("gcc") use gettext for locali
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-03-28 12:56 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-03-28 13:02
---
I have two patches for the other missing parts to fix this PR.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #38 from rguenth at gcc dot gnu dot org 2008-03-28 13:40
---
Fixed in GCC 4.4 with the store-motion rewrite to use an alias-oracle:
:
r_I_lsm.18 = r[5];
r_I_lsm.13 = r[0];
r_I_lsm.14 = r[1];
r_I_lsm.15 = r[2];
r_I_lsm.16 = r[3];
r_I_lsm.17 = r[4];
r_I_lsm.27 =
--- Comment #39 from rguenth at gcc dot gnu dot org 2008-03-28 13:45
---
Subject: Bug 19580
Author: rguenth
Date: Fri Mar 28 13:44:41 2008
New Revision: 133683
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133683
Log:
2008-03-28 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #3 from burnus at gcc dot gnu dot org 2008-03-28 13:47 ---
Subject: Bug 35721
Author: burnus
Date: Fri Mar 28 13:47:06 2008
New Revision: 133684
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133684
Log:
2008-03-28 Tobias Burnus <[EMAIL PROTECTED]>
PR fort
--- Comment #4 from burnus at gcc dot gnu dot org 2008-03-28 13:49 ---
FIXED on the trunk (4.4.0). Thanks again for the report.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from hjl dot tools at gmail dot com 2008-03-28 14:04 ---
The testcase has 10001 nested (), which is processed with recursive calls.
My default stack limit is 8MB. 10001 recursive calls need around 8MB stack.
Any changes in my setup will push it over the limit. I think we s
--- Comment #13 from baldrick at gcc dot gnu dot org 2008-03-28 14:30
---
This has been fixed.
--
baldrick at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from mstein dot lists at googlemail dot com 2008-03-28
14:51 ---
backtrace:
[EMAIL PROTECTED]:~/build/m68hc11-elf/build/gcc$ gdb -args
/home/mstein/build/m68hc11-elf/build/./gcc/cc1 -quiet -nostdinc -v -I. -I.
-I../.././gcc -I/home/mstein/combined-trunk/libgcc
-I/home/ms
For
integer :: a(2)
integer, volatile :: i
i = 1
a(1:i) = a(1:2)
end
The message is misleading:
At line 4 of file aa.f90
Fortran runtime error: Array bound mismatch, size mismatch for dimension 1 of
array 'a' (0/1)
ISSUE:
The size should be "1/2" and not "0/1" (For a zero-sized array the out
--- Comment #45 from baldrick at gcc dot gnu dot org 2008-03-28 14:58
---
The recent VRP improvements made no difference to this bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2008-03-28 15:18
---
Reduced testcase:
integer, dimension(10) :: ILA1 = (/1,2,3,4,5,6,7,8,9,10/)
call mvbits ((ILA1((/9,9,6,2,4,9,2,9,6,10/))), 2, 4, ILA1, 3)
write (*,'(10(I3))') ila1
end
output is:
17 18 11 36 77 22 39
--- Comment #2 from dominiq at lps dot ens dot fr 2008-03-28 15:29 ---
For the second test in comment #1, ifort gives:
fortcom: Error: pr35681_2.f90, line 2: The shapes of the arguments do not
conform. [MVBITS]
call mvbits ((ILA1((/9/))), 2, 4, ILA1, 3)
-
--- Comment #3 from dick dot hendrickson at gmail dot com 2008-03-28 15:48
---
Subject: Re: wrong result for vector subscripted array expression in MVBITS
Right, in case you haven't found it yet, the first paragraph of
12.7.3, page 214, says effectively
that all of the arguments must
--- Comment #4 from dominiq at lps dot ens dot fr 2008-03-28 16:22 ---
It looks like a missing temporary:
integer, dimension(10) :: ILA1 = (/1,2,3,4,5,6,7,8,9,10/), ILA2, ILA3
ILA3 = (/9,9,6,2,4,9,2,9,6,10/)
print '(10(I3))', ILA1((/9,9,6,2,4,9,2,9,6,10/))
ILA2 = ILA1
do i = 1
Linux 2.6.24
glibc 2.7
Celeron (Mendocino) - 466MHz
When i try to compile gcc 4.3.0, I get the following (gcc 4.2.3 compiles
perfectly, but 4.3.0 doesn't):
/home/fraga/b/./gcc/xgcc -B/home/fraga/b/./gcc/
-B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/
-isystem /usr/local/i
The following valid code snippet triggers an ICE since GCC 4.3.0
when compiled with "-W":
=
struct A
{
A();
template A(const T&);
};
struct B : A
{
B(const B&) {}
};
=
bug.cc: In copy constructor 'B::B(const B&
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35734
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-28 17:33 ---
How did you configure GCC? How did you invoke make?
How did you configure/build GMP/MPFR ?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from mstein dot lists at googlemail dot com 2008-03-28
17:34 ---
A simple
'int main (int argc, char *argv[]) { return 0; }'
still fails with "error: in default_secondary_reload, at
targhooks.c:612" in rev. 133684 (trunk).
--
mstein dot lists at googlemail dot com c
--- Comment #1 from reichelt at gcc dot gnu dot org 2008-03-28 17:37
---
Manuel, Jason, was probably introduced by your patch:
2008-02-14 Manuel Lopez-Ibanez <[EMAIL PROTECTED]>
Jason Merrill <[EMAIL PROTECTED]>
PR c++/5645
PR c++/11159
* class.c
--- Comment #7 from reichelt at gcc dot gnu dot org 2008-03-28 17:44
---
A short C++ testcase I ran into:
struct A
{
A();
~A();
};
void foo()
{
A x[1];
}
==
--
reichelt at gcc dot gnu dot org changed:
What|Removed
--- Comment #8 from reichelt at gcc dot gnu dot org 2008-03-28 18:13
---
Here's a reduced C testcase (fuirther reduced from PR35663):
===
struct A
{
struct A *p;
};
int foo(const struct A *q)
{
return q->p == q;
}
void bar(int);
void baz()
{
struct
Hi,
compiling newlib now fails with:
xgcc -c -O1 ldtoa-delta.c
/home/mstein/combined-trunk/newlib/libc/stdlib/ldtoa.c: In function '_ldtoa_r':
/home/mstein/combined-trunk/newlib/libc/stdlib/ldtoa.c:2857: internal compiler
error: in default_secondary_reload, at targhooks.c:649
rev: 133684
--
The following valid code snippet triggers an ICE on mainline
when compiled with "-Wall":
=
void foo()
{
while (1)
for (;;({ continue; }))
;
}
=
bug.c: In function 'foo':
bug.c:4: internal compiler error: S
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35736
--- Comment #1 from mstein dot lists at googlemail dot com 2008-03-28
18:23 ---
Created an attachment (id=15393)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15393&action=view)
delta-reduced
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35735
The following valid code snippet triggers an ICE since GCC 4.2.0
when compiled with "-O":
=
#include
jmp_buf buf;
int foo()
{
__complex__ int i = 0;
if (__builtin_setjmp(buf))
{
i = 1;
bar();
}
return i == 0;
}
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35737
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
The following valid code snippet triggers an ICE since GCC 4.2.0
when compiled with "-fopenmp":
=
int foo();
void bar()
{
int i;
#pragma omp atomic
i += foo;
}
=
bug.c: In function 'bar':
bug.c:7: internal co
--- Comment #11 from rguenth at gcc dot gnu dot org 2008-03-28 18:54
---
Patches:
http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01803.html
http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01811.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34793
The following valid code snippet triggers an ICE since GCC 4.3.0
when compiled with "-fmudflap -O":
=
_Decimal128 foo(int n, ...)
{
int i;
_Decimal128 j;
__builtin_va_list va;
__builtin_va_start(va,n);
for (i = 0; i < n; i++)
j += __builtin_va
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35739
conjg(transpose(a)) still gives wrong results, if it is assigned to a.
transpose(conjg(a)) works.
program main
implicit none
complex, dimension(2,2) :: a,b,c
a(1,1) = (1.,1.)
a(2,1) = (2.,2.)
a(1,2) = (3.,3.)
a(2,2) = (4.,4.)
print *, "original: ",a
b = conjg(tr
--- Comment #46 from rguenth at gcc dot gnu dot org 2008-03-28 19:18
---
Ok, I didn't really expect that ;)
Some new background information. With the middle-end type-system work we now
omit conversions from sub-types T' to their base-types T. Thus we have
the three cases
T' sub;
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-03-28 19:21 ---
SCCVN now tries to simplify COND_EXPR conditions using their operands value
number. This still doesn't remove redundant comparisons.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30997
The following (valid ?) code snippet triggers an ICE since GCC 4.2.0:
=
struct A
{
char c;
int& i;
};
int j = __builtin_offsetof (A, i);
=
bug.cc:7: warning: invalid access to non-static data member 'A::i' of NU
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35741
--- Comment #1 from burnus at gcc dot gnu dot org 2008-03-28 19:40 ---
Confirmed.
A simple patch would be the following:
Index: expr.c
===
--- expr.c (Revision 133693)
+++ expr.c (Arbeitskopie)
@@ -2502,6 +2502,7
--- Comment #1 from burnus at gcc dot gnu dot org 2008-03-28 19:58 ---
Confirm. There seems to be a temporary missing.
Paul, you have fixed PR 31994, do you have an idea here?
The problem seems to be in general expressions of this type:
array = function(transpose(array))
where func
A broken diagnostic is issued for the following invalid code snippet
since GCC 4.1.0:
=
void foo()
{
for (;;)
({break;})();
}
=
#'goto_expr' not supported by pp_c_expression#'bug.c: In function 'foo':
bug.c:4: e
--
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=35742
Hi Joseph,
on March 15 you changed to priority of PR 35435 and PR 35441 to P4.
IMHO this is not in line with our current policy:
* PR 35435 is not an error-recovery bug (i.e. we don't issue a valid
error message before the ICE). So this should rather be P2, I think.
* PR 35441 is a diagnostic b
On Fri, 28 Mar 2008, Volker Reichelt wrote:
> Hi Joseph,
>
> on March 15 you changed to priority of PR 35435 and PR 35441 to P4.
> IMHO this is not in line with our current policy:
>
> * PR 35435 is not an error-recovery bug (i.e. we don't issue a valid
> error message before the ICE). So this
--- Comment #3 from bugzilla-gcc at thewrittenword dot com 2008-03-28
20:58 ---
(In reply to comment #2)
> (In reply to comment #1)
> > ld is running at this time so I doubt this is a GCC bug.
>
> The Pid it is referring to ("Pid 18929 received a SIGSEGV for stack growth
> failure.") i
The following program fails when rg0025 attempts to allocate a negative
amount of memory under windows XP. It doesn't abort when the array
subscripts are explicit constants instead of variables.
Dick Hendrickson
program try_rg0025
! fails on Windows XP
! gcc version 4.4.0 20080312 (experime
The following invalid code snippets triggers an ICE since GCC 4.1.0:
=
struct A
{
void x[1] __attribute__((packed));
};
=
bug.c:3: error: declaration of 'x' as array of voids
bug.c:3: internal compiler error: tree c
The following program aborts at run-time opening a
box that says
"a.exe has encountered a problem and needs to close.
We are sorry for the inconvenience."
And then offers to send an error report to Microsoft.
I believe the problem is the extraction of the 1/NF0
from within the WHERE block.
--- Comment #1 from reichelt at gcc dot gnu dot org 2008-03-28 21:45
---
Mine.
Patch here: http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01822.html
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
---
The following invalid code snippets triggers an ICE since GCC 4.3.0:
==
int foo(int i);
void bar()
{
__complex__ int i;
X j;
if (i = foo(j))
;
}
==
bug.c: In function 'bar':
bug.c:6: error: 'X' undeclared (first use in this function)
bug.c:6: er
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35746
The following invalid code snippets triggers an ICE since GCC 4.3.0:
=
void foo()
{
({ i; ({ i; }); 0; });
}
=
bug.cc: In function 'void foo()':
bug.cc:3: error: 'i' was not declared in this scope
gimplification failed:
>
head
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35747
The following invalid code snippet triggers an ICE since at least GCC 2.95.3:
=
union U { void x[1]; };
void foo()
{
(union U)0;
}
=
bug.c:1: error: declaration of 'x' as array of voids
bug.c: In function 'foo':
bug.c:5: internal
This is my code that is generating a false violation when compiled with mudflap
and the following options
export MUDFLAP_OPTIONS='-mode-check -viol-segv -backtrace=4 -verbose-violations
-check-initialization'
#include
#include
#include
#include
#include
#include
#include
#include
int mai
--- Comment #1 from burnus at gcc dot gnu dot org 2008-03-28 22:05 ---
Confirm.
Valgrind shows:
Process terminating with default action of signal 8 (SIGFPE): dumping core
Integer divide by zero at address 0x40274EADB
at 0x4008C6: MAIN__ (ghfhgk.f90:15)
> Divide incorrectly extra
The following invalid code snippet triggers an ICE since at least GCC 2.95.3:
=
void foo(int[]);
void foo(x) int x[](); {}
=
bug.c: In function 'foo':
bug.c:2: error: declaration of 'x' as array of functions
bug.c:2: internal compile
The following invalid code snippet triggers an ICE since GCC 4.2.0:
=
void foo(int i)
{
extern int a[i];
#pragma omp parallel
a[0] = 0;
}
=
bug.c: In function 'foo':
bug.c:3: error: object with variably modified type must ha
--- Comment #47 from rguenth at gcc dot gnu dot org 2008-03-28 22:12
---
What is interesting is that j__target_type___XDLU_10__20 is a unsigned sub type
with range [10, 20] of a signed base type with range [-128, 127]. So, we
enter compare_values ((js__TtB)20, (j__target_type___XDLU_10
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2008-03-28 22:14
---
Subject: Bug 35699
Author: jvdelisle
Date: Fri Mar 28 22:13:17 2008
New Revision: 133699
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133699
Log:
2008-03-28 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #48 from rguenth at gcc dot gnu dot org 2008-03-28 22:14
---
Created an attachment (id=15394)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15394&action=view)
patch for comment #47
This is what I was playing with.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2008-03-28 22:17
---
Subject: Bug 35699
Author: jvdelisle
Date: Fri Mar 28 22:16:29 2008
New Revision: 133700
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133700
Log:
2008-03-28 Jerry DeLisle <[EMAIL PROTECTED]>
I combined the current gcc and binutils mainlines into a combined
gcc + binutils source tree. When I tried to bootstrap it on
Linux/ia32 and Linux/Intel64 with shared library enabled, it went
to an infinite loop when as or ld from stage 2 was used. The problem is
ld-new tries to use itself to relin
--- Comment #49 from rguenth at gcc dot gnu dot org 2008-03-28 22:35
---
As of
"The TYPE_MIN/MAX_VALUEs
are of the type of the base type, so target_first_66s value range is
[10, 20] at the point of this comparison. Is this supposed to be
a comparison with -128 or with 128? That is, i
--- Comment #50 from baldrick at free dot fr 2008-03-28 22:42 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
> T' sub;
> T x;
>
> x = sub; (1)
> sub = (T')x; (2)
> x = VIEW_CONVERT_EXPR (sub); (3)
>
> where VRP for the simple copy (1) does not rest
--- Comment #3 from bruno at clisp dot org 2008-03-28 22:46 ---
> you are entering a scope that has objects constructed.
Can you point out the sections in the ISO C++ standard that say that an 'if'
statement can create the scope for some objects?
--
http://gcc.gnu.org/bugzilla/show
--- Comment #4 from bruno at clisp dot org 2008-03-28 22:48 ---
The bug also occurs with g++ 4.3.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35708
--- Comment #51 from baldrick at free dot fr 2008-03-28 22:48 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
> This is fold simplifying (js__TtB) target_first == -128 to
> target_first == 128 via fold_sign_changed_comparison.
Right, that was my instant guess. The Ad
--- Comment #3 from dfranke at gcc dot gnu dot org 2008-03-28 22:58 ---
Subject: Bug 34714
Author: dfranke
Date: Fri Mar 28 22:57:25 2008
New Revision: 133701
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133701
Log:
gcc/fortran:
2008-03-28 Daniel Franke <[EMAIL PROTECTED]>
--- Comment #52 from rguenth at gcc dot gnu dot org 2008-03-28 22:58
---
I'm now testing a variant of the patch that fixes fold_sign_changed_comparison
and just initializes incoming parameter value-ranges based on their types.
This seems to do the same range-check removals and looks lik
--- Comment #4 from dfranke at gcc dot gnu dot org 2008-03-28 23:02 ---
Fixed in trunk, no backport. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
---
1 - 100 of 117 matches
Mail list logo
