--- Comment #3 from phresnel at gmail dot com 2010-07-07 06:29 ---
(In reply to comment #1)
(In reply to comment #0)
undefined reference to `vtable for IFoo'
Suggestions:
* Ensure that no (pure) member function of `IFoo' became unintentionally
non-pure because of a
--- Comment #4 from phresnel at gmail dot com 2010-07-07 06:55 ---
Little update: I re-opened this report at
http://sourceware.org/bugzilla/show_bug.cgi?id=11793 .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44841
Testcase:
struct foo { int };
gcc-4.6:
test.c:1:18: error: expected identifier or ( before } token
test.c:1:18: error: expected specifier-qualifier-list at end of input
clang:
test.c:1:18: error: expected member name or ';' after declaration specifiers
struct foo { int };
~~~ ^
--- Comment #5 from jakub at gcc dot gnu dot org 2010-07-07 07:17 ---
Yeah, the amount of regressions is huge, both on x86_64-linux and i686-linux.
The difference is in i386 now overriding config/elfos.h definition:
/* Write the extra assembler code needed to declare a function
Consider the following C++ source code files
= testLib.h ===
#include stdexcept
#include iostream
#define DEBUG1(X) std::coutX;
typedef int IndexType;
namespace Upagraha
{
templatetypename X,int Size
class CompileTimeFixedSizeData
{
protected:
X _data[Size];
--- Comment #1 from hlprasu at gmail dot com 2010-07-07 07:22 ---
Created an attachment (id=21120)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21120action=view)
The test case attached
To simplify the task of whomsoever who wants to see the behaviour, all the
files mentioned in
--- Comment #4 from marc dot glisse at normalesup dot org 2010-07-07 07:44
---
Created an attachment (id=21121)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21121action=view)
Trivial patch
There doesn't seem to be much point using --with-gmp-build (it is mostly useful
to improve
--- Comment #5 from rguenther at suse dot de 2010-07-07 08:35 ---
Subject: Re: [4.6 Regression] Bootstrap fails after
MEM-REF merge
On Tue, 6 Jul 2010, sje at cup dot hp dot com wrote:
--- Comment #4 from sje at cup dot hp dot com 2010-07-06 22:56 ---
I successfully
--- Comment #12 from rguenther at suse dot de 2010-07-07 08:38 ---
Subject: Re: [4.6 Regression] -fcompare-debug failure for
C++ i386.c
On Wed, 7 Jul 2010, amylaar at gcc dot gnu dot org wrote:
--- Comment #11 from amylaar at gcc dot gnu dot org 2010-07-07 02:16
---
(In
--- Comment #12 from rguenth at gcc dot gnu dot org 2010-07-07 08:43
---
(In reply to comment #11)
(In reply to comment #10)
My mistake. gcc.dg/pr39794.c failed with -m64 on Linux/x86-64, not
on Linux/ia32. The testcase in comment #7 started to fail between
revision 161671 and
--- Comment #1 from ramana at gcc dot gnu dot org 2010-07-07 08:43 ---
Can you reproduce this with GCC built using sources from http://gcc.gnu.org ?
If not please report such issues to the vendors of your toolchain. If you can
reproduce this with GCC built from FSF sources please let us
--- Comment #13 from rguenth at gcc dot gnu dot org 2010-07-07 08:51
---
It's a scheduling issue (and thus an alias issue). -fno-schedule-insns2 fixes
the problem. We mis-schedule the unrolled part.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #14 from rguenth at gcc dot gnu dot org 2010-07-07 09:01
---
Huh. Unrolling preserves MEM_ATTRs even though it re-writes the RTXen. That
causes scheduling to see just a bunch of repeated
(insn 218 309 219 18 t.c:9 (parallel [
(set (mem:SI (reg/v/f:DI 1 dx
--- Comment #5 from redi at gcc dot gnu dot org 2010-07-07 09:11 ---
(In reply to comment #3)
The answer is to
ensure the first, non-inline virtual function is defined. That's it.
In my humble opinion, no it's not the answer, at least not in my, and I guess
in many people's
--- Comment #2 from redi at gcc dot gnu dot org 2010-07-07 09:18 ---
You need to use -fPIC for a shared object, so the version without that is not
valid.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44855
--- Comment #3 from hlprasu at gmail dot com 2010-07-07 09:30 ---
Subject: Re: Static members not initialised in explicit
template instances of library
But, as I know, no where is it mentioned to be necessary for static
member initialisation. Why should the compiler allow for
--- Comment #15 from rakdver at kam dot mff dot cuni dot cz 2010-07-07
09:37 ---
Subject: Re: [4.6 regression] RTL loop
unrolling causes FAIL: gcc.dg/pr39794.c
--- Comment #14 from rguenth at gcc dot gnu dot org 2010-07-07 09:01
---
Huh. Unrolling preserves
--- Comment #16 from amonakov at gcc dot gnu dot org 2010-07-07 09:54
---
(In reply to comment #15)
Subject: Re: [4.6 regression] RTL loop
unrolling causes FAIL: gcc.dg/pr39794.c
I am not sure what you mean -- I may be misunderstanding how rtl alias
analysis
works, but
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-07-07 10:08 ---
This is the same as PR43270 (and the fix for it cures it).
*** This bug has been marked as a duplicate of 43270 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #18 from rguenth at gcc dot gnu dot org 2010-07-07 10:08
---
*** Bug 44848 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|r161876 breaks bootstrap on |[4.6 Regression] r161876
|darwin.
--- Comment #1 from burnus at gcc dot gnu dot org 2010-07-07 10:09 ---
Created an attachment (id=21122)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21122action=view)
Draft patch for kinds
Some constants such as GFC_STAT_STOPPED_IMAGE have been added as part of the
coarray work.
--- Comment #17 from rakdver at kam dot mff dot cuni dot cz 2010-07-07
10:09 ---
Subject: Re: [4.6 regression] RTL loop
unrolling causes FAIL: gcc.dg/pr39794.c
(In reply to comment #15)
Subject: Re: [4.6 regression] RTL loop
unrolling causes FAIL:
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44852
--- Comment #18 from rguenth at gcc dot gnu dot org 2010-07-07 10:30
---
(In reply to comment #17)
Subject: Re: [4.6 regression] RTL loop
unrolling causes FAIL: gcc.dg/pr39794.c
(In reply to comment #15)
Subject: Re: [4.6 regression] RTL loop
unrolling
--- Comment #19 from rakdver at kam dot mff dot cuni dot cz 2010-07-07
10:35 ---
Subject: Re: [4.6 regression] RTL loop
unrolling causes FAIL: gcc.dg/pr39794.c
I am not sure what you mean -- I may be misunderstanding how rtl alias
analysis
works, but as far as I
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-07-07 10:38 ---
Fixed at least for 4.3.5 4.4.5 and 4.5.1.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from rguenth at gcc dot gnu dot org 2010-07-07 10:43
---
(In reply to comment #19)
Subject: Re: [4.6 regression] RTL loop
unrolling causes FAIL: gcc.dg/pr39794.c
I am not sure what you mean -- I may be misunderstanding how rtl
alias analysis
--- Comment #21 from rakdver at kam dot mff dot cuni dot cz 2010-07-07
10:47 ---
Subject: Re: [4.6 regression] RTL loop
unrolling causes FAIL: gcc.dg/pr39794.c
Consider this simplified example:
for (i ...)
{
/*A*/ t = a[i];
/*B*/ a[i+1] = t;
--- Comment #22 from rguenth at gcc dot gnu dot org 2010-07-07 10:48
---
(In reply to comment #21)
Subject: Re: [4.6 regression] RTL loop
unrolling causes FAIL: gcc.dg/pr39794.c
Consider this simplified example:
for (i ...)
{
/*A*/ t =
--- Comment #23 from rakdver at kam dot mff dot cuni dot cz 2010-07-07
10:51 ---
Subject: Re: [4.6 regression] RTL loop
unrolling causes FAIL: gcc.dg/pr39794.c
Consider this simplified example:
for (i ...)
{
/*A*/ t = a[i];
/*B*/
--- Comment #24 from rguenth at gcc dot gnu dot org 2010-07-07 11:06
---
In
...
*p_1 = x;
y = *(p_1 + 1);
...
I can say that *p_1 does not alias *(p_1 + 1) independent on what code
is around. If it would be
BB3:
# p_1 = PHI p_0, p_2(3)
*p_1 = x;
y = *(p_1 + 1);
--- Comment #25 from matz at gcc dot gnu dot org 2010-07-07 11:15 ---
Due to SSA form the alias information reflects dependencies only between
accesses as if it ignores back edges. Hence any transformation that
transforms a back edge into a forward edge, or moves code over back edges
--- Comment #26 from rakdver at kam dot mff dot cuni dot cz 2010-07-07
11:19 ---
Subject: Re: [4.6 regression] RTL loop
unrolling causes FAIL: gcc.dg/pr39794.c
In
...
*p_1 = x;
y = *(p_1 + 1);
...
I can say that *p_1 does not alias *(p_1 + 1) independent
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-07-07 11:22 ---
The addition by 10 appears during postreload, where we substitute
(insn 24 35 65 4 t.i:9 (set (reg:QI 9 r9 [orig:44 prephitmp.3 ] [44])
(const_int 58 [0x3a])) 45 {movqi} (expr_list:REG_EQUAL (const_int 58
--- Comment #27 from rakdver at kam dot mff dot cuni dot cz 2010-07-07
11:31 ---
Subject: Re: [4.6 regression] RTL loop
unrolling causes FAIL: gcc.dg/pr39794.c
Due to SSA form the alias information reflects dependencies only between
accesses as if it ignores back edges.
--- Comment #28 from rguenth at gcc dot gnu dot org 2010-07-07 11:59
---
The following is a fix (or workaround) for the problem.
Index: gcc/tree-ssa-alias.c
===
--- gcc/tree-ssa-alias.c(revision 161869)
+++
--- Comment #29 from matz at gcc dot gnu dot org 2010-07-07 12:10 ---
[just for completeness to not lose the thought:]
Thinking about this some more (triggered by the problem of not having nice
back edges in irreducible loops), it's not really the back edges that are
interesting but the
Currently, gfortran saves scalar constants (PARAMETER) only in the .mod file
while array parameters are saved as global, static variable in the .o file and
additionally as expression in the .mod file.
This has all kind of funny consequences. For instance:
print *, array_par, (array_par),
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-07-07 12:43 ---
Subject: Bug 44790
Author: rguenth
Date: Wed Jul 7 12:43:38 2010
New Revision: 161907
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161907
Log:
2010-07-07 Richard Guenther rguent...@suse.de
PR
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-07-07 13:04 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from domob at gcc dot gnu dot org 2010-07-07 13:05 ---
See http://gcc.gnu.org/ml/fortran/2010-07/msg00058.html.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44709
--- Comment #26 from sfilippone at uniroma2 dot it 2010-07-07 13:15 ---
(In reply to comment #25)
This fixes test_vt2 but not test_coo. Will keep investigating.(and of
course it should be done for functions as well as subroutines...)
Index: gcc/fortran/resolve.c
--- Comment #13 from amylaar at gcc dot gnu dot org 2010-07-07 13:15
---
(In reply to comment #12)
Hm, different SSA name versions are not good - that might cause
code generation differences. Where do they first differ?
t.c.025t.einline2 / t.c.gk.025t.einline2
--
--- Comment #14 from amylaar at gcc dot gnu dot org 2010-07-07 13:22
---
(In reply to comment #12)
$ diff -u -I '^ # DEBUG.*$' t.c.025t.* t.c.gk.025t.*
--- t.c.025t.einline2 2010-07-07 13:59:11.251978485 +0100
+++ t.c.gk.025t.einline22010-07-07 13:59:11.451101846 +0100
@@
--- Comment #15 from jakub at gcc dot gnu dot org 2010-07-07 13:23 ---
The reduced testcase doesn't fail for me, the unreduced one fails though.
-fcompare-debug complains about different ORIGINAL_REGNOs and different ivtmp.*
names.
--
--- Comment #7 from jason at gcc dot gnu dot org 2010-07-07 13:24 ---
That thread does help, thanks. But part of my confusion was that the testcase
you added with that patch (abi/covariant1) didn't actually seem to test the
bug. When I add a definition of c14::f17, the test starts
--- Comment #16 from rguenther at suse dot de 2010-07-07 13:24 ---
Subject: Re: [4.6 Regression] -fcompare-debug failure for
C++ i386.c
On Wed, 7 Jul 2010, amylaar at gcc dot gnu dot org wrote:
--- Comment #14 from amylaar at gcc dot gnu dot org 2010-07-07 13:22
---
(In
--- Comment #2 from hjl at gcc dot gnu dot org 2010-07-07 13:33 ---
Subject: Bug 44844
Author: hjl
Date: Wed Jul 7 13:33:04 2010
New Revision: 161910
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161910
Log:
Retry rdrand if the carry flag isn't valid.
gcc/
2010-07-07 H.J. Lu
--- Comment #6 from hjl at gcc dot gnu dot org 2010-07-07 13:36 ---
Subject: Bug 44850
Author: hjl
Date: Wed Jul 7 13:36:31 2010
New Revision: 161911
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161911
Log:
Revert revision 161876.
2010-07-07 H.J. Lu hongjiu...@intel.com
Juan Rodriguez-Carvajal reported at
http://gcc.gnu.org/ml/fortran/2010-07/msg00057.html
that compiling the following program ICEs with:
f951.exe: internal compiler error: in output_constructor_regular_field, at
varasm.c:4996
It works with GCC 4.5 and might be due to the constructor
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.6.0
Known to work||4.5.0
Target
--- Comment #17 from amylaar at gcc dot gnu dot org 2010-07-07 13:48
---
(In reply to comment #16)
Maybe I'm blind, but the SSA name versions are all the same in
the above diff.
The ssa name 1881 gets changed to 1882, isn't that significant?
--
--- Comment #18 from jakub at gcc dot gnu dot org 2010-07-07 13:55 ---
That's not SSA name, but DECL_UID of the underlying decl.
I believe such changes are considered ok if it just means different gaps
between uids with -g vs. -g0.
--
--- Comment #8 from nathan at gcc dot gnu dot org 2010-07-07 13:56 ---
Hm, I guess I must have flubbed the testcase. After all this time, I don't
have a better recollection. Sorry.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43120
--- Comment #19 from rguenth at gcc dot gnu dot org 2010-07-07 13:57
---
Yes, that's ok. I'm re-reducing the testcase (which also fails with
-fno-ivopts).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832
--- Comment #30 from rguenth at gcc dot gnu dot org 2010-07-07 13:58
---
I'm going to test the patch in comment #28.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from amylaar at gcc dot gnu dot org 2010-07-07 14:00
---
Created an attachment (id=21123)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21123action=view)
typescript looking at inrements of next_decl_uid
The last ssa name before 1881 in the dump files is 1872; so
--- Comment #21 from amylaar at gcc dot gnu dot org 2010-07-07 14:02
---
(In reply to comment #19)
Yes, that's ok. I'm re-reducing the testcase (which also fails with
-fno-ivopts).
FWIW I've reduced the testcase with the aim of reproducing the problem in
r160832, which is when the
--- Comment #22 from amylaar at gcc dot gnu dot org 2010-07-07 14:06
---
(In reply to comment #18)
That's not SSA name, but DECL_UID of the underlying decl.
I believe such changes are considered ok if it just means different gaps
between uids with -g vs. -g0.
For compiler-generated
reg...@john-home:~$ current-gcc -O0 small.c -o small
reg...@john-home:~$ ./small
checksum g_610 = 1
reg...@john-home:~$ current-gcc -O1 small.c -o small
reg...@john-home:~$ ./small
checksum g_610 = 0
reg...@john-home:~$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
--- Comment #27 from sfilippone at uniroma2 dot it 2010-07-07 14:25 ---
(In reply to comment #26)
For the test_coo.f03 case, what happens is shown in the following dump.
{
struct class$base_sparse_mat class.6;
if (vtab$d_coo_sparse_mat.allocate == 0B)
{
--- Comment #23 from jakub at gcc dot gnu dot org 2010-07-07 14:25 ---
Hash tables hashed by DECL_UID should be traversed only when the traversal
order doesn't affect code generation. E.g. Richard fixed a few places to just
set
bits in a bitmap and then iterate over the bitmap for code
--- Comment #24 from rguenth at gcc dot gnu dot org 2010-07-07 14:34
---
Created an attachment (id=21124)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21124action=view)
less reduced testcase
Reduced at topformflat level 0 only.
--
--- Comment #1 from dmitrij dot ledkov at ubuntu dot com 2010-07-07 14:39
---
Duplicate of Bug #40868.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42311
--- Comment #1 from burnus at gcc dot gnu dot org 2010-07-07 14:47 ---
My idea is:
a) For scalar expressions, generate simply always the scalar variable.
b) For array accesses, generate a const variable at the beginning of the
current block (subroutine, function, BLOCK) - if the
--- Comment #25 from amylaar at gcc dot gnu dot org 2010-07-07 14:47
---
Created an attachment (id=21125)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21125action=view)
diff -u -I '^ # DEBUG.*$' t.c.093t.pre t.c.gk.093t.pre
Disregarding where merely the base names of ssa name
--- Comment #26 from rguenth at gcc dot gnu dot org 2010-07-07 14:48
---
The first difference appears in .093t.pre (comparing -nouid dumps):
cat ii386.3.3.i.gk.094t.pre | grep -v '# DEBUG' | diff -u ii386.3.3.i.094t.pre
- | less
void
struct Base1 {};
struct Derived1 : public Base1 {};
const Base1 f1() { Base1 x; return x; }
const Base1 f2() { return Base1(); }
const Base1 f3() { Derived1 x; return x; }
const Base1 f4() { return Derived1(); }
struct Base2 { int m_foo; };
struct Derived2 : public Base2 {};
const Base2 f5() {
--- Comment #27 from amylaar at gcc dot gnu dot org 2010-07-07 14:56
---
(In reply to comment #26)
The first difference appears in .093t.pre (comparing -nouid dumps):
cat ii386.3.3.i.gk.094t.pre | grep -v '# DEBUG' | diff -u ii386.3.3.i.094t.pre
- | less
is that .093t.pre or
--- Comment #28 from rguenth at gcc dot gnu dot org 2010-07-07 15:00
---
No, the culprit is loop header copying which causes
@@ -2634,8 +2634,8 @@
goto bb 8;
bb 8:
- # .MEM_6 = PHI .MEM_106(7), .MEM_105(D)(6)
- # .MEM_107 = VDEF .MEM_6
+ # .MEM_149 = PHI .MEM_106(7),
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- Comment #29 from amylaar at gcc dot gnu dot org 2010-07-07 15:06
---
(In reply to comment #26)
thus I think we have to look for an instability in the SCC walker.
There's a qsort call. Is compare_ops guaranteed never to return 0 for
items that are not identical?
--
--- Comment #2 from burnus at gcc dot gnu dot org 2010-07-07 15:20 ---
Created an attachment (id=21126)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21126action=view)
Test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40571
--- Comment #2 from burnus at gcc dot gnu dot org 2010-07-07 15:23 ---
Note: The tricky part for a simple fix is:
moduleArray(i)
If one simply wraps in resolve_code the code-expr(1,2) with parentheses (e =
gfc_get_parentheses (e)) this leads to D.123 = modulearray[i], which does
not
--- Comment #3 from burnus at gcc dot gnu dot org 2010-07-07 15:24 ---
See PR 44856 for the reason why it fails for some expressions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40571
--- Comment #6 from baldrick at gcc dot gnu dot org 2010-07-07 15:25
---
Fixed in commits 161918 (mainline) and 161919 (gcc-4.5 branch).
--
baldrick at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from bernds at gcc dot gnu dot org 2010-07-07 15:27 ---
Subject: Bug 44404
Author: bernds
Date: Wed Jul 7 15:26:48 2010
New Revision: 161920
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161920
Log:
PR rtl-optimization/44404
* auto-inc-dec.c
--- Comment #3 from sje at cup dot hp dot com 2010-07-07 15:30 ---
I haven't been able to come up with a test case other then bootstrapping. If I
build a non-bootstrap compiler and run the testsuite I don't get any unexpected
failures due to this problem. It is only when, during
--- Comment #1 from ro at gcc dot gnu dot org 2010-07-07 15:54 ---
Created an attachment (id=21127)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21127action=view)
preprocessed libfortran/io/format.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44843
--- Comment #2 from ro at gcc dot gnu dot org 2010-07-07 15:54 ---
A reghunt identified this patch as the culprit:
2010-07-05 Richard Guenther rguent...@suse.de
* tree.c (reference_alias_ptr_type): New function.
* tree.h (reference_alias_ptr_type): Declare.
*
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2010-07-07 16:24
---
I won't be able to start a regression hunt until this week-end.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44857
--- Comment #3 from hp at gcc dot gnu dot org 2010-07-07 16:24 ---
(In reply to comment #2)
The addition by 10 appears during postreload, where we substitute
...
which by itself doesn't look wrong.
That's right, if the two stores had been to different locations, it'd have been
--- Comment #4 from sje at cup dot hp dot com 2010-07-07 17:22 ---
The problem seems to happen when compiling cp/decl.c. If I compile this file
at -O1 instead of -O2 the resulting C++ compiler will work. I am trying to see
if I can track it down to one function within cp/decl.c.
--
--- Comment #30 from amylaar at gcc dot gnu dot org 2010-07-07 17:27
---
(In reply to comment #28)
No, the culprit is loop header copying which causes
I also see changes in the MEM_* after loop header copying.
It happens during the second call of copy_loop_header. Alas,
it seems
--- Comment #31 from amylaar at gcc dot gnu dot org 2010-07-07 17:50
---
(In reply to comment #30)
The first difference I seen in debug / no debug values of
cfun-gimple_df-free_ssanames-ssa_name.version for the relevant function
is in vrp.
Debug:
Hardware watchpoint 10:
--- Comment #18 from spop at gcc dot gnu dot org 2010-07-07 18:14 ---
Changpeng, should this PR be closed now?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44576
--- Comment #19 from changpeng dot fang at amd dot com 2010-07-07 19:00
---
(In reply to comment #18)
Changpeng, should this PR be closed now?
No. I am still looking at the dependence computation cost. I just found the
most of the time is spent in memory allocation and freeing of
The attached program causes spill failure on latest 4.5 branch with -mthumb
it fails when no -On is used and works when -Os/-O2 is used but fails again
when -fno-omit-frame-pointer is passed in addition to -Os or -O2
arm-oe-linux-uclibceabi-gcc -mthumb -Os -fno-omit-frame-pointer recvfrom.i
--- Comment #1 from raj dot khem at gmail dot com 2010-07-07 19:35 ---
Created an attachment (id=21128)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21128action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44860
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
--- Comment #32 from amylaar at gcc dot gnu dot org 2010-07-07 19:53
---
tree-vrp.c:find_switch_asserts uses compare_case_labels to sort case labels,
with the main key being the uid of the case label.
We have different case labels when debugging, and their uid sorts differently
in
cat bug.ii
bool f();
struct counted_base {
virtual void destroy() { }
void release() { if (f()) destroy(); }
};
struct shared_count {
shared_count() { }
~shared_count() { if (pi) pi-release(); }
shared_count(shared_count r) : pi(r.pi) { if (pi)
--- Comment #12 from hjl at gcc dot gnu dot org 2010-07-07 21:11 ---
Subject: Bug 44695
Author: hjl
Date: Wed Jul 7 21:11:25 2010
New Revision: 161933
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161933
Log:
Backport 8bit div/mod improvements.
gcc/
2010-07-07 H.J. Lu
--- Comment #7 from hjl at gcc dot gnu dot org 2010-07-07 21:11 ---
Subject: Bug 44588
Author: hjl
Date: Wed Jul 7 21:11:25 2010
New Revision: 161933
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161933
Log:
Backport 8bit div/mod improvements.
gcc/
2010-07-07 H.J. Lu
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2010-07-07 21:24
---
Fixed in commits 161918 (mainline) and 161919 (gcc-4.5 branch).
The right procedure is to copy-and-paste the ChangeLog entry in the commit log,
this will automatically add a cross-reference with an URL to this
--- Comment #2 from burnus at gcc dot gnu dot org 2010-07-07 21:28 ---
(In reply to comment #1)
I won't be able to start a regression hunt until this week-end.
Working: 2010-04-10-r158177
Failing: 2010-04-13-r158277
The array constructor work was merged as Rev. 158253 - thus, as
--- Comment #3 from hjl at gcc dot gnu dot org 2010-07-07 21:39 ---
Subject: Bug 44844
Author: hjl
Date: Wed Jul 7 21:39:30 2010
New Revision: 161936
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161936
Log:
Backport support for AVX Programming Reference (June, 2010).
gcc/
--- Comment #7 from hjl dot tools at gmail dot com 2010-07-07 21:41 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #4 from hjl dot tools at gmail dot com 2010-07-07 21:42 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
1 - 100 of 125 matches
Mail list logo
