--- Comment #11 from bonzini at gnu dot org 2009-02-01 08:07 ---
still present.
--
bonzini at gnu dot org changed:
What|Removed |Added
Last reconfirmed|2008-03-25
--- Comment #48 from bonzini at gnu dot org 2009-02-01 08:14 ---
Fixed on the trunk with the original testcase:
4.2 -O2 0m13.897s
4.2 -O3 miscompiled
4.4 -O2/-O3 0m8.714s
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #2 from alexey dot veselovsky at gmail dot com 2009-02-01
09:17 ---
I think it should be error, not warning. (comeau and ms vc claims it as error)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39045
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39055
--- Comment #7 from dominiq at lps dot ens dot fr 2009-02-01 10:37 ---
Created an attachment (id=17220)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17220action=view)
testin complex matrix multiplication
Comment #0 is not fully accurate. With some more testsing with the
attached
The following invalid code snippet triggers an ICE since at least GCC 2.95.3
(with the exception of 3.3.[2-6] where the code is wrongly accepted):
struct A
{
templateint void foo();
};
templateint struct B
{
friend void A::foo0(int = 0);
};
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.3.4 |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33604
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-01 10:57 ---
Better split this. P2 for the trunk non-error recovery one. For the rest
WONTFIX.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
The following (IMHO valid) code snippet triggers an ICE since GCC 4.3.0
when compiled with -O:
double foo()
{
double x;
asm( : =r,r(x) : 0,0(x));
return x;
}
bug.c: In function 'foo':
bug.c:5: internal
--- Comment #9 from dominiq at lps dot ens dot fr 2009-02-01 10:58 ---
Did you try enabling SSE3 btw?
No. How do I get the enabled SSE* by default?
Can you post the ifort assembly of the loop?
L_B1.14:# Preds L_B1.14 L_B1.13
lea (%rsi,%r9,8),
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to work||3.2.3
Priority|P3 |P2
The following (IMHO valid) testcase triggers an ICE since GCC 4.3.0
(when fixed-point types were introduced):
void foo()
{
asm( : : r(0r));
}
bug.c: In function 'foo':
--- Comment #11 from patriciak784-gccmainling at yahoo dot de 2009-02-01
11:44 ---
I am sorry that I was a bit unclear - 4.0.0 @ 95634 works for PR20239 but
doesn't for this problem.
But the patch from PR20239 fixed both problems on 3.4.4, so both bugs are no
duplicates, sorry.
--
This used to work in 4.3, but doesn't on trunk:
$ gnatchop /opt/cfarm/src/trunk/gcc/testsuite/ada/acats/support/repbody.ada
$ gnatchop /opt/cfarm/src/trunk/gcc/testsuite/ada/acats/support/repspec.ada
$ gnatchop /opt/cfarm/src/trunk/gcc/testsuite/ada/acats/tests/c4/c4a013a.ada
$ gnatmake -f -g
--- Comment #4 from laurent at guerby dot net 2009-02-01 13:47 ---
With -mieee they indeed pass.
Was the default changed for 4.4?
--
laurent at guerby dot net changed:
What|Removed |Added
--- Comment #3 from ubizjak at gmail dot com 2009-02-01 12:22 ---
(In reply to comment #0)
This problem also cause FAIL in the same way for:
c456001 c45624a c45624b c4a013a cxa5a03 cxg2002 cxg2017 cxg2020
These should probably be compiled with -mieee. Can you try to compile using
--- Comment #1 from laurent at guerby dot net 2009-02-01 11:59 ---
Forgot to add version:
$ gcc -v
Using built-in specs.
Target: alphaev56-unknown-linux-gnu
Configured with: /opt/cfarm/src/trunk/configure
--prefix=/n/30/guerby/install-trunk-143742 --enable-languages=c,ada
--- Comment #3 from falk at debian dot org 2009-02-01 10:50 ---
The main problem is that just replacing the code by the below loop won't
necessarily give a speedup. strlen is usually implemented in highly efficient
and platform-specific assembly that treats several bytes at a time. I
The following invalid code snippet triggers an ICE on the trunk:
==
__complex__ int i({0});
==
bug.cc:1: internal compiler error: in process_init_constructor, at
cp/typeck2.c:1192
Please submit a full bug report, [etc.]
The bug appeared
--- Comment #10 from rguenther at suse dot de 2009-02-01 11:11 ---
Subject: Re: Complex matrix product is not
vectorized
On Sun, 1 Feb 2009, dominiq at lps dot ens dot fr wrote:
--- Comment #9 from dominiq at lps dot ens dot fr 2009-02-01 10:58
---
Did you try enabling
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39054
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-02-01 10:40
---
New SRA should fix this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39061
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
GCC host triplet|alpha-unknown-linux-gnu |
GCC target triplet|
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39060
--- Comment #2 from laurent at guerby dot net 2009-02-01 12:00 ---
Testresults: http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00058.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39061
The following invalid code snippet triggers an ICE since GCC 4.3.4
(so we have a regression on the 4.3 branch):
==
struct A {};
templatetypename void foo()
{
A().~int();
}
==
bug.cc: In function 'void foo()':
bug.cc:5: error: expected
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39054
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|--- |4.4.0
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39053
--- Comment #41 from rguenth at gcc dot gnu dot org 2009-02-01 11:08
---
Ok, let's say then comparing -O[23s] compile-times is unfair as we never
stated they are optimized for compile-time but they explicitly contain passes
that may usually _not_ help. -O1 may be a different story,
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39059
--- Comment #10 from patriciak784-gccmainling at yahoo dot de 2009-02-01
11:22 ---
(In reply to comment #6)
read_original_filename lexes a token, which hits EOF, which
causes the buffer to be popped.
This is sort of an odd scenario.
Perhaps working around it in
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39060
The following invalid code snippet triggers an ICE since GCC 4.1.1:
===
void foo() =
===
On the trunk I get:
bug.cc:1: internal compiler error: in cp_lexer_consume_token, at
cp/parser.c:637
Please submit a full bug report, [etc.]
Before this was only an error-recovery
--- Comment #2 from tkoenig at gcc dot gnu dot org 2009-02-01 15:53 ---
(In reply to comment #1)
I don't think trying to solve this particular case is useful.
In order to extend the -finit- - options for gfortran to
allocatable arrays, I was thinking of adding an assignment
statement
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-01 11:02 ---
Loop fusion by GRAPHITE may be able to do this in the future (as a
side-effect).
I don't think trying to solve this particular case is useful.
--
rguenth at gcc dot gnu dot org changed:
What
--- Comment #2 from paolo dot carlini at oracle dot com 2009-02-01 16:22
---
On it.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39059
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-02-01 13:25 ---
3.3.6 and 3.4.1 accept it, starting with 3.4.2 we reject it and since 4.2.0 we
ICE.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
The following invalid testcase triggers an ICE on the trunk:
struct A
{
A(void* i=);
A(void* i=);
A(void* i=);
void operator+ (void* i=);
virtual void foo1(=);
void foo2(=);
void foo3(=);
void foo4(=);
void foo5(=);
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39056
The following valid code snippet triggers an ICE since GCC 3.4.0:
==
templateint struct A
{
int i;
A() { void foo(int=i); }
};
A0 a;
==
bug.cc: In function 'void foo(int) [with int anonymous = 0]':
bug.cc:4: instantiated from
--- Comment #1 from reichelt at gcc dot gnu dot org 2009-02-01 11:03
---
A slightly more complex testcase crashes in a different place:
double foo()
{
double x, y;
asm( : =r,r(x), =r,r(y) : %0,0(x), r,r(0));
return x;
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-02-01 10:49 ---
This is somewhat expected. We vectorize the complex product using vectors
of real parts and vectors of complex parts of two complex numbers (so we
are not using the fancy haddsub SSE codes). Did you try enabling
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39056
libssp only checks for alloca.h header for alloca(), but mingw headers
define it in malloc.h. this results in the following warning:
../../../gcc-svn/libssp/ssp.c: In function 'fail':
../../../gcc-svn/libssp/ssp.c:109: warning: implicit declaration of function
'alloca'
--- Comment #1 from sezeroz at gmail dot com 2009-02-01 16:47 ---
Created an attachment (id=17221)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17221action=view)
libssp alloca patch for mingw
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39062
in windows replacement of mprotect() in libgcc2.c uses VirtualProtect
which requires an unsigned, not a signed ptr as its last argument. the
attached patch fixes a 'may be used uninitialized' warning, too.
here are the warnings:
../../../gcc-svn/libgcc/../gcc/libgcc2.c: In function 'mprotect':
md5.h of libiberty assumes unsigned long to be of equal size to the size
of a pointer, but that isn't true for all sys tems (ie. win64). this patch
is a workaround for that, probably ugly, but md5.h should include stdint.h
not for _LIBC only.. here is the generated warning:
--- Comment #1 from sezeroz at gmail dot com 2009-02-01 16:57 ---
Created an attachment (id=17223)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17223action=view)
libiberty md5.h win64 patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39064
in function hash_pointer(), libiberty/hashtab.c casts its pointer argument
to long, probably with the assumption that long is 64 bits on all 64 bit
systems, which isn't true for win64. it must cast to intptr_t, instead.
here is the warning:
../../../gcc-svn/libiberty/hashtab.c: In function
--- Comment #1 from sezeroz at gmail dot com 2009-02-01 17:00 ---
Created an attachment (id=17224)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17224action=view)
libiberty hashtab.c intptr_t fix
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39065
DO_GLOBAL_CTORS_BODY casts __CTOR_LIST__[0] to unsigned long, probably
with the assumption that long is 64 bits on all 64 bit systems, which
isn't true for win64. it must cast to uintptr_t, instead. here is the
warning:
../../../gcc-svn/libgcc/../gcc/libgcc2.c: In function '__do_global_ctors':
--- Comment #1 from sezeroz at gmail dot com 2009-02-01 17:03 ---
Created an attachment (id=17225)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17225action=view)
DO_GLOBAL_CTORS_BODY win64 uintptr_t fix
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39066
--- Comment #1 from sezeroz at gmail dot com 2009-02-01 16:53 ---
Created an attachment (id=17222)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17222action=view)
mprotect warnings fix
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39063
Consider this simple class:
class TV
{
private:
float truth;
float confidence;
public:
TV(float, float);
float getT(void);
};
extern TV my_tv_maker(float tr);
float my_subr(float tr)
{
TV tv = my_tv_maker(434.23);
return tv.getT();
}
On powerPC, when
gcc -march=core2 -O3 -ftree-vectorizer-verbose=6
for this code:
#define SIZE 1
signed short a[SIZE];
signed short b[SIZE];
signed short c[SIZE];
void add()
{
int i;
for (i = 0; i SIZE; ++i)
a[i] = b[i] + c[i];
}
cannot vectorize the loop:
add_sshort.c:9: note:
gcc -march=core2 -O3 -ftree-vectorizer-verbose=6
for this code:
#define SIZE 1
signed short a[SIZE];
signed short b[SIZE];
signed short c[SIZE];
void add()
{
int i;
for (i = 0; i SIZE; ++i)
a[i] = b[i] + c[i];
}
cannot vectorize the loop:
add_sshort.c:9: note:
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-01 20:50 ---
*** This bug has been marked as a duplicate of 39068 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-01 20:50 ---
*** Bug 39069 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39068
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Keywords|
--- Comment #2 from dorit at gcc dot gnu dot org 2009-02-01 21:06 ---
(reminds me of a couple missed-optimization PRs where vectorization is also
failing due to casts - PR31873 , PR26128 - don't know if this is related)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39068
$ cat test.cpp
templatetypename X struct junk {
templatetypename Y static Y y();
templatetypename Y char test(typeof(yY().foo())*);
static int const value=sizeof(testX(0));
};
int function() { int const v=junkint::value; };
$ g++ -c -v test.cpp
Using built-in specs.
Target:
--- Comment #14 from rguenth at gcc dot gnu dot org 2009-02-01 21:34
---
Hm, on the alias-improvements branch I now XPASS the not return 1 check, but -
why do you think we should have two dereferences to *p?
Hm, because:
# VUSE .MEM_6(D)
a = *p;
# .MEM_7 = VDEF .MEM_6(D)
*0B
From:
http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00069.html
FAIL: gcc.dg/pch/common-1.c -O0 -g -I. (test for excess errors)
FAIL: gcc.dg/pch/common-1.c -O0 -g assembly comparison
FAIL: gcc.dg/pch/common-1.c -O0 -I. (test for excess errors)
...
Executing on host:
--- Comment #15 from rguenth at gcc dot gnu dot org 2009-02-01 22:02
---
Err, that last comment probably didn't make much sense. I wanted to say I see
# VUSE .MEM_6(D)
a = *p;
# .MEM_7 = VDEF .MEM_6(D)
*0B = 5;
return *p == a;
so the pattern for two = *p does not match.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|--- |4.4.0
This might end up at won't fix. I don't know whether the program is invalid
(I wouldn't wonder if it were).
Using ifort 11.1, openf95, sunf95, pathf95 and pgif95 the attached program
shows as last logical value F.
Using NAG f95, g95 and gfortran, it aborts while reading the last logical.
(g77
--- Comment #1 from burnus at gcc dot gnu dot org 2009-02-01 23:09 ---
Created an attachment (id=17226)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17226action=view)
Test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39072
--- Comment #2 from burnus at gcc dot gnu dot org 2009-02-01 23:18 ---
If one reads an integer (i1) instead of a logical variable (l1),
gfortran/g95/f95 read a 0.
* * *
10.6.2 Logical editing makes it quite explicit that it is invalid:
The input field consists of optional blanks,
--- Comment #3 from paolo at gcc dot gnu dot org 2009-02-02 00:42 ---
Subject: Bug 39053
Author: paolo
Date: Mon Feb 2 00:41:52 2009
New Revision: 143861
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143861
Log:
/cp
2009-02-01 Paolo Carlini paolo.carl...@oracle.com
--- Comment #4 from paolo dot carlini at oracle dot com 2009-02-02 00:43
---
Fixed for 4.4.0.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #3 from paolo dot carlini at oracle dot com 2009-02-02 01:58
---
Mine.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #3 from bje at gcc dot gnu dot org 2009-02-02 02:35 ---
Thanks for expanding the test case, Janis. I think this is worthy of a test
case in the regression testsuite, which I will submit now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39034
--- Comment #3 from ghazi at gcc dot gnu dot org 2009-02-02 03:49 ---
Patch posted here:
http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00050.html
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from mmitchel at gcc dot gnu dot org 2009-02-02 06:41
---
Yes, designated initializers are of course a GNU extension to C++. I'm
surprised that icc accepts them in its strict mode.
In GNU C++, it makes sense for us to accept the same extensions that are
accepted in GNU
--- Comment #16 from mark at codesourcery dot com 2009-02-02 07:15 ---
Subject: Re: [4.4 regression] Unexplained 'anonymous' is
used uninitialized in this function warning in cc1plus -m64
rguenther at suse dot de wrote:
Ok. But, as opposed to inheritance, inserting empty members
78 matches
Mail list logo
