--- Additional Comments From eda-qa at disemia dot com 2005-07-21 19:55
---
Created an attachment (id=9325)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9325&action=view)
demostration of the error
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22597
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-21
19:56 ---
Subject: Bug 22576
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-07-21 19:56:30
Modified files:
gcc: Change
FAIL: 23_containers/set/explicit_instantiation/3.cc (test for excess errors)
is still present on mainline on i686-pc-linux-gnu on 20050721 (07:00 UTC). This
was related to bugs 22444, 22416, 22483 which have been closed (1.cc and 2.cc do
indeed now pass).
/scratch/gcc/nightly-2005-07-21
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-21
19:58 ---
Subject: Bug 21149
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-07-21 19:58:31
Modified files:
gcc: Change
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-21
19:59 ---
Subject: Bug 21149
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-07-21 19:59:09
Modified files:
gcc: ChangeLog
gcc/config/i386: s
--
What|Removed |Added
Keywords||ice-on-valid-code
Summary|23_containers/set/explicit_i|[4.1 Regression]
|nstantia
I triggered a segfault on a i386 target with a piece of code intented to be
compiled for avr target. I get a more descriptive message by modifiying the code
a little bit. Here is the source, messages and versions :
typedef unsigned long uint32_t;
typedef unsigned char uint8_t;
int
main (void)
{
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-21
20:14 ---
Confirmed, reduced testcase:
extern "C" void abort(void);
int t = 0;
struct point
{
point( const point& o ) {}
explicit point(){}
point __attribute__((pure)) operator/(const double m
--
What|Removed |Added
Component|c |target
Keywords||ice-on-invalid-code
http://gcc.gnu.org/bugzilla/show_b
--- Additional Comments From sebor at roguewave dot com 2005-07-21 20:33
---
(In reply to comment #13)
...
> * g++.dg/lookup/two-stage2.C: New.
FWIW, the following comment in this patch is wrong:
+ g(2);// f(char) followed by f(int)
^^
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-21
20:33 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-21
20:33 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-21
20:38 ---
Confirmed, only the second example fails from 4.0.0 upwards.
--
What|Removed |Added
--- Additional Comments From pbrook at gcc dot gnu dot org 2005-07-21
21:06 ---
gcc4 behaviour seems fine to me.
A slightly simpler example
int foo(int a)
{
int b;
asm ("" : "+r" (b) : "r" (a));
return b;
}
Can be (and is) legitimately be transformed into
: ChangeLog
gcc/config/rs6000: rs6000.md
gcc/testsuite : ChangeLog
Added files:
gcc/testsuite/gcc.c-torture/compile: 20050721-1.c
Log message:
PR target/20191
Backport from mainline:
2004-04-23 Dale Johannesen <[EMAIL PROTEC
Steps:
93> /opt/gcc401chk/bin/g++ -pass-exit-codes
../cpp/bugfiles/error/EckelRob_104822.ii
../jammed/Barney/eckel.cpp:2039: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for inst
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-21
22:12 ---
I don't see why it should be different than 1. It would only be helpful when
you have automated builds
but even then you need to look at the errors.
and for recursive crash testing you need to look for a
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-21
22:14 ---
One more thing usually ICEs have better error messages than just Segmentation
fault.
some give the line number in GCC's source where it occurred.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22600
--- Additional Comments From janis at gcc dot gnu dot org 2005-07-21 22:25
---
Fixed on the 3.4 branch.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From bangerth at dealii dot org 2005-07-21 23:00
---
No, icc puts it into bss and runs code to initialize it with 7:
.bss
.align 4
.globl _ZN3obj5sevenE
_ZN3obj5sevenE:
.type _ZN3obj5sevenE,@object
.size _ZN3obj5
--- Additional Comments From bangerth at dealii dot org 2005-07-21 23:11
---
With Andrew's little testcase, I get
g/x> cat > x.cc
include "core.hh"
typedef unsigned int size_t;
namespace std
{
using ::size_t;
}
g/x> /home/bangerth/bin/gcc-4.1-pre/bin/c++ -c x.cc
x.cc:1: er
--- Additional Comments From bangerth at dealii dot org 2005-07-21 23:17
---
Your explicit instantiation
template int foo< A_class >(A_class a);
obviously matches both the declarations of foo. I'm unsure which
one the compiler should choose, but if you want to instantiate the
secon
--- Additional Comments From danglin at gcc dot gnu dot org 2005-07-21
23:19 ---
I won't have time to test until early next week.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22577
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-07-21
23:26 ---
Jakub --
Thank you for finding the patch that fixed this problem.
Richard's patch changed things to mark the problematic variable as
DECL_IGNORED_P earlier, so my patch is no longer necessary.
As for J
--- Additional Comments From phenning at lanl dot gov 2005-07-21 23:26
---
(In reply to comment #5)
> Your explicit instantiation
> template int foo< A_class >(A_class a);
> obviously matches both the declarations of foo. I'm unsure which
> one the compiler should choose, but if you
Typing the command "gnat" results in the following output (note this is Centos
4.1 but I am pretty sure this is not target specific) :
GNAT 3.4.3 20050227 (Red Hat 3.4.3-22.1) Copyright 1996-2004 Free Software Found
ation, Inc.
List of available commands
GNAT BIND gnatbind
GNAT CH
--- Additional Comments From pcarlini at suse dot de 2005-07-21 23:34
---
> The test case passes for me on powerpc-linux with GCC 3.4.x and fails with
> everything later.
Mainline doesn't fail for me on x86-linux, but I have it configured with a
different allocator (new).
--- Additional Comments From bangerth at dealii dot org 2005-07-22 00:18
---
Oh, I apparently didn't read closely enough. I see the problem now.
For others -- take this:
-
template void f(T) {}
template void f(T) {}
template void f (int);
-
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-22
00:33 ---
Subject: Bug 22504
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-07-22 00:33:48
Modified files:
gcc: ChangeLog tree-complex.c
Log messag
Because there is a size limitation to 64K in this software.
I prepared a single file with no includes that faithfully reproduced the bug:
bug0.cpp: In member function 'double AtomicDouble::CompareExchange(double,
double) volatile':
bug0.cpp:4999: internal compiler error: in create_tmp_var, at gimp
On Fri, 2005-07-22 at 00:57 +, jacob dot navia at ants dot com
wrote:
> Because there is a size limitation to 64K in this software.
> I prepared a single file with no includes that faithfully reproduced the bug:
> bug0.cpp: In member function 'double AtomicDouble::CompareExchange(double,
> dou
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-07-22
00:59 ---
Subject: Re: New: I can't enter a bug here
On Fri, 2005-07-22 at 00:57 +, jacob dot navia at ants dot com
wrote:
> Because there is a size limitation to 64K in this software.
> I prepared a single file
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-22
01:01 ---
Are you filing via the web?
If so attach the preprocessed source after you submitted the bug.
The reason for the limit is so we don't get the preprocessed source inlined and
have to copy and paste.
I see yo
--- Additional Comments From pcarlini at suse dot de 2005-07-22 01:24
---
For the moment, I give up: in my opinion, a miscompilation is still the most
likely possibility. Meaningless behaviors are taking place: for instance, the
testcase passes if I exchange the arguments of swap to (my_
--- Additional Comments From igodard at pacbell dot net 2005-07-22 01:25
---
Then Andrew's test case is not showing the problem. In the original, although
the message is the same as Andrew's, the line/file reference is deep inside a
system include that contains the first program text aft
The invalid code below results in "internal compiler error: in pop_binding, at
cp/name-lookup.c:380"
with a checking version of GCC 4.0.1. Does not happen with GCC 3.3.4.
class NameOne : public static_small_value
{
inline NameOne(T v) {
}
{
};
template
class NameTwo : private NameThree
{
--- Additional Comments From flash at pobox dot com 2005-07-22 02:32
---
Created an attachment (id=9326)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9326&action=view)
104911_HtmlView_min.ii
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22603
--- Additional Comments From flash at pobox dot com 2005-07-22 02:35
---
This sounds like bugs 9777 and 5402, but those were supposedly fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22603
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-22
02:43 ---
Confirmed, only a 4.0 regression. We do not get an ICE on the mainline.
--
What|Removed |Added
--
--- Additional Comments From bangerth at dealii dot org 2005-07-22 03:16
---
I believe you, though I can't reproduce with a simple set of include files.
Can you try to reduce your program to something more reasonable that still
shows the same problem?
W.
--
http://gcc.gnu.org/b
The invalid code below results in "internal compiler error: Segmentation fault"
with a checking version of GCC 4.0.1. Does not happen with GCC 3.3.4 or Apple
GCC 4.0.0.
Like the code for bug 22603, this is a greatly-reduced and anonymized excerpt,
found by Daniel
Wilkerson's Delta, from a real
--- Additional Comments From flash at pobox dot com 2005-07-22 03:38
---
Created an attachment (id=9327)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9327&action=view)
BBinder_segfault.ii
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22604
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-22
03:53 ---
Confirmed.
Here is the backtrace:
#0 0x080b94b6 in dfs_modify_vtables (binfo=0xb7d11840, data=0xb7cbe398) at
/home/peshtigo/
pinskia/src/gnu/gcc/src/gcc/cp/class.c:2032
#1 0x08122b40 in dfs_walk_all (binf
--- Additional Comments From gnu at the-meissners dot org 2005-07-22 03:54
---
I forgot to mention, the patch was against the mainline, sources current as of
July 20th.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22599
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-22
03:58 ---
I should mention this started to happen after 20041124 but before 20050225.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22604
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-22
04:00 ---
I should mention this was started after 20050225 which was when the branch
happened.
And here is the backtrace:
#0 fancy_abort (file=0x1197880 "../../gcc/cp/name-lookup.c", line=380,
function=0x1197904
"
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-22
04:03 ---
No feedback in 3 months.
--
What|Removed |Added
Status|WAITING
Hi,
gcc 4 seems quite a bit smarter at keeping the stack smaller, and as you can see
below allocates the 8 byte structure across two stack slots.
It did break something, which drew this to my attention, and James Wilson
already some analsysis in
http://www.gelato.unsw.edu.au/archives/linux-ia64/0
--- Additional Comments From hjl at lucon dot org 2005-07-22 05:45 ---
I have identified that
http://gcc.gnu.org/ml/gcc-patches/2005-06/msg01149.html
is the cause.
--
What|Removed |Added
---
--- Additional Comments From uros at kss-loka dot si 2005-07-22 05:46
---
I was trying to trigger the "unrecognizable insn" bug with gcc-4.1, because
this bug should be fixed by the patch in PR22576.
I have tested:
gcc -O2 -mno-ieee-fp fractal.c
gcc -O2 -ffast-math fractal.c
gcc -O2 fr
--- Additional Comments From igodard at pacbell dot net 2005-07-22 05:50
---
# 1 "opClock.cc"
# 1 "/home/ivan/ootbc/members/src//"
# 1 ""
# 1 ""
# 1 "opClock.cc"
include "core.hh"
# 1 "../../members/include/opClock.hh" 1
# 1 "/mnt/export/local/bin/../lib/gcc/i686-pc-linux-gnu/3.4.0/../..
--- Additional Comments From hjl at lucon dot org 2005-07-22 05:51 ---
It looks like the unwind info in libstdc++.so is bad.
(gdb) r
Starting program:
/export/build/gnu/gcc-next/build-ia64-linux/gcc/testsuite/cond1.exe
Program received signal SIGSEGV, Segmentation fault.
0x201b9
--- Additional Comments From mark at codesourcery dot com 2005-07-22 06:25
---
Subject: Re: [4.0/4.1 Regression] debug info omitted for
uninitialized variables
mmitchel at gcc dot gnu dot org wrote:
> I will try a test run with my patch reverted; if that passes, and still fixes
> the
--- Additional Comments From mark at codesourcery dot com 2005-07-22 06:52
---
Subject: Re: [4.0/4.1 Regression] debug info omitted for
uninitialized variables
mark at codesourcery dot com wrote:
> Unfortunately, it failed -- gcc.dg/pch/global-1.c fails at -O3.
>
> I have not yet fi
101 - 154 of 154 matches
Mail list logo
