--- Comment #3 from jiez at gcc dot gnu dot org 2010-03-23 08:55 ---
My patch for this bug:
http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01039.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42556
--- Comment #6 from dodji at gcc dot gnu dot org 2010-03-23 09:33 ---
Created an attachment (id=20167)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20167&action=view)
Draft patch
This draft patch emits a DW_AT_GNU_default_value_unrepresentable attribute flag
when the default argu
make[3]: Entering directory
`/root/src/GNU/unmodified_gnu/gcc-4.4.3/i686-pc-linux-gnu/libgfortran'
if /bin/sh ./libtool --tag=CC --mode=compile
/root/src/GNU/unmodified_gnu/gcc-4.4.3/host-i686-pc-linux-gnu/gcc/xgcc
-B/root/src/GNU/unmodified_gnu/gcc-4.4.3/host-i686-pc-linux-gnu/gcc/
-B/usr/local/i6
--- Comment #14 from dodji at gcc dot gnu dot org 2010-03-23 09:54 ---
Not working on this atm.
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
Assig
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-03-23 10:17 ---
For which target? What internal error?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-03-23 10:24 ---
We need a testcase to reproduce the bug (preprocessed source). You also
might want to try removing -mcmodel=large (you really shouldn't need that).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43477
--- Comment #1 from jakub at gcc dot gnu dot org 2010-03-23 10:49 ---
That's a bug in your glibc headers, not in gcc. Just use newer glibc.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--
sin(x) (and sinf(x)) *used* to work accurately on earlier gcc versions, e.g.
gcc 3.4.6 20060404 (Red Hat 3.4.6-9) ON x86_64-redhat-linux
gcc 4.2.1 on Macintosh
OR
cross compiling for ARM Cortex-A8 with gcc version 4.3.2
BUT sin(x) becomes progressively more inaccurate with increasing
--- Comment #1 from simon dot fenney at imgtec dot com 2010-03-23 12:06
---
Created an attachment (id=20168)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20168&action=view)
Trivial test program that outputs sin(x) and sinf(x) for various vals VS
expected results
I haven't added
--- Comment #2 from pluto at agmk dot net 2010-03-23 12:08 ---
duplicate of PR43405.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43490
--- Comment #2 from tydeman at tybor dot com 2010-03-23 12:08 ---
Host and target info:
CPU: Intel Pentium 4
OS: Linux
Fedora Core 10 with gcc 4.3.2
Fedora Core 11 with gcc 4.4.1
Fedora Core 12 with gcc 4.4.3
Command line options: CFLAGS="-std=gnu99 -pedantic -H -fno-builtin
-froun
--- Comment #3 from simon dot fenney at imgtec dot com 2010-03-23 12:20
---
(In reply to comment #2)
> duplicate of PR43405.
>
It's doesn't seem to be the same. I just tried the test source from 43405 and
on the old system (gcc 3.4.6) (which I assumed was working) got:
doubl
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-03-23 12:30 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #8 from ktietz at gcc dot gnu dot org 2010-03-23 12:32 ---
(In reply to comment #7)
> An updated patch is at
>
> http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00937.html
>
Patch is fine. It is absolutely necessary to support gcc's intrinsic headers
for mingw. The fixinclude
--- Comment #4 from dominiq at lps dot ens dot fr 2010-03-23 13:00 ---
> BUT sin(x) becomes progressively more inaccurate with increasing magnitude of
> x, as with the above version (on x86). At a guess, it would seem like
> something
> has broken the "range reduction" maths.
Since p
--- Comment #20 from manu at gcc dot gnu dot org 2010-03-23 13:05 ---
(In reply to comment #19)
>
> I wanted to record my unfinished patch to track macro expansion locations,
> and this bug seemed like an appropriate place.
What is missing from this patch? Is it only the macro location
--- Comment #5 from simon dot fenney at imgtec dot com 2010-03-23 13:10
---
(In reply to comment #4)
> > BUT sin(x) becomes progressively more inaccurate with increasing magnitude
> > of
> > x, as with the above version (on x86). At a guess, it would seem like
> > something
> > has br
--- Comment #6 from pluto at agmk dot net 2010-03-23 13:17 ---
(In reply to comment #3)
> (In reply to comment #2)
> > duplicate of PR43405.
> Using maple and computing the result to 30 decimal places, I get
> -.852200849767188801772705893753
> so it looks like there is
--- Comment #4 from rearnsha at gcc dot gnu dot org 2010-03-23 13:18
---
This second example clearly has nothing to do with the stated bug report
summary line (there's no "m" constraint anywhere in the test case), and you
make no attempt to explain what you think is wrong. Please see t
--- Comment #1 from rearnsha at gcc dot gnu dot org 2010-03-23 13:21
---
You haven't explained what you think is wrong, and you haven't even said what
options you used to generated the code.
If the optimizer is not on the generated code *will* be very poor. That's why
we have an optim
--- Comment #9 from hjl at gcc dot gnu dot org 2010-03-23 13:24 ---
Subject: Bug 40722
Author: hjl
Date: Tue Mar 23 13:24:37 2010
New Revision: 157665
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157665
Log:
Fix stdlib.h for mingw.
2010-03-23 H.J. Lu
PR target/407
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-03-23 13:28 ---
This is a glibc problem. Confirmed by LD_PRELOADing a different libm which
makes it work.
Please report to glibc bugzilla instead.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #8 from simon dot fenney at imgtec dot com 2010-03-23 13:37
---
(In reply to comment #6)
> you can test two different implementations:
> 1). '-O2 -m32 -fno-builtin' - force libm.so calls and test libc
> implementation.
> 2). '-O2 -m32' to test gcc compile-time evaluation.
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-03-23 13:37
---
Unassinging Andrew. Raising priority to P2.
At -O2 we now optimize main () to
main ()
{
:
# DEBUG a => 2
# DEBUG b => 3
# DEBUG c => 4
# DEBUG a => 3
# DEBUG b => 4
[t.c : 13:22] printf ([t.c : 13] &
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-03-23 13:39 ---
CCing mips maintainer
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-03-23 13:39 ---
David?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43385
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-03-23 13:41 ---
Not exactly a primary or secondary target. CCing maintainer.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Component|rtl-optimization|target
Priority|P3 |P1
http://gc
--- Comment #5 from mirq-gccboogs at rere dot qmqm dot pl 2010-03-23 14:04
---
The problem is that gcc sometimes emits instructions that are copying the
global r4 (even when it's marked as const) into temporary. Originally I thought
that the simplies case was this asm statememt, but it
--- Comment #5 from tschwinge at gcc dot gnu dot org 2010-03-23 14:14
---
Also got hit by this.
--
tschwinge at gcc dot gnu dot org changed:
What|Removed |Added
gcc sometimes allocates a temporary register for a variable that is global and
has a fixed register. This happens when:
a. the global is a register-fixed variable
b. global is a pointer to structure
c. an address of structure's field is passed as argument to inlined function
d. the global is ma
--- Comment #2 from mirq-gccboogs at rere dot qmqm dot pl 2010-03-23 14:37
---
Sorry, I try to split encountered problems into simple testcases and after a
few I forgot to add the common things to bugreports.
The difference between ma() and mb() in the example is a global's size:
ma()
--- Comment #6 from meissner at gcc dot gnu dot org 2010-03-23 15:10
---
The rs6000 change on 2010-03-17 is the culprit. If I do a svn update for the
sandbox, and then do:
$ svn update -r157529 gcc/config/rs6000
There is no error.
--
meissner at gcc dot gnu dot org changed:
--- Comment #21 from tromey at gcc dot gnu dot org 2010-03-23 15:19 ---
> What is missing from this patch? Is it only the macro location tracked or the
> parameter expanded within the macro?
The biggest problem with the patch is that I didn't finish debugging it.
It causes regressions
--- Comment #12 from jakub at gcc dot gnu dot org 2010-03-23 15:22 ---
Thus we are talking about:
extern int printf (const char *, ...);
__attribute__((noinline))
int add2 (int a, int b)
{
return a + b;
}
static inline int add3 (int a, int b, int c)
{
return a + add2 (b, c);
}
int
--- Comment #13 from jakub at gcc dot gnu dot org 2010-03-23 15:56 ---
Created an attachment (id=20169)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20169&action=view)
gcc45-pr19192.patch
Untested fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19192
--- Comment #7 from meissner at gcc dot gnu dot org 2010-03-23 16:10
---
I forgot Peter was on vacation. I'll take it.
--
meissner at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from tromey at gcc dot gnu dot org 2010-03-23 16:11 ---
In the case where the default value is an expression,
would it be possible to just emit the expression as a string?
I believe that would be sufficient for gdb's purposes.
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #14 from matz at gcc dot gnu dot org 2010-03-23 16:16 ---
Simply replace the recursive call to expand_expr_real_1 with a call to
expand_expr_real. That's the wrapper setting locations.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19192
--- Comment #15 from jakub at gcc dot gnu dot org 2010-03-23 16:17 ---
Created an attachment (id=20170)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20170&action=view)
gcc45-pr19192.patch
Updated patch that also fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43479#c1
testcase.
--- Comment #16 from jakub at gcc dot gnu dot org 2010-03-23 16:19 ---
Actually it is not, it restores neither curr_insn_block or
curr_insn_source_location.
Perhaps the fix would be to fix that function though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19192
--- Comment #3 from aflyhorse at foxmail dot com 2010-03-23 16:30 ---
(In reply to comment #2)
> We need a testcase to reproduce the bug (preprocessed source). You also
> might want to try removing -mcmodel=large (you really shouldn't need that).
I've tryed to remove all newly added op
--- Comment #17 from jakub at gcc dot gnu dot org 2010-03-23 16:37 ---
Created an attachment (id=20171)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20171&action=view)
gcc45-pr19192.patch
Patch that does that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19192
--- Comment #18 from matz at gcc dot gnu dot org 2010-03-23 16:46 ---
It should mostly not matter anymore as expand_expr_real_[12] and friends use
an explicit location parameter, stored away before expanding operands.
But to be safe, yes, expand_expr_real() should instead also restore
th
Hi,
The attached code produces the subject error.
[sfili...@donald bug14]$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/gnudev/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../fortran-dev/configure
--- Comment #1 from sfilippone at uniroma2 dot it 2010-03-23 17:10 ---
Created an attachment (id=20172)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20172&action=view)
test case
If I switch the comments on lines 27-28 the code compiles, i.e. it is the
GENERIC interface that is no
--- Comment #3 from jakub at gcc dot gnu dot org 2010-03-23 17:24 ---
Created an attachment (id=20173)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20173&action=view)
gcc45-pr43479-test.patch
This testcase is fixed on x86_64-linux by the PR19192 proposed patch (second or
third).
See following code snippet; when the MY_THROW macro is changed to
do { throw ::my_error( MeSSaGe ); } while( 1 )
then I get the expected result, i.e. invocation of the executable prints "error
foo" and returns 1 to the shell... This is on an i7 iMac with Mac OS X 10.6.2
with 64bit Kernel and curr
When running the testsuite on ia64-unknown-linux-gnu with extra passes
containing -fpic/-fPIC I get the following additional error on the 4.4 branch:
FAIL: gcc.c-torture/execute/vector-2.c execution, -O2
FAIL: gcc.c-torture/execute/vector-2.c execution, -Os
on 4.5 trunk I get:
FAIL: gcc.c-tort
--- Comment #9 from law at redhat dot com 2010-03-23 17:36 ---
Subject: Re: Powerpc generates worse code for
-mvsx on gromacs even though there are no VSX instructions used
On 03/22/10 16:20, vmakarov at redhat dot com wrote:
> --- Comment #6 from vmakarov at redhat dot com 2010-
--- Comment #1 from ghazi at gcc dot gnu dot org 2010-03-23 17:36 ---
4.4.4 ia64 results with error:
http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg01631.html
4.5.0 ia64 results with error:
http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg01997.html
--
ghazi at gcc dot gnu dot org
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-23 17:37 ---
Most likely related to PR 43277. I want to say Darwin10's unwinder is broken
...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
When running the testsuite on ia64-unknown-linux-gnu with extra passes
containing -fpic/-fPIC I get the following additional error on the 4.5 trunk:
FAIL: gcc.c-torture/execute/2603-1.c execution, -O2
FAIL: gcc.c-torture/execute/2603-1.c execution, -O3 -fomit-frame-pointer
FAIL: gcc.c-to
--- Comment #4 from jakub at gcc dot gnu dot org 2010-03-23 17:54 ---
It is update_equiv_regs that does this. Will look into it tomorrow.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from sfilippone at uniroma2 dot it 2010-03-23 18:01 ---
Forgot to highlight that this only applies to fortran-dev branch, with a fresh
4.5 build it compiles cleanly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43492
When running the testsuite on powerpc-unknown-linux-gnu with extra passes
containing -fpic/-fPIC I get the following additional error:
FAIL: gcc.target/powerpc/gcse-1.c scan-assembler-times @ha 1
The error happens on the 4.3/4.4 branches and 4.5 trunk:
http://gcc.gnu.org/ml/gcc-testresults/201
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-23 18:20 ---
>I don't speak ppc, so is this expected or is it a GCC bug?
The testcase just needs to be changed for -fPIC/-fpic really, maybe just
skipped.
The @ha means taking the high part of the address for relocations.
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-03-23 18:22 ---
This sounds like an aliasing issue which is only exposed on ia64.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
When running the testsuite on powerpc-unknown-linux-gnu with extra passes
containing -fPIC I get the following additional error on the 4.3 branch:
FAIL: gcc.dg/pch/static-1.c -O0 -g assembly comparison
FAIL: gcc.dg/pch/static-1.c -O0 assembly comparison
FAIL: gcc.dg/pch/static-2.c -O0 -g assembl
--- Comment #1 from ghazi at gcc dot gnu dot org 2010-03-23 18:39 ---
The "-O0" vs "-O0 -g" diffs appear to be the same except for line number
changes. So here is just the "-O0 -g" diffs for both testcases:
line #69
< .LCL1:
> .LCL0:
line #70
< .long .LCTOC1-.LCF1
> .long .
I have compiled various C and C++ source files in attempt to generate async
unwind tables for better stack trace accuracy with asynchronous signals, adding
-fasynchronous-unwind-tables to compile options. I have so far been completely
unable to come up with any example where the option would produc
--- Comment #10 from vmakarov at redhat dot com 2010-03-23 18:45 ---
(In reply to comment #5)
>
> Still I'll investigate a bit more why there are a lot of unexpected spills
> during assignment with -mvsx for the current code.
>
The problem is in that part of VSX_REGS (altivec regs) do
--- Comment #1 from jakub at gcc dot gnu dot org 2010-03-23 18:47 ---
-fasynchronous-unwind-tables is the default on x86_64.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from lat at cern dot ch 2010-03-23 18:52 ---
Created an attachment (id=20174)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20174&action=view)
Random C source file for testing
Random C source file for additional testing. Compile on Linux with and without
-fasynchron
--- Comment #3 from lat at cern dot ch 2010-03-23 18:54 ---
Ah, that would explain it. Does it mean that all omissions and inaccuracies in
unwind information are bugs? Like the lack of unwind info for thunks?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43498
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-03-23 18:56 ---
(In reply to comment #3)
> Ah, that would explain it. Does it mean that all omissions and inaccuracies in
> unwind information are bugs? Like the lack of unwind info for thunks?
yes thunks should have unwind tables
When running the testsuite on powerpc-unknown-linux-gnu with extra passes
containing -fpic I get the following additional error on the 4.3 branch:
Running target unix/-fpic
FAIL: libgomp.fortran/appendix-a/a.22.7.f90 -Os (test for excess errors)
UNRESOLVED: libgomp.fortran/appendix-a/a.22.7.f90
--- Comment #5 from lat at cern dot ch 2010-03-23 18:58 ---
OK, reopening bug then.
--
lat at cern dot ch changed:
What|Removed |Added
Status|RESOLVED
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-23 19:00 ---
>BFD 2.17
Considering this is an old version of binutils, it might be a bug in binutils.
Since this is openmp code, I would not doubt it is related to TLS.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43499
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-03-23 19:02 ---
And most likely fixed by:
http://sourceware.org/ml/binutils/2008-11/msg00240.html :) Which is talking
about TLS and the different models which gets changed by -fPIC.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- Comment #6 from lat at cern dot ch 2010-03-23 19:04 ---
Changing subject to be more descriptive of the actual bug.
--
lat at cern dot ch changed:
What|Removed |Added
--- Comment #1 from ghazi at gcc dot gnu dot org 2010-03-23 19:05 ---
Testcase also fails on powerpc-unknown-linux-gnu with -fpic/-fPIC:
http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg01630.html
--
ghazi at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from zsojka at seznam dot cz 2010-03-23 19:06 ---
I can't reproduce it anymore in r157675 with x86_64, probably fixed by r157573:
http://gcc.gnu.org/viewcvs?view=revision&revision=157573
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43357
--- Comment #7 from pinskia at gcc dot gnu dot org 2010-03-23 19:13 ---
The x86-64 target writes directly out asm rather than going through some RTL
code which causes unwind tables not to be written out for the thunks.
--
pinskia at gcc dot gnu dot org changed:
What|R
--- Comment #11 from vmakarov at gcc dot gnu dot org 2010-03-23 19:19
---
Subject: Bug 43413
Author: vmakarov
Date: Tue Mar 23 19:18:42 2010
New Revision: 157676
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157676
Log:
2010-03-23 Vladimir Makarov
PR rtl-optimizati
When running the testsuite on powerpc-unknown-linux-gnu with extra passes
containing -fPIC I get the following additional errors on the 4.4 branch:
FAIL: gcc.c-torture/execute/va-arg-trap-1.c compilation, -O2 (internal
compiler error)
FAIL: gcc.c-torture/execute/va-arg-trap-1.c compilation, -O3
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-23 19:25 ---
*** This bug has been marked as a duplicate of 39254 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #20 from pinskia at gcc dot gnu dot org 2010-03-23 19:25
---
*** Bug 43500 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #21 from ghazi at gcc dot gnu dot org 2010-03-23 19:55 ---
As noted in duplicate PR43500, I am able to reproduce this error on plain
powerpc-unknown-linux-gnu when adding -fPIC. I can run tests for the 4.4.
branch but it will take several days to get a baseline result vs a p
--- Comment #10 from mrs at gcc dot gnu dot org 2010-03-23 20:03 ---
Subject: Bug 33120
Author: mrs
Date: Tue Mar 23 20:02:57 2010
New Revision: 157677
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157677
Log:
PR target/33120
* config/darwin.h (ASM_OUTPUT_ALIGNE
--- Comment #27 from spop at gcc dot gnu dot org 2010-03-23 20:08 ---
I just verified that the problem is well in CLooG-PPL.
With CLooG-ISL we generate a correct code that looks like this:
for (c2=1;c2<=D.1554_10-3;c2++) {
S1(c2);
for (c4=0;c4<=c2-1;c4++) {
S2(c2,c4);
--- Comment #11 from mrs at gcc dot gnu dot org 2010-03-23 20:13 ---
This should now be fixed.
--
mrs at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #3 from danglin at gcc dot gnu dot org 2010-03-23 20:24 ---
Also don't see any more.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #22 from dominiq at lps dot ens dot fr 2010-03-23 20:32 ---
> As noted in duplicate PR43500, I am able to reproduce this error on plain
> powerpc-unknown-linux-gnu when adding -fPIC. I can run tests for the 4.4.
> branch but it will take several days to get a baseline result
--- Comment #3 from davem at gcc dot gnu dot org 2010-03-23 20:40 ---
Sorry, it's taking a long time to sort out the test case. The
GLIBC regex code is huge and non-trivial.
However I did track down that it might be dependent upon optimization
options, for example I can reproduce with
Command line:
gcc -g testcase.c
- testcase.c -
void foo (int __attribute__ ((__mode__ (vector_size (8 x) {}
void bar (int x[i()]) {}
--
(reduced from testsuite/gcc.dg/parm-impl-decl-1.c)
Tested revisions:
r157675 - crash
r157460 - crash
r157122 - crash
r153685 - cr
--- Comment #28 from spop at gcc dot gnu dot org 2010-03-23 21:24 ---
I fixed this problem in CLooG-PPL: the code generated with
the new version looks like the code generated by CLooG-ISL:
for (c2=1;c2<=D.1554_10-3;c2++) {
S1(c2);
for (c4=0;c4<=c2-1;c4++) {
S2(c2,c4);
--- Comment #29 from spop at gcc dot gnu dot org 2010-03-23 21:27 ---
Also note that with the fix in CLooG-PPL,
gfortran -O2 -fgraphite-identity air.f90 -o air
./air
passes without error.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42181
--- Comment #1 from zsojka at seznam dot cz 2010-03-23 21:31 ---
Created an attachment (id=20175)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20175&action=view)
better testcase
This testcase is better as it is valid C89 code (I believe)
--
http://gcc.gnu.org/bugzilla/show_b
--- Comment #2 from zsojka at seznam dot cz 2010-03-23 21:33 ---
C89 + GNU extensions, that is
--
zsojka at seznam dot cz changed:
What|Removed |Added
Keywords|
--- Comment #3 from jakub at gcc dot gnu dot org 2010-03-23 22:05 ---
I'd say this is a dup of PR43381.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43501
--- Comment #8 from jakub at gcc dot gnu dot org 2010-03-23 22:10 ---
At least when using CFI asm this is solvable easily, see how I've changed i386
PIC setup generation. Without CFI asm it would be much harder though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43498
--- Comment #2 from ghazi at gcc dot gnu dot org 2010-03-23 22:17 ---
Testcase also fails on sparc64-unknown-linux-gnu with -fpic/-fPIC in both 32
and 64 bit modes:
http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg00753.html
--
ghazi at gcc dot gnu dot org changed:
What
--- Comment #4 from jakub at gcc dot gnu dot org 2010-03-23 22:41 ---
Wouldn't this be the same issue as
http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01086.html
?
On the trunk it wasn't just one commit, but several:
156888, 156889, 156893, 156903, 156913
If yes, would be interesting to k
--- Comment #3 from kkojima at gcc dot gnu dot org 2010-03-23 23:13 ---
Fixed.
--
kkojima at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #12 from meissner at gcc dot gnu dot org 2010-03-23 23:40
---
This reduces the spills, and brings the performance backs up. I'm closing the
bug. Thanks.
--
meissner at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from meissner at gcc dot gnu dot org 2010-03-23 23:43
---
I have tracked down the issue, and will submit a patch tomorrow after further
testing. The issue is when a multi-word items is loaded to GPRS, and the
address is of the form (r0+reg), the compiler was using r0 as
Command line:
g++ -std=c++0x testcase.cpp
testcase.cpp
void f() { []{}(); }
--
valgrind shows uninitialised read with this testcase
Tested revisions:
r157675 - fail
Valgrind output:
$ valgrind --trace-children=yes -q /mnt/svn/gcc-trunk/binary-157675-lto/bin/g++
-std
--- Comment #1 from zsojka at seznam dot cz 2010-03-24 00:03 ---
Created an attachment (id=20176)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20176&action=view)
reduced testcase showing -fcompare-debug failure
Line numbers are random:
$ /mnt/svn/gcc-trunk/binary-157675-lto/bin/
--- Comment #2 from paolo dot carlini at oracle dot com 2010-03-24 00:05
---
Let's add Jason in CC
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
1 - 100 of 115 matches
Mail list logo
