--- Comment #11 from jason at gcc dot gnu dot org 2010-01-15 06:18 ---
*** Bug 42569 has been marked as a duplicate of this bug. ***
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from jason at gcc dot gnu dot org 2010-01-15 06:18 ---
*** This bug has been marked as a duplicate of 42701 ***
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #15 from BlanchardJ at ieee dot org 2010-01-15 05:12 ---
(In reply to comment #14)
> (In reply to comment #10)
> > In reply to #9:
> >
> > I have tried to build gcc with and without my own patch on our solaris
> > machines. While both of them fails they fail at the same plac
--- Comment #14 from david dot kirkby at onetel dot net 2010-01-15 04:44
---
(In reply to comment #10)
> In reply to #9:
>
> I have tried to build gcc with and without my own patch on our solaris
> machines. While both of them fails they fail at the same place (namely
> configuration o
/import/git/gcc/configure --enable-languages=c
--disable-bootstrap --prefix=/usr/gcc-4.5.0 --with-local-prefix=/usr/local
--with-plugin-ld=ld.gold --enable-gold
Thread model: posix
gcc version 4.5.0 20100114 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-B./' '-B/export/build/gnu/gcc/bui
--- Comment #5 from espindola at gcc dot gnu dot org 2010-01-15 03:54
---
Note that
-plugin-opt=-pass-through=/foo/bar/libgcc.a
is missing in the linker invocation.
That is the problem. When BUG is not defined, the undefined reference is
visible early on. You can check that with
GNUTA
--with-local-prefix=/usr/local
--with-plugin-ld=ld.gold --enable-gold
Thread model: posix
gcc version 4.5.0 20100114 (experimental) (GCC)
[...@gnu-6 gold-2]$
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from hjl dot tools at gmail dot com 2010-01-15 03:36 ---
(In reply to comment #1)
> Created an attachment (id=19601)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19601&action=view) [edit]
> C source code
>
It works for me with 4.5.0 20100114 (expe
--- Comment #6 from hjl dot tools at gmail dot com 2010-01-15 03:31 ---
(In reply to comment #5)
> > Confirmed. Also note -fschedule-insns is basically broken for x86 anyways.
> >
>
> Do you have a list of bug reports where -fschedule-insns is broken on x86?
> We tried to compile all
--- Comment #8 from mmitchel at gcc dot gnu dot org 2010-01-15 03:26
---
Ramana --
If I'm reading the log correctly for PR36633 the change that Jason made there
didn't actually fix the bug; it was just a cleanup. He commented that
something else had changed which made the bug go away.
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2010-01-15 02:07
---
Fixed.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASS
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2010-01-15 02:06
---
Subject: Bug 42684
Author: jvdelisle
Date: Fri Jan 15 02:06:23 2010
New Revision: 155931
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155931
Log:
2010-01-14 Jerry DeLisle
PR fortran/42684
--- Comment #20 from paolo dot carlini at oracle dot com 2010-01-15 02:05
---
Normally should look, for your i686 target, like the final part of this:
http://gcc.gnu.org/ml/gcc-testresults/2010-01/msg01263.html
(please disregard the 23_containers failures, it's a temporary problem,
--- Comment #19 from paolo dot carlini at oracle dot com 2010-01-15 02:02
---
(we are not particularly interested in the g++ testresults, that this the
results for the C++ front-end proper, we are interested in the library results)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=427
--- Comment #18 from paolo dot carlini at oracle dot com 2010-01-15 02:00
---
Just build everything with default configure options, then go inside the
libstdc++-v3 *build* dir and type 'make check'.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
--- Comment #17 from phil at nwl dot cc 2010-01-15 01:55 ---
(In reply to comment #16)
> (output files g++.{log,sum} follow as attachments)
Mkay, bugzilla doesn't like the big logs. Meanwhile, take these:
- http://nwl.cc/~n0-1/g++.log
- http://nwl.cc/~n0-1/g++.sum
--
http://gcc.gnu
--- Comment #16 from phil at nwl dot cc 2010-01-15 01:49 ---
(In reply to comment #14)
> I'll give the testsuite a try, but this will take some time (svn checkout is
> still running).
>
Oh boy, here it comes. I hope I've done the right thing, as there is little
documentation about how
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2010-01-15 01:47
---
Subject: Bug 42684
Author: jvdelisle
Date: Fri Jan 15 01:47:43 2010
New Revision: 155930
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155930
Log:
2010-01-14 Jerry DeLisle
PR fortran/42684
--- Comment #4 from spop at gcc dot gnu dot org 2010-01-15 01:20 ---
The problem here is that the loop invariant motion moves rt(i,j) into
a temporary outside the innermost loop:
real*8 rt(6,6),r(6,6),rtt(6,6)
do i=1,6
do j=1,6
t = rt(i,j)
do ia=1,6
--- Comment #7 from ramana at gcc dot gnu dot org 2010-01-15 01:15 ---
With trunk I still see the dump as per the original attachment .
I think these 3 lines in the dump cause it to fail . The question though is why
the +4 and -4 are not folded out on the ARM port
D.1844_3 = (unsig
--- Comment #6 from ramana at gcc dot gnu dot org 2010-01-15 01:09 ---
Created an attachment (id=19603)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19603&action=view)
Dumps from testcase.
dumps attached.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39251
--- Comment #13 from hubicka at gcc dot gnu dot org 2010-01-15 00:33
---
Hi,
sorry for replying late, I was missed this problem somehow in my bugzilla
folder. The test in question verify that variables that are common or weak are
also etither public or external.
I will have time to try
--- Comment #4 from mmitchel at gcc dot gnu dot org 2010-01-15 00:17
---
OK, I will fix this one.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jakub at gcc dot gnu dot org 2010-01-14 23:21 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #9 from jakub at gcc dot gnu dot org 2010-01-14 23:20 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #9 from jakub at gcc dot gnu dot org 2010-01-14 23:19 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-01-14 23:01 ---
So the failure is only with the patch from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42633 closing as worksforme then.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #9 from janus at gcc dot gnu dot org 2010-01-14 22:59 ---
Another way to get rid of the error is:
Index: fortran/module.c
===
--- fortran/module.c(revision 155865)
+++ fortran/module.c(working copy)
@@ -
--- Comment #8 from jakub at gcc dot gnu dot org 2010-01-14 22:49 ---
Subject: Bug 42674
Author: jakub
Date: Thu Jan 14 22:49:17 2010
New Revision: 155922
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155922
Log:
PR middle-end/42674
* c-decl.c (finish_function):
--- Comment #8 from jakub at gcc dot gnu dot org 2010-01-14 22:47 ---
Subject: Bug 42608
Author: jakub
Date: Thu Jan 14 22:46:43 2010
New Revision: 155921
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155921
Log:
PR c++/42608
* varasm.c (declare_weak): Add weak
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-01-14 22:45 ---
This works for me with revision 155912 which I just compiled.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from jakub at gcc dot gnu dot org 2010-01-14 22:44 ---
Subject: Bug 42674
Author: jakub
Date: Thu Jan 14 22:43:56 2010
New Revision: 155920
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155920
Log:
PR middle-end/42674
* c-decl.c (finish_function):
--- Comment #2 from torbenh at gmx dot de 2010-01-14 22:41 ---
it all started when i added the copy constructor for fvec
but before that, the result of a fvec ( fvec x, fvec y ) wasnt
correct.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42751
--- Comment #7 from jakub at gcc dot gnu dot org 2010-01-14 22:41 ---
Subject: Bug 42608
Author: jakub
Date: Thu Jan 14 22:41:02 2010
New Revision: 155919
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155919
Log:
PR c++/42608
* varasm.c (declare_weak): Add weak
--- Comment #3 from jakub at gcc dot gnu dot org 2010-01-14 22:39 ---
Subject: Bug 42657
Author: jakub
Date: Thu Jan 14 22:38:29 2010
New Revision: 155917
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155917
Log:
PR debug/42657
* tree-inline.c (copy_debug_stmt):
--- Comment #1 from torbenh at gmx dot de 2010-01-14 22:34 ---
Created an attachment (id=19602)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19602&action=view)
the offending proprocessed file.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42751
--- Comment #10 from jason at gcc dot gnu dot org 2010-01-14 22:34 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
compiling this takes more than 7 hours even when its only -O2
dunno... i interrupted it. never finished.
/opt/gcc/bin/g++ -MD -MF .deps/process.d -c -O2 -ffast-math -march=core2
-std=gnu++0x -msse3 -o process.o process.ii
--
Summary: pretty massive inlining and a huge number of tempo
--- Comment #9 from jason at gcc dot gnu dot org 2010-01-14 22:32 ---
Subject: Bug 42701
Author: jason
Date: Thu Jan 14 22:32:24 2010
New Revision: 155916
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155916
Log:
PR c++/42701
* call.c (build_new_method_call): Do
--- Comment #8 from janus at gcc dot gnu dot org 2010-01-14 22:23 ---
The patch in comment #7 regresses on dummy_procedure_2.f90 and
proc_ptr_result_1.f90.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42677
--- Comment #3 from d dot g dot gorbachev at gmail dot com 2010-01-14
22:15 ---
> Is the undefined reference to libgcc? Is it being linked statically?
Yes. In both cases (with and without -DBUG), the ld command line is
/usr/local/bin/ld -plugin
/usr/local/libexec/gcc/i686-pc-linux-gnu
--- Comment #5 from reza dot yazdani at amd dot com 2010-01-14 22:12
---
> Confirmed. Also note -fschedule-insns is basically broken for x86 anyways.
>
Do you have a list of bug reports where -fschedule-insns is broken on x86?
We tried to compile all the SPEC 2006 with this option an
--- Comment #5 from vimal78 at gmail dot com 2010-01-14 21:42 ---
i am sorry, this is not a defect.
--
vimal78 at gmail dot com changed:
What|Removed |Added
S
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-01-14 21:39 ---
This is related to PR 39747. The issue is that you need both 32bit and 64bit
libgmp for the target if you are compiling libjava also.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
I did a svn checkout of the GOMP/OpenMP source
dir
155860
svn://gcc.gnu.org/svn/gcc/trunk
svn://gcc.gnu.org/svn/gcc
and build/installed recent versions of gmp, mpfr, mpc:
gmp-4.3.2 mpc-0.8.1 mpfr-2.4.2
in /usr/local
I configured gcc with
$ ./configure --with-gmp=/usr/local --with
--- Comment #7 from janus at gcc dot gnu dot org 2010-01-14 21:35 ---
(In reply to comment #2)
> I would guess it is due to PR 36947.
Yes, I think this is correct. r148519, to be precise.
The following patch fixes it:
Index: interface.c
=
--- Comment #5 from bergner at gcc dot gnu dot org 2010-01-14 21:12 ---
This ended up being a latent bug exposed by Bernd's patch. I posted a fix
here:
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00678.html
--
bergner at gcc dot gnu dot org changed:
What|Remove
--- Comment #4 from paolo dot carlini at oracle dot com 2010-01-14 20:47
---
Let's keep this one open instead, as a reminder that the libcs of non-GNU
targets have to provide a mechanism similar to the one used by recent glibcs:
http://gcc.gnu.org/viewcvs?view=revision&revision=14377
--- Comment #10 from jason at gcc dot gnu dot org 2010-01-14 20:45 ---
Fixed in 4.4, 4.5; not fixing in 4.3.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from paolo dot carlini at oracle dot com 2010-01-14 20:44
---
Yes, I agree, in the light of the resolution of DR456, let's keep open 33935
instead, and clarify in it that non-GNU targets have yet to provide a mechanism
similar to the one used in recent glibcs.
--
htt
--- Comment #9 from jason at gcc dot gnu dot org 2010-01-14 20:42 ---
Subject: Bug 42655
Author: jason
Date: Thu Jan 14 20:42:16 2010
New Revision: 155915
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155915
Log:
PR c++/42655
* call.c (convert_like_real): Do ful
--- Comment #5 from marc dot glisse at normalesup dot org 2010-01-14 20:35
---
(In reply to comment #4)
> It seems to me extremely unlikely that an implementation decides to provide
> the
> full-const version when called by a c++ compiler and nothing else, because C++
> does *not* add
--- Comment #3 from paolo dot carlini at oracle dot com 2010-01-14 20:31
---
Indeed. Matthias filed the PR and then I only changed the Summary to better
clarify that the point is simply not warning, *ever*, in system headers. Nice
that you agree about that analysis of mine and that a fi
--- Comment #8 from jason at gcc dot gnu dot org 2010-01-14 20:22 ---
Subject: Bug 42655
Author: jason
Date: Thu Jan 14 20:21:58 2010
New Revision: 155913
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155913
Log:
PR c++/42655
* call.c (convert_like_real): Do ful
--- Comment #10 from David dot Biesack at sas dot com 2010-01-14 20:09
---
I ran across this error also.
I have local recent builds of gmp, mpfr, mpc and configured with
./configure --with-gmp=/usr/local --with-mpfr=/usr/local --with-mpc=/usr/local
I'm working with a clean snapshot of
--- Comment #9 from matt at use dot net 2010-01-14 20:05 ---
The configure command:
../gcc-trunk/configure --prefix=/home/matt --enable-gold
--enable-build-with-cxx --enable-lto --enable-stage1-checking=all
--disable-werror --enable-bootstrap --enable-languages=c,c++,lto
I then adjust t
--- Comment #1 from dcb314 at hotmail dot com 2010-01-14 19:55 ---
Created an attachment (id=19601)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19601&action=view)
C source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42749
I just tried to compile the package pspdftool with
the GNU C compiler version 4.5 snapshot 20100107 and the
compiler said
gcc -DHAVE_CONFIG_H -I.-std=gnu99 -O2 -g -m64 -fmessage-length=0
-D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
-fasynchronous-unwind-tables -MT pdf_parser.o -MD -MP
--- Comment #9 from pinskia at gcc dot gnu dot org 2010-01-14 19:46 ---
So you don't have libmpc in the LD_LIBRARY_PATH or setup ld.conf correctly. I
normally use a static version of libmpc.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #8 from David dot Biesack at sas dot com 2010-01-14 19:42
---
Created an attachment (id=19600)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19600&action=view)
failed config on x86_64 (openmp)
configure failed to determine the suffice for object files, causing gcc bui
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2010-01-14 19:30
---
By contrived I meant - made to look like your real code, but not necessarily
your real code. I want to make sure "contrived" is not inetrpreted here as
negative in any way.
At least conceptually one could compute
--- Comment #12 from spop at gcc dot gnu dot org 2010-01-14 19:24 ---
The kernel from Comment #2 looks identical to the kernel from PR42637 that is
also miscompiled.
These two PRs may be the same.
Konrad, could you look at the testcase from PR42637 that is more precise?
Thanks,
Sebasti
--- Comment #2 from mmitchel at gcc dot gnu dot org 2010-01-14 19:22
---
Paolo --
I think that the warning is accurate; the mangling of va_list has indeed
changed on ARM in GCC 4.4 in order to conform to the ARM ABI specifications.
There is an option to turn off warnings about PSABI i
--- Comment #7 from spop at gcc dot gnu dot org 2010-01-14 19:20 ---
As this is failing also on trunk I'm closing this bug as invalid.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from paolo dot carlini at oracle dot com 2010-01-14 18:26
---
Mark, can you have a look to this issue, thanks!
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
-
--- Comment #1 from meissner at gcc dot gnu dot org 2010-01-14 18:21
---
Created an attachment (id=19599)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19599&action=view)
Patch to enable sqrtdf if -mvsx
Patch to split sqrtdf2 into expander/insn.
--
http://gcc.gnu.org/bugzill
see http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00670.html and followups. seen
on the gcc-4_4-branch and the trunk, glibc version is eglibc-2.11.1
when running the libstdc++v3 testsuite on arm-linux-gnueabi, a lot of test
cases fail with excess errors, e.g.
FAIL: 17_intro/using_namespace_std_t
--- Comment #7 from jamborm at gcc dot gnu dot org 2010-01-14 18:02 ---
Fixed.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from jamborm at gcc dot gnu dot org 2010-01-14 18:00 ---
Subject: Bug 42706
Author: jamborm
Date: Thu Jan 14 18:00:34 2010
New Revision: 155911
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155911
Log:
2010-01-14 Martin Jambor
PR tree-optimization/427
--- Comment #6 from trifunovic at gcc dot gnu dot org 2010-01-14 17:51
---
aermod.f90 fails also on the gcc_trunk, without using Graphite.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41924
--- Comment #12 from hjl dot tools at gmail dot com 2010-01-14 17:34
---
Intel AVX architecture won't fault on unaligned load-op instructions
and unaligned VMOV* instructions are as fast as aligned VMOV*
instructions on aligned memory. For AVX, we can always use unaligned
VMOV* instruct
--- Comment #11 from law at redhat dot com 2010-01-14 17:29 ---
Subject: Re: vectorizer created unaligned vector
insns
On 01/13/10 02:35, irar at il dot ibm dot com wrote:
> --- Comment #10 from irar at il dot ibm dot com 2010-01-13 09:35 ---
> Yes, I understand that we can't
--- Comment #12 from pthaugen at gcc dot gnu dot org 2010-01-14 17:29
---
The first patch appeared to work, resulting in correct ordering, but the second
patch had some issues. It also corrected the original ordering, but introduced
some new incorrect code for handling the args coming i
--- Comment #4 from paolo dot carlini at oracle dot com 2010-01-14 17:23
---
It seems to me extremely unlikely that an implementation decides to provide the
full-const version when called by a c++ compiler and nothing else, because C++
does *not* add an overload, *replaces both*. Thus i
In doing the power7 work, I inadvertently disabled sqrtdf2 for power7, because
I didn't notice it was a define_insn instead of the define_expand and separate
define_insn as used by the other DF operations.
--
Summary: -mcpu=power7 (or -mvsx) does not generate the xssqrtdp
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-01-14 16:57 ---
Note that with the current middle-end setup we cannot really ever derive
anything about alignment when just seeing a pointer type. We only can
ever derive alignment information when having access to the pointed-to
d
--
trifunovic at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |trifunovic at gcc dot gnu
|dot org
--- Comment #18 from rguenth at gcc dot gnu dot org 2010-01-14 16:45
---
Not working on this. The ICE will go away with release checking.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42742
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Priority|P3 |P1
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42736
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-checking, ice-on-valid-
|
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42715
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42713
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42706
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42701
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42685
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42684
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42677
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42676
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42674
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42655
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42248
--- Comment #5 from paolo dot carlini at oracle dot com 2010-01-14 16:34
---
PR42634 is fixed, we can safely close this one too.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-01-14 16:21 ---
Correct. Especially resetting debug stmts inside a predicate is extra ugly ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42719
--- Comment #5 from ramana at gcc dot gnu dot org 2010-01-14 16:21 ---
I took a cursory look at this case . This looks like a bug in the
backend specifically in arm_output_epilogue where the epilogue code
isn't designed to cope for restoring disjoint sets of registers from
the stack when
--- Comment #5 from matz at gcc dot gnu dot org 2010-01-14 16:17 ---
I don't think the big hammer is necessary. trivially_conflicts_p only is a
heuristic predicate influencing how other code is emitted. That other code
needs to handle them already, otherwise more transformations would
--- Comment #4 from jakub at gcc dot gnu dot org 2010-01-14 16:10 ---
Created an attachment (id=19598)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19598&action=view)
gcc45-pr42719.patch
Big hammer patch to reset the debug stmts because of which we'd return true
from trivially_co
1 - 100 of 184 matches
Mail list logo
