--- Comment #10 from hubicka at gcc dot gnu dot org 2009-01-30 08:00
---
Yes, it is harmless, so P4 should be better match. The test is checking that
loop disambugiation is done one way not the other way while both are correct
choices.
Honza
--
hubicka at gcc dot gnu dot org
--- Comment #28 from ktietz at gcc dot gnu dot org 2009-01-30 08:54 ---
(In reply to comment #19)
Anyone else could test it, please?
ok, I tested it for linux64 and and for w64 without any new problems.
I applied the patch (see rev. #143780). Just the testcase is missing.
Do you apply
--- Comment #29 from jakub at gcc dot gnu dot org 2009-01-30 09:23 ---
Subject: Bug 39002
Author: jakub
Date: Fri Jan 30 09:22:48 2009
New Revision: 143782
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143782
Log:
PR target/39002
* g++.dg/torture/pr39002.C: New
--- Comment #30 from jakub at gcc dot gnu dot org 2009-01-30 09:29 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from ubizjak at gmail dot com 2009-01-30 09:56 ---
You can workaround this PE/COFF problem with -fno-common.
*** This bug has been marked as a duplicate of 37216 ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #51 from ubizjak at gmail dot com 2009-01-30 09:56 ---
*** Bug 39039 has been marked as a duplicate of this bug. ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #5 from bonzini at gnu dot org 2009-01-30 10:01 ---
The posted patch seems wrong, since the test is testing chmod you should use
stat to check the result.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #3 from hariharans at picochip dot com 2009-01-30 10:04 ---
Index: gcc/common.opt
===
--- gcc/common.opt (revision 143749)
+++ gcc/common.opt (working copy)
@@ -386,7 +386,7 @@
Do not put
--- Comment #4 from paolo dot carlini at oracle dot com 2009-01-30 10:18
---
The diagnostic issue is trivial, just add a check for error_mark_node on the
return value of reshape_init_r, consistently with other calls.
However, I'm still analyzing whether we really want to reject. As
The attached file causes an ICE with gcc-4.3.2 and gcc-4.3.3 on at least two
targets (ix86 Linux and Blackfin) when compiled with -O2.
bug.i: In function 'foo':
bug.i:18: internal compiler error: in get_addr_dereference_operands, at
tree-ssa-operands.c:1698
This happens during the vrp2 pass:
--- Comment #1 from bernds_cb1 at t-online dot de 2009-01-30 10:51 ---
Created an attachment (id=17212)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17212action=view)
Testcase to reproduce the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39041
--- Comment #13 from jakub at gcc dot gnu dot org 2009-01-30 10:58 ---
Nothing changed in gsf-scan.c, but out of the 3 objects in libgsf.so that
changed it seems to be gsf-output-csv.c where r143570 makes difference for
gsf-scan. Looking at it now...
--
--- Comment #14 from jakub at gcc dot gnu dot org 2009-01-30 11:38 ---
And clearly the bug is in libgsf, not in gcc.
g_enum_register_static documentation says:
GObject keeps a reference to the data, so it cannot be stack-allocated.
so this relies on this optimization.
--- Comment #15 from jakub at gcc dot gnu dot org 2009-01-30 11:39 ---
Created an attachment (id=17213)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17213action=view)
libgsf-enum-register.patch
Patch that fixes this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39015
--- Comment #16 from jakub at gcc dot gnu dot org 2009-01-30 11:40 ---
Invalid.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #1 from jakub at gcc dot gnu dot org 2009-01-30 11:48 ---
For very recent glibc this has been fixed with
http://gcc.gnu.org/viewcvs?root=gccview=revrev=143773
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30928
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #2 from paolo dot carlini at oracle dot com 2009-01-30 12:08
---
*** Bug 33935 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #3 from paolo dot carlini at oracle dot com 2009-01-30 12:08
---
This is really the same as libstdc++/30928.
*** This bug has been marked as a duplicate of 30928 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-01-30 13:39 ---
Confirmed. There's a type mismatch in the substituted statement:
pretmp.27_29 = *cpumask.bits[0]
arg 1 indirect_ref 0x775267c0 type integer_type 0x77e89540 int
arg 0 addr_expr 0x7752a180
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-01-30 13:46 ---
I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-01-30 13:47 ---
4.2 works, the problem is latent in 4.4
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from dcb314 at hotmail dot com 2009-01-30 13:48 ---
(In reply to comment #1)
Yes this would be slightly useful but one has to be care full of what is
warned about.
Agreed. For a first cut, a simple straight forward job, without
considering the complex cases, could be
--- Comment #6 from hjl at gcc dot gnu dot org 2009-01-30 14:14 ---
Subject: Bug 38995
Author: hjl
Date: Fri Jan 30 14:13:50 2009
New Revision: 143789
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143789
Log:
gcc/
2009-01-30 H.J. Lu hongjiu...@intel.com
PR lto/38995
I have 10GB free space in /tmp. But it isn't enough to run
make check because LTO tests don't cleanup after run. It
leads to many false alarms and make my machine unusable.
--
Summary: [LTO] LTO tests don't cleanup temporary files
Product: gcc
Version: 4.4.0
--- Comment #5 from bangerth at gmail dot com 2009-01-30 15:00 ---
(In reply to comment #4)
However, I'm still analyzing whether we really want to reject. As data points,
ICC doesn't, even in strict mode; on the other hand Comeau rejects the
identifier family already...
Does it
--- Comment #2 from paolo at gcc dot gnu dot org 2009-01-30 15:03 ---
Subject: Bug 33465
Author: paolo
Date: Fri Jan 30 15:03:10 2009
New Revision: 143790
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143790
Log:
/cp
2009-01-30 Paolo Carlini paolo.carl...@oracle.com
--- Comment #1 from paolo at gcc dot gnu dot org 2009-01-30 15:03 ---
Subject: Bug 38655
Author: paolo
Date: Fri Jan 30 15:03:10 2009
New Revision: 143790
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143790
Log:
/cp
2009-01-30 Paolo Carlini paolo.carl...@oracle.com
--- Comment #3 from bangerth at gmail dot com 2009-01-30 15:03 ---
This is probably related to PR 2288.
--
bangerth at gmail dot com changed:
What|Removed |Added
--- Comment #3 from paolo dot carlini at oracle dot com 2009-01-30 15:05
---
Fixed for 4.4.0.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #5 from bangerth at gmail dot com 2009-01-30 15:05 ---
*** Bug 39038 has been marked as a duplicate of this bug. ***
--
bangerth at gmail dot com changed:
What|Removed |Added
--- Comment #4 from bangerth at gmail dot com 2009-01-30 15:05 ---
*** This bug has been marked as a duplicate of 18770 ***
--
bangerth at gmail dot com changed:
What|Removed |Added
--- Comment #2 from paolo dot carlini at oracle dot com 2009-01-30 15:05
---
Fixed for 4.4.0.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from bangerth at gmail dot com 2009-01-30 15:13 ---
Yes, I think this would be an optimizing compiler could potentially perform.
At the same time I think you are expecting too much from the compiler: it
would have to have a semantic understanding of what the strlen
--- Comment #1 from bangerth at gmail dot com 2009-01-30 15:20 ---
Confirmed. The original testcase had a function argument of type
pointer-to-pointer-to-array-of-unknown-size, but this testcase
also fails:
template typename T_
bool f (T_ p);
bool g ()
{
--
bangerth at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #1 from bangerth at gmail dot com 2009-01-30 15:23 ---
Confirmed.
--
bangerth at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from bangerth at gmail dot com 2009-01-30 15:27 ---
Confirmed. This used to work in 4.1 where we got the following error
(which does not earn the prize for the prettiest error message ever):
g/x /home/bangerth/bin/gcc-4.1.1/bin/c++ -c x.cc
x.cc: In function 'int main()':
--- Comment #2 from bangerth at gmail dot com 2009-01-30 15:28 ---
Thinking some more about it, I believe that the code is actually valid.
icc accepts it, for comparison.
W.
--
bangerth at gmail dot com changed:
What|Removed |Added
--- Comment #5 from bangerth at gmail dot com 2009-01-30 15:29 ---
I think Jason confirmed this already...
--
bangerth at gmail dot com changed:
What|Removed |Added
--- Comment #10 from bangerth at gmail dot com 2009-01-30 15:37 ---
(In reply to comment #9)
Following the twisted maze that is BOOST_CLASS_EXPORT() leads me to think that
it is (very) roughly equivalent to this:
void dummy(boost::archive::xml_iarchive ar, A a, B b) {
--- Comment #3 from bangerth at gmail dot com 2009-01-30 15:45 ---
Confirmed. There is no need to convolve error messages like that.
W.
--
bangerth at gmail dot com changed:
What|Removed |Added
--- Comment #16 from bangerth at gmail dot com 2009-01-30 15:49 ---
(In reply to comment #5)
Excuse me, but I do not understand what makes this code invalid. Could anybody
explain? If so, does this apply to all the test cases given (also for bugs
that
are marked as duplicates of
--- Comment #17 from bangerth at gmail dot com 2009-01-30 15:51 ---
*** Bug 38681 has been marked as a duplicate of this bug. ***
--
bangerth at gmail dot com changed:
What|Removed |Added
--- Comment #7 from bangerth at gmail dot com 2009-01-30 15:51 ---
(In reply to comment #5)
Did I understand this wrong ? Does the correct interpretation of the standard
not allow for member-function-pointers as non-type arguments ?
It does, but it requires them to be in a
--- Comment #2 from bangerth at gmail dot com 2009-01-30 15:58 ---
The standard details certain side effects of throwing exceptions such
as allocating and freeing memory as well as setting expressions that
std::uncaught_exception can evaluate. These side effects can not
always be
--- Comment #2 from bangerth at gmail dot com 2009-01-30 16:02 ---
Confirmed. Gcc would have to keep track of the actual types of variables.
W.
--
bangerth at gmail dot com changed:
What|Removed |Added
--- Comment #7 from hjl dot tools at gmail dot com 2009-01-30 16:04 ---
I think it is caused by revision 118356:
http://gcc.gnu.org/ml/gcc-cvs/2006-11/msg7.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39026
--- Comment #13 from manu at gcc dot gnu dot org 2009-01-30 16:11 ---
(In reply to comment #12)
For source codes [a-k]*, there where 906 occurrences of the set but
not used warning from Intel C/C++.
@dcb
I think nobody is discussing that we would want such warning (in some form
--- Comment #2 from esigra at gmail dot com 2009-01-30 16:12 ---
GCC already understands the semantics of strlen. If one of the operands to
is a constant and the other is strlen, it is optimized (such as strlen(str) =
1). It just seems like the case with strlen on both sides is
--- Comment #1 from jakub at gcc dot gnu dot org 2009-01-30 16:17 ---
Subject: Bug 39028
Author: jakub
Date: Fri Jan 30 16:17:30 2009
New Revision: 143797
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143797
Log:
PR c++/39028
* parser.c
--- Comment #2 from jakub at gcc dot gnu dot org 2009-01-30 16:18 ---
Fixed on the trunk so far.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-01-30 16:35 ---
I think this may be due to the use of setjmp and
DEF_GCC_BUILTIN(BUILT_IN_SETJMP, setjmp, BT_FN_INT_PTR, ATTR_NULL)
missing the fact that setjmp returns twice.
Note also the inconsistency in
if
[...@gnu-6 gcc]$ cat /tmp/i.ii
inline void foo () {}
int
main ()
{
foo ();
return 0;
}
[...@gnu-6 gcc]$ ./xgcc -B./ -fpie /tmp/i.ii -S
[...@gnu-6 gcc]$ grep call i.s | grep foo
call_z3f...@plt
[...@gnu-6 gcc]$
Do we need @PLT for PIE?
--
Summary: C++ compiler
GCC-4.3.3, all previous versions are unaffected.
This snippet:
8 --- 8
#include stdio.h
int main()
{
static const char *s = hello world;
printf(s);
return 0;
}
- 8 -- 8 -
built with -Wformat throws this warning:
test-f.c: In function 'main':
test-f.c:5:
--- Comment #8 from hjl dot tools at gmail dot com 2009-01-30 16:44 ---
(In reply to comment #6)
It would be a way more local change than changing what binds local
(which also affects other languages).
My proposal patch will bind undefined functions global, instead of
local. It
--- Comment #7 from jakub at gcc dot gnu dot org 2009-01-30 16:54 ---
ECF_RETURNS_TWICE is set by special_function_p, doesn't need anything special
in
builtins.def.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38977
--- Comment #3 from paolo dot carlini at oracle dot com 2009-01-30 16:57
---
In the meanwhile the patch for PR38503 has been installed and unfortunately I
have to report that this issue seems indeed different, eg, this testcase is
still not fixed on x86_64-linux:
#include string
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last
--- Comment #17 from jdassen at debian dot org 2009-01-30 17:02 ---
Now fixed in libgsf upstream:
http://svn.gnome.org/viewvc/libgsf?view=revisionrevision=1039
Thank you very much!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39015
--- Comment #8 from matz at gcc dot gnu dot org 2009-01-30 17:12 ---
But special_function_p looks at the name of the function, which is
__builtin_setjmp in case the builtin is used explicitely:
% cat x.c
#include setjmp.h
jmp_buf env;
int f(void){ return __builtin_setjmp(env);}
% gdb
--- Comment #9 from jakub at gcc dot gnu dot org 2009-01-30 17:23 ---
Ah, I thought special_function_p would strip off __builtin_ prefix from tname,
but apparently it doesn't. I'd say it should, something like:
--- gcc/calls.c2009-01-28 12:57:50.0 +0100
+++
--- Comment #1 from tydeman at tybor dot com 2009-01-30 17:31 ---
My analysis shows that
d10=0x2fe3=+3.e-15
So, d10 is not zero, while d2 is zero.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39034
--- Comment #16 from jakub at gcc dot gnu dot org 2009-01-30 17:31 ---
Patch to set DECL_EXTERNAL instead:
http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01525.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39013
--- Comment #20 from hjl at gcc dot gnu dot org 2009-01-30 17:32 ---
Subject: Bug 38745
Author: hjl
Date: Fri Jan 30 17:31:24 2009
New Revision: 143798
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143798
Log:
2009-01-30 H.J. Lu hongjiu...@intel.com
2009-01-27
--- Comment #6 from hjl at gcc dot gnu dot org 2009-01-30 17:32 ---
Subject: Bug 38747
Author: hjl
Date: Fri Jan 30 17:31:24 2009
New Revision: 143798
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143798
Log:
2009-01-30 H.J. Lu hongjiu...@intel.com
2009-01-27 Richard
--- Comment #10 from hjl at gcc dot gnu dot org 2009-01-30 17:32 ---
Subject: Bug 38748
Author: hjl
Date: Fri Jan 30 17:31:24 2009
New Revision: 143798
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143798
Log:
2009-01-30 H.J. Lu hongjiu...@intel.com
2009-01-27
--- Comment #18 from hjl at gcc dot gnu dot org 2009-01-30 17:32 ---
Subject: Bug 38503
Author: hjl
Date: Fri Jan 30 17:31:24 2009
New Revision: 143798
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143798
Log:
2009-01-30 H.J. Lu hongjiu...@intel.com
2009-01-27
--- Comment #21 from hjl at gcc dot gnu dot org 2009-01-30 17:32 ---
Subject: Bug 38851
Author: hjl
Date: Fri Jan 30 17:31:24 2009
New Revision: 143798
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143798
Log:
2009-01-30 H.J. Lu hongjiu...@intel.com
2009-01-27
--- Comment #2 from tydeman at tybor dot com 2009-01-30 17:34 ---
This is NOT a dup of 39034. In this one, the value of the expression is zero.
In 39034, the value of d10 is not zero (but should be).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39035
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34955
--- Comment #12 from hjl at gcc dot gnu dot org 2009-01-30 17:47 ---
Subject: Bug 38789
Author: hjl
Date: Fri Jan 30 17:46:24 2009
New Revision: 143799
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143799
Log:
2009-01-30 H.J. Lu hongjiu...@intel.com
Backport from
--- Comment #7 from hjl dot tools at gmail dot com 2009-01-30 18:30 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from janis at gcc dot gnu dot org 2009-01-30 18:30 ---
Is N1312 available online? I had not heard of any version later than N1290.
--
janis at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from hjl dot tools at gmail dot com 2009-01-30 18:41 ---
(In reply to comment #1)
Is N1312 available online? I had not heard of any version later than N1290.
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1312.pdf
--
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #3 from marc dot glisse at normalesup dot org 2009-01-30 20:38
---
Hello,
looking at the two last comments, I think we are speaking of slightly different
things, although they are related. I was asking for some const_cast of the
return value, in case the const version of
--- Comment #2 from janis at gcc dot gnu dot org 2009-01-30 20:44 ---
Created an attachment (id=17214)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17214action=view)
expanded testcase
I expanded the testcase to test both constant folding and runtime calculations
for all three
--
janis at gcc dot gnu dot org changed:
What|Removed |Added
CC||hjl dot tools at gmail dot
|
--
janis at gcc dot gnu dot org changed:
What|Removed |Added
CC||hjl dot tools at gmail dot
|
--- Comment #17 from jakub at gcc dot gnu dot org 2009-01-30 20:47 ---
Subject: Bug 39013
Author: jakub
Date: Fri Jan 30 20:46:32 2009
New Revision: 143803
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143803
Log:
PR target/39013
* c-decl.c (pop_scope): Set
--- Comment #3 from janis at gcc dot gnu dot org 2009-01-30 20:48 ---
Created an attachment (id=17215)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17215action=view)
expanded testcase
I expanded the testcase to test both constant folding and runtime calculations
for all three
--- Comment #18 from jakub at gcc dot gnu dot org 2009-01-30 20:50 ---
Fixed on the trunk so far.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known
g++ allows to exist not inited reference in this case:
struct X
{
int x;
};
int main()
{
X* p_x = new X; // now there is not inited reference (p_x-x)
// now we can try to use p_x-x
std::cout p_x-x std::endl; // segmentation fault
return 0;
}
There are no errors or warnings.
--
janis at gcc dot gnu dot org changed:
What|Removed |Added
CC||hjl dot tools at gmail dot
|
--- Comment #3 from bkoz at gcc dot gnu dot org 2009-01-30 20:56 ---
Created an attachment (id=17216)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17216action=view)
remove visibility attribute with -D_GLIBCXX_VISIBILITY=0, run testuite with it
and -fvisibility-hidden
--
--- Comment #3 from janis at gcc dot gnu dot org 2009-01-30 20:57 ---
Ryan, would you please provide information about the status of C library
decimal float support for powerpc*-linux and s390-linux?
HJ, would you please provide information about the status of C library decimal
float
--- Comment #1 from hjl dot tools at gmail dot com 2009-01-30 21:08 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01533.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from hjl dot tools at gmail dot com 2009-01-30 21:22 ---
The updated patch is at
http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01534.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #3 from janis at gcc dot gnu dot org 2009-01-30 21:31 ---
The bug is a duplicate of 20785 because the pragma is not implemented.
From the point of view of GCC it is invalid because fenv.h and the functions
it declares are not provided by GCC, but by the C library.
--
--- Comment #3 from hjl at gcc dot gnu dot org 2009-01-30 21:55 ---
Subject: Bug 39010
Author: hjl
Date: Fri Jan 30 21:55:30 2009
New Revision: 143806
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143806
Log:
2009-01-30 H.J. Lu hongjiu...@intel.com
PR lto/39010
--- Comment #4 from hjl dot tools at gmail dot com 2009-01-30 21:58 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Version info:
$ powerpc-apple-darwin8.11.0-gcc-4.4.0 -v
Using built-in specs.
Target: powerpc-apple-darwin8.11.0
Configured with: ../gcc-4.4-20090116/configure --prefix=/opt/local
--enable-languages=c,c++,objc,obj-c++ --libdir=/opt/local/lib/gcc44
--includedir=/opt/local/include/gcc44
--
janis at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |janis at gcc dot gnu dot org
|dot org
g++ crashes with a segmentation fault trying to compile the attached program
--
Summary: Segmentation fault in g++
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-01-30 22:09 ---
Subject: Bug 39041
Author: rguenth
Date: Fri Jan 30 22:09:15 2009
New Revision: 143808
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143808
Log:
2009-01-30 Richard Guenther rguent...@suse.de
PR
--- Comment #1 from dima at debian dot org 2009-01-30 22:10 ---
Created an attachment (id=17217)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17217action=view)
test case which triggers the core dump
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39047
--- Comment #2 from dima at debian dot org 2009-01-30 22:13 ---
$ g++ -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.2-1ubuntu12'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-01-30 22:14 ---
Subject: Bug 39041
Author: rguenth
Date: Fri Jan 30 22:14:39 2009
New Revision: 143809
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143809
Log:
2009-01-30 Richard Guenther rguent...@suse.de
PR
1 - 100 of 119 matches
Mail list logo
