--- Comment #10 from davem at davemloft dot net 2010-03-24 06:43 ---
Created an attachment (id=20179)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20179&action=view)
source that emitted miscompiled function
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43385
--- Comment #9 from jakub at gcc dot gnu dot org 2010-03-24 06:38 ---
Could you please also attach regexec.i (and what gcc options were used to
compile it), so that I can inspect it with a cross-compiler? Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43385
--- Comment #8 from davem at davemloft dot net 2010-03-24 06:02 ---
Created an attachment (id=20178)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20178&action=view)
miscompiled function
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43385
--- Comment #7 from davem at davemloft dot net 2010-03-24 06:01 ---
Created an attachment (id=20177)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20177&action=view)
correctly compiled function
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43385
--- Comment #6 from davem at davemloft dot net 2010-03-24 06:00 ---
In the regex cases, glibc/posix/regexec.c:merge_state_with_log() is what
gets miscompiled.
I will attach match_good.s and match_bad.s
match_good.s is a working compile of this function, using gcc-4.3.2
match_bad.s is
--- Comment #14 from mckelvey at maskull dot com 2010-03-24 04:57 ---
I now see that sjlj dll is back in /usr/local/bin, along with the other one. I
delete them, and the new g++ works. At least it compiles to a .o again. We'll
see if my project actually runs properly.
So I guess that th
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2010-03-24
04:06 ---
caused by...
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
--- Comment #5 from davem at davemloft dot net 2010-03-24 03:01 ---
Yes, the failures mentioned in:
http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01086.html
are the same exact ones I am seeing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43385
At r157681, x86_64-apple-darwin10 has developed numerous libjava testsuite
failures...
http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg02039.html
These did not exist at r157609.
--
Summary: many libjava testsuite regressions on x86_64-apple-
darwin10
: posix
gcc version 4.5.0 20100323 (experimental) (GCC)
mckel...@mckelvey-pc ~/PD
$ which g++
/usr/local/bin/g++
mckel...@mckelvey-pc ~/PD
$ cygcheck /usr/local/bin/g++
C:\cygwin\usr\local\bin\g++.exe
C:\cygwin\bin\cygwin1.dll
C:\Windows\system32\ADVAPI32.DLL
C:\Windows\system32
--- Comment #2 from yuri at tsoft dot com 2010-03-24 01:14 ---
I would put higher priority here over the other missed optimizations because
this is the basic c/c++ construct and it's used very frequently.
--
yuri at tsoft dot com changed:
What|Removed
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-24 01:12 ---
The problem comes from cross jumping happening late so it only gets rid of the
conditional after register allocation.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |A
Decrementing of the field causes 3 instructions for what could be one on i686
target.
--- testcase ---
struct C { int fld; };
extern void a();
extern void b();
void f(C *c) {
if (--c->fld > 0) {
a();
} else {
a();
}
}
--- result of assembly with -O5 option ---
_Z1fP1C:
.LFB0:
--- Comment #4 from aflyhorse at foxmail dot com 2010-03-24 00:26 ---
Hmmm... i don't know if it is useful to give you the configure option i did at
that time... Happy i have a habit of recording every command i used during
installation:
$ ../src/configure --build=x86_64-w64-mingw32
--e
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rearnsha at gcc dot gnu dot
|dot org
--- 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
--- 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/
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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);
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 #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
--- 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 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 #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 #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 #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 #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 #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 #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
--
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 #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
--- 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 #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 #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 #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 #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 #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 #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
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 #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
--- 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 #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 #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 #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
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 #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 .
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 #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
---
--- 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.
--
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 #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
--- 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
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 #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
---
--- 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 #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-
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
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
--- 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).
--- 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
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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()
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 #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
--- 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
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Component|rtl-optimization|target
Priority|P3 |P1
http://gc
--- 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
---
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
1 - 100 of 115 matches
Mail list logo
