The label is placed on illegal address when only loading the address of a label
without jump into. (compile with -O2 option)
test_func()
{
func(here);
func1();
here:
func2();
}
--
Summary: Illegal loading the address of a label with -O2
Product:
--- Comment #4 from patchapp at dberlin dot org 2006-08-03 06:05 ---
Subject: Bug number PR25828
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00056.html
--
--- Comment #1 from inaoka dot kazuhiro at renesas dot com 2006-08-03
06:07 ---
Created an attachment (id=12001)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12001action=view)
testcase
gcc -S -O2 label_address.c
label_address.s
.file label_address.c
.text
--- Comment #7 from martin at mpa-garching dot mpg dot de 2006-08-03 06:22
---
(In reply to comment #3)
Andrew, I think it is a bug. The language in section 12.4.1.5 is somewhat
convoluted and the description of PRESENT() suggest that PRESENT is special.
From 12.4.1.5:
An
--- Comment #8 from sgk at troutmask dot apl dot washington dot edu
2006-08-03 06:26 ---
Subject: Re: [4.2 Regression]: Optional argument failed
On Thu, Aug 03, 2006 at 06:22:10AM -, martin at mpa-garching dot mpg dot de
wrote:
My understanding of this is that the error
--- Comment #9 from martin at mpa-garching dot mpg dot de 2006-08-03 06:40
---
(In reply to comment #8)
I just submitted a patch that appears to fix the problem.
The problem is __convert_* (ie internal gfortran functions)
are caught by the error checking.
Hmm, but my point was
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-08-03 07:36
---
I don't know what I was thinking when I proclaimed this invalid code. It's
clearly valid; the cast is a reinterpret_cast.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from inaoka dot kazuhiro at renesas dot com 2006-08-03
07:59 ---
(In reply to comment #4)
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/m32r/m32r.md
Could you please apply the same path to 4.1 and 4.0 branch?
--
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2006-08-03 08:37
---
Is this really such a big deal? Solaris uses DWARF, and so does Apple now.
Sure, as far as Solaris is concerned, end of the story. But other platforms
are stuck with STABS (Tru64, HP-UX). And it seems that
OS is OpenBSD 3.9-release.
I installed gcc 4.1.1 in the standard GCC way (configure, gmake, gmake
install),
*not* using the OpenBSD package system, under /usr/local/ . This gcc compiles
hello, world fine, and also a toy test program using 'new int[10]'.
However, attempting to compile a certain
--- Comment #1 from jthorn at aei dot mpg dot de 2006-08-03 11:22 ---
Created an attachment (id=12002)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12002action=view)
output of '/usr/local/bin/g++ -v' and '/usr/local/bin/g++ -v -save-temps ...
my-file.cc'
This is a script(1)
--- Comment #2 from jthorn at aei dot mpg dot de 2006-08-03 11:25 ---
Created an attachment (id=12003)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12003action=view)
preprocessed source file, gzipped
This is the .ii file produced by
/urs/local/bin/g++ -v -save-temps ...
--- Comment #12 from reichelt at gcc dot gnu dot org 2006-08-03 11:34
---
Subject: Bug 28250
Author: reichelt
Date: Thu Aug 3 11:33:49 2006
New Revision: 115900
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115900
Log:
PR c++/28257
PR c++/28259
PR
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-08-03 11:34
---
Subject: Bug 28267
Author: reichelt
Date: Thu Aug 3 11:33:49 2006
New Revision: 115900
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115900
Log:
PR c++/28257
PR c++/28259
PR
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-08-03 11:34
---
Subject: Bug 28257
Author: reichelt
Date: Thu Aug 3 11:33:49 2006
New Revision: 115900
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115900
Log:
PR c++/28257
PR c++/28259
PR
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-08-03 11:34
---
Subject: Bug 28259
Author: reichelt
Date: Thu Aug 3 11:33:49 2006
New Revision: 115900
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115900
Log:
PR c++/28257
PR c++/28259
PR
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-08-03 11:36
---
Subject: Bug 28259
Author: reichelt
Date: Thu Aug 3 11:35:52 2006
New Revision: 115901
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115901
Log:
PR c++/28257
PR c++/28259
PR
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-08-03 11:36
---
Subject: Bug 28267
Author: reichelt
Date: Thu Aug 3 11:35:52 2006
New Revision: 115901
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115901
Log:
PR c++/28257
PR c++/28259
PR
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-08-03 11:36
---
Subject: Bug 28257
Author: reichelt
Date: Thu Aug 3 11:35:52 2006
New Revision: 115901
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115901
Log:
PR c++/28257
PR c++/28259
PR
--- Comment #13 from reichelt at gcc dot gnu dot org 2006-08-03 11:36
---
Subject: Bug 28250
Author: reichelt
Date: Thu Aug 3 11:35:52 2006
New Revision: 115901
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115901
Log:
PR c++/28257
PR c++/28259
PR
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-03 11:44 ---
This is actually invalid but I cannot find where in the docs which talk about
this issue. What is happening is the scheduler is moving around the label as
the basic block which contains the user label is gone.
--
--
gbenson at redhat dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |gbenson at redhat dot com
|dot org
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-03 11:50 ---
This is a matter of a mismatch of defines with openbsd's headers and what
openbsd's defines in GCC's headers say.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #11 from mkuvyrkov at gcc dot gnu dot org 2006-08-03 12:03
---
(In reply to comment #10)
Created an attachment (id=11997)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11997action=view) [edit]
Patch
This patch bootstraps and has no new regression on {i386,
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-08-03 12:04
---
Now also fixed on 4.1 branch, and 4.0 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-08-03 12:04
---
Now also fixed on 4.1 branch and 4.0 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-08-03 12:05
---
Now also fixed on 4.1 branch and 4.0 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from donour at cs dot unm dot edu 2006-08-03 13:21 ---
Subject: Re: [4.0/4.1/4.2 Regression] ICE with pointer to
member function initializer and cast to a different type
mmitchel at gcc dot gnu dot org wrote:
--- Comment #6 from mmitchel at gcc dot gnu dot org
--target=frv-linux-gnu --prefix=/opt/frv-4.1
--enable-languages=c --with-build-time-tools=/opt/frv-4.1/frv-linux-gnu/bin/
--with-as=/opt/frv-4.1/frv-linux-gnu/bin/frv-linux-gnu-as
Thread model: posix
gcc version 4.2.0 20060803 (experimental)
I configured the package with the configuration line you can
--- Comment #1 from dhowells at redhat dot com 2006-08-03 13:38 ---
Created an attachment (id=12004)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12004action=view)
Stripped down testcase for the bug
I get the error on line 92 of this source file:
warthog./gcc/xgcc -B./gcc -O2
--- Comment #6 from tom dot horsley at ccur dot com 2006-08-03 13:45
---
I'd add that this isn't a problem just for multi-dimension arrays. If you
declare different arrays like integer a1(5) integer a2(1:5) integer
a3(2:6)
they all show up with incorrect lower bound of 0 and upper
--- Comment #6 from dje at gcc dot gnu dot org 2006-08-03 13:48 ---
Subject: Bug 27566
Author: dje
Date: Thu Aug 3 13:48:01 2006
New Revision: 115902
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115902
Log:
PR target/27566
* config/rs6000/rs6000.c
The following code does not generate any warning when
compiled with g++ 4.0.x and 4.1.x on a x86_64 platform:
/*
#include cstdio
int f(void);
int f(void)
{
return (long) std::printf;
}
*/
typedef unsigned long mysize_t;
void *mymmap(void *start, mysize_t length, int prot , int flags, int
--- Comment #6 from Alexandra dot Kossovsky at oktetlabs dot ru 2006-08-03
14:12 ---
I've got this bug when building cross compiler gcc-3.4.6 on i686-linux for
x86_64-linux on Debian Sarge system.
Thanks to Ralf Corsepius for his patch.
--
Alexandra dot Kossovsky at oktetlabs dot
Currently, gfortran does not support the NEW_LINE intrinsic.
Expected: It is supported.
Testcase:
-
program newline
implicit none
WRITE(*,'(A)') 'This is record 1.'//NEW_LINE('A')//'This is record 2.'
end program newline
-
From Fortran 2003 standard:
13.7.85 NEW LINE
test enviroment: AIX 5.2, 5.3; gcc 3.3.2, 4.1.0
code to reproduce:
int f()
{
try
{
throw 1;
}
catch(int){}
return 0;
}
int i = f();
int main( int argc, char* argv[] )
{
return 0;
}
--
Summary: thowing exception before main() leads to crash on AIX
--- Comment #10 from sgk at troutmask dot apl dot washington dot edu
2006-08-03 16:17 ---
Subject: Re: [4.2 Regression]: Optional argument failed
On Thu, Aug 03, 2006 at 06:40:21AM -, martin at mpa-garching dot mpg dot de
wrote:
Hmm, but my point was that even if gfortran thinks
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28586
--- Comment #8 from sje at gcc dot gnu dot org 2006-08-03 16:35 ---
Subject: Bug 27291
Author: sje
Date: Thu Aug 3 16:35:31 2006
New Revision: 115904
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115904
Log:
PR rtl-optimization/28221
Backport from mainline.
--- Comment #11 from sje at gcc dot gnu dot org 2006-08-03 16:35 ---
Subject: Bug 28221
Author: sje
Date: Thu Aug 3 16:35:31 2006
New Revision: 115904
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115904
Log:
PR rtl-optimization/28221
Backport from mainline.
--- Comment #12 from sje at cup dot hp dot com 2006-08-03 16:39 ---
Fixed by backporting Nathan's patch and the fix for PR 27291.
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #2 from sje at gcc dot gnu dot org 2006-08-03 16:58 ---
Subject: Bug 28256
Author: sje
Date: Thu Aug 3 16:57:54 2006
New Revision: 115905
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115905
Log:
PR c++/28256
* decl.c (check_initializer): Check for 1
--- Comment #7 from hjl at lucon dot org 2006-08-03 16:58 ---
Apparently, it was done on purpose:
http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01161.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27537
--- Comment #3 from sje at cup dot hp dot com 2006-08-03 17:02 ---
Fix is now on mainline and the 4.1 branch.
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #12 from vda dot linux at googlemail dot com 2006-08-03 17:06
---
Created an attachment (id=12005)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12005action=view)
Alternative algorithm v. 3
Formatting fixes mostly
--
vda dot linux at googlemail dot com changed:
--- Comment #3 from sje at gcc dot gnu dot org 2006-08-03 17:10 ---
Subject: Bug 28432
Author: sje
Date: Thu Aug 3 17:09:57 2006
New Revision: 115906
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115906
Log:
PR c++/28432
* decl2.c (check_classfn): Remove early
--- Comment #4 from sje at gcc dot gnu dot org 2006-08-03 17:16 ---
Subject: Bug 28432
Author: sje
Date: Thu Aug 3 17:16:20 2006
New Revision: 115908
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115908
Log:
PR c++/28432
* decl2.c (check_classfn): Remove early
--- Comment #5 from sje at cup dot hp dot com 2006-08-03 17:17 ---
Fixed on mainline, 4.1 branch, and 4.0 branch.
--
sje at cup dot hp dot com changed:
What|Removed |Added
Compare this trivial program compiled with -DVBOOL and not:
#include vector
int main() {
unsigned N = 10;
for (unsigned i = 0; i 10; ++i) {
#if VBOOL
std::vectorbool V;
V.resize(N);
#else
char *X = new char[(N+7)/8];
memset(X, 0, (N+7)/8);
delete[] X;
#endif
}
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-03 18:23 ---
This is most likely due to the fact the C++98 standard special cases bool. Yes
there is a defect against the standard about that and I think it was already
going to change.
--
--- Comment #2 from sabre at nondot dot org 2006-08-03 18:31 ---
Andrew, I'm well aware that vectorbool stores things in compact form. If you
read my example, it's clear that I understand that.
Even with the current algorithm used by vectorbool, it should not use
std::fill internally,
--- Comment #7 from dje at gcc dot gnu dot org 2006-08-03 18:36 ---
Subject: Bug 27566
Author: dje
Date: Thu Aug 3 18:36:28 2006
New Revision: 115909
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115909
Log:
PR target/27566
* config/rs6000/rs6000.c
--- Comment #8 from dje at gcc dot gnu dot org 2006-08-03 18:37 ---
Patch applied to mainline and 4.1 branch.
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from dje at gcc dot gnu dot org 2006-08-03 18:48 ---
Fixing this requires implementing fallback framestate for AIX, for which there
is little demand.
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pcarlini at suse dot de 2006-08-03 19:16 ---
Hi. I think this specific issue can be (almost) fixed rather easily, by making
fill_insert smarter, that is slowly setting some bits of the previous and next
underlying unsigned long and then proceeding one unsigned long
--- Comment #4 from sabre at nondot dot org 2006-08-03 19:21 ---
the people actively working in the C++ Standard Commitee strongly dislike
vectorbool for many reasons, and probably it will be deprecated in C++03 and
replacement added. That implies, in turn, that it's not so easy to
--- Comment #5 from pcarlini at suse dot de 2006-08-03 19:28 ---
(In reply to comment #4)
Fair enough. My impression was that this was because std::vectorbool is
not a container and that the specialization doesn't act like the parent
container. My (possibly flawed) understanding
$ cat test.cpp
class Foo { static void f() {} };
int main()
{
Foo foo;
void (*f)();
f = foo.f;
return 0;
}
$ g++ -Wall test.cpp echo success
success
If trying compile it with another compiler
http://cpp.sourceforge.net/?show=18471
I got something like this:
--- Comment #8 from chris at bubblescope dot net 2006-08-03 19:48 ---
One quick piece of advice. Have you tried compiling your entire application
against the libstdc++ debug mode? It might help narrow down where the problem
is.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27530
--- Comment #5 from patchapp at dberlin dot org 2006-08-03 20:15 ---
Subject: Bug number PR c++/27398
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00075.html
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-03 20:16 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from agner at agner dot org 2006-08-03 20:20 ---
hjl wrote:
Apparently, it was done on purpose
Yes, the -Os non-alignment was obviously done on purpose. The problem is that
other modules that may be called from the -Os module rely on the stack being
aligned by 16. The
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2006-08-03
20:27 ---
Subject: Re: FAIL: g++.dg/other/unused1.C scan-assembler string\tclass2 and
string\tprinter
Attached hppa1.1-hp-hpux10.20 assembler output. Probably, we should
XFAIL.
Dave
--- Comment #6 from dave
--- Comment #21 from dorit at gcc dot gnu dot org 2006-08-03 20:35 ---
Subject: Bug 27770
Author: dorit
Date: Thu Aug 3 20:35:05 2006
New Revision: 115910
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115910
Log:
PR tree-optimization/27770
* tree-vectorizer.h
--- Comment #3 from bonzini at gnu dot org 2006-08-03 20:36 ---
is this a rejects-valid?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28275
--enable-nls --disable-werror
--with-gnu-as --with-gnu-ld --with-demangler-in-ld --with-system-zlib
--with-slibdir=/lib64 --without-system-libunwind --without-x
--with-long-double-128 --enable-bootstrap x86_64-pld-linux
Thread model: posix
gcc version 4.2.0 20060803 (experimental) (PLD-Linux
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-03 20:39 ---
I think we should error out even if the template is not instantiated.
Otherwise we get a QOI problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28275
--- Comment #4 from pluto at agmk dot net 2006-08-03 20:41 ---
(In reply to comment #2)
works fine with BOOT_CFLAGS=-01 STAGE1_CFLAGS=-O0.
with BOOT_CFLAGS=-O2 ices as above.
please ignore this comment. i missed note about my common cflags
(-fwrpav -fno-strict-aliasing)
--
--- Comment #4 from pluto at agmk dot net 2006-08-03 20:42 ---
*** This bug has been marked as a duplicate of 28230 ***
--
pluto at agmk dot net changed:
What|Removed |Added
--- Comment #5 from pluto at agmk dot net 2006-08-03 20:42 ---
*** Bug 28272 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28230
--- Comment #6 from pluto at agmk dot net 2006-08-03 20:44 ---
(In reply to comment #5)
(In reply to comment #4)
so it will be better if gcc searches gawk in $path rather than awk.
Why there are OS's which have real POSIX awk that are not gawk. Like mawk,
etc.
because they
--- Comment #9 from rsandifo at gcc dot gnu dot org 2006-08-03 21:06
---
Created an attachment (id=12010)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12010action=view)
A hackish fix
I agree with Kaz that a blockage would be a correct fix here.
I'm just worried about the
--- Comment #6 from gdr at integrable-solutions dot net 2006-08-03 21:13
---
Subject: Re: vectorbool is extremely slow (900x slower than it should be)
pcarlini at suse dot de [EMAIL PROTECTED] writes:
| By the way, I think Andrew has a point, maybe not clearly stated, in that all
|
--- Comment #7 from pcarlini at suse dot de 2006-08-03 22:12 ---
(In reply to comment #6)
some committee members dislike vectorbool for various reasons; but
I don't see a chance it is going to change.
Really? Or that comment of yours is just the effect of my typo C++03 for C++0x?
I
We have a code which uses a rather complicated set of defined types. When
compiling one set of these type definitions (in a module), I get the following
error.
In file temp.f90:34
end type GroupRigidMotion
1
Error: Component prescribedmotiondata of SEQUENCE type
--- Comment #5 from apl at alum dot mit dot edu 2006-08-03 22:51 ---
issuing an error here probably will cause you to violate SFINAE as well.
And to my mind as a 'user', the QOI issue is that an optimization flag is
interfering with a perfectly reasonable behavior when I don't
--- Comment #1 from ccnelson at itacllc dot com 2006-08-03 22:52 ---
Created an attachment (id=12011)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12011action=view)
Demo file to illustrate the problem
gfortran -c temp.f90 should illustrate the problem. As an aside: Lahey,
Intel,
--- Comment #8 from gdr at integrable-solutions dot net 2006-08-03 23:01
---
Subject: Re: vectorbool is extremely slow (900x slower than it should be)
pcarlini at suse dot de [EMAIL PROTECTED] writes:
| (In reply to comment #6)
| some committee members dislike vectorbool for
I get the following gnat regression. It looks a lot like PR26827 but that one
is with gcc-4.1 while mine works with 4.1 and fails with 4.2. Below is a
reduced testcase based on the code from the application ghdl that is failing.
(sid)101:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -c
--- Comment #3 from tbm at cyrius dot com 2006-08-03 23:31 ---
Sorry to be dense, but how do I split this attachment into separate files so
they can be compiled?
--
tbm at cyrius dot com changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #2 from pcarlini at suse dot de 2006-08-04 00:01 ---
The difference between 3.4.x and 4.x is due to the builtins, therefore the
underlying libc, being called by the latter. As such, this is not a
libstdc++-v3 proper issue anymore, because in any case, we definitely want to
--- Comment #3 from gdr at integrable-solutions dot net 2006-08-04 00:09
---
Subject: Re: What should be value of sqrt(complexdouble(-1.0,-0.0))?
pcarlini at suse dot de [EMAIL PROTECTED] writes:
| The difference between 3.4.x and 4.x is due to the builtins, therefore the
|
--- Comment #9 from pcarlini at suse dot de 2006-08-04 00:19 ---
(In reply to comment #8)
| (In reply to comment #6)
| some committee members dislike vectorbool for various reasons; but
| I don't see a chance it is going to change.
|
| Really?
well, that is my opinion. To
Running GCC with -O2 enabled on the attached file causes a segmentation fault.
This file was reduced from a much bigger file using delta.
[EMAIL PROTECTED]:~/cvs/Ivy/deputytests/minim$ gcc --version
gcc (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu5)
Copyright (C) 2006 Free Software Foundation, Inc.
This is
--- Comment #1 from rob at ennals dot org 2006-08-04 00:27 ---
Created an attachment (id=12012)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12012action=view)
Running gcc -O2 on this file gives a segfault.
Tested using gcc (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu5), the standard GCC
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
The following invalid code snippet triggers an ICE since GCC 4.0.0:
=
void *p = new (::X;
=
bug.cc:1: error: '::X' has not been declared
bug.cc:1: error: expected type-specifier before ';' token
bug.cc:1: internal compiler error: tree check:
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28593
The following invalid code snippet triggers an ICE on the 4.1 branch
and mainline:
===
templatevoid, int struct A;
===
bug6.cc:1: error: 'void' is not a valid type for a template constant parameter
bug6.cc:1: internal compiler error: tree
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28594
The following invalid code snippet triggers an ICE since GCC 4.1.0:
===
templateint struct A
{
static const int i;
};
templateint N struct B
{
char c[AN::i], d;
};
B0 b;
===
bug.cc: In instantiation of 'B0':
bug.cc:11: instantiated
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28595
Configure for libssp tries to build or run executables, even when configured
for cross-compile.
Workaround: specify --disable-libssp in configure.
--
Summary: libssp does not build for cross-compile
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
--- Comment #2 from wilson at specifix dot com 2006-08-04 01:34 ---
Subject: Re: make of gcc-4.1.1 failed using icc v9.1.042
on ia64
pinskia at gcc dot gnu dot org wrote:
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-02 20:13
---
If not, then what is the
When a friend function is defined in inside a class,
and then passed to a STL algorithm function,
gcc 4.1 reports it can't find the friend function.
gcc 4.0 and gcc 3.4.4 will compile the following code snippet.
gcc 4.1.0 (Fedora 5 x86-64) won't compile, it returns this error message.
--- Comment #10 from wilson at gcc dot gnu dot org 2006-08-04 01:49 ---
This is the same bug as PR 28490. I verified that my prototype patch for PR
28490 fixes it.
*** This bug has been marked as a duplicate of 28490 ***
--
wilson at gcc dot gnu dot org changed:
What
--- Comment #13 from wilson at gcc dot gnu dot org 2006-08-04 01:49 ---
*** Bug 28495 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28490
--- Comment #14 from wilson at gcc dot gnu dot org 2006-08-04 01:55 ---
Steve Ellcey posted a patch here:
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00016.html
I posted a better patch here:
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00054.html
This patch has not been tested
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-04 02:15 ---
(In reply to comment #2)
Essentially, we are using offsetof to size an array. This would be a
GCC extension that icc apparently does not support.
But that actually does not make sense since this is after ICC
1 - 100 of 116 matches
Mail list logo
