--- Comment #9 from ebotcazou at gcc dot gnu dot org 2010-09-14 10:30
---
Reasonable workaround.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2010-09-14 10:30
---
Reasonable workaround.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2010-09-14 10:30
---
Reasonable workaround.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from paolo dot carlini at oracle dot com 2010-09-14 10:46
---
Seems simple
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #8 from jamborm at gcc dot gnu dot org 2010-09-14 11:53 ---
Sorry, I messed up when I tried to remove includes from the testcase. Thanks
for fixing it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45645
--- Comment #2 from jakub at gcc dot gnu dot org 2010-09-14 11:26 ---
Created an attachment (id=21789)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21789action=view)
gcc46-pr45663.patch
A sign extension insn for the first bar call is scheduled before the a.j++
insns
with the
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-09-14
11:40 ---
Subject: Re: All ifunc tests fail on Solaris 2
--- Comment #3 from nathan at codesourcery dot com 2010-09-14 10:23
---
yes, I'm testing a patch that checks the glibc version number -- I'm
--- Comment #3 from pluto at agmk dot net 2010-09-14 12:04 ---
(In reply to comment #1)
It's nothing to do with unordered_map, it's std::string, and it fails because
lazy_string was added in GDB 7.1
we can probably do something like
if (gdb.VERSION == '7.0'):
--- Comment #4 from redi at gcc dot gnu dot org 2010-09-14 12:47 ---
looks sensible, I'll do that
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from Joost dot VandeVondele at pci dot uzh dot ch
2010-09-14 13:07 ---
A slight variation leads to an lto1 ICE:
declaring build eri as: 'extern void (*build_eri)(void);'
leads to:
gcc -c -flto test_c.c ; gfortran -c -flto test.f90 ; rm all.a ; ar -r all.a
test_c.o
Compiler output:
$ gcc file[12].C -flto -nostdlib -r
In file included from :1:0:
file1.C: In member function '__base_ctor ':
file1.C:2:1: error: type mismatch in address expression
void A::T42b (struct A *, void *) *
void A::T431 (struct A *, void *)
D.2073.__pfn = bar;
file1.C:2:1: internal
--- Comment #1 from zsojka at seznam dot cz 2010-09-14 13:22 ---
Created an attachment (id=21790)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21790action=view)
reduced testcase, packed
- header.h -
struct A;
typedef void (A::*Am1) (void *);
typedef void (A::*Am2) ();
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45667
--- Comment #6 from jamborm at gcc dot gnu dot org 2010-09-14 13:55 ---
Jakub, I have not understood whether you think the warning emitted
when compiling the c code from comment #4 has the correct line number
or not. I see it attributed to the line with the return statement
which I
--- Comment #4 from jakub at gcc dot gnu dot org 2010-09-14 14:00 ---
Created an attachment (id=21791)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21791action=view)
gcc46-pr45635.patch
Fix.
--
jakub at gcc dot gnu dot org changed:
What|Removed
--- Comment #19 from rearnsha at gcc dot gnu dot org 2010-09-14 14:05
---
Fixed in all maintained releases.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from ibolton at gcc dot gnu dot org 2010-09-14 14:29 ---
Technically, this is ICE on invalid code, but a more user-friendly error would
be better. As it happens, one has been added to trunk, as of 16th June.
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg01501.html
I
--- Comment #5 from jakub at gcc dot gnu dot org 2010-09-14 14:47 ---
Created an attachment (id=21792)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21792action=view)
gcc46-pr45635.patch
Alternatively, we can avoid computing the address of fn altogether on
--- Comment #3 from jamborm at gcc dot gnu dot org 2010-09-14 15:02 ---
I can reproduce the problem and it does not happen with -fno-ipa-sra = mine.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
As g++ now may, or may not, produce an indirect error on mismatched attributes
between a forward declaration and later definition, and that is incredibly
confusing to the end-user (aka me), i hereby humbly ask for a warning in such
condition; a hint at the problematic declaration would be a plus.
--- Comment #5 from jakub at gcc dot gnu dot org 2010-09-14 15:24 ---
Simplified testcase that ICEs the same way on x86_64-linux (-O3) and i686-linux
(-O3 -msse2):
int s[4];
unsigned char *t[4];
void
foo (void)
{
int i;
for (i = 0; i 4; i++)
{
s[i] = -s[i];
t[i]
--- Comment #23 from vmakarov at redhat dot com 2010-09-14 15:46 ---
(In reply to comment #22)
Fixed everywhere but on 4.3 branch.
Maybe commit the patch there too?
I think there is a smaller probability that this bug occurs in gcc4.3 because
it is based on the old RA. IRA uses
--- Comment #2 from hjl dot tools at gmail dot com 2010-09-14 16:02 ---
It is caused by revision 159939:
http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00996.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #6 from hubicka at gcc dot gnu dot org 2010-09-14 16:13 ---
Created an attachment (id=21793)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21793action=view)
Proposed patch
Hi,
this patch should solve the problem (dive into ADDR_EXPR to get actual
fndecl).I no longer
--- Comment #6 from jakub at gcc dot gnu dot org 2010-09-14 16:18 ---
Created an attachment (id=21794)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21794action=view)
gcc46-pr45633-1.patch
The s[i] = -s[i]; line is also unnecessary in the testcase.
One possible patch attached,
--- Comment #7 from jakub at gcc dot gnu dot org 2010-09-14 16:20 ---
Created an attachment (id=21795)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21795action=view)
gcc46-pr45633-2.patch
Another fix, this one keeps disallowing such MINUS_EXPR. Unfortunately the
generated code
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2010-09-14 16:25
---
Fixing.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Some constructs cause gcc to warn as always causing a buffer overflow
incorrectly. For example, this is a minimalistic version of a warning found in
wine-1.3.2:
--
#include string.h
#include stdlib.h
#include stdint.h
struct T {
union {
struct {
--- Comment #1 from jakub at gcc dot gnu dot org 2010-09-14 17:09 ---
This is intentional, considering this as a flexible array member is already way
too over what should be allowed.
Either use a true flexible array member, or use memcpy instead (which isn't
limited to field boundaries,
--- Comment #8 from jakub at gcc dot gnu dot org 2010-09-14 17:15 ---
I've looked at the combiner with the second patch, but I'm afraid this isn't
fixable in the combiner easily. While combiner is able for i3
(set (reg:V2DI res) (plus:V2DI (reg:V2DI temp) (mem:V2DI (symbol_ref:P t
--- Comment #4 from jamborm at gcc dot gnu dot org 2010-09-14 17:54 ---
The miscompiled file appears to be spxweightst.o, the miscompilation probably
happens when transforming a call to int soplex::DataSetDATA::number(const
soplex::DataKey) const [with DATA = soplex::SVSet::DLPSV]
--
--- Comment #9 from jakub at gcc dot gnu dot org 2010-09-14 18:43 ---
Created an attachment (id=21796)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21796action=view)
gcc46-pr45633-3.patch
Patch that uses TER to expand PLUS_EXPR/POINTER_PLUS_EXPR as MINUS_EXPR if it
is really
--- Comment #8 from laurent at guerby dot net 2010-09-14 19:19 ---
With 4.4.2 as base on gcc57 (and your PR45444 patch) I don't see the comparison
failure:
http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg01282.html
--
laurent at guerby dot net changed:
What|Removed
--- Comment #7 from hjl dot tools at gmail dot com 2010-09-14 19:22 ---
(In reply to comment #6)
Created an attachment (id=21793)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21793action=view) [edit]
Proposed patch
Hi,
this patch should solve the problem (dive into ADDR_EXPR
--- Comment #8 from jakub at gcc dot gnu dot org 2010-09-14 19:25 ---
Could you please also try the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45635#c5 patch? Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45635
--- Comment #9 from mikpe at it dot uu dot se 2010-09-14 19:40 ---
(In reply to comment #8)
With 4.4.2 as base on gcc57 (and your PR45444 patch) I don't see the
comparison
failure:
http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg01282.html
Please try --with-arch=armv5te
Hi,
Given the following test C++ file:
class Class
{
public:
void func();
float *buf;
int size;
};
void Class::func()
{
for (int i = 0; i size; ++i) {
buf[i] = 0;
}
}
4.6 (see below for exact version) will generate larger code (36 vs.
--- Comment #10 from laurent at guerby dot net 2010-09-14 20:04 ---
Ok will do.
Note: arm.c:arm_reload_in_hi() seems to have a few non deterministic calls to
gen_rtx_*, eg:
emit_insn (gen_zero_extendqisi2 (gen_rtx_SUBREG (SImode, operands[0], 0),
--- Comment #3 from pthaugen at gcc dot gnu dot org 2010-09-14 20:04
---
Not sure I understand everything involved here, but isn't the test a little
suspect any time higher optimization levels and instruction scheduling are
enabled?
--
pthaugen at gcc dot gnu dot org changed:
The following testcase demonstrates where reassociation/regrouping of
expressions could result in greater parallelism for processors that have
multiple arithmetic execution units.
int myfunction (int a, int b, int c, int d, int e, int f, int g, int h) {
int ret;
ret = a + b + c + d + e + f +
--- Comment #2 from t7 at gmail dot com 2010-09-14 21:28 ---
(In reply to comment #1)
*** This bug has been marked as a duplicate of 45362 ***
--
t7 at gmail dot com changed:
What|Removed |Added
Bootstrapping revision 164287 on powerpc-apple-darwin9 fails with:
...
/opt/gcc/darwin_buildw/./prev-gcc/xgcc -B/opt/gcc/darwin_buildw/./prev-gcc/
-B/opt/gcc/gcc4.6w/powerpc-apple-darwin9/bin/
-B/opt/gcc/gcc4.6w/powerpc-apple-darwin9/bin/
-B/opt/gcc/gcc4.6w/powerpc-apple-darwin9/lib/ -isystem
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-14 22:34 ---
*** Bug 45666 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45362
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-14 22:34 ---
This is the same issue as PR 45362, PR 45362 has a description of what is
happening though it does show when it happened.
*** This bug has been marked as a duplicate of 45362 ***
--
pinskia at gcc dot gnu dot
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-09-14 22:35 ---
(In reply to comment #2)
http://gcc.gnu.org/bugs/#need
Since this is a bug in the preprocessor it is hard to get a preprocessed source
that causes a bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45362
--- Comment #1 from hjl at gcc dot gnu dot org 2010-09-14 22:41 ---
Subject: Bug 45672
Author: hjl
Date: Tue Sep 14 22:41:03 2010
New Revision: 164289
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164289
Log:
Define TARGET_VECTORIZE_UNITS_PER_SIMD_WORD for rs6000.
2010-09-14
--- Comment #1 from nicola at gcc dot gnu dot org 2010-09-14 22:47 ---
GCC from trunk (will become 4.6.0) refuses to compile
@try/@catch/@throw/@synchronized expressions if -fobjc-exceptions is not used.
Thanks
--
nicola at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from nicola at gcc dot gnu dot org 2010-09-14 22:52 ---
If you want to use dealloc for compatibility with Apple Cocoa / GNUstep Base,
then you also want the warnings that dealloc needs to include a call to [super
dealloc], so I wouldn't change the compiler ;-)
You could
--- Comment #8 from t7 at gmail dot com 2010-09-14 22:55 ---
No idea, what is going on but I saved your testcase.c as pr45230 and it doesn't
produce the ICE, target gcc is x86_64-w64-mingw32.
bash-4.1$ ./xmingw-trunk-w64-sjlj/bin/x86_64-w64-mingw32-gcc -w -Os -lm -m32
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2010-09-14
23:27 ---
ICEs are atill present for both strncmp-1.c and reduced testcase on
x86_64-apple-darwin10 at r164287.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45230
Command line:
$ gcc -O3 -fcompare-debug -march=amdfam10 ada-langn.i
or
$ gcc -O2 -fcompare-debug -finline-functions -fipa-cp-clone
-fkeep-inline-functions ada-langn.i
(I am not able to reproduce it with these flags anymore)
or
$ gcc -O1 -fgcse -finline-small-functions -foptimize-sibling-calls
--- Comment #1 from zsojka at seznam dot cz 2010-09-14 23:43 ---
Created an attachment (id=21797)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21797action=view)
testcase, preprocessed ada-lang.c from GDB (licensed under GPLv2)
Reducing is very slow, after 4 hours of delta run I
The testcase below leads to the following linker error on current trunk, gcc
4.5.0 and gcc 4.5.1:
$gfortran fails.f90
/tmp/ccG09ce7.o: In function `__fails_test_MOD_bar':
fails.f90:(.text+0xe): undefined reference to `vtab$b_t.1500'
collect2: ld returned 1 exit status
The patch at the end of the
--- Comment #13 from zsojka at seznam dot cz 2010-09-15 00:05 ---
It seems all the testsuite failures caused by -fno-ira-share-spill-slots and
gone now, good!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40386
--- Comment #10 from t7 at gmail dot com 2010-09-15 00:17 ---
(In reply to comment #9)
ICEs are atill present for both strncmp-1.c and reduced testcase on
x86_64-apple-darwin10 at r164287.
You are right. I was suspicious about the pr45230 having no .c extension in the
file name
--- Comment #11 from t7 at gmail dot com 2010-09-15 00:23 ---
FYI, I applied these to gcc-trunk for testing purposes.
[PATCH 1/6] Factor out is_gimple_reg calls.
[PATCH 2/6] A function is affine when CHREC_RIGHT is invariant.
[PATCH 3/6] Fix chrec_contains_symbols_defined_in_loop.
--- Comment #9 from hjl dot tools at gmail dot com 2010-09-15 04:09 ---
(In reply to comment #5)
Created an attachment (id=21792)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21792action=view) [edit]
gcc46-pr45635.patch
Alternatively, we can avoid computing the address of fn
--- Comment #1 from hjl dot tools at gmail dot com 2010-09-15 04:29 ---
*** This bug has been marked as a duplicate of 44382 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #6 from hjl dot tools at gmail dot com 2010-09-15 04:29 ---
*** Bug 45671 has been marked as a duplicate of this bug. ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #10 from tkoenig at gcc dot gnu dot org 2010-09-15 05:01
---
One point:
As far as I can see, you are calling compute_spt_call on functions in
'naked' expressions, as in
a = f(x)
but you are not following array or substring references, as in
a(f(x)) = g(f(y))
where the
--- Comment #1 from hjl dot tools at gmail dot com 2010-09-15 05:25 ---
It is caused by revision 162618:
http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg00972.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from hjl at gcc dot gnu dot org 2010-09-15 05:37 ---
Subject: Bug 45672
Author: hjl
Date: Wed Sep 15 05:36:47 2010
New Revision: 164296
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164296
Log:
Correct XXX_units_per_simd_word return type.
2010-09-14 H.J. Lu
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2010-09-15 05:38
---
It is caused by revision 162618:
http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg00972.html
No, it isn't, this commit reverted an incorrect change done in revision 161907.
--
ebotcazou at gcc dot gnu dot org
On Linux/x86, revision 164252:
http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg00546.html
caused:
FAIL: gcc.dg/guality/sra-1.c -O2 line 42 a.j == 14
FAIL: gcc.dg/guality/sra-1.c -O2 -flto line 42 a.j == 14
FAIL: gcc.dg/guality/sra-1.c -O2 -fwhopr line 42 a.j == 14
FAIL: gcc.dg/guality/sra-1.c
Consider
program main
integer :: a(100), b(100), c(100)
a = 2
do i=1,10
b = a
c = 1/b
print *,c
end do
end program main
The statements
b = a
c = 1/b
could be moved out of the loop. (The second one still has the
problem that we currently don't know that print doesn't
--- Comment #1 from hjl dot tools at gmail dot com 2010-09-15 05:45 ---
*** This bug has been marked as a duplicate of 45663 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #4 from hjl dot tools at gmail dot com 2010-09-15 05:45 ---
*** Bug 45675 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45663
101 - 167 of 167 matches
Mail list logo
