--- Comment #6 from ebotcazou at gcc dot gnu dot org 2008-09-05 06:24
---
> I tried revision 140023 on RHEL4U6. I can bootstrap
> with --enable-languages=c i586-linux.
Which branch? I still get the failure on mainline at revision 140025.
--
http://gcc.gnu.org/bugzilla/show_bug.c
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirme
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |spop at gcc dot gnu dot org
|dot org
--- Comment #5 from hjl dot tools at gmail dot com 2008-09-05 04:47 ---
I tried revision 140023 on RHEL4U6. I can bootstrap
with --enable-languages=c i586-linux.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
--- Comment #10 from hjl dot tools at gmail dot com 2008-09-05 02:21
---
This may be related to PR 37378 and PR 37377.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37360
--- Comment #1 from danglin at gcc dot gnu dot org 2008-09-05 02:20 ---
In charset.c.004t.gimple, I see
cvt.77 = cvt;
D.6101 = cvt.77.width;
width = (size_t) D.6101;
So, I think stage must be miscompiled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37380
In stage2,
/home/dave/gnu/gcc-4.4/objdir/./prev-gcc/xgcc
-B/home/dave/gnu/gcc-4.4/objdir/./prev-gcc/
-B/home/dave/opt/gnu/gcc/gcc-4.4.0/hppa-linux/bin/ -I../../gcc/libcpp -I.
-I../../gcc/libcpp/../include -I../../gcc/libcpp/include -g -O2 -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-pr
--- Comment #3 from danglin at gcc dot gnu dot org 2008-09-05 02:01 ---
I seen this failure with several files including a-direct.adb. The failure
in bitmap_allocator.cc is here:
../../../../gcc/libstdc++-v3/src/bitmap_allocator.cc: In member function 'void
__gnu_cxx::free_list::_M_cle
--- Comment #2 from danglin at gcc dot gnu dot org 2008-09-05 01:56 ---
Created an attachment (id=16227)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16227&action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37265
2008/9/5 zhihang wang <[EMAIL PROTECTED]>
> 我安装qt的时候提示xlib.h文件找不到。我想从网上下载光盘安装。但是不知道这个文件在哪个包里面
>
> ~~
>
libx11-dev
参考 APT HOWTO[1] 5.3 和 5.4 节
[1]: http://www.debian.org/doc/manuals/apt-howto/index.zh-cn.html
--- Comment #7 from janis at gcc dot gnu dot org 2008-09-04 23:33 ---
Subject: Bug 32783
Author: janis
Date: Thu Sep 4 23:32:05 2008
New Revision: 140013
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140013
Log:
2008-09-04 Samuel Tardieu <[EMAIL PROTECTED]>
PR targe
--- Comment #5 from hp at gcc dot gnu dot org 2008-09-04 23:29 ---
Bug disappeared. Still failed with revision 139979, passed since at least
139984.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from happyarch at gmail dot com 2008-09-04 23:07 ---
(In reply to comment #6)
> (In reply to comment #5)
> > Hi,
> >
> > i tried your patch, but it doesn't work for my lfs64(linux from scratch
> > pure-64bit)
> > http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01407.html
>
--- Comment #9 from daney at gcc dot gnu dot org 2008-09-04 22:48 ---
(In reply to comment #2)
> > Andrey, this is likely due to the selective scheduler merge. Can you
> > investigate or delegate?
> We couldn't reproduce this with a cross from x86_64. Also, Adam Nemet fixed
> the prob
--- Comment #19 from jwakely dot gcc at gmail dot com 2008-09-04 22:40
---
fixed for 4.4
--
jwakely dot gcc at gmail dot com changed:
What|Removed |Added
Sta
--- Comment #18 from redi at gcc dot gnu dot org 2008-09-04 22:34 ---
Subject: Bug 36962
Author: redi
Date: Thu Sep 4 22:33:10 2008
New Revision: 140012
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140012
Log:
PR libstdc++/36962
* include/Makefile.am: Update h
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2008-09-04
22:33 ---
gfortran -freciprocal-math -floop-block -O2 -fgraphite aermod.f90
...ICEs with...
aermod.f90: In function ocalc:
aermod.f90:8312: internal compiler error: in expand_scalar_variables_expr, at
graphite.c:
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2008-09-04
22:31 ---
gfortran -fassociative-math -floop-block -O2 -fgraphite aermod.f90
...ICEs with...
aermod.f90: In function ocalc:
aermod.f90:8312: internal compiler error: in expand_scalar_variables_expr, at
graphite.c
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2008-09-04
22:27 ---
gfortran -fno-signed-zeros -floop-block -O2 -fgraphite aermod.f90
...ICEs with...
aermod.f90: In function ocalc:
aermod.f90:8312: internal compiler error: in expand_scalar_variables_expr, at
graphite.c:
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2008-09-04
22:23 ---
gfortran -fno-trapping-math -floop-block -O2 -fgraphite aermod.f90
...ICEs with...
aermod.f90: In function ocalc:
aermod.f90:8312: internal compiler error: in expand_scalar_variables_expr, at
graphite.c
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2008-09-04
22:21 ---
gfortran -funsafe-loop-optimizations -floop-block -O2 -fgraphite aermod.f90
...ICEs with...
aermod.f90: In function ocalc:
aermod.f90:8312: internal compiler error: in expand_scalar_variables_expr, at
g
When compiling the aermod.f90 from the Polyhedron 2005 benchmarks with gfortran
using either...
gfortran -ffast-math -floop-block -O2 -fgraphite aermod.f90
or
gfortran -ffast-math -O2 -floop-strip-mine -fgraphite aermod.f90
results in the compiler error...
aermod.f90: In function vrtcbl:
aer
--- Comment #17 from jwakely dot gcc at gmail dot com 2008-09-04 21:39
---
Created an attachment (id=16226)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16226&action=view)
new patch
As requested, except I didn't split tr1_impl/boost_sp_counted_base.h
My preference would be to l
--- Comment #1 from danglin at gcc dot gnu dot org 2008-09-04 21:32 ---
This was introduced in revision 138733.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #16 from pault at gcc dot gnu dot org 2008-09-04 21:22 ---
> I find this behavior very confusing, inconsistent with the concept of scoping
> units.
(In reply to comment #7)
> I think this should be rejected :
Lahey and deep contemplation agree with you:-)
I am trying to
--- Comment #5 from hjl dot tools at gmail dot com 2008-09-04 21:13 ---
All failures have
-2147483648
-2147483648
0
0
0
java.lang.ArithmeticException: / by zero
java.lang.ArithmeticException: / by zero
-9223372036854775808
0
java.lang.ArithmeticException: / by zero
java.lang.ArithmeticE
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-09-04 21:09 ---
>From the revisions it certainly wasn't me. But all the selective scheduler is
in.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-09-04 21:07 ---
Your latest testresults don't include the Divide_2 failure anymore.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37378
--- Comment #32 from hjl dot tools at gmail dot com 2008-09-04 21:05
---
I am closing this bug. We will track PR 37364 separately.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-09-04 21:05 ---
Architecture? I don't see these.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from hjl dot tools at gmail dot com 2008-09-04 21:04 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #1 from hjl dot tools at gmail dot com 2008-09-04 21:02 ---
Unfortunately, trunk was broken from revision 139821 to 139861
on ia64. This regression may be caused by patches from Richard
or Honza.
--
hjl dot tools at gmail dot com changed:
What|Removed
On Linux/ia64, revision 139863 has new failures
+FAIL: Divide_1 execution - source compiled test
+FAIL: Divide_1 -findirect-dispatch execution - source compiled test
+FAIL: Divide_1 -O3 execution - source compiled test
+FAIL: Divide_1 -O3 -findirect-dispatch execution - source compiled test
+FAIL:
--- Comment #38 from lucier at math dot purdue dot edu 2008-09-04 20:49
---
OK, but I was moved to write because Jakub's latest 4.4 status report requests
Please concentrate now on fixing bugs, especially the performance regressions.
and this is a definite 4.3/4.4 performance regressi
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2008-09-04 20:46
---
Excerpt from 168r.asmcons:
(insn:HI 108 107 109 14 /home/eric/svn/gcc/gcc/df-scan.c:1479 (set (reg/f:SI
373 [ df.3419 ])
(mem/f/c/i:SI (symbol_ref:SI ("df") [flags 0x40] ) [166 df+0 S4 A32])) 41 {*movsi_1
--- Comment #37 from rguenth at gcc dot gnu dot org 2008-09-04 20:43
---
We have to admit that this bug is unlikely to get fixed in the 4.3 series.
It still lacks proper analysis, as unfortunately that done on the shorter
testcase was not valid. Analysis takes time, and honestly at thi
--- Comment #20 from dodji at gcc dot gnu dot org 2008-09-04 20:42 ---
Hello,
It would be nice to provide a testcase that could help reproduce the
performance degradation easily.
Moreoever, I don't have access to a ppc box yet. How could I have that ?
--
http://gcc.gnu.org/bugzill
--- Comment #36 from lucier at math dot purdue dot edu 2008-09-04 20:39
---
I don't really understand the status of this bug.
Before 4.3.0, it was P!, and Mark said he said he'd "like to see us start to
explain these kinds of dramatic performance changes."
There was quite a bit of det
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2008-09-04 20:36
---
In the assembly file:
.L871:
movl%ebx, %eax
movl%edx, 20(%ebx)
callT.911
movldf, %esi
movl60(%esi), %eax
movl%esi, 36(%esp) <-- save df
--- Comment #3 from paolo dot carlini at oracle dot com 2008-09-04 20:35
---
Of course involves also libstdc++-v3, its exports.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2008-09-04 20:32
---
Created an attachment (id=16225)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16225&action=view)
Preprocessed source
Sorry, I don't have time to reduce it.
Compile with -O2 -fomit-frame-pointer -mtune=pen
--- Comment #10 from hjl dot tools at gmail dot com 2008-09-04 20:30
---
Created an attachment (id=16224)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16224&action=view)
A patch
I am testing this patch
2008-09-04 H.J. Lu <[EMAIL PROTECTED]>
PR target/37364
*
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2008-09-04 20:30
---
It's a miscompilation of df-scan.c:df_reorganize_refs_by_reg by
regalloc/reload.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #19 from dje at gcc dot gnu dot org 2008-09-04 20:25 ---
The patch for this bug significantly degrades PowerPC performance.
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from domob at gcc dot gnu dot org 2008-09-04 20:23 ---
I'll try to find something about this in the standard. But you think DIMENSION
(and friends) is legally apply-able ("applicable"?) to symbols that are
declared later with their type? Hm... I hope to find out :)
Oth
At revision 140002 I get on i586-linux:
/home/eric/build/gcc/native32/./gcc/xgcc -B/home/eric/build/gcc/native32/./gcc/
-B/home/eric/install/gcc/i586-suse-linux/bin/
-B/home/eric/install/gcc/i586-suse-linux/lib/ -isystem
/home/eric/install/gcc/i586-suse-linux/include -isystem
/home/eric/install/gc
--- Comment #9 from hjl dot tools at gmail dot com 2008-09-04 20:17 ---
I am concerned about those "*Yi"/"*Ym" and "r" pairs:
[EMAIL PROTECTED] i386]$ grep "\*Yi" *.md
i386.md:"=r,m ,*y,*y,?rm,?*y,*x,*x,?r ,m ,?*Yi,*x")
i386.md:"g ,ri,C ,*
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-09-04 20:12 ---
If we decide the test is bogus we should remove it, not xfail it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37364
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-09-04 20:09 ---
Marked as regression to show up in the important bug list.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from burnus at gcc dot gnu dot org 2008-09-04 20:02 ---
(In reply to comment #4)
> DIMENSION x(:)
> (if that's a legal way to specify DIMENSION, I'm not sure)?
"dimension(:)" is only valid for (a) dummy arguments or (b)
allocatable/pointer; but with "(5)" instead of "(:)"
--- Comment #11 from tehila at il dot ibm dot com 2008-09-04 19:46 ---
(In reply to comment #10)
> I'm bootstraping and testing it on x86 now.
Bootstrap fails (at least on x86_64) (with ICE).
Tehila.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37221
--- Comment #7 from hjl dot tools at gmail dot com 2008-09-04 19:45 ---
(In reply to comment #6)
> First of all, I've check the generated code on Core2 and I found it is not
> slower than using movd.
I think MMX may be slow anyway.
> The reason for this is in insn
>
> (insn:HI 14
--- Comment #32 from ebotcazou at gcc dot gnu dot org 2008-09-04 19:30
---
> I tried i586-linux with ira-merge branch. It built libgcc fine.
> So the problem is either fixed on ira-merge branch or it isn't
> caused by IRA merge.
Or isn't exposed on that branch.
It's a stack slot reuse
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-09-04 19:25 ---
Appearantly I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from vmakarov at redhat dot com 2008-09-04 19:25 ---
First of all, I've check the generated code on Core2 and I found it is not
slower than using movd.
IRA assigns hard registers calculating their costs. It the memory is
cheaper, it assigns memory. The first decisio
--- Comment #3 from domob at gcc dot gnu dot org 2008-09-04 19:17 ---
Subject: Bug 37099
Author: domob
Date: Thu Sep 4 19:16:13 2008
New Revision: 139997
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139997
Log:
2008-09-04 Daniel Kraft <[EMAIL PROTECTED]>
* PR fortr
--- Comment #1 from kris dot van dot hees at oracle dot com 2008-09-04
19:12 ---
The vendor extension mangling was based on the following email as feedback on
the original patch:
http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01622.html
The original suggested mangling was:
char16_t
--- Comment #8 from hjl at gcc dot gnu dot org 2008-09-04 19:03 ---
Subject: Bug 37359
Author: hjl
Date: Thu Sep 4 19:02:33 2008
New Revision: 139996
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139996
Log:
2008-09-04 Vladimir Makarov <[EMAIL PROTECTED]>
PR middle-
--- Comment #31 from rsandifo at gcc dot gnu dot org 2008-09-04 18:48
---
Subject: Bug 37243
Author: rsandifo
Date: Thu Sep 4 18:47:35 2008
New Revision: 139993
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139993
Log:
gcc/
PR middle-end/37243
* ira-build.c (f
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P1 |P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37376
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37376
char16_t and char32_t are still mangled as a vendor extension in the 4.4
sources. This is a blocker for 4.4; we need a standard mangling before it is
released in order to avoid binary incompatibility with future releases.
--
Summary: No standard mangling for char16/32_t yet
--- Comment #5 from hjl dot tools at gmail dot com 2008-09-04 18:39 ---
Just for the record, move between MMX and GPR isn't a major issue
since we prefer SSE anyway. If it is the only inter class register
move problem for IRA, I am OK to close it as WONTFIX.
--
http://gcc.gnu.org/bu
--
grosser at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Prio
We detect this SCoP:
for (i ...)
{
foo(); // Difficult
// ScoP entry
for (j ...)
B;
a = 5 + i;
for (k ...)
C;
// SCoP exit
}
To find the parameters we have to "instantiate_scev" for every bb.
"instantiate_scev" requires an argument "outermost_loop" to define,
which loop
--- Comment #4 from hjl dot tools at gmail dot com 2008-09-04 17:54 ---
(In reply to comment #3)
> The problem may be in IRA_COVER_CLASSES. -mtune=core2 turns on
> TARGET_INTER_UNIT_MOVES, which means move between mmx and 64bit
> integer registers is cheaper than load/store. But IRA does
--- Comment #3 from hjl dot tools at gmail dot com 2008-09-04 17:43 ---
The problem may be in IRA_COVER_CLASSES. -mtune=core2 turns on
TARGET_INTER_UNIT_MOVES, which means move between mmx and 64bit
integer registers is cheaper than load/store. But IRA doesn't
handle it properly.
--
--- Comment #8 from daney at gcc dot gnu dot org 2008-09-04 17:39 ---
It is reproducible in a cross compiler as well.
This is my command line:
/home/daney/gccsvn/mipsel-trunk/gcc/cc1 -fpreprocessed j.i -quiet -march=sb1
-O2 -o j.s
Changing to -march={mips32,mips32r2,r5000} "fixes" the
--- Comment #2 from psmith at gnu dot org 2008-09-04 17:34 ---
I tried this with the latest stable, GCC 4.3.2, and I still had the same
failures.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36442
--- Comment #1 from chris dot fairles at gmail dot com 2008-09-04 17:33
---
mainline compiles first snippet fine. second gives:
error: 'void N2::f(int)' should have been declared inside 'N2'
For what its worth msvc 9 and Comeau C/C++ 4.3.10.1 compile both snippets w/o
error.
--
--- Comment #7 from daney at gcc dot gnu dot org 2008-09-04 17:17 ---
The problem is present in 139918
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37360
--- Comment #4 from domob at gcc dot gnu dot org 2008-09-04 17:14 ---
Shouldn't for this code:
IMPLICIT TYPE(t)(x)
DIMENSION x(:)
x get the implicit type on the DIMENSION statement and this be thus equivalent
to
TYPE(t) :: x
DIMENSION x(:)
(if that's a legal way to specify DIMENSION,
The following code (example A) compiles:
namespace N1 { void f() {} }
namespace N2 { void f(int) {} using N1::f; }
main() { N2::f(0); }
But this code does not compile (example B) because the compiler claims there is
no f(int) within N2:
namespace N1 { void f() {} }
namespace N2 { void
--- Comment #10 from amacleod at redhat dot com 2008-09-04 16:51 ---
As long as it removes any dead PHIs, it would be sufficient. Other types of
dead statements don't have 'unexpected' side effects across basic block
boundaries, and should be handled fine. Other than being a waste of eff
--- Comment #14 from w dot doeringer at fh-worms dot de 2008-09-04 16:48
---
Created an attachment (id=16223)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16223&action=view)
compiler error on valid code
might point to the problem causing the seg fault
--
http://gcc.gnu.org/
--- Comment #4 from patriciak784-gccmainling at yahoo dot de 2008-09-04
16:38 ---
Now I know why gcc complains about a misformed pch file nul.gch!
Checking if a file named NUL plus any extension exists, will always return that
it exists because I did this on windows! open will not open
Hi,
We have an opening for………
Position: J2EE Architect
Location: Marlborough, MA
Duration: 3 Months+
The Solutions Architect will discover, document, and assess the state of
multiple enterprise application architectures vis-à-vis failover and
recovery. Successful candidates will b
The preprocessor does not parse variadic macros correctly when they are used in
source code generated by other macros. I think that directives within macros
are non-standard, but some standard library functions are implemented as macros
when using FORTIFY_SOURCE, which can cause problems in code th
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-09-04 16:17 ---
Thanks for the explanation, for the branch I would recommend an extra DCE
pass right before pass_del_ssa. On the trunk we need to make sure to run
this at -O0 as well. Note that the simple DCE can leave dead statem
--- Comment #2 from hjl dot tools at gmail dot com 2008-09-04 16:13 ---
(In reply to comment #1)
> "-O2 -march=core2 -fno-ira -fno-regmove" generates
>
> movqx(%rip), %mm0
> paddd y(%rip), %mm0
> movq%mm0, -8(%rsp)
> movq-8(%rsp), %rax
>
>
--- Comment #6 from daney at gcc dot gnu dot org 2008-09-04 16:12 ---
I get the same ICE using gcc (Debian 4.3.1-8) 4.3.1 as the bootstrap compiler,
so I am going with the theory that the bootstrap compiler is not the cause of
this problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--- Comment #8 from amacleod at redhat dot com 2008-09-04 16:09 ---
out of ssa generally expects that there is no dead code.
I think the original logic was that you never want to generate code for dead
statements, so DCE would be run just before out of ssa.
It assumes any conflicts ca
--
grosser at gcc dot gnu dot org changed:
What|Removed |Added
CC||grosser at gcc dot gnu dot
|
During SCoP detection we split bbs (e.g. in "scopdet_edge_info"), but the SCoP
detection should only detect SCoPs and not modify anything.
Also it splits bbs in inner loops, that do not need to be splitted.
Bb splitting was introduced to make SCoPs entry/exit defined by a single edge.
That is a gr
--- Comment #1 from hjl dot tools at gmail dot com 2008-09-04 16:02 ---
"-O2 -march=core2 -fno-ira -fno-regmove" generates
movqx(%rip), %mm0
paddd y(%rip), %mm0
movq%mm0, -8(%rsp)
movq-8(%rsp), %rax
It seems that regmove isn't effective for
--- Comment #30 from hjl at gcc dot gnu dot org 2008-09-04 15:47 ---
Subject: Bug 37243
Author: hjl
Date: Thu Sep 4 15:46:05 2008
New Revision: 139987
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139987
Log:
2008-09-04 H.J. Lu <[EMAIL PROTECTED]>
PR rtl-optimizatio
--- Comment #5 from contact at multimedia dot cx 2008-09-04 15:13 ---
Perhaps the change should have, but it didn't. The problem still manifests with
SVN 139974 (latest as of yesterday).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37044
--- Comment #5 from hjl dot tools at gmail dot com 2008-09-04 14:58 ---
I would suggest to try ira-merge branch to rule out any IRA related
problems.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37360
--- Comment #1 from hjl dot tools at gmail dot com 2008-09-04 14:55 ---
You should include and use va_XXX macros.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
--- Comment #31 from hjl dot tools at gmail dot com 2008-09-04 14:53
---
I tried i586-linux with ira-merge branch. It built libgcc fine.
So the problem is either fixed on ira-merge branch or it isn't
caused by IRA merge.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37296
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-09-04 14:53 ---
As on the trunk we are now feeding out-of-SSA with random dead statements
at -O0 we should look into this. Or schedule a DCE pass before it if it
cannot cope with dead statements.
--
rguenth at gcc dot gnu dot o
First of all, thanx to all the gcc team for their fantastic job.
gcc: 4.3.2 bootstraped with CFLAGS=-O2 -pipe -march=athlon -fomit-frame-pointer
Target: linux 2.6.25 on mandriva 2008.0
Problem: the following code works fine with low optimization -O0, -O1,
but gives fancy results with -O2, -O3. N
--- Comment #4 from daney at gcc dot gnu dot org 2008-09-04 14:49 ---
You will note that I configured with --with-arch=sb1.
This in turn causes cc1 to be invoked with -march=sb1
I will attempt to test with a cross build.
My bootstrap gcc is: gcc (GCC) 4.4.0 20080223 (experimental) [tr
--- Comment #3 from hp at gcc dot gnu dot org 2008-09-04 14:42 ---
No regressions for native x86_64-unknown-linux-gnu.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37363
--- Comment #3 from abel at ispras dot ru 2008-09-04 14:34 ---
This does not fail on a cross for us with 139918.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37360
--- Comment #16 from paolo dot carlini at oracle dot com 2008-09-04 14:00
---
Great, thanks a lot again.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36962
--- Comment #15 from jwakely dot gcc at gmail dot com 2008-09-04 13:52
---
Sure, I can do that
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36962
--- Comment #3 from patriciak784-gccmainling at yahoo dot de 2008-09-04
13:35 ---
I did examine both problems a bit further.
If I understand correctly what is happening, there is the object parse_in which
is, during program flow, passed to preprocess_file as argument pfile.
An object of
--- Comment #29 from hjl dot tools at gmail dot com 2008-09-04 13:34
---
On ira-merge branch at revision 139972, there are no regression
on Linux/ia32 and Linux/ia64. Linux/x86-64 has regressions:
+FAIL: gcc.target/i386/pr34256.c scan-assembler-times mov 2
It is tracked by PR 37364.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org
|dot org
1 - 100 of 141 matches
Mail list logo
