--- Additional Comments From matz at suse dot de 2005-04-15 06:51 ---
Perhaps due to the IPA infrastructure?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20991
g++ reports: "gpp_bug.cpp:10: internal compiler error: Segmentation fault", on
both Gentoo Linux (gcc 3.3.5) and Solaris (gcc 3.3.2).
Full output of "g++ gpp_bug.cpp":
gpp_bug.cpp: In function `void func()':
gpp_bug.cpp:10: internal compiler error: Segmentation fault
Please submi
--- Additional Comments From matz at suse dot de 2005-04-15 06:21 ---
Created an attachment (id=8640)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8640&action=view)
Tarball with the testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21039
This hits when compiling rrdtools, which creates a perl .xs module. It's
and autoconf package, and hence has a config.h. perl also has a config.h
used from it's headers (by doing a 'include "config.h"', so the one from the
perl include dir is used correctly), which has a multiple include guard
--- Additional Comments From nicolas dot girard at nerim dot net
2005-04-15 06:10 ---
Created an attachment (id=8639)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8639&action=view)
Source files
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21034
--- Additional Comments From nicolas dot girard at nerim dot net
2005-04-15 06:09 ---
Sure.
Actually the main file is a .F file. The tgz I'm about to attach contain the
following files:
- main.F : main file
- guess.h params.h pinch_complet.h prec.h: included by the preprocessor
--- Additional Comments From igodard at pacbell dot net 2005-04-15 06:04
---
Yes, it's a design flaw of C that parens and bracked are so overloaded that the
compiler (or the human) can't tell if the problem is too many openers or not
enough closers. Still, every little bit helps :-)
Iva
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-15
05:56 ---
Subject: [PR tree-optimization/21029, RFC] harmful chrec type conversions
I started out by handling the specific case that the Ada front-end
triggers, reduced to function f() in the attached testcase. Later
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-15
05:44 ---
Subject: Bug 21004
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-15 05:43:57
Modified files:
gcc: ChangeLog convert.c builtins.c
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Keywords|
--- Additional Comments From bangerth at dealii dot org 2005-04-15 05:36
---
It may also very well be the case that the shown opening brace isn't the
one that is unmatched, but that you forgot to close a block somewhere in
the middle.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-15
05:36 ---
Hmm, all of the testcases listed here work on the mainline.
--
What|Removed |Added
Know
--- Additional Comments From bangerth at dealii dot org 2005-04-15 05:31
---
The unqualified name Foo is looked up within the class hierarchy, and finds
the name of the base class.
W.
--
What|Removed |Added
---
--- Additional Comments From bangerth at dealii dot org 2005-04-15 05:29
---
A::foo_ is not template-dependent, so it is looked up and bound at the time
of template definition, not at instantiation time. Because template-dependent
base classes are not visible at the time, the access is
--- Additional Comments From ltg at zes dot uni-bremen dot de 2005-04-15
05:25 ---
Subject: RE: [4.0 RC1] Bootstrap failure (ld: TOC overflow)
On 15-Apr-2005 pinskia at physics dot uc dot edu wrote:
>
> It is already done for BOOT_LDFLAGS.
OK. I configured now with:
BOOT_LDFLAGS="-
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-04-15
05:07 ---
Subject: Re: Intrinisc function SPREAD is broken
>
>
>This appears to fix the benchmark in question.
>
>
>
I believe that reshape needs the same/similar fix.
Is ret->data = NULL guaranteed for temporarie
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-15
04:05 ---
I don't know if it would useful or not. Take the following:
void g(); void h();
void f()
{
//. say about 100 lines
if (a) {
//. say about 100 lines
//. say about 100 lines
}
well you
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-15 04:05
---
Testing the obvious fix.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu
On Apr 14, 2005, at 10:32 PM, Jay Summet wrote:
-BEGIN PGP SIGNED MESSAGE-
I ran into an interesting bug when attempting to add imlib2 to a
program that
uses GLUT. The program would compile/link fine, but segfault when the
imlib_load_image() call was made. (initial call to imlib)
The fix
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-15
03:31 ---
Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail
On Apr 12, 2005, Roger Sayle <[EMAIL PROTECTED]> wrote:
> I still like your fallbacks, that by trying harder we perform better
> o
--- Additional Comments From matz at suse dot de 2005-04-15 03:16 ---
One strange thing is, that the call to getWidth() in B is already in .generic:
if (retval.1)
{
getWidth (&i_bnds);
}
while the call to getWidth() in isEmpty() (which is inlined later into
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-15
03:09 ---
Subject: Bug 20739
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-15 03:09:51
Modified files:
gcc: ChangeLog gimplify.c
gcc/tes
--- Additional Comments From matz at suse dot de 2005-04-15 02:40 ---
We see this error in blender. I was able to reduce it quite a bit to this:
struct IMG_Rect {
virtual inline int getWidth() const;
virtual inline bool isEmpty() const;
virtual int getVisibility(int) const;
};
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-15
02:40 ---
> Hmm? VRP is automatically enabled at -O2 and higher.
But it doesn't run unless we find some ASSERT_EXPR, and if all we have is a
simple loop, no such ASSERT_EXPR is introduced.
--
http://gcc.gnu.org/b
-BEGIN PGP SIGNED MESSAGE-
I ran into an interesting bug when attempting to add imlib2 to a program that
uses GLUT. The program would compile/link fine, but segfault when the
imlib_load_image() call was made. (initial call to imlib)
The fix?
change:
int time;
to:
//int time;
the time integ
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-15
02:32 ---
Subject: Re: [PR middle-end/20739] lvalue cond-expr gimplification may crash on
cv-qual diffs
On Apr 14, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> Bootstrap and regtest pased on amd64-linux-gnu, a
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-15 01:31
---
Just checked in a workaround patch.
For a real fix, keep an eye on PR 21024.
--
What|Removed |Added
---
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-15
01:29 ---
Subject: Bug 21021
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-15 01:29:44
Modified files:
gcc: ChangeLog tree-vrp.c
gcc/tes
--- Additional Comments From ltg at zes dot uni-bremen dot de 2005-04-15
01:08 ---
Subject: RE: [4.0 RC1] Bootstrap failure (ld: TOC overflow)
On 15-Apr-2005 pinskia at gcc dot gnu dot org wrote:
>
> --- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-15
> 00:51
In:
void foo() {
int i;
int j;
int k;
you get:
~/ootbc/members/src$ g++ foo.cc
foo.cc: In function `void foo()':
foo.cc:5: error: expected `}' at end of input
The disgnostic should show the line number of the unmatched opener "{". Finding
mismatched brackets can be a real pain in l
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-15
00:51 ---
Also what gcc are you starting with?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21037
--- Additional Comments From pinskia at physics dot uc dot edu 2005-04-15
00:49 ---
Subject: Re: New: [4.0 RC1] Bootstrap failure (ld: TOC overflow)
On Apr 14, 2005, at 8:45 PM, ltg at zes dot uni-bremen dot de wrote:
> I tried to build gcc-4.0.0-20050410 (RC1) and got the following
On Apr 14, 2005, at 8:45 PM, ltg at zes dot uni-bremen dot de wrote:
I tried to build gcc-4.0.0-20050410 (RC1) and got the following error:
BOOT_CFLAGS="-O9 -maix64" CFLAGS="-O9 -maix64" CXXFLAGS="-O9 -maix64"
LIBCFLAGS="-g -O9 -maix64" LIBCXXFLAGS="-g -O9 -maix64
-fno-implicit-templates"
nohup /u
I tried to build gcc-4.0.0-20050410 (RC1) and got the following error:
/usr/local/bin/gcc -maix64 -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING
-DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition-DHAVE_CONFIG_H -o cc1 \
c-parse.o c-lan
Description of problem:
gcj ICEs compiling Azureus 2.2.0.2 to native code.
Version-Release number of selected component (if applicable):
gcc-java-4.0.0-0.42 from RedHat Fedora Core Development
How reproducible:
Always
Steps to Reproduce:
1. Download and unpack Azureus 2.2.0.2 from
http://azureu
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-14
23:37 ---
Subject: Bug 14311
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-14 23:37:47
Modified files:
gcc: ChangeLog builtin-types.def builtins.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14
23:33 ---
Could you attach the .f90 file?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21034
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-14 23:07
---
Patch posted:
http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01668.html
--
What|Removed |Added
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-14 23:02
---
A comment in the patch says "Tested on i686-pc-linux-gnu", but
it just means that it will have been tested by the time I post this patch. :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21030
The comments in basic_string.h above std::basic_string::compare(...) and
therefore the Doxygen-generated documentation do not correctly describe the
behaviour of the compare() member function.
In all cases, the comments describe compare() as comparing strings by length
first, and calling traits::c
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-14 23:01
---
Created an attachment (id=8638)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8638&action=view)
patch
--
What|Removed |Added
--- Additional Comments From nicolas dot girard at nerim dot net
2005-04-14 22:35 ---
Created an attachment (id=8637)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8637&action=view)
Assembler file generated using the -save-temps option
--
http://gcc.gnu.org/bugzilla/show_bug.c
Hi,
I was in the process of translating a program written in f77 into f90 when this
bug occurred. All I did was to add parameters to a function ; these parameters
must correspond to the dimensions of arrays, as I want to allocate memory to
them dynamically.
I declared my arrays like:
real
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-04-14 22:25
---
*** Bug 21033 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-04-14 22:25
---
*** This bug has been marked as a duplicate of 19435 ***
--
What|Removed |Added
--- Additional Comments From acct4290 at dedion dot com 2005-04-14 22:14
---
Created an attachment (id=8636)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8636&action=view)
Preprocessed (.i) file for test case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21033
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-14 22:14
---
Reduced down to:
void
foo (int unit)
{
int i;
for (i = 0; unit; i++, unit--)
{
if (i >= 0)
{
int j = i;
while (j)
j--;
}
}
}
--
--- Additional Comments From acct4290 at dedion dot com 2005-04-14 22:12
---
Created an attachment (id=8635)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8635&action=view)
Source file for self-contained test case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21033
gcc erroneously reports "excess elements in array initializer" under certain
circumstances (sample code attached). I'm using gcc 3.3.3 under Fedora Core 2,
but I've seen the same problem on 3.4 and 4.0 experimental.
begin self-contained test program bug.c
/* I know you don't want #incl
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14
22:01 ---
Note neg just flips a bit so it is correct anyways and there is no loss of
precession.
This also happens on ppc darwin, I don't know what to make of this. A C person
has to comment to say
something abou
If you compile the function
void assign2(float* a, double b) {
volatile float v = -b;
*a = -v;
}
you will see that GCC 3.4.3, e.g., at -O2, produces
fldl12(%ebp)
fstps -20(%ebp)
movl8(%ebp), %eax
flds-20(%ebp)
fchs
fstps -4(%ebp
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-04-14
21:49 ---
Created an attachment (id=8634)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8634&action=view)
Proposed fix for PR 18495.
This appears to fix the benchmark in question.
--
What|Remov
--- Additional Comments From schlie at comcast dot net 2005-04-14 21:28
---
(In reply to comment #0)
I guess I misunderstand the problem, as given:
const double ggPi = 3.14159265358979323846;
double const divPi = 1 / ggPi;
It would seem that neither ggPi or divPI should be designa
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14
20:50 ---
Confirmed, I thought I saw a bug like before.
--
What|Removed |Added
CC|
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14
20:44 ---
Confirmed, also happens on i686-pc-linux-gnu.
--
What|Removed |Added
Status|UNCO
Consider:
int
foo (int a)
{
int b = a != 0;
unsigned char c = b;
if (c)
return 1;
else
return 0;
}
We end up with code like this:
b_3 = a_2 != 0;
c_4 = (unsigned char) b_3;
if (c_4 != 0) goto ; else goto ;
We want to forward-propagate the preceding two statements into the
--- Additional Comments From janis at gcc dot gnu dot org 2005-04-14 20:43
---
Created an attachment (id=8633)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8633&action=view)
minimized test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21030
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14
20:42 ---
(In reply to comment #3)
> The other thing is that signed integer wrapping is defined if we add -fwrapv
> which means we now
miss
> compile some java programs too.
Actually I tried basically the same pro
Mainline GCC for powerpc-linux gets an ICE compiling 176.gcc from SPEC
CPU2000 with -O2, as shown with this minimized test case:
elm3b149% /home/janis/tools/gcc-mline-20050414/bin/gcc -O2 -c bug.c
bug.c: In function
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14
20:25 ---
The other thing is that signed integer wrapping is defined if we add -fwrapv
which means we now miss
compile some java programs too.
Confirmed.
--
What|Removed |Added
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-14
20:19 ---
Created an attachment (id=8632)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8632&action=view)
C testcase that triggers the bug
The problem is that (from the vrp dump):
Simulating statement (from ssa
--- Additional Comments From dnovillo at redhat dot com 2005-04-14 20:18
---
Subject: Re: New: vrp miscompiles Ada front-end, drops loop exit test in
well-defined wrap-around circumstances
On Thu, Apr 14, 2005 at 08:16:09PM -, aoliva at gcc dot gnu dot org wrote:
> Unfortunately,
csets___elabb gets miscompiled in stage2, such that stage3 enters and endless
loop compiling ada.ads. Unfortunately, vrp seldom kicks in, so it's a bit
difficult to duplicate the problem. Perhaps it would make sense to add a
command-line option to force vrp on, and add that to torture, just to se
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14
19:40 ---
Looks like subregs are getting in the way.
Confirmed.
--
What|Removed |Added
Sta
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14
19:35 ---
*** Bug 21028 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14
19:35 ---
*** This bug has been marked as a duplicate of 6872 ***
--
What|Removed |Added
I tried to build a gcc-3.4-20050408 cross compiler for a
powerpc-aix5.2 system, and I got the following:
gcc -O9 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -pedantic -Wno-long-long-DHAVE_CONFIG_H gcov-dump.o
version.o ../libiberty/libiberty.a
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14
19:30 ---
(In reply to comment #2)
> Here's a minimized test case that fails on powerpc64-linux with -m64 -O2:
> On IRC pinskia pointed out that powerpc64-linux supports older CPUs by
> default than does powerpc-darwi
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14
19:22 ---
*** Bug 21027 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14
19:22 ---
This is a dup of bug 17758, which I reported when I was looking into a
tree-optimizator ICE long time
ago. I also noticed just recently when I was about to work on PR 17758, that
_gfortran_runtime_error
$ cat bounds-check.f90
program main
integer, parameter :: n=10
integer :: m,i
integer a(n), b(n)
call foo(a,m)
do i=1,m
b(i) = a(i)*a(i)
end do
print *,b(1:m)
end program main
subroutine foo(a)
integer a(10)
a = 2
m = 12
end subroutine foo
$ gfortran -fbounds-check -fdump-t
--- Additional Comments From mark at gcc dot gnu dot org 2005-04-14 19:14
---
This was "fixed" by the following patch on the 4.0 branch (20050414):
2005-04-14 Tom Tromey <[EMAIL PROTECTED]>
* java/lang/natClassLoader.cc (_Jv_FindClass): Use system loader,
--
What|Removed |Added
Known to fail||3.4.4 3.3.5
Known to work||4.0.0 4.1.0
http://gcc.gnu.org/bugzilla/show_bug.
// compile with -O0
template class C
{
void f ()
{
typedef typeof(*this) int;
}
};
// not a regression, fixed in 4.0 and above:
// Search converges between 2004-06-24-trunk (#471) and 2004-06-26-trunk (#472).
--
Summary: ICE in check_tag_decl, at cp/decl.c:3516
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14
19:10 ---
Fixed on the mainline:
: Search converges between 2004-03-01-trunk (#446) and 2004-04-01-trunk (#447).
Broke:
: Search converges between 2001-03-18-trunk (#11) and 2001-03-25-trunk (#12).
--
Wh
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-04-14 19:02 ---
// reduced testcase
template class C
{
void f ()
{
typedef int U;
typedef typeof(*this) U;
}
};
--
What|Removed |Added
---
--- Additional Comments From aph at gcc dot gnu dot org 2005-04-14 18:47
---
Do you want me to post the patch, then?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21020
--- Additional Comments From janis at gcc dot gnu dot org 2005-04-14 18:22
---
Fixed with the patch. Today the tests pass on powerpc64-linux.
--
What|Removed |Added
--- Additional Comments From janis at gcc dot gnu dot org 2005-04-14 18:18
---
Here's a minimized test case that fails on powerpc64-linux with -m64 -O2:
extern void bar (void *);
extern double x;
void
foo (
--- Additional Comments From tromey at gcc dot gnu dot org 2005-04-14
18:05 ---
For 4.0, my recent system class loader patch works around this problem.
The attached patch should go in the trunk asap.
I looked at all other users of _Jv_FindClassFromSignature,
and this was the only proble
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-04-14 18:02 ---
reduced testcase, compile with '-O1 -fschedule-insns -funit-at-a-time',
fails with 3.3-hammer, 3.4, 4.0 and mainline, introduced in 2003:
: Search converges between 2003-07-11-trunk (#291) and 200
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-14
18:02 ---
Subject: Bug 21010
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-14 18:02:37
Modified files:
gcc/testsuite/gcc.dg/vect: vect-ifcvt-1.c vect-ifcvt-2
--- Additional Comments From roger at eyesopen dot com 2005-04-14 17:37
---
You'll notice in loop.c that everywhere that we currently set all_reduced to
zero, we also set ignore to true. This change is to avoid wasting CPU cycles,
if we know that an IV can't be eliminated, there's no po
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-14
17:21 ---
Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail
On Apr 12, 2005, Roger Sayle <[EMAIL PROTECTED]> wrote:
> ! v->ignore = 1;
What's the point of the statement above?
--- Additional Comments From roger at eyesopen dot com 2005-04-14 17:19
---
Thanks Alex! This is OK for mainline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20739
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-14
17:03 ---
Subject: Re: [PR middle-end/20739] lvalue cond-expr gimplification may crash on
cv-qual diffs
On Apr 4, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> If the operands of a cond-expr used as an lvalue
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14
16:52 ---
Confirmed.
It also worked with "3.4.0 20040116" which means it was broken after the branch
of 3.4.0.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14
16:49 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14
16:48 ---
Confirmed. This has been wrong since "3.5.0 20040909".
--
What|Removed |Added
3.4.3 seg faults on this:
template struct X { char x[N]; };
template X<1 + sizeof(T) - sizeof(T)> F(T const &);
template struct S { int d() { F(1); } };
Appears to be quite dependent on the fact that the template argument
involves "sizeof(T) - sizeof(T)" - if the - is changed to a +, it wor
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-04-14 16:33 ---
Created an attachment (id=8631)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8631&action=view)
smaller testcase (4749 bytes)
confirmed on amd64 with both 4.0.0 and mainline.
--
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/sh
Consider:
extern void *bar (void);
int
foo (unsigned int *p)
{
const void *r = bar ();
if (r >= (const void *) *p)
return 1;
return 0;
}
t03.generic looks like so.
foo (p)
{
void * D.1155;
unsigned int D.1156;
int D.1157;
const void * r;
D.1155 = bar ();
r = D.1155;
D
--
What|Removed |Added
BugsThisDependsOn||21024
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21021
Yesterday I upgraded my fedora core 3 instalation and got gcc4 installed.
I tested the mudflap code and found a problem. The reduced test case is
below.
when I have two programs a.c and b.c
-- a.c --
typedef struct { char *name; } dummy;
dummy d[] = { {"a"}, {0} };
-- b.c --
typedef struct { char
I wrote a program that is fine compiling by MS VC 7.1 or higher
and works correctly. It also is compiling by CodeWarior 8.0.
Unfortunately gcc says subj. :(
Source code you can find in attach.
gcc --version
gcc (GCC) 3.3.5 (Gentoo Linux 3.3.5-r1, ssp-3.3.2-3, pie-8.7.7.1)
Copyright (C) 2003
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14
15:53 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-14 15:51
---
Before VRP (even before ASSERT_EXPR insertion), we have
const void * r;
unsigned int D.1157;
void * D.1156;
:
:
if (r_3 >= D.1157_5) goto ; else goto ;
Note that we already have a type-mismatch
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-14
15:43 ---
Subject: Bug 20924
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-04-14 15:43:07
Modified files:
gcc: Change
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-14
15:25 ---
Subject: Bug 20963
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-14 15:25:02
Modified files:
gcc: ChangeLog tree-ssa-pre.c
Log messag
1 - 100 of 146 matches
Mail list logo
