--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-03-28 08:38 ---
See also PR20160
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20160
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20654
CVS g++ produces incorrect code when compiling the following file with -Os.
There does not appear to be a problem with gcc 4.0.
--- Begin op_test.cpp
#include iostream
using namespace std;
class Pair { protected: int a; int b;
public:
Pair(){}
Pair(int x, int y) : a(x), b(y) {}
int
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-28
11:57 ---
Confirmed.
--
What|Removed |Added
CC|
--
Summary: ICE (segv)
Product: gcc
Version: 3.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
--- Additional Comments From igodard at pacbell dot net 2005-03-28 12:22
---
Created an attachment (id=8471)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8471action=view)
compiler output (-v)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20668
--- Additional Comments From igodard at pacbell dot net 2005-03-28 12:23
---
Created an attachment (id=8472)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8472action=view)
source code (-save-temps, compressed)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20668
--- Additional Comments From aaronavay62 at aaronwl dot com 2005-03-28
12:42 ---
Thanks Danny. So there is already machinery to fix this; it just needs to be
adapted to be case-insensitive. I'm working on a patch.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-28
13:04 ---
can you give the full version of 4.1? I thought this was fixed in a later
version of 4.1.0 already.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20667
--
What|Removed |Added
Component|c++ |middle-end
Keywords||wrong-code
--
What|Removed |Added
Attachment #8471|application/octet-stream|text/plain
mime type||
--
What|Removed |Added
Keywords||error-recovery, ice-on-
||invalid-code
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-28
13:15 ---
I cannot reproduce this with 4.1.0 20050327.
I think this was fixed with the patch for PR 20542.
--
What|Removed |Added
--
What|Removed |Added
Known to fail||4.1.0 3.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20668
--- Additional Comments From m dot calderbank at iname dot com 2005-03-28
13:44 ---
(In reply to comment #2)
I cannot reproduce this with 4.1.0 20050327.
I think this was fixed with the patch for PR 20542.
Yes, please accept my apologies. It turns out I was still using 20050321, and
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-28
13:47 ---
Closing as fixed then. Next time take please use a more up todate compiler to
report bugs with if you
are going to use the mainline.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-28
14:05 ---
Confirmed, reduced testcase:
template long struct f
{
typedef int reference;
};
templatetypename E struct bitset
{
static const E lwb;
static const long bitCount = int(lwb) + 1;
typename
/testsuite : ChangeLog
Added files:
gcc/testsuite/gcc.c-torture/compile: 20050328-1.c
Log message:
PR middle-end/20635
* varasm.c (mark_decl_referenced): Do not mark extern inline functions
as needed.
* compile/gcc.c-torture/compile/20050328-1.c: New
--- Additional Comments From bangerth at dealii dot org 2005-03-28 15:06
---
Yes, there are multiple PRs in the database about diagnostics when people
forget the semicolon at the end of a struct or class declaration. There are
also examples in these PRs that show why this case is so
When compiling the following (incorrect) code:
--test.cc
// Wolfgang Wieser, 03/2005
class A
{
templatetypename T1void B(int,T1) {}
void B(int,int) {}
};
void foo()
{
A a;
a.B(1,2,3);
}
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-28 17:48
---
To clarify this:
! End of record is not detected
!on second READ
! iostats should be 0, 0, -2, -1
The standard says:
Execution of an input/output statement containing the IOSTAT= specifier causes
the
--- Additional Comments From sje at cup dot hp dot com 2005-03-28 18:08
---
Fixed by skipping the test on IA64 HP-UX.
--
What|Removed |Added
Status|NEW
--- Additional Comments From sje at cup dot hp dot com 2005-03-28 18:11
---
Fixed by increasing arena_size on HP-UX.
--
What|Removed |Added
Status|UNCONFIRMED
There is some strange behavihour about the register f29 (and may be the next
floating registers) when an exception is raised. Its value is not properly
loaded. Going into the sources of gcc, I found sth interresting there :
unwind-ia64.c:2298:(p7) ldf.fill f29 = [r27] \n\t
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-28
18:19 ---
Subject: Bug 19890
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-03-28 18:19:13
Modified files:
gcc/testsuite : ChangeLog
--
What|Removed |Added
GCC host triplet|3.4.4 |ia-64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20670
--
What|Removed |Added
Severity|critical|normal
Component|other |target
Keywords|
--- Additional Comments From rth at gcc dot gnu dot org 2005-03-28 19:13
---
Indeed, SRA *does* need to be updated to handle the RANGE_EXPR. And not in the
hash routine at all -- it needs to happen before that. Consider the following
modified test case:
struct A
{
int i[6];
A
This test simulates the process of clearing the present bit
in an x86 page table entry. The code *should* load the PTE,
clear the present bit, and store the PTE. On x86, it is
possible to perform these 3 steps in a single instruction, i.e.
AND memory with immediate operand. The code should also
The following will compile fine:
int main(void)
{
int a;
(Note the lack of closing brace)
--
Summary: New C parser doesn't check whether functions that end
files are closed properly
Product: gcc
Version: 4.1.0
Status:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-28
19:35 ---
Confirmed.
--
What|Removed |Added
CC||pinskia
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-28
20:48 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02530.html.
--
What|Removed |Added
28 07:44:16 UTC 2005
Native configuration is sparc64-unknown-linux-gnu
Compiler version: 4.1.0 20050328 (experimental)
Platform: sparc64-unknown-linux-gnu
configure flags: sparc64-linux --enable-__cxa_atexit --disable-multilib --
enable-shared --enable-languages=c,c++
I get these C PCH failures
--
What|Removed |Added
Summary|C PCH assembly comparison |C PCH testsuite assembly
|failure |comparison failure
--
What|Removed |Added
Component|c |pch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20673
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-28
21:04 ---
Indeed I do not have time to work on this. I should have unassigned
this bug long ago, sorry about that.
--
What|Removed |Added
--- Additional Comments From dje at gcc dot gnu dot org 2005-03-28 21:31
---
patch committed
--
What|Removed |Added
Status|NEW |RESOLVED
--
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20470
Small .C program shows a problem where a value of 1.0 is calculated, but that
value falls through 2 if-checks ... one checks for if (val = 1.0) , the next
checks for if (val 1.0) ... one of these if checks must be true but neither
true leg is taken.
problem surfaces at optimization level -O1
--
What|Removed |Added
Summary|unexpected result from |unexpected result from
|floating compare|floating compare
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-28
21:53 ---
*** This bug has been marked as a duplicate of 323 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-28
21:53 ---
*** Bug 20674 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-28
21:57 ---
Test case, thanks to Tom Tromey:
T.java:
public class T
{
int field;
public void test(int f) {
synchronized (this) {
if (field != 0)
throw new IllegalStateException();
--- Additional Comments From piaget at us dot ibm dot com 2005-03-28 22:09
---
I do not think this is a precision problem. Although -ffloat-store resolves the
problem, I feel this has changed the behavior of the program sufficiently to
avoid the problem ... I should not have mentioned
--- Additional Comments From rth at gcc dot gnu dot org 2005-03-28 22:11
---
Subject: Re: [PR middle-end/20491] combine generates bad subregs
On Thu, Mar 24, 2005 at 07:45:44AM -0300, Alexandre Oliva wrote:
* combine.c (subst): Make sure we don't create invalid subregs.
Ok.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org |org
Status|NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-28
22:34 ---
If you write the function like so:
enum myRC doSomeMath
(
int i1,
float *f1,
float* f2,
float* f3,
float* f4
)
{
int i;
float f5=0.0;
float f6=0.0;
float f7=0.0;
for(i=0; ii1global; i++){
--- Additional Comments From wilson at gcc dot gnu dot org 2005-03-28
22:40 ---
The patch passed testing, and has been submitted to gcc-patches here:
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02542.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20286
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-28
22:40 ---
What options did you use to get the x86 asm?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20671
--- Additional Comments From piaget at us dot ibm dot com 2005-03-28 22:44
---
I tried this on a 64-bit system, and noticed I needed to compile -m32 to get
the error (this was on an older gcc level, though. 3.2.3)
I don't understand how this can be a precision problem. How can both if
--- Additional Comments From piaget at us dot ibm dot com 2005-03-28 22:46
---
my mistake in the previous post
how can both if-checks be false?
val = 1.0
and
val 1.0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20674
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-28
22:49 ---
(In reply to comment #6)
I tried this on a 64-bit system, and noticed I needed to compile -m32 to get
the error (this was on an older gcc level, though. 3.2.3)
Well considering x86_64 uses the sse
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-28
22:52 ---
Don't worry about it, I can reproduce it on PPC:
lwz r0,0(r12)
rlwinm r3,r0,0,1,31
mr r4,r3
stw r3,0(r12)
rlwimi r4,r0,0,1,1
mr r5,r4
stw r4,0(r12)
--- Additional Comments From piaget at us dot ibm dot com 2005-03-28 23:05
---
323 compares 2 values across a function call ... somthing a programmer can
reasonably consider. My problem occurs with 2 successive lines of code
admittedly with 2 compares per line). I don't have a problem
--- Additional Comments From sje at cup dot hp dot com 2005-03-28 23:21
---
Fixed by not running the test on IA64 HP-UX in ILP32 mode.
--
What|Removed |Added
--- Additional Comments From dave at synergy dot org 2005-03-28 23:34
---
gnatmake -O3 bit_test
objdump --disassemble -r bit_test.o
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20671
(as both unwind and libgcc2 unnecessarily presume 64 bit support, patch follows)
--
Summary: Small targets without 64 bit long long support are can't
bootstrap GCC.
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
--- Additional Comments From schlie at comcast dot net 2005-03-28 23:52
---
Created an attachment (id=8476)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8476action=view)
proposed patch
The following patch enables small targets which don't support a 64 bit
long long type to build,
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-29
00:25 ---
Note all patches should always goto [EMAIL PROTECTED]
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-29
00:26 ---
Also note that the dwarf-2 unwinder needs to be 64bit the last time I looked (I
think it is defined by the
dwarf-2 standard).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20675
--- Additional Comments From schlie at comcast dot net 2005-03-29 00:28
---
Subject: Re: Small targets without 64 bit long long
support are can't bootstrap GCC.
Note all patches should always goto gcc-patches
ok, just sent.
--
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-29
00:32 ---
Subject: Bug 20286
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_3-branch
Changes by: [EMAIL PROTECTED] 2005-03-29 00:32:03
Modified files:
gcc:
--- Additional Comments From wilson at gcc dot gnu dot org 2005-03-29
00:33 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--
What|Removed |Added
Keywords||diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20669
--
Summary: ICE (segv)
Product: gcc
Version: 3.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
--- Additional Comments From schlie at comcast dot net 2005-03-29 01:14
---
Subject: Re: Small targets without 64 bit long long
support are can't bootstrap GCC.
Also note that the dwarf-2 unwinder needs to be 64bit the last time I looked
(I think it is defined by the dwarf-2
--- Additional Comments From igodard at pacbell dot net 2005-03-29 01:14
---
Created an attachment (id=8477)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8477action=view)
compiler output (-v)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20676
--- Additional Comments From igodard at pacbell dot net 2005-03-29 01:14
---
Created an attachment (id=8478)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8478action=view)
source code (-save-temps, compressed)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20676
--
What|Removed |Added
Attachment #8477|application/octet-stream|text/plain
mime type||
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-29
01:33 ---
Reduces to the same problem as PR 20668.
*** This bug has been marked as a duplicate of 20668 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-29
01:33 ---
*** Bug 20676 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20668
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-29
01:39 ---
Confirmed, I could sware I saw this before.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-29
01:46 ---
What about changing the IDEs so they understand the natural language
warning/error/note
classification instead?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165
--
What|Removed |Added
Keywords||diagnostic
Last reconfirmed|2004-12-28 01:41:09 |2005-03-29 01:49:04
date|
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-29
01:55 ---
Some of this is already fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13355
--- Additional Comments From schlie at comcast dot net 2005-03-29 02:09
---
Subject: Re: Small targets without 64 bit long long
support are can't bootstrap GCC.
Also note that the dwarf-2 unwinder needs to be 64bit the last time I looked
(I think it is defined by the dwarf-2
--- Additional Comments From igodard at pacbell dot net 2005-03-29 02:14
---
Thought it might be a dup but wasn't sure.
Ivan
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20676
In:
enum A {b = -1, c, d};
bool foo(A a) { return a b || a d; }
you get:
foo.cc: In function `bool foo(A)':
foo.cc:2: warning: comparison is always false due to limited range of data type
If an enum is always necessarily an unsigned type then the initialization of b
should get a warning or
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-29
03:18 ---
Enums are specials in C++ as outside of the range of the enum is undefined.
Anyways this is fixed in 3.4.2.
--
What|Removed |Added
--- Additional Comments From schlie at comcast dot net 2005-03-29 03:42
---
Subject: Re: Small targets without 64 bit long long
support are can't bootstrap GCC.
Static debug data should be based on it's required encoding specification,
and have nothing to do with a target's
--- Additional Comments From gschafer at zip dot com dot au 2005-03-29
04:53 ---
I just hit this trying to compile psmisc-21.6 with snapshot gcc-4.0-20050326:
pstree.c: In function 'dump_tree':
pstree.c:539: internal compiler error: in cgraph_mark_reachable_node, at
cgraph.c:477
I'll
On Mon, 2005-03-28 at 23:05 +, piaget at us dot ibm dot com wrote:
--- Additional Comments From piaget at us dot ibm dot com 2005-03-28
23:05 ---
323 compares 2 values across a function call ... somthing a programmer can
reasonably consider. My problem occurs with 2 successive
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-03-29
04:58 ---
Subject: Re: unexpected result from floating compare
On Mon, 2005-03-28 at 23:05 +, piaget at us dot ibm dot com wrote:
--- Additional Comments From piaget at us dot ibm dot com 2005-03-28
g++ compiler stopped without any warning or error message. Preprocessor file is
OK
but assembler file is incomplete.
--
Summary: Make process stopped
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
--- Additional Comments From vladakk at abanka dot co dot yu 2005-03-29
06:55 ---
Created an attachment (id=8479)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8479action=view)
Environment info
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20678
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-29
07:03 ---
The code is invalid, reducing, this is most likely related to an undefined type
or something like that and
a packed structure (which you cannot take the address of a field any more).
--
What
--
What|Removed |Added
GCC host triplet|Windows vlada-xp 5.1 SP2 x86|MinGW 3.7, Windows vlada-xp
|Intel_x86_Family15_Model2_St|5.1 SP2 x86
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-03-29
07:12 ---
I don't have time to test it and submit it correctly, but I think the following
should work. I someone has time to do it before I do, please feel free to
test/comment/apply.
Index: inquire.c
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-29
07:21 ---
The code is invalid, reduced to:
struct a
{
a(const a);
};
struct b
{
a aa __attribute__((packed));
};
struct c
{
b bb;
c(const b __a): bb(__a) {}
};
--
What|Removed
On Mar 29, 2005, at 2:13 AM, fxcoudert at gcc dot gnu dot org wrote:
-*ioparm.exist = (u != NULL);
+*ioparm.exist = (u != NULL ? 1 : 0);
This change does nothing.
-- Pinski
--- Additional Comments From pinskia at physics dot uc dot edu 2005-03-29
07:24 ---
Subject: Re: INQUIRE incorrectly reports the existence of UNITS
On Mar 29, 2005, at 2:13 AM, fxcoudert at gcc dot gnu dot org wrote:
-*ioparm.exist = (u != NULL);
+*ioparm.exist = (u !=
--- Additional Comments From christian dot joensson at gmail dot com
2005-03-29 07:49 ---
This also happens on 4.0 branch, see testreport at
http://gcc.gnu.org/ml/gcc-testresults/2005-03/msg01946.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20673
91 matches
Mail list logo
