Testcase:
#include
#include
struct Tst { unsigned char data[1]; };
int main(void)
{
struct Tst *tst = malloc(sizeof(struct Tst) + 10);
unsigned char *tmp = tst->data;
tst->data[0] = 0;
tmp[0] = 1;
tmp[1] = 2;
printf("%x %x\n", tmp[0], tmp[1]);
with the current GCC trunk checkout I suddenly get an error in attached
testcase.
Not sure if it is valid c.
/home/marcus/projects/gcc.trunk/BIN/bin/gcc -m32 -c -O2 vxd.i
vxd.i: In function 'VXD_Win32s':
vxd.i:13: error: invalid use of void expression
--
Summary: strange new error
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
Component|c |target
http:
--- Comment #1 from marcus at jet dot franken dot de 2008-04-22 07:33
---
Created an attachment (id=15508)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15508&action=view)
vxd.i
gcc -m32 -O2 -c vxd.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36005
--
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 #24 from vapier at gentoo dot org 2008-04-22 07:51 ---
the proposed patch in question seems to break the opposite scenario on ia64:
--without-system-libunwind
--
vapier at gentoo dot org changed:
What|Removed |Added
--- Comment #4 from irar at il dot ibm dot com 2008-04-22 07:57 ---
The problem here is that we do not check the types of interleaved data-refs,
but only their steps (and since float and int are of the same size here, their
steps are equal). And then we treat all the data-refs as if they
--- Comment #1 from ubizjak at gmail dot com 2008-04-22 08:36 ---
I have tested a couple of approaches using following code:
--cut here--
#include
__m128 test_0 (__m64 __A, __m64 __B)
{
__v4sf __zero = (__v4sf) _mm_setzero_ps ();
__v4sf __sfa = __builtin_ia32_cvtpi2ps (__zero, (__
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-04-22 08:58 ---
*** This bug has been marked as a duplicate of 35992 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-04-22 08:58 ---
*** Bug 36005 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #19 from rguenth at gcc dot gnu dot org 2008-04-22 09:31
---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassign
--- Comment #16 from jakub at gcc dot gnu dot org 2008-04-22 09:48 ---
Especially for 4.3.x getting rid of the
"HACK. GROSS. This is absolutely disgusting."
might not be something desirable for a stable branch. We've lived with this
gross absolutely disgusting hack for more than 7 years
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-04-22 09:51 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #16 from jakub at gcc dot gnu dot org 2008-04-22 10:01 ---
Downgrading to P2, the patches so far all seem to be quite risky for the
branches, the wrong-code is on a corner case and isn't a recent regression.
Regarding the comment #14 patch, I'd say the complete_type should b
The following is a regression observed with build == host == i686-pc-mingw32
and target == x86_64-pc-mingw32, built from mainline sources. It used to pass
with a build dated 2007-11-30.
$ cat Codelet.f90
program test
integer, parameter :: wp = 4
complex(wp), parameter :: i = (0._wp, 1._wp)
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2008-04-22 10:08
---
Created an attachment (id=15509)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15509&action=view)
All tree dumps (from -fdump-tree-all) for the testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36
/tmp/cvs/gcc-20080422/Build/./gcc/xgcc -B/tmp/cvs/gcc-20080422/Build/./gcc/
-B/tmp/cvs/gcc-20080422/Build/root/ia64-suse-linux/bin/
-B/tmp/cvs/gcc-20080422/Build/root/ia64-suse-linux/lib/ -isystem
/tmp/cvs/gcc-20080422/Build/root/ia64-suse-linux/include -isystem
/tmp/cvs/gcc-20080422/Build/root
--- Comment #2 from uros at gcc dot gnu dot org 2008-04-22 12:41 ---
Subject: Bug 29096
Author: uros
Date: Tue Apr 22 12:41:14 2008
New Revision: 134558
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134558
Log:
PR target/29096
* config/i386/xmmintrin.h (_mm_cvtp
--- Comment #3 from ubizjak at gmail dot com 2008-04-22 12:52 ---
Implemented in 4.4.0
--
ubizjak at gmail dot com changed:
What|Removed |Added
URL|
--- Comment #2 from jakub at gcc dot gnu dot org 2008-04-22 13:12 ---
Apparently missing pop_stmt_list during error handling.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from zadeck at gcc dot gnu dot org 2008-04-22 13:44 ---
Subject: Bug 36003
Author: zadeck
Date: Tue Apr 22 13:43:47 2008
New Revision: 134559
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134559
Log:
2008-04-22 Kenneth Zadeck <[EMAIL PROTECTED]>
PR midd
When the attached source file is compiled with 'gcc -O3 -c', the code that uses
it produces wrong results. The problem disappears if 'gcc -O3 -fno-inline -c'
or if the variables inside 'generate_point_symmetry' are declared as 'static'.
This is the output of gcc-4.3 -v :
Using built-in specs.
Tar
--- Comment #1 from xavier at tddft dot org 2008-04-22 13:53 ---
Created an attachment (id=15510)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15510&action=view)
the code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36008
--- Comment #2 from aldot at gcc dot gnu dot org 2008-04-22 14:13 ---
Please provide a self-contained testcase (see http://gcc.gnu.org/bugs.html )
that ideally abort()s on a wrong result.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36008
double a[16][64], y[64], x[16];
void foo(void)
{
int i, j;
for (j = 0; j < 64; ++j)
for (i = 0; i < 16; ++i)
y[j] = y[j] + a[i][j] * x[i];
}
PRE moves the load of y[j] out of the inner loop like
pretmp = y[j];
for (i = 0; i < 16; ++i)
{
D.xxx = pretmp + a[i][j]
--- Comment #3 from jason at gcc dot gnu dot org 2008-04-22 14:44 ---
fixed
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
For the testcase
double a[16][64], y[64], x[16];
void foo(void)
{
int i, j;
for (j = 0; j < 64; ++j)
for (i = 0; i < 16; ++i)
y[j] = y[j] + a[i][j] * x[i];
}
with -O2 -fno-tree-pre -fno-tree-loop-im -ftree-loop-linear loop interchange
is performed but with PRE or lim moving the load
For the testcase
double a[16][16][64], y[16][64], x[16][16];
void foo(void)
{
int i, j, k;
for (k = 0; k < 16; ++k)
for (j = 0; j < 64; ++j)
for (i = 0; i < 16; ++i)
{
y[k][j] = y[k][j] + a[k][i][j] * x[k][i];
}
}
loop interchange is performed with -O2 -fn
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-04-22 15:19 ---
perfect_nestify needs to be enhanced to handle this I guess. In fact we cannot
distribute these loops but need to undo what PRE/lim do.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36010
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-04-22 15:22 ---
Bwaves from SPEC2006 has
...
do l=1,nb
y(l,i,j,k)=0.0d0
do m=1,nb
y(l,i,j,k)=y(l,i,j,k)+
1 a(l,m,i,j,k)*x(m,i,j,k)+
2
--- Comment #10 from tromey at gcc dot gnu dot org 2008-04-22 15:24 ---
I think this should be fixable now that mapped locations have gone in.
The key is to have c_lex_with_flags return a value for in_system_header
which comes from the token's "original" location, not the macro expansion
testcase
#include
struct foo
{
virtual void bar(){ }
int foo::*baz;
};
int main()
{
foo* x = new foo();
assert (x->baz == foo().baz);
}
result
$ g++43 bug.cpp -o bag; ./bug
assertion "x->baz == foo().baz" failed: file "bug.cpp", line 11
--
Summary: Wrong initialization in
The program below aborts at runtime when compiled by gcc 4.3.0 with option "-O2
-std=c99" (it runs correctly without optimization or when compiled with "icc
-std=c99 -restrict"). I believe it should have defined behavior according to
the standard (see e.g. PR14192), for p[0] and q[0] are not restr
gcc produces broken function entry code when building code with incomplete
prototypes, and -mregparm=3.
The following test case illustrates the problem ...
extern int printf (const char *, ...) __attribute__ ((regparm(0)));
static int test();
int main(int argc, char **argv) {
test(0,1,2,3,4,
/* { dg-do run } */
/* { dg-options "-O0" } */
/* { dg-options "-O0 -mregparm=3" { target { { i?86-*-* x86_64-*-* } && ilp32 }
} } */
static int test ();
int
main (void)
{
test (0, 1, 2, 3, 4, 5, 6, 7);
return 0;
}
static int
test (int a, int b, int c, int d, int e, int f, int g, int h)
{
--- Comment #1 from jakub at gcc dot gnu dot org 2008-04-22 16:15 ---
*** This bug has been marked as a duplicate of 36015 ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from jakub at gcc dot gnu dot org 2008-04-22 16:15 ---
*** Bug 36014 has been marked as a duplicate of this bug. ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from ubizjak at gmail dot com 2008-04-22 16:43 ---
(In reply to comment #2)
> Well, this bug needs proper analysis and a testcase, but yes, I also see this
> slowdown.
Richi, the only difference in generated code is by backing out your patch [1]
[1] http://gcc.gnu.org/vi
--- Comment #4 from ubizjak at gmail dot com 2008-04-22 16:51 ---
Confirmed also on core2:
benchmarked with patch:
22 Apr 2008 18:47:04 gfortran - Compile nf
command=gfortran -march=opteron -ffast-math -funroll-loops -ftree-loop-linear
-ftree-vectorize -msse3 -O3 nf.s -o nf
22 Apr 200
--- Comment #3 from xavier at tddft dot org 2008-04-22 17:16 ---
The code comes from spglib, a library to calculate symmetry groups from
crystals, so it is quite complex. The problem is that I didn't wrote it I don't
understand it enough to be able to produce a small self-contained test
--- Comment #5 from janis at gcc dot gnu dot org 2008-04-22 17:21 ---
Subject: Bug 35981
Author: janis
Date: Tue Apr 22 17:20:40 2008
New Revision: 134562
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134562
Log:
2008-04-22 Kris Van Hees <[EMAIL PROTECTED]>
PR testsui
Hello!
In my opinion the g++ compiler has a problem with for-loop scoping. (Please
see attached code snipplet.) The output of the program is:
+++ For Loop +++
Constructor of LoopMe with=98
Destructor of LoopMe with=98
LoopMe op+= called
I'm invalid and destroyed already
Constructor of
--- Comment #1 from gnu4u at flonatel dot org 2008-04-22 17:29 ---
Created an attachment (id=15511)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15511&action=view)
Source to reproduce the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36016
--- Comment #56 from Ralf dot Wildenhues at gmx dot de 2008-04-22 17:51
---
Subject: Re: [4.3/4.4 Regression]: Combined gcc +
binutils source tree doesn't bootstrap with --enable-shared
* bonzini at gnu dot org wrote on Tue, Apr 22, 2008 at 08:27:07AM CEST:
> > So I'm not yet
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-04-22 18:14 ---
(In reply to comment #3)
> [1] http://gcc.gnu.org/viewcvs?view=rev&revision=129796
It was a correctness fix, which usually will slow down generated code. :)
So you have to look at the difference to make sure that t
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-04-22 18:43 ---
$ gfortran ga4076.f90
$ ./a.out
1 100 T
2 101 F
3 1 T
4 52 F
$ gfortran-4.2 ga4076.f90
$ ./a.out
1 100 T
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-04-22 18:46 ---
A regression (well, sort of; 4.2 failed with the bogus
error message, but at least it didn't generate wrong code):
$ gfortran-4.2 foo.f90
$ ./a.out
Fortran runtime error: rank of return array does not equal 1
--
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-04-22 18:48 ---
Not a regression, 4.1 through 4.4 all fail.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35995
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-04-22 18:50 ---
Not a regression, 4.1 and 4.2 fail with the equally bogus
error message
a.out:
../../../../../gcc/branches/gcc-4_1-branch/libgfortran/generated/matmul_r4.c:152:
matmul_r4: Assertion `count == b->dim[0].ubound + 1 -
--- Comment #3 from tkoenig at gcc dot gnu dot org 2008-04-22 18:57 ---
This one is seriously strange.
It depends on the mask argument being a compile-time constant.
Apparently, simplification goes down a wrong path somewhere.
Looking at the
$ cat try.f90
program GA4076
! fails
extern double sqrt (double);
extern void abort (void);
__attribute__((noinline)) double
foo (double a)
{
double b, c, d = 0.7;
if (a <= d)
b = sqrt (d * a);
else
{
c = (1.0 - d) * (1.0 - a);
b = c > 0 ? 1.0 - sqrt (c) : 1.0;
}
return b;
}
int
main (void)
{
double
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|--- |4.3.1
http://gcc.g
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35993
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35994
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36015
--- Comment #1 from jakub at gcc dot gnu dot org 2008-04-22 19:53 ---
4.2 would recreate the call:
/* Wrap the computation of the argument in a SAVE_EXPR, as we may
need to expand the argument again. This way, we will not perform
side-effects more the once. */
--
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
$ powerpc64-linux-gcc -m64 -Wp,-MD,drivers/md/.raid6altivec1.o.d -nostdinc
-isystem
/usr/local/DIR/gcc-powerpc64-4.3-20080417/lib/gcc/powerpc64-linux/4.3.1/include
-D__KERNEL__ -Iinclude -Iinclude2
-I/home/bunk/linux/kernel-2.6/git/linux-2.6/include -include
include/linux/autoconf.h -Iarch/powerpc
--- Comment #1 from bunk at stusta dot de 2008-04-22 20:25 ---
Created an attachment (id=15512)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15512&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36018
--- Comment #2 from bunk at stusta dot de 2008-04-22 20:27 ---
No ICE when trying to compile this kernel with gcc 4.3.0, gcc 4.4 wasn't
tested.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36018
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
If a member template is defined with same template parameter name as the class
name, then this parameter does not hide the class name.
The following code explains the problem:
#include
struct B {
static const int x = 1;
};
struct A {
static const int x = 0;
template
static void f() {
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.3.2 |4.3.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36018
--- Comment #3 from jakub at gcc dot gnu dot org 2008-04-22 22:07 ---
Subject: Bug 35747
Author: jakub
Date: Tue Apr 22 22:06:58 2008
New Revision: 134567
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134567
Log:
PR c++/35747
* semantics.c (finish_stmt_expr): Ca
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-04-22 22:10 ---
if (x->baz != (TARGET_EXPR >>
;>).baz)
I believe there's a dup for this ...
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from jakub at gcc dot gnu dot org 2008-04-22 22:15 ---
Subject: Bug 35747
Author: jakub
Date: Tue Apr 22 22:14:25 2008
New Revision: 134568
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134568
Log:
PR c++/35747
* semantics.c (finish_stmt_expr): Ca
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-04-22 22:17 ---
Confirmed. The tree level gets this right and we expand from
# VUSE
D.1761 = *p;
# SMT.5_9 = VDEF
*D.1761 = 1;
# SMT.5_10 = VDEF
**q = 2;
if (*D.1761 != 2)
and cse1 removes the comparison.
--
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-04-22 22:20 ---
Indeed. It would be interesting to analyze what optimization the folding
enabled
and see if that can be recovered somehow.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34163
--- Comment #5 from jakub at gcc dot gnu dot org 2008-04-22 22:21 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-04-22 22:25 ---
EDG agrees with you.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keyw
Consider this simple loop:
int shift_integer (int value, unsigned int amount)
{
unsigned int i;
for (i=0; ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=36020
--- Comment #4 from pault at gcc dot gnu dot org 2008-04-22 22:34 ---
> Paul, can you maybe shed any light on this?
>
Not for some days, I'm afraid. I'm in China, up to my eyeballs with day-time
work.
It'll be high priority when I get back.
Paul
--
http://gcc.gnu.org/bugzilla/
--- Comment #2 from jakub at gcc dot gnu dot org 2008-04-22 22:34 ---
Subject: Bug 36017
Author: jakub
Date: Tue Apr 22 22:33:48 2008
New Revision: 134569
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134569
Log:
PR rtl-optimization/36017
* builtins.c (expand_er
--- Comment #3 from jakub at gcc dot gnu dot org 2008-04-22 22:37 ---
Subject: Bug 36017
Author: jakub
Date: Tue Apr 22 22:36:27 2008
New Revision: 134570
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134570
Log:
PR rtl-optimization/36017
* builtins.c (expand_er
--- Comment #2 from fang at csl dot cornell dot edu 2008-04-22 22:38
---
PR 32245?
--
fang at csl dot cornell dot edu changed:
What|Removed |Added
CC|
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-04-22 22:40 ---
this is not strength reduction but the reverse operation, final value
calculation.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from jakub at gcc dot gnu dot org 2008-04-22 22:43 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from xavier at tddft dot org 2008-04-22 22:49 ---
Created an attachment (id=15513)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15513&action=view)
Test case, 1st file (no includes)
--
xavier at tddft dot org changed:
What|Removed
--- Comment #5 from xavier at tddft dot org 2008-04-22 22:49 ---
Created an attachment (id=15514)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15514&action=view)
Test case 2nd file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36008
--- Comment #6 from xavier at tddft dot org 2008-04-22 22:51 ---
I have managed to create a test case:
Correct case:
[EMAIL PROTECTED]:~$ gcc-4.3 bravais.c mathfunc.c -O3 -fno-inline
bravais.c: In function âmainâ:
bravais.c:83: warning: incompatible implicit declaration of built-in
--- Comment #2 from n dot pipenbrinck at cubic dot org 2008-04-22 23:10
---
(In reply to comment #1)
> this is not strength reduction but the reverse operation, final value
> calculation.
Ooops. Sorry for that. Should I rename the entry or can we just live with it?
--
http://gcc.g
--- Comment #1 from jason at gcc dot gnu dot org 2008-04-22 23:14 ---
Subject: Bug 35316
Author: jason
Date: Tue Apr 22 23:13:19 2008
New Revision: 134571
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134571
Log:
PR c++/35316
* semantics.c (finish_decltype_type)
--- Comment #2 from jason at gcc dot gnu dot org 2008-04-23 01:46 ---
Subject: Bug 35316
Author: jason
Date: Wed Apr 23 01:45:30 2008
New Revision: 134578
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134578
Log:
PR c++/35316
* semantics.c (finish_decltype_type)
When declaring a function with __attribute__((alloc_size(n))), gcc segfaults if
n exceeds the number of arguments to the function.
--
Summary: Out-of-bounds parameter to alloc_size causes gcc to
segfault
Product: gcc
Version: 4.3.0
--- Comment #1 from df at dfranke dot us 2008-04-23 02:50 ---
Correction: this occurs only when a function takes no arguments but alloc_size
is used.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36021
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-04-23 05:51 ---
Subject: Bug 35988
Author: tkoenig
Date: Wed Apr 23 05:50:54 2008
New Revision: 134579
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134579
Log:
2008-04-23 Thomas Koenig <[EMAIL PROTECTED]>
PR li
--- Comment #3 from tkoenig at gcc dot gnu dot org 2008-04-23 05:53 ---
Fixed on trunk, closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-04-23 05:58 ---
These tests call the library function, so whatever goes
wrong here probably needs to be fixed in the
generated functions as well.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed
With the following foo.cpp sample:
#include
__attribute__((visibility("default"))) void foo() {
int array[] = { 23, 5, -10, 0, 0, 321, 1, 2, 99, 30 };
int elements = sizeof(array) / sizeof(array[0]);
std::sort(array, array + elements);
}
Building with the following command line:
g++-4.3 -
The following code snippet triggers an ICE on the 4.3 branch and mainline:
void foo(int i)
{
(int [i]) { 1 };
}
bug.cc: In function 'void foo(int)':
bug.cc:3: internal compiler error: in tree_low_cst, at tree.c:4879
Please submit a full bug repo
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36023
92 matches
Mail list logo
