[Bug c++/44841] Add suggestion to undefined reference to `vtable for ...�
--- 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 missing or deleted `= 0' While I think adding a note would be helpful, the suggestion above is ridiculous. It certainly shouldn't be the first suggestion. Of course this was just a quick scratch, but stating it's ridiculous is unnecessarily offending, i.e. ridiculous in itself. 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 cases. I did not want to define it, but wanted to have a purely virtual function, without definition. Again, the wording is just a quick scratch, but your answer which is it is not necessarily the right solution either. Suggestions about unintentionally becoming non-pure would cause more confusion than they would help. Well, it can be rephrased. Maybe something like Did you intend to make it a pure virtual function? Add `= 0' then. Otherwise, ensure to define the function. would be the better solution. However, the error comes from the linker, so there's nothing gcc can do about it when compiling. Okay, my fail to not know that ld bugs don't go here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44841
[Bug c++/44841] Add suggestion to undefined reference to `vtable for ...�
--- 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
[Bug c/44854] New: Improve diagnostic for missing member name or ';' in a struct
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 };
~~~ ^
Clang knows what you mean and the diagnostic message is better.
--
Summary: Improve diagnostic for missing member name or ';' in a
struct
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pzhao at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44854
[Bug target/44850] [4.6 Regression] Many test failures
--- 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 properly.
Some svr4 assemblers need to also have something extra said about the
function's return value. We allow for that here. */
#ifndef ASM_DECLARE_FUNCTION_NAME
#define ASM_DECLARE_FUNCTION_NAME(FILE, NAME, DECL) \
do\
{ \
ASM_OUTPUT_TYPE_DIRECTIVE (FILE, NAME, function); \
ASM_DECLARE_RESULT (FILE, DECL_RESULT (DECL));\
ASM_OUTPUT_LABEL (FILE, NAME);\
} \
while (0)
#endif
(and config/darwin.h, config/netbsd-aout.h and config/openbsd.h too).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44850
[Bug c++/44855] New: Static members not initialised in explicit template instances of library
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]; //! The storage of the data
static IndexType _size; //! The size of the data.
public:
CompileTimeFixedSizeData()
{
DEBUG1(Template value = Size std::endl);
DEBUG1(Static variable value = _size std::endl);
}
virtual ~CompileTimeFixedSizeData()
{}
};
//setting the value of _size, which is static
templatetypename X,int Size
IndexType CompileTimeFixedSizeDataX,Size::_size=Size;
/** Create an instance of CompileTimeFixedSizeData and associated functions.
*/
#define COMPILE_TIME_FIXED_SIZE_DATA_INSTANCE(TYPE,SIZE) \
template class CompileTimeFixedSizeDataTYPE,SIZE;
}
= testLib.cpp ===
#include testLib.h
namespace Upagraha
{
COMPILE_TIME_FIXED_SIZE_DATA_INSTANCE(double,3)
}
= main.cpp ===
#include testLib.h
namespace Upagraha {
//extern template class CompileTimeFixedSizeDatadouble,3;
// FIXME: Uncomment to see a change in behavior
}
int main()
{
Upagraha::CompileTimeFixedSizeDatadouble,3 a;
}
= makefile ===
#OPTIONS=-rdynamic -fno-implicit-templates -fPIC
OPTIONS=-rdynamic -fno-implicit-templates
# FIXME: Uncomment the top one to see change in behaviour
test:libtestLib.so testLib.h main.cpp
g++ $(OPTIONS) $(TOPTIONS) main.cpp -L${PWD} -ltestLib -o main
libtestLib.so: testLib.cpp testLib.h
g++ $(OPTIONS) $(TOPTIONS) -shared testLib.cpp -o libtestLib.so
clean:
rm main libtestLib.so *~
Put the above four files in same the directory and do the following
*) make
*) export LD_LIBRARY_PATH=$PWD
*) ./main
You'll see the output as
=
Template value = 3
Static variable value = 0
=
Now, follow either of the two FIXMEs and build the program and run to get
=
Template value = 3
Static variable value = 3
=
Why this difference in behaviour in initialisation of static variable
Upagraha::CompileTimeFixedSizeDataX,Size::_size? Could somebody please
explain this?
--
Summary: Static members not initialised in explicit template
instances of library
Product: gcc
Version: 4.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hlprasu at gmail dot com
GCC build triplet: i686-redhat-linux
GCC host triplet: i686-redhat-linux
GCC target triplet: i686-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44855
[Bug c++/44855] Static members not initialised in explicit template instances of library
--- 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 my previous post is packaged in a tar.bz2 file attached here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44855
[Bug bootstrap/44455] GCC fails to build if MPFR 3.0.0 (Release Candidate) is used
--- 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 performance a bit, but gcc explicitly tells GMP to be slow), so let's just use the same options as MPC. It works with mpfr 2.3.1 and 3.0.0. Any particular trap I am missing? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44455
[Bug middle-end/44790] [4.6 Regression] Bootstrap fails after MEM-REF merge
--- 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 bootstrapped ToT (after setting flag_partial_inlining to 0 to work around pr44716) using the patch. Testing also looked good, there are some new failures but they are all either new tests that may have never worked on this platform or tests that are also failing on other platforms. Ok. I'll bootstrap test the patch on x86_64-linux and apply it. Thanks, Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44790
[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c
--- 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 reply to comment #10)
;; Function void ix86_expand_vector_init_general(bool, machine_mode, rtx,
rtx)
Compiling the reduced testcase in a subdirectory of the r160832 gcc build
directory with:
../g++ -B.. -da -march=pentiumpro -mtune=generic -m32 t.c --dump-tree-all
-g
-S -fdump-unnumbered
, I see this in the final dump:
Hmm, that's actually the same as for r160828; but still, r160828 passes the
-fcompare-debug debug test with the reduced test case, while r160832 fails it.
Running this test with --save-temps and diffing the output shows that somehow
we end up with different tmp_var_id_num values for variables created by
tree-ssa-pre.c:
--- t.gkd 2010-07-07 03:02:40.831101079 +0100
+++ t.gk.gkd2010-07-07 03:02:40.886978157 +0100
@@ -454,9 +454,9 @@
(insn:TI# 0 0 t.c:78 (set (reg/f:SI 2 cx [116])
(mem/s/f:SI (plus:SI (mult:SI (reg/v:SI 0 ax [orig:80 i ] [80])
(const_int 4 [0x4]))
-(reg/f:SI 3 bx [orig:95 pretmp.21 ] [95])) [ *pretmp.21_81 S4
A32]))# {*movsi_1} (expr_list:REG_EQUIV (mem/s/f:SI (plus:SI (mult:SI
(reg/v:SI
0 ax [orig:80 i ] [80])
+(reg/f:SI 3 bx [orig:95 pretmp.21 ] [95])) [ *pretmp.21_82 S4
A32]))# {*movsi_1} (expr_list:REG_EQUIV (mem/s/f:SI (plus:SI (mult:SI
(reg/v:SI
0 ax [orig:80 i ] [80])
(const_int 4 [0x4]))
-(reg/f:SI 3 bx [orig:95 pretmp.21 ] [95])) [ *pretmp.21_81 S4
A32])
+(reg/f:SI 3 bx [orig:95 pretmp.21 ] [95])) [ *pretmp.21_82 S4
A32])
(nil)))
(insn:TI# 0 0 t.c:78 (set (mem/s/f:SI (plus:SI (plus:SI (mult:SI (reg/v:SI 0
ax [orig:80 i ] [80])
(const_int 4 [0x4]))
Hm, different SSA name versions are not good - that might cause
code generation differences. Where do they first differ?
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832
[Bug middle-end/44838] [4.6 regression] FAIL: gcc.dg/pr39794.c
--- 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 161840. I am doing a binary search. It may be the real cause. It is caused by revision 161840: http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg00194.html How can that be the cause if the failure happens without IVOPTs? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44838
[Bug c/44853] can't find a register in class 'GENERAL_REGS' while reloading 'asm'
--- 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 know. Also give a better testcase which is consistent, complete and small, this is code with undefined behaviour, at the very best this is the Compiler ICE'ing on invalid code. All your local variables are uninitialized and they've been marked as input constraints to your asm. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44853
[Bug rtl-optimization/44838] [4.6 regression] RTL loop unrolling and scheduling cause FAIL: gcc.dg/pr39794.c
--- 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 |Added CC||rguenth at gcc dot gnu dot ||org Component|middle-end |rtl-optimization Keywords||alias, wrong-code Summary|[4.6 regression] FAIL: |[4.6 regression] RTL loop |gcc.dg/pr39794.c|unrolling and scheduling ||cause FAIL: gcc.dg/pr39794.c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44838
[Bug rtl-optimization/44838] [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 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 [orig:100 a ] [100]) [2 *a_22+0 S4
A32])
(ashift:SI (mem:SI (reg/v/f:DI 1 dx [orig:100 a ] [100]) [2
*a_22+0 S4 A32])
(const_int 1 [0x1])))
(clobber (reg:CC 17 flags))
]) 490 {*ashlsi3_1} (expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_EQUAL (ashift:SI (mem:SI (plus:DI (reg/v/f:DI 0 ax
[orig:84 a ] [84])
(const_int 16 [0x10])) [2 *a_22+0 S4 A32])
(const_int 1 [0x1]))
(nil
(insn 220 219 221 18 t.c:10 (set (reg:SI 4 si [103])
(mem:SI (plus:DI (reg/v/f:DI 1 dx [orig:100 a ] [100])
(const_int -8 [0xfff8])) [2 MEM[(int *)a_22 +
-8B]+0 S4 A32])) 63 {*movsi_internal} (nil))
(insn 221 220 222 18 t.c:10 (parallel [
(set (reg:SI 4 si [103])
(plus:SI (reg:SI 4 si [103])
(mem:SI (plus:DI (reg/v/f:DI 1 dx [orig:100 a ] [100])
(const_int -4 [0xfffc])) [2 MEM[(int
*)a_22 + -4B]+0 S4 A32])))
(clobber (reg:CC 17 flags))
]) 251 {*addsi_1} (expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(insn 222 221 310 18 t.c:10 (set (mem:SI (plus:DI (reg/v/f:DI 1 dx [orig:100 a
] [100])
(const_int 4 [0x4])) [2 MEM[(int *)a_22 + 4B]+0 S4 A32])
(reg:SI 4 si [103])) 63 {*movsi_internal} (expr_list:REG_DEAD (reg:SI 4
si [103])
(expr_list:REG_DEAD (reg/v/f:DI 1 dx [orig:100 a ] [100])
(expr_list:REG_EQUAL (plus:SI (mem:SI (plus:DI (reg/v/f:DI 1 dx
[orig:100 a ] [100])
(const_int -8 [0xfff8])) [2 MEM[(int
*)a_22 + -8B]+0 S4 A32])
(mem:SI (plus:DI (reg/v/f:DI 1 dx [orig:100 a ] [100])
(const_int -4 [0xfffc])) [2 MEM[(int
*)a_22 + -4B]+0 S4 A32]))
(nil)
where there is obviously no conflicts between the above patterns during
different unrolled copies.
Who is supposed to magically deal with that? (or what is supposed to prevent
this from happening?)
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rakdver at gcc dot gnu dot
||org
Summary|[4.6 regression] RTL loop |[4.6 regression] RTL loop
|unrolling and scheduling|unrolling causes FAIL:
|cause FAIL: gcc.dg/pr39794.c|gcc.dg/pr39794.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44838
[Bug c++/44841] Add suggestion to undefined reference to `vtable for ...�
--- 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 cases. I did not want to define it, but wanted to have a purely virtual function, without definition. Well if you follow my rule you'd look at your class to see which is the first non-inline virtual and you'd realise frob() isn't pure, and be able to change that if that's what you want. Again, the wording is just a quick scratch, but your answer which is it is not necessarily the right solution either. It's better to be able to fix the general case by following a simple rule than to make the compiler enumerate all the possible ways a user might have got it wrong. The ways to write invalid code are almost infinite. There's often only one way to get it right. Suggestions about unintentionally becoming non-pure would cause more confusion than they would help. Well, it can be rephrased. Maybe something like Did you intend to make it a pure virtual function? Add `= 0' then. Otherwise, ensure to define the function. would be the better solution. I disagree. It's far more common for this error to be caused by a missing definition, or by having no non-inline virtuals, than a function which is meant to be pure but has been declared wrong. You've made a particular mistake and you're asking for the compiler to be modified to tell you exactly what you need to change. There are a few different ways to get this error, I don't think yours is the most common, so I don't think your suggestion is the right one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44841
[Bug c++/44855] Static members not initialised in explicit template instances of library
--- 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
[Bug c++/44855] Static members not initialised in explicit template instances of library
--- 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 such a subtle error? Or is this documented somewhere? Besides this issue, I've not faced any other problem in using shared library by not using -fPIC. Could you please point out the necessary implications that I am missing here? On 7 July 2010 14:48, redi at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- 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
[Bug rtl-optimization/44838] [4.6 regression] RTL loop unrolling causes FAIL: gcc.dg/pr39794.c
--- 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 MEM_ATTRs even though it re-writes the RTXen. That causes scheduling to see just a bunch of repeated where there is obviously no conflicts between the above patterns during different unrolled copies. Who is supposed to magically deal with that? (or what is supposed to prevent this from happening?) I am not sure what you mean -- I may be misunderstanding how rtl alias analysis works, but as far as I can tell, what unroller does (just preserving the MEM_ATTRs) is conservatively correct (so, potentially it may make us believe that there are dependences that are not really present, but it should not cause a wrong-code bug). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44838
[Bug rtl-optimization/44838] [4.6 regression] RTL loop unrolling causes FAIL: gcc.dg/pr39794.c
--- 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 as far as I can tell, what unroller does (just preserving the
MEM_ATTRs) is conservatively correct (so, potentially it may make us believe
that there are dependences that are not really present, but it should not
cause
a wrong-code bug).
Consider this simplified example:
for (i ...)
{
/*A*/ t = a[i];
/*B*/ a[i+1] = t;
}
MEM_ATTRS would indicate that memory references in A and B do not alias.
Unrolling by 2 produces:
for (i ...)
{
/*A */ t = a[i];
/*B */ a[i+1] = t;
/*A'*/ t = a[i+1];
/*B'*/ a[i+2] = t;
}
Preserving MEM_ATTRS wrongly indicates that memory references in B and A' do
not alias, and the scheduler then may happen to lift A' above B.
--
amonakov at gcc dot gnu dot org changed:
What|Removed |Added
CC||amonakov at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44838
[Bug c/44848] Bogus array subscript is below array bounds with loops
--- 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 |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44848
[Bug tree-optimization/43270] array-bounds false negative
--- 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 CC||eli dot friedman at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43270
[Bug bootstrap/44849] [4.6 Regression] r161876 breaks bootstrap on darwin.
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|r161876 breaks bootstrap on |[4.6 Regression] r161876 |darwin. |breaks bootstrap on darwin. Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44849
[Bug fortran/40571] F2008: ISO_FORTRAN_ENV: Missing constants
--- 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. Besides the compiler_*() functions (PR 40569), the coarray LOCK_* types are missing. To this patch: It adds support for the *_kinds parameter arrays. TODO: a) It does not fully work, while the following is OK print *, (real_kinds), shape(real_kinds) without (), it gives a linker error: print *, real_kinds namely: undefined reference to `__iso_fortran_env_MOD_integer_kinds' b) The .texi changes are missing -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40571
[Bug rtl-optimization/44838] [4.6 regression] RTL loop unrolling causes FAIL: gcc.dg/pr39794.c
--- 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: 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 can tell, what unroller does (just preserving the
MEM_ATTRs) is conservatively correct (so, potentially it may make us believe
that there are dependences that are not really present, but it should not
cause
a wrong-code bug).
Consider this simplified example:
for (i ...)
{
/*A*/ t = a[i];
/*B*/ a[i+1] = t;
}
MEM_ATTRS would indicate that memory references in A and B do not alias.
but this is clearly wrong, since B in iteration X aliases with A in iteration
X+1.
So, not a problem in unroller.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44838
[Bug middle-end/44852] [4.6 Regression]: miscompilation of newlib dtoa.c after mem-ref2 merge
-- 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
[Bug rtl-optimization/44838] [4.6 regression] RTL loop unrolling causes FAIL: gcc.dg/pr39794.c
--- 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 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 can tell, what unroller does (just preserving the
MEM_ATTRs) is conservatively correct (so, potentially it may make us
believe
that there are dependences that are not really present, but it should not
cause
a wrong-code bug).
Consider this simplified example:
for (i ...)
{
/*A*/ t = a[i];
/*B*/ a[i+1] = t;
}
MEM_ATTRS would indicate that memory references in A and B do not alias.
but this is clearly wrong, since B in iteration X aliases with A in iteration
X+1.
So, not a problem in unroller.
It is not wrong. You have the two identical pointers p = a[i] and
q = p + 1. *p and *q do not alias. Never.
Now unrolling rewrites p and q but does not adjust MEM_ATTRs. So
alias information still claims the same pointer bases are used for
every unrolled load/store, which is certainly not true.
(In the past we didn't preserve pointer bases at all, which is why
we didn't hit this before. Starting with 4.5.0 and export of
points-to information we do, so passes need to fix MEM_ATTRs accordingly)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44838
[Bug rtl-optimization/44838] [4.6 regression] RTL loop unrolling causes FAIL: gcc.dg/pr39794.c
--- 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 can tell, what unroller does (just preserving the
MEM_ATTRs) is conservatively correct (so, potentially it may make us
believe
that there are dependences that are not really present, but it should
not cause
a wrong-code bug).
Consider this simplified example:
for (i ...)
{
/*A*/ t = a[i];
/*B*/ a[i+1] = t;
}
MEM_ATTRS would indicate that memory references in A and B do not alias.
but this is clearly wrong, since B in iteration X aliases with A in
iteration
X+1.
So, not a problem in unroller.
It is not wrong. You have the two identical pointers p = a[i] and
q = p + 1. *p and *q do not alias. Never.
Well, then you have some other definition of aliasing than me. For me, two
memory references M1 and M2 do not alias, if on every code path, the locations
accessed by M1 and M2 are different. With this definition, *p and *q may
alias,
as the example above shows. What is your definition?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44838
[Bug c++/44851] questionable 'anonymous' may be used uninitialized warning and code failure
--- 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 Status|UNCONFIRMED |RESOLVED Keywords||wrong-code Known to fail||4.2.4 4.3.4 4.4.3 4.5.0 Known to work||4.1.2 4.3.5 4.4.5 4.5.1 Resolution||FIXED Target Milestone|--- |4.3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44851
[Bug rtl-optimization/44838] [4.6 regression] RTL loop unrolling causes FAIL: gcc.dg/pr39794.c
--- 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
works, but as far as I can tell, what unroller does (just preserving
the
MEM_ATTRs) is conservatively correct (so, potentially it may make us
believe
that there are dependences that are not really present, but it should
not cause
a wrong-code bug).
Consider this simplified example:
for (i ...)
{
/*A*/ t = a[i];
/*B*/ a[i+1] = t;
}
MEM_ATTRS would indicate that memory references in A and B do not alias.
but this is clearly wrong, since B in iteration X aliases with A in
iteration
X+1.
So, not a problem in unroller.
It is not wrong. You have the two identical pointers p = a[i] and
q = p + 1. *p and *q do not alias. Never.
Well, then you have some other definition of aliasing than me. For me, two
memory references M1 and M2 do not alias, if on every code path, the locations
accessed by M1 and M2 are different. With this definition, *p and *q may
alias,
as the example above shows. What is your definition?
My definition is that the two statements in sequence A, B have a
true dependence if stmt B accesses memory written to by A.
Thus, in this context *p and *q do not alias (and this is what
the scheduler and every other optimization pass queries).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44838
[Bug rtl-optimization/44838] [4.6 regression] RTL loop unrolling causes FAIL: gcc.dg/pr39794.c
--- 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;
}
MEM_ATTRS would indicate that memory references in A and B do not
alias.
but this is clearly wrong, since B in iteration X aliases with A in
iteration
X+1.
So, not a problem in unroller.
It is not wrong. You have the two identical pointers p = a[i] and
q = p + 1. *p and *q do not alias. Never.
Well, then you have some other definition of aliasing than me. For me, two
memory references M1 and M2 do not alias, if on every code path, the
locations
accessed by M1 and M2 are different. With this definition, *p and *q may
alias,
as the example above shows. What is your definition?
My definition is that the two statements in sequence A, B have a
true dependence if stmt B accesses memory written to by A.
Thus, in this context *p and *q do not alias (and this is what
the scheduler and every other optimization pass queries).
what do you mean by statements in sequence?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44838
[Bug rtl-optimization/44838] [4.6 regression] RTL loop unrolling causes FAIL: gcc.dg/pr39794.c
--- 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 = a[i];
/*B*/ a[i+1] = t;
}
MEM_ATTRS would indicate that memory references in A and B do not
alias.
but this is clearly wrong, since B in iteration X aliases with A in
iteration
X+1.
So, not a problem in unroller.
It is not wrong. You have the two identical pointers p = a[i] and
q = p + 1. *p and *q do not alias. Never.
Well, then you have some other definition of aliasing than me. For me,
two
memory references M1 and M2 do not alias, if on every code path, the
locations
accessed by M1 and M2 are different. With this definition, *p and *q may
alias,
as the example above shows. What is your definition?
My definition is that the two statements in sequence A, B have a
true dependence if stmt B accesses memory written to by A.
Thus, in this context *p and *q do not alias (and this is what
the scheduler and every other optimization pass queries).
what do you mean by statements in sequence?
statement B executes after A.
Note that the issue we run into here is partly (or completely?) due to
the fact that the pointer variables in MEM_ATTRs are SSA names and
that we still honor their single-definition (and thus trivial
equality) property on RTL.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44838
[Bug rtl-optimization/44838] [4.6 regression] RTL loop unrolling causes FAIL: gcc.dg/pr39794.c
--- 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*/ a[i+1] = t;
}
MEM_ATTRS would indicate that memory references in A and B do not
alias.
but this is clearly wrong, since B in iteration X aliases with A in
iteration
X+1.
So, not a problem in unroller.
It is not wrong. You have the two identical pointers p = a[i] and
q = p + 1. *p and *q do not alias. Never.
Well, then you have some other definition of aliasing than me. For me,
two
memory references M1 and M2 do not alias, if on every code path, the
locations
accessed by M1 and M2 are different. With this definition, *p and *q
may
alias,
as the example above shows. What is your definition?
My definition is that the two statements in sequence A, B have a
true dependence if stmt B accesses memory written to by A.
Thus, in this context *p and *q do not alias (and this is what
the scheduler and every other optimization pass queries).
what do you mean by statements in sequence?
statement B executes after A.
which means what? In the example above, due to the loop, you cannot say which
statement
executes after which.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44838
[Bug rtl-optimization/44838] [4.6 regression] RTL loop unrolling causes FAIL: gcc.dg/pr39794.c
--- 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); p_2 = p_1 + 1; goto BB3; that would be still correct (I can exchange those two statements). For cross loop-iteration dependence after unrolling you would see accesses based on different pointer SSA name bases. Now on RTL we are not in SSA form and so yes, this change might be a bit fishy (I, too, just discovered this side-effect and I assumed passes would already to something here). A way around this is to either adjust or clear MEM_OFFSET. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44838
[Bug rtl-optimization/44838] [4.6 regression] RTL loop unrolling causes FAIL: gcc.dg/pr39794.c
--- 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 needs to do adjustment to the alias info (effectively doing something like PHI translation, or making the alias info simply more imprecise). Hmpf. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44838
[Bug rtl-optimization/44838] [4.6 regression] RTL loop unrolling causes FAIL: gcc.dg/pr39794.c
--- 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 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); p_2 = p_1 + 1; goto BB3; that would be still correct (I can exchange those two statements). Well, yes. Still, I would like to hear your formal definition of what it means for two memory references (not to) alias. We certainly can modify the code to ensure such a property, but just toying around without knowing precisely what this property is definitely is not a good idea. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44838
[Bug middle-end/44852] [4.6 Regression]: miscompilation of newlib dtoa.c after mem-ref2 merge
--- 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
[0x3a])
(nil)))
for
(insn 24 35 65 4 t.i:9 (set (reg:QI 9 r9 [orig:44 prephitmp.3 ] [44])
(plus:QI (reg:QI 9 r9 [orig:44 prephitmp.3 ] [44])
(const_int 10 [0xa]))) 77 {*addqi3_non_v32} (expr_list:REG_EQUAL
(const_int 58 [0x3a])
(nil)))
in
(insn 69 34 35 4 t.i:8 (set (reg:QI 9 r9)
(const_int 48 [0x30])) 45 {movqi} (nil))
(insn 35 69 24 4 t.i:8 (set (mem:QI (plus:SI (reg/v/f:SI 10 r10 [orig:47 s ]
[47])
(const_int -1 [0x])) [0 MEM[(char *)s_22 +
4294967295B]+0 S1 A8])
(reg:QI 9 r9)) 45 {movqi} (nil))
(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
[0x3a])
(nil)))
which by itself doesn't look wrong.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44852
[Bug rtl-optimization/44838] [4.6 regression] RTL loop unrolling causes FAIL: gcc.dg/pr39794.c
--- 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. Well, this is closer to what I was asking for; so, the actual definition that we use is: Two memory references M1 and M2 (appearing in statements S1 and S2) if for every code execution path P, and every appearance A1 of S1 and A2 of S2 in P such that no backedge is taken between A1 and A2, the memory locations accessed in A1 and A2 are different. Still, this is somewhat ambiguous (in the presence of irreducible loops, it is not quite clear what is a backedge). Hence any transformation that transforms a back edge into a forward edge, or moves code over back edges needs to do adjustment to the alias info (effectively doing something like PHI translation, or making the alias info simply more imprecise). Hmpf. It is kind of unpleasant that this affects optimizations like loop unrolling, which should make sheduling better (but likely won't do as well if we have to just throw away the results of alias analysis). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44838
[Bug rtl-optimization/44838] [4.6 regression] RTL loop unrolling causes FAIL: gcc.dg/pr39794.c
--- 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)
+++ gcc/tree-ssa-alias.c(working copy)
@@ -801,7 +780,8 @@ indirect_refs_may_alias_p (tree ref1 ATT
/* If both bases are based on pointers they cannot alias if they may not
point to the same memory object or if they point to the same object
and the accesses do not overlap. */
- if (operand_equal_p (ptr1, ptr2, 0))
+ if (gimple_in_ssa_p (cfun)
+ operand_equal_p (ptr1, ptr2, 0))
{
if (TREE_CODE (base1) == MEM_REF)
offset1 += mem_ref_offset (base1).low * BITS_PER_UNIT;
In SSA form we are sure that if two SSA names are equal their (same) definition
dominates them. So if you ask whether the two memory references do alias
if they are still in loopy form they do not. For every iteration they
have a strict ordering with respect to the definition of their name.
Now if you unroll the loop and re-instantiate SSA form you can't use the
previous alias query result to determine cross-loop-iteration dependences.
The above patch disables offset-based disambiguation for accesses via
pointers (technically a nice thing to have).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44838
[Bug rtl-optimization/44838] [4.6 regression] RTL loop unrolling causes FAIL: gcc.dg/pr39794.c
--- 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 underlying property of SSA, namely the correspondence between static single assignments and dynamic single assignments: The alias oracle will give correct answers only for memory references when it can infer runtime equality of values from syntactic equality, which it can for a correct SSA program. So, if M1 and M2 (two memrefs) contain mentions of syntactically the same values, then A1/A2 (two accesses to M1/M2) have to be dominated by the dynamically same definitions of those values. For SSA form that's trivially true, for RTL of course it isn't. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44838
[Bug fortran/44856] New: Usage of array PARAMETERs: Literal copy vs. global variable
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), shape(array_par) Here, the first item is accessed via the global variable, for the second one a static variable is produced in place, which is then accessed, and for the third one, the front end simplifies the expression and generates an variable containing the shape. Similarly for: a = array_par(1) a = array_par(1) + 0 In the first case, one accesses the global variable while in the second case, one generates a temporary local variable, initialized by the literal. There are a couple of issues: a) For intrinsic modules, it does not work (cf. PR 40571) as there is no .o file. b) Accessing the global variable in case of taking a scalar does not make sense: a = parameter_array(1) should always use (a local variable with) the literal. c) Also in other cases, it can make sense to generate a local copy of the literal - as done in case of (parameter_array) - though, one probably wants to limit the inline size. Comments? Suggestions? -- Summary: Usage of array PARAMETERs: Literal copy vs. global variable Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org OtherBugsDependingO 40571 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44856
[Bug middle-end/44790] [4.6 Regression] Bootstrap fails after MEM-REF merge
--- 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 middle-end/44790 * expr.c (expand_expr_real_1): Go the POINTER_PLUS_EXPR path for expanding the constant offset for MEM_REFs. Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44790
[Bug middle-end/44790] [4.6 Regression] Bootstrap fails after MEM-REF merge
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44790
[Bug fortran/44709] BLOCK and GOTO/EXIT/CYCLE
--- 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
[Bug fortran/43945] [OOP] Derived type with GENERIC: resolved to the wrong specific TBP
--- 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 === --- gcc/fortran/resolve.c (revisione 161820) +++ gcc/fortran/resolve.c (copia locale) @@ -5593,7 +5593,7 @@ gfc_symbol *vtab; vtab = gfc_find_derived_vtab (declared, true); gcc_assert (vtab); - gfc_add_component_ref (code-expr1, genname); + /* gfc_add_component_ref (code-expr1, genname); */ } gfc_add_component_ref (code-expr1, name); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43945
[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832
[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c
--- 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 @@ -149,14 +161,14 @@ int i; int n; struct rtx_def * ops[32]; + unsigned char D.1889; unsigned char D.1888; - unsigned char D.1887; + int D.1887; int D.1886; - int D.1885; int ix86_isa_flags.6; - struct rtx_def * D.1883; - struct rtvec_def * D.1882; - const unsigned char D.1881; + struct rtx_def * D.1884; + struct rtvec_def * D.1883; + const unsigned char D.1882; int mode.5; struct rtvec_def * * D.1872; int D.1817; @@ -329,22 +365,26 @@ L27: mode.5_58 = (int) mode_12; - D.1881_59 = mode_nunits[mode.5_58]; - n_60 = (int) D.1881_59; + D.1882_59 = mode_nunits[mode.5_58]; + n_60 = (int) D.1882_59; + # DEBUG n = n_60 ix86_expand_vector_init_concat (mode_12, target_10(D), ops[0], n_60); goto bb 32; half: mode.5_61 = (int) mode_12; - D.1881_62 = mode_nunits[mode.5_61]; - n_63 = (int) D.1881_62; + D.1882_62 = mode_nunits[mode.5_61]; + n_63 = (int) D.1882_62; + # DEBUG n = n_63 + # DEBUG i = 0 goto bb 26; bb 25: - D.1882_64 = *D.1872_50; - D.1883_66 = D.1882_64-elem[i_65]; - ops[i_65] = D.1883_66; + D.1883_64 = *D.1872_50; + D.1884_66 = D.1883_64-elem[i_65]; + ops[i_65] = D.1884_66; i_67 = i_65 + 1; + # DEBUG i = i_67 bb 26: # i_65 = PHI 0(24), i_67(25) @@ -359,25 +401,26 @@ L29: ix86_isa_flags.6_68 = ix86_isa_flags; - D.1885_69 = ix86_isa_flags.6_68 524288; - if (D.1885_69 == 0) + D.1886_69 = ix86_isa_flags.6_68 524288; + if (D.1886_69 == 0) goto bb 30 (L31); else goto bb 29 (L30); L30: ix86_isa_flags.6_70 = ix86_isa_flags; - D.1886_71 = ix86_isa_flags.6_70 131072; - if (D.1886_71 == 0) + D.1887_71 = ix86_isa_flags.6_70 131072; + if (D.1887_71 == 0) goto bb 30 (L31); else goto bb 32; L31: mode.5_72 = (int) mode_12; - D.1887_73 = mode_size[mode.5_72]; - D.1888_74 = D.1887_73 / 4; - if (D.1888_74 == 4) + D.1888_73 = mode_size[mode.5_72]; + D.1889_74 = D.1888_73 / 4; + # DEBUG n_words = (int) D.1889_74 + if (D.1889_74 == 4) goto bb 31; else goto bb 32; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832
[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c
--- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832
[Bug c++/43120] Virtual inheritence with covariant return type confuses GCC
--- 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 failing; even 3.4 refers to the no-this-adjustment covariant thunk in the c14 vtable. So I'm not sure what the patch was actually doing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43120
[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c
--- 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 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 @@ -149,14 +161,14 @@ int i; int n; struct rtx_def * ops[32]; + unsigned char D.1889; unsigned char D.1888; - unsigned char D.1887; + int D.1887; int D.1886; - int D.1885; int ix86_isa_flags.6; - struct rtx_def * D.1883; - struct rtvec_def * D.1882; - const unsigned char D.1881; + struct rtx_def * D.1884; + struct rtvec_def * D.1883; + const unsigned char D.1882; int mode.5; struct rtvec_def * * D.1872; int D.1817; @@ -329,22 +365,26 @@ L27: mode.5_58 = (int) mode_12; - D.1881_59 = mode_nunits[mode.5_58]; - n_60 = (int) D.1881_59; + D.1882_59 = mode_nunits[mode.5_58]; + n_60 = (int) D.1882_59; + # DEBUG n = n_60 ix86_expand_vector_init_concat (mode_12, target_10(D), ops[0], n_60); goto bb 32; half: mode.5_61 = (int) mode_12; - D.1881_62 = mode_nunits[mode.5_61]; - n_63 = (int) D.1881_62; + D.1882_62 = mode_nunits[mode.5_61]; + n_63 = (int) D.1882_62; + # DEBUG n = n_63 + # DEBUG i = 0 goto bb 26; bb 25: - D.1882_64 = *D.1872_50; - D.1883_66 = D.1882_64-elem[i_65]; - ops[i_65] = D.1883_66; + D.1883_64 = *D.1872_50; + D.1884_66 = D.1883_64-elem[i_65]; + ops[i_65] = D.1884_66; i_67 = i_65 + 1; + # DEBUG i = i_67 bb 26: # i_65 = PHI 0(24), i_67(25) @@ -359,25 +401,26 @@ L29: ix86_isa_flags.6_68 = ix86_isa_flags; - D.1885_69 = ix86_isa_flags.6_68 524288; - if (D.1885_69 == 0) + D.1886_69 = ix86_isa_flags.6_68 524288; + if (D.1886_69 == 0) goto bb 30 (L31); else goto bb 29 (L30); L30: ix86_isa_flags.6_70 = ix86_isa_flags; - D.1886_71 = ix86_isa_flags.6_70 131072; - if (D.1886_71 == 0) + D.1887_71 = ix86_isa_flags.6_70 131072; + if (D.1887_71 == 0) goto bb 30 (L31); else goto bb 32; L31: mode.5_72 = (int) mode_12; - D.1887_73 = mode_size[mode.5_72]; - D.1888_74 = D.1887_73 / 4; - if (D.1888_74 == 4) + D.1888_73 = mode_size[mode.5_72]; + D.1889_74 = D.1888_73 / 4; + # DEBUG n_words = (int) D.1889_74 + if (D.1889_74 == 4) goto bb 31; else goto bb 32; Maybe I'm blind, but the SSA name versions are all the same in the above diff. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832
[Bug target/44844] Wrong _rdrand_uXX intrinsic implementation
--- 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 hongjiu...@intel.com PR target/44844 * config/i386/i386.md (rdrandmode): Changed to expand to retry if the carry flag isn't valid. (rdrandmode_1): New. gcc/testsuite/ 2010-07-07 H.J. Lu hongjiu...@intel.com PR target/44844 * gcc.target/i386/rdrand-1.c: Scan jnc. * gcc.target/i386/rdrand-2.c: Likewise. * gcc.target/i386/rdrand-3.c: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/rdrand-1.c trunk/gcc/testsuite/gcc.target/i386/rdrand-2.c trunk/gcc/testsuite/gcc.target/i386/rdrand-3.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44844
[Bug target/44850] [4.6 Regression] Many test failures
--- 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 PR target/44850 * config/i386/i386.c (ix86_function_ms_hook_prologue): Revert revision 161876. (ix86_expand_prologue): Likewise. (ix86_handle_fndecl_attribute): Likewise. (ix86_asm_declare_function_name): Likewise. * config/i386/i386.h (ASM_DECLARE_FUNCTION_NAME): Likewise. * config/i386/cygming.h (ASM_DECLARE_FUNCTION_NAME): Likewise. (SUBTARGET_ASM_DECLARE_FUNCTION_NAME): Likewise. * config/i386/i386-protos.h (ix86_asm_declare_function_name): Likewise. * doc/extend.texi: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/cygming.h trunk/gcc/config/i386/i386-protos.h trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.h trunk/gcc/doc/extend.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44850
[Bug fortran/44857] New: [4.6 Regression] ICE in output_constructor_regular_field, at varasm.c:4996
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 reorganization. Module CFML_String_Utilities implicit none private Type, Public :: Err_Text_Type integer :: nlines character (len=132), dimension(5) :: txt End Type Err_Text_Type Type (Err_Text_Type), public :: Mess_FindFMT = Err_Text_Type(0, (/ , , , , /)) End Module CFML_String_Utilities -- Summary: [4.6 Regression] ICE in output_constructor_regular_field, at varasm.c:4996 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44857
[Bug fortran/44857] [4.6 Regression] ICE in output_constructor_regular_field, at varasm.c:4996
-- burnus at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.6.0 Known to work||4.5.0 Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44857
[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c
--- 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? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832
[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c
--- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832
[Bug c++/43120] Virtual inheritence with covariant return type confuses GCC
--- 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
[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c
--- 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
[Bug rtl-optimization/44838] [4.6 regression] RTL loop unrolling causes FAIL: gcc.dg/pr39794.c
--- 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 AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-07-06 21:40:24 |2010-07-07 13:58:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44838
[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c
--- 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 the increment to 1873 should be legitimate. Any idea which of the logged increments I should take a closer look at? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832
[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c
--- 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 un-reduced testcase first fails. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832
[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c
--- 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 temporary variables, isn't the DECL_UID part of the name? And doesn't that affect hash tables, and thus ordering? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832
[Bug c/44858] New: likely integer wrong code bug
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
COLLECT_LTO_WRAPPER=/home/regehr/z/compiler-install/gcc-r161813-install/libexec/gcc/i686-pc-linux-gnu/4.6.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r161813-install
--program-prefix=r161813- --enable-languages=c,c++
Thread model: posix
gcc version 4.6.0 20100704 (experimental) (GCC)
reg...@john-home:~$ cat small.c
extern int printf (__const char *__restrict __format, ...);
int g_33 = 3;
int g_610 = 1;
long long foo(int i1, int i2)
{
return (i1 / i2);
}
int main(void)
{
int l_2 = 2;
l_2 = foo(1, g_610) g_610;
g_610 = (g_33 != 0) | l_2;
printf(checksum g_610 = %d\n, g_610);
return l_2;
}
--
Summary: likely integer wrong code bug
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: regehr at cs dot utah dot edu
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44858
[Bug fortran/43945] [OOP] Derived type with GENERIC: resolved to the wrong specific TBP
--- 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)
{
vtab$d_coo_sparse_mat.allocate_mnnz = (void (*T62) (void))
d_coo_allocate_mnnz;
vtab$d_coo_sparse_mat.set_null = (void (*T62) (void)) d_coo_set_null;
vtab$d_coo_sparse_mat.get_fmt = (void (*T62) (void)) d_coo_get_fmt;
}
class.6.$vptr = (struct vtype$base_sparse_mat * {ref-all})
vtab$d_coo_sparse_mat;
class.6.$data = (struct base_sparse_mat *) acoo;
base_allocate_mnnz (n, n, class.6, nnz);
}
At the end of the block, since the type of acoo is known at compile time, the
call gets resolved to base_allocate_mnnz, instead of resolving to
vtab$d_coo_sparse_mat.allocate_mnnz
which would contain the correct function.
As shown in test_vt2, when the dynamic type is not known at compile time the
naive diff I posted works.
What happens in the code is that when the compiler enters this function
static gfc_try
resolve_typebound_static (gfc_expr* e, gfc_symtree** target,
gfc_actual_arglist** actual)
{
gcc_assert (e-expr_type == EXPR_COMPCALL);
gcc_assert (!e-value.compcall.tbp-is_generic);
/* Update the actual arglist for PASS. */
if (update_compcall_arglist (e) == FAILURE)
return FAILURE;
*actual = e-value.compcall.actual;
*target = e-value.compcall.tbp-u.specific;
gfc_free_ref_list (e-ref);
e-ref = NULL;
e-value.compcall.actual = NULL;
return SUCCESS;
}
we have
(gdb) print *(e-value.compcall.tbp-u.specific)
$7 = {priority = 3856, left = 0x0, right = 0x0, name = 0x71ae24c8
base_allocate_mnnz, ambiguous = 0, n = {sym = 0x13c6580, uop = 0x13c6580,
common = 0x13c6580, tb = 0x13c6580}}
instead of pointing to the correct d_coo_allocate_mnnz (to which the vtab is
correctly pointing).
I have nowhere near enough knowledge of the code to conceive a fix, hopefully
someone knowledgeable will take up..
Moreover, there still is the issue of initializing CLASS allocatables (see
generic_23_1.f03) where it appears that something is missing after (sourced)
allocation.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43945
[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c
--- 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 generation (which means gaps between uids don't affect code generation, just reordering of decl uids could). You can just compare -fdump-final-insns= dumps from the -fcompare-debug invocation, that's what is actually being compared. Those dumps are with TDF_NOUID. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832
[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c
--- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832
[Bug java/42311] Cross build fails because native gcj needed to build ecjx
--- 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
[Bug fortran/44856] Usage of array PARAMETERs: Literal copy vs. global variable
--- 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 variable is smaller than -farray-parameter-inline-limit or if from an intrinsic module. The trick for (b) is to collect this information in the symbol attribute (i.e. not needed if never access or when only scalars are accessed). Additionally, one needs to make sure that then in the current block the copied parameter is accessed. I think a reasonable value for the limit could be something like 10, 20. (I am actually not sure whether the FE does mark the module global parameters variable as restricted or as constant. If one and if possible, one should do so.) An example. The trick is to make sure that (ModulePara(1)) does not simply generate, e.g., D.1558 = modulepara[0]; which is pointless. module m integer, parameter :: ModulePara(2) = [ 1, 2 ] end module m program test use m implicit none integer :: (2),i i=1 = ModulePara ! access modulepara (1) print *, ModulePara ! access modulepara (2) print *, ModulePara(i)! access modulepara (3) print *, ModulePara(i)+i ! access modulepara (4) print *, ModulePara(i)+1 ! access modulepara (5) (1) = (ModulePara(1)) ! use literal (1) = ModulePara(1) ! use literal print *, ModulePara(1)! use literal end program test Dump contains the (correct!) six accesses to modulepara (5 + extern). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44856
[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c
--- 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 versions vary according to the DECL_UID, the first ssa name version change is in 093t.pre -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832
[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c
--- 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
_ZL31ix86_expand_vector_init_generalb12machine_modeP7rtx_defS1_.isra.0(boo
l, machine_mode, rtx, rtvec_def**) (bool mmx_ok, machine_mode mode, struct
rtx_d
ef * target, struct rtvec_def * * ISRA.45)
{
- int pretmp.167;
struct rtvec_def * pretmp.166;
int pretmp.165;
struct rtvec_def * pretmp.164;
@@ -4625,11 +4624,11 @@
goto bb 8;
bb 44:
- pretmp.166_99 = *ISRA.45_147(D);
+ pretmp.166_11 = *ISRA.45_147(D);
bb 7:
# i_173 = PHI i_13(46), 0(44)
- D._10 = pretmp.166_99;
+ D._10 = pretmp.166_11;
D._12 = D._10-elem[i_173];
ops[i_173] = D._12;
i_13 = i_173 + 1;
where we have differences in assigned value-numbers and walk SCCs in a
different oder.
SCC consists of: i_172 i_21
vs.
SCC consists of: i_173 i_13
thus I think we have to look for an instability in the SCC walker.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832
[Bug c++/44859] New: missed warning: returning reference to temporary
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() { Base2 x; return x; }
const Base2 f6() { return Base2(); }
const Base2 f7() { Derived2 x; return x; }
const Base2 f8() { return Derived2(); }
g++ emits a warning for all cases (either reference to local variable x
returned or returning reference to temporary), except for the last case f8.
Adding -Wall -Wextra does not change anything. Apparently this seems to be
caused by the cast of a temporary (in contrast to the local variable in f7) to
a non-empty base class.
It would be nice if g++ would warn for this case as well.
--
Summary: missed warning: returning reference to temporary
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joachim dot reichel at gmx dot de
GCC build triplet: x64_64-unknown-linux-gnu
GCC host triplet: x64_64-unknown-linux-gnu
GCC target triplet: x64_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44859
[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c
--- 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 .094t.pre ? And what revision of trunk are you looking at? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832
[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c
--- 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), .MEM_105(D)(6) + # .MEM_107 = VDEF .MEM_149 ix86_expand_vector_init_concat (mode_1(D), target_14(D), ops, n_8); goto bb 34; @@ -2665,8 +2665,8 @@ goto bb 11; bb 11: - # .MEM_15 = PHI .MEM_108(10), .MEM_105(D)(9) - # .MEM_109 = VDEF .MEM_15 + # .MEM_6 = PHI .MEM_108(10), .MEM_105(D)(9) + # .MEM_109 = VDEF .MEM_6 op0_23 = gen_reg_rtx (half_mode_22); # .MEM_110 = VDEF .MEM_109 op1_24 = gen_reg_rtx (half_mode_22); @@ -2826,8 +2826,8 @@ bb 23: # word_48 = PHI word_96(22), word_97(24) - # .MEM_37 = PHI .MEM_102(22), .MEM_98(24) - # .MEM_128 = VDEF .MEM_37 + # .MEM_26 = PHI .MEM_102(22), .MEM_98(24) + # .MEM_128 = VDEF .MEM_26 words[i_163] = word_48; i_78 = i_163 + 1; if (n_words_54 i_78) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832
[Bug c++/44859] missed warning: returning reference to temporary
-- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2010-07-07 15:04:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44859
[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c
--- 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? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832
[Bug fortran/40571] F2008: ISO_FORTRAN_ENV: Missing constants
--- 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
[Bug fortran/44856] Usage of array PARAMETERs: Literal copy vs. global variable
--- 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 help for internal modules (cf. PR 40571) ... -- burnus at gcc dot gnu dot org changed: What|Removed |Added Keywords||rejects-valid http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44856
[Bug fortran/40571] F2008: ISO_FORTRAN_ENV: Missing constants
--- 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
[Bug tree-optimization/41355] Type of ADDR_EXPR in CALL_EXPR not rebuilt when function is cloned
--- 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 Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41355
[Bug rtl-optimization/44404] auto-inc-dec generates an invalid assembly instruction
--- 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 (find_inc): Avoid calling count_occurrences if possible, use reg_overlap_mentioned_p instead. Modified: trunk/gcc/ChangeLog trunk/gcc/auto-inc-dec.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44404
[Bug middle-end/44716] [4.6 Regression] Bootstrap fails with partial inlining (r161382)
--- 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 bootstrap, I run the cc1plus executable that was built by the stage1 cc1 that I get a failure. At that point trying to compile any C++ program with cc1plus results in cc1plus aborting. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44716
[Bug middle-end/44843] [4.6 regression] All 32-bit fortran execution tests SEGV on SPARC: unaligned access
--- 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
[Bug middle-end/44843] [4.6 regression] All 32-bit fortran execution tests SEGV on SPARC: unaligned access
--- 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. * tree-ssa-loop-ivopts.c (copy_ref_info): Restructure to allow non-TARGET_MEM_REF new refs. (rewrite_use_address): Pass old alias pointer type to create_mem_ref. * tree-ssa-address.c (create_mem_ref_raw): Get alias pointer type. Build a MEM_REF instead of a TARGET_MEM_REF if possible. (create_mem_ref): Get alias pointer type. Adjust calls to create_mem_ref_raw. (maybe_fold_tmr): Likewise. * tree-flow.h (create_mem_ref): Adjust prototype. I'm attaching the preprocessed format.i (from libgfortran/io/format.c). The patch changes format.s as follows: --- format.s2010-07-07 16:26:07.933989030 +0200 +++ /var/gcc/gcc-4.6.0-20100705/10-gcc/sparc-sun-solaris2.10/libgfortran/format. s 2010-07-07 16:23:08.775373256 +0200 @@ -2267,7 +2267,7 @@ _gfortrani_free_format_hash_table: ld [%i0+248], %g1 orcc%g1, 0, %o0 be,a,pn %icc, .LL256 -st %g0, [%i0+240] +stx%g0, [%i0+240] .LLSM424: call_gfortrani_free_format_data, 0 nop I.e. a store to [%i0+240] is done with stx, although the destination isn't 8-byte aligned. I'm compiling the .i file like this: ./cc1 -fpreprocessed format.i -mcpu=v9 -g -O2 -std=gnu99 -fcx-fortran-rules -ffunction-sections -fdata-sections -fPIC -o format.s $ -- ro at gcc dot gnu dot org changed: What|Removed |Added CC||rguenther at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44843
[Bug fortran/44857] [4.6 Regression] ICE in output_constructor_regular_field, at varasm.c:4996
--- 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
[Bug middle-end/44852] [4.6 Regression]: miscompilation of newlib dtoa.c after mem-ref2 merge
--- 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 optimal (the add by 10 being shorter than loading the constant 0x3a; no scheduling issues). But, JFTR, that observation is just incidental and beside the point. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44852
[Bug middle-end/44716] [4.6 Regression] Bootstrap fails with partial inlining (r161382)
--- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44716
[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.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 that copy_loop_header is innocent, because it gets different freed ssa name versions for debug / no debug compilation: Debug: Breakpoint 5, copy_loop_headers () at ../../gcc/gcc/tree-ssa-loop-ch.c:140 140 loop_optimizer_init (LOOPS_HAVE_PREHEADERS (gdb) call debug_tree(cfun-gimple_df-free_ssanames) ssa_name 0xb7db20f0 nothrow var var_decl 0xb7d97060 retval.3def_stmt version 87 in-free-list (gdb) call debug_tree(cfun-gimple_df-free_ssanames-common.chain) ssa_name 0xb7dacfc0 nothrow var var_decl 0xb7d91d80 retval.1def_stmt version 83 in-free-list No debug: Breakpoint 5, copy_loop_headers () at ../../gcc/gcc/tree-ssa-loop-ch.c:140 140 loop_optimizer_init (LOOPS_HAVE_PREHEADERS (gdb) call debug_tree(cfun-gimple_df-free_ssanames) ssa_name 0xb7da5f90 nothrow var var_decl 0xb7d95060 retval.3def_stmt version 87 in-free-list (gdb) call debug_tree(cfun-gimple_df-free_ssanames-common.chain) ssa_name 0xb7da5db0 nothrow var var_decl 0xb7d90d80 retval.1def_stmt version 82 in-free-list -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832
[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c
--- 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: cfun-gimple_df-free_ssanames Old value = (tree) 0xb7db2330 New value = (tree) 0xb7dacf60 release_ssa_name (var=0xb7dacf60) at ../../gcc/gcc/tree-ssanames.c:241 241 } 2: cfun-gimple_df-free_ssanames-ssa_name.version = 82 (gdb) bt #0 release_ssa_name (var=0xb7dacf60) at ../../gcc/gcc/tree-ssanames.c:241 #1 0x086a280e in release_defs (stmt=0xb7dacf90) at ../../gcc/gcc/tree-ssanames.c:293 #2 0x086d85e6 in remove_range_assertions () at ../../gcc/gcc/tree-vrp.c:5326 #3 execute_vrp () at ../../gcc/gcc/tree-vrp.c:7442 #4 0x084d5797 in execute_one_pass (pass=0x8c42f00) at ../../gcc/gcc/passes.c:1576 #5 0x084d5a9d in execute_pass_list (pass=0x8c42f00) at ../../gcc/gcc/passes.c:1631 #6 0x084d5ab0 in execute_pass_list (pass=0x8c41d80) at ../../gcc/gcc/passes.c:1632 #7 0x085d562a in tree_rest_of_compilation (fndecl=0xb7d88980) at ../../gcc/gcc/tree-optimize.c:420 #8 0x0876e5bc in cgraph_expand_function (node=0xb7cf686c) at ../../gcc/gcc/cgraphunit.c:1632 #9 0x0876ffd9 in cgraph_expand_all_functions () at ../../gcc/gcc/cgraphunit.c:1711 #10 cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1967 #11 0x08770995 in cgraph_finalize_compilation_unit () at ../../gcc/gcc/cgraphunit.c:1171 #12 0x0818863a in cp_write_global_declarations () at ../../gcc/gcc/cp/decl2.c:3925 #13 0x0857c650 in compile_file (argc=21, argv=0xb494) ---Type return to continue, or q return to quit---q at ../../gcc/gcc/topleQuit (gdb) frame 4 #4 0x084d5797 in execute_one_pass (pass=0x8c42f00) at ../../gcc/gcc/passes.c:1576 1576 todo_after = pass-execute (); (gdb) p pass-name $5 = 0x8aa58e2 vrp No debug: Hardware watchpoint 12: cfun-gimple_df-free_ssanames Old value = (tree) 0xb7dad1b0 New value = (tree) 0xb7da5d50 release_ssa_name (var=0xb7da5d50) at ../../gcc/gcc/tree-ssanames.c:241 241 } 3: cfun-gimple_df-free_ssanames-ssa_name.version = 81 1: cfun-decl = (tree) 0xb7d88900 (gdb) bt #0 release_ssa_name (var=0xb7da5d50) at ../../gcc/gcc/tree-ssanames.c:241 #1 0x086a280e in release_defs (stmt=0xb7da5d80) at ../../gcc/gcc/tree-ssanames.c:293 #2 0x086d85e6 in remove_range_assertions () at ../../gcc/gcc/tree-vrp.c:5326 #3 execute_vrp () at ../../gcc/gcc/tree-vrp.c:7442 #4 0x084d5797 in execute_one_pass (pass=0x8c42f00) at ../../gcc/gcc/passes.c:1576 #5 0x084d5a9d in execute_pass_list (pass=0x8c42f00) at ../../gcc/gcc/passes.c:1631 #6 0x084d5ab0 in execute_pass_list (pass=0x8c41d80) at ../../gcc/gcc/passes.c:1632 #7 0x085d562a in tree_rest_of_compilation (fndecl=0xb7d88900) at ../../gcc/gcc/tree-optimize.c:420 #8 0x0876e5bc in cgraph_expand_function (node=0xb7cf6498) at ../../gcc/gcc/cgraphunit.c:1632 #9 0x0876ffd9 in cgraph_expand_all_functions () at ../../gcc/gcc/cgraphunit.c:1711 #10 cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1967 #11 0x08770995 in cgraph_finalize_compilation_unit () at ../../gcc/gcc/cgraphunit.c:1171 #12 0x0818863a in cp_write_global_declarations () at ../../gcc/gcc/cp/decl2.c:3925 #13 0x0857c650 in compile_file (argc=19, argv=0xb4b4) ---Type return to continue, or q return to quit---q at ../../gcc/gcc/topleQuit (gdb) frame 4 #4 0x084d5797 in execute_one_pass (pass=0x8c42f00) at ../../gcc/gcc/passes.c:1576 1576 todo_after = pass-execute (); (gdb) p pass-name $7 = 0x8aa58e2 vrp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832
[Bug middle-end/44576] [4.5/4.6 Regression] testsuite/gfortran.dg/zero_sized_1.f90 with huge compile time on prefetching + peeling
--- 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
[Bug middle-end/44576] [4.5/4.6 Regression] testsuite/gfortran.dg/zero_sized_1.f90 with huge compile time on prefetching + peeling
--- 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 data dependence relatiuon structure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44576
[Bug target/44860] New: Thumb ICE due to spill failure
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
recvfrom.i: In function '__libc_recvfrom':
recvfrom.i:5:9: error: unable to find a register to spill in class 'LO_REGS'
recvfrom.i:5:9: error: this is the insn:
(insn 73 19 74 2 recvfrom.i:5 (set (reg:SI 12 ip [150])
(const_int 146 [0x92])) 167 {*thumb1_movsi_insn} (expr_list:REG_EQUAL
(const_int 146 [0x92])
(nil)))
recvfrom.i:5: confused by earlier errors, bailing out
here is the test case
extern __thread int __libc_errno __attribute__ ((tls_model (initial-exec)));
int __libc_recvfrom(
int sockfd, void * buffer, int len, int flags, void * to, void * tolen) {
return (int)({
unsigned int _inline_sys_result = ({ unsigned int _internal_sys_result;
{ int _sys_buf[2]; register int _a1 __asm__ (a1); register int *_v3 __asm__
(v3) = _sys_buf; int _v2tmp = (int) (tolen); int _v1tmp = (int) (to); int
_a4tmp = (int) (flags); int _a3tmp = (int) (len); int _a2tmp = (int) (buffer);
int _a1tmp = (int) (sockfd); _a1 = _a1tmp; register int _a2 __asm__ (a2) =
_a2tmp; register int _a3 __asm__ (a3) = _a3tmp; register int _a4 __asm__
(a4) = _a4tmp; register int _v1 __asm__ (v1) = _v1tmp; register int _v2
__asm__ (v2) = _v2tmp; *_v3 = (int) (((0 +292))); __asm__ __volatile__ (str
r7, [v3, #4]\n \tldr r7, [v3]\n \tswi 0 @ syscall
SYS_ify(__libc_recvfrom) \n \tldr r7, [v3, #4] : =r (_a1) : r
(_v3) , r (_a1), r (_a2), r (_a3), r (_a4), r (_v1), r (_v2) :
memory); _internal_sys_result = _a1; } (int) _internal_sys_result; }); if
(__builtin_expect (((unsigned int) (_inline_sys_result) = 0xf001u), 0)) {
(__libc_errno = ((-(_inline_sys_result; _inline_sys_result = (unsigned int)
-1; } (int) _inline_sys_result; }); }
--
Summary: Thumb ICE due to spill failure
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: raj dot khem at gmail dot com
GCC build triplet: x86_64-linux
GCC host triplet: x86_64-linux
GCC target triplet: arm-oe-linux-uclibceabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44860
[Bug target/44860] Thumb ICE due to spill failure
--- 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
[Bug rtl-optimization/44469] [4.5/4.6 Regression] internal compiler error: in fixup_reorder_chain, at cfglayout.c:797
-- 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 | Status|NEW |ASSIGNED Last reconfirmed|2010-06-24 21:40:33 |2010-07-07 19:43:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44469
[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c
--- 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 relation to user labels that happen to become case labels. With debug enabled, the label 'half' is sorted at the start of the array: (gdb) call debug_tree($49[0]) case_label_expr 0xb7dab0b4 type void_type 0xb7d00840 void asm_written VOID align 8 symtab 0 alias set -1 canonical type 0xb7d00840 pointer_to_this pointer_type 0xb7d008a0 side-effects tree_1 arg 0 integer_cst 0xb7d18300 type integer_type 0xb7d002a0 int constant 5 arg 2 label_decl 0xb7d99bd0 half type void_type 0xb7d00840 void VOID file t.c line 75 col 1 align 1 context function_decl 0xb7d88980 ix86_expand_vector_init initial error_mark 0xb7cf07e0 abstract_origin label_decl 0xb7cf9f18 half t.c:73:5 (gdb) call debug_tree((tree)0xb7d99bd0) label_decl 0xb7d99bd0 half type void_type 0xb7d00840 void asm_written VOID align 8 symtab 0 alias set -1 canonical type 0xb7d00840 pointer_to_this pointer_type 0xb7d008a0 VOID file t.c line 75 col 1 align 1 context function_decl 0xb7d88980 ix86_expand_vector_init initial error_mark 0xb7cf07e0 abstract_origin label_decl 0xb7cf9f18 half (gdb) p ((tree)0xb7d99bd0)-decl_minimal.uid $50 = 1877 (gdb) call debug_tree($49[1]) case_label_expr 0xb7dab024 type void_type 0xb7d00840 void asm_written VOID align 8 symtab 0 alias set -1 canonical type 0xb7d00840 pointer_to_this pointer_type 0xb7d008a0 side-effects tree_1 arg 2 label_decl 0xb7d99c24 L. type void_type 0xb7d00840 void used ignored VOID file t.c line 95 col 5 align 1 context function_decl 0xb7d88980 ix86_expand_vector_init abstract_origin label_decl 0xb7d93000 L. t.c:95:5 (gdb) p ((tree)0xb7d99c24)-decl_minimal.uid $51 = 1890 With debug disabled, 'half' sorts at the end of the array: (gdb) call debug_tree($44[3]) case_label_expr 0xb7da4090 type void_type 0xb7d00840 void VOID align 8 symtab 0 alias set -1 canonical type 0xb7d00840 pointer_to_this pointer_type 0xb7d008a0 side-effects tree_1 arg 0 integer_cst 0xb7d182a0 type integer_type 0xb7d002a0 int constant 3 arg 1 integer_cst 0xb7d182d0 type integer_type 0xb7d002a0 int constant 4 arg 2 label_decl 0xb7d98c24 L.27 type void_type 0xb7d00840 void used ignored VOID file t.c line 67 col 5 align 1 context function_decl 0xb7d88900 ix86_expand_vector_init abstract_origin label_decl 0xb7cf9e1c L.0 t.c:67:5 (gdb) call debug_tree($44[4]) case_label_expr 0xb7da40b4 type void_type 0xb7d00840 void VOID align 8 symtab 0 alias set -1 canonical type 0xb7d00840 pointer_to_this pointer_type 0xb7d008a0 side-effects tree_1 arg 0 integer_cst 0xb7d18300 type integer_type 0xb7d002a0 int constant 5 arg 2 label_decl 0xb7d98c78 half type void_type 0xb7d00840 void used VOID file t.c line 75 col 1 align 1 context function_decl 0xb7d88900 ix86_expand_vector_init initial error_mark 0xb7cf07e0 abstract_origin label_decl 0xb7cf9f18 half t.c:73:5 (gdb) p ((tree)0xb7d98c24)-decl_minimal.uid $46 = 1892 (gdb) p ((tree)0xb7d98c78)-decl_minimal.uid $47 = 1893 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832
[Bug tree-optimization/44861] New: internal compiler error: in vectorizable_load, at tree-vect-stmts.c:3812
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) pi-release(); }
counted_base* pi;
};
struct Foo;
struct shared_ptr {
Foo operator*() { return *ptr; }
Foo* ptr;
shared_count refcount;
};
struct Bar {
Bar(Foo, shared_ptr);
};
void g() {
shared_ptr foo;
new Bar(*foo, foo);
}
g++ -O2 -ftree-vectorize bug.ii
bug.ii: In function void g():
bug.ii:27:6: internal compiler error: in vectorizable_load, at
tree-vect-stmts.c:3812
I'm using SVN revision tr...@161911 on linux_x86_64.
--
Summary: internal compiler error: in vectorizable_load, at tree-
vect-stmts.c:3812
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wouter dot vermaelen at scarlet dot be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44861
[Bug rtl-optimization/44695] [4.6 Regression] ice in simplify_subreg, at simplify-rtx.c:5117
--- 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 hongjiu...@intel.com Backport from mainline 2010-07-04 H.J. Lu hongjiu...@intel.com PR rtl-optimization/44695 * config/i386/i386.md (extract_code): Removed. (udivmodqi4): Likewise. (divmodqi4): New. (udivmodqi4): Likewise. (divmodhiqi3): Change div/mod to HImode and extend operand 2 to HImode. (udivmodhiqi3): Likewise. 2010-06-24 H.J. Lu hongjiu...@intel.com PR target/44588 * config/i386/i386.md (extract_code): New. (udivmodqi4): Likewise. (divmodhiqi3): Likewise. (udivmodhiqi3): Likewise. (udivqi3): Remvoved. gcc/testsuite/ 2010-07-07 H.J. Lu hongjiu...@intel.com Backport from mainline 2010-07-04 H.J. Lu hongjiu...@intel.com PR rtl-optimization/44695 * gcc.dg/torture/pr44695.c: New. 2010-06-24 H.J. Lu hongjiu...@intel.com PR target/44588 * gcc.target/i386/mod-1.c: New. * gcc.target/i386/umod-1.c: Likewise. * gcc.target/i386/umod-2.c: Likewise. * gcc.target/i386/umod-3.c: Likewise. Modified: branches/ix86/gcc-4_5-branch/gcc/config/i386/i386.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44695
[Bug target/44588] Very inefficient 8bit mod/div
--- 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 hongjiu...@intel.com Backport from mainline 2010-07-04 H.J. Lu hongjiu...@intel.com PR rtl-optimization/44695 * config/i386/i386.md (extract_code): Removed. (udivmodqi4): Likewise. (divmodqi4): New. (udivmodqi4): Likewise. (divmodhiqi3): Change div/mod to HImode and extend operand 2 to HImode. (udivmodhiqi3): Likewise. 2010-06-24 H.J. Lu hongjiu...@intel.com PR target/44588 * config/i386/i386.md (extract_code): New. (udivmodqi4): Likewise. (divmodhiqi3): Likewise. (udivmodhiqi3): Likewise. (udivqi3): Remvoved. gcc/testsuite/ 2010-07-07 H.J. Lu hongjiu...@intel.com Backport from mainline 2010-07-04 H.J. Lu hongjiu...@intel.com PR rtl-optimization/44695 * gcc.dg/torture/pr44695.c: New. 2010-06-24 H.J. Lu hongjiu...@intel.com PR target/44588 * gcc.target/i386/mod-1.c: New. * gcc.target/i386/umod-1.c: Likewise. * gcc.target/i386/umod-2.c: Likewise. * gcc.target/i386/umod-3.c: Likewise. Modified: branches/ix86/gcc-4_5-branch/gcc/config/i386/i386.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44588
[Bug tree-optimization/41355] Type of ADDR_EXPR in CALL_EXPR not rebuilt when function is cloned
--- 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 audit trail. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41355
[Bug fortran/44857] [4.6 Regression] ICE in output_constructor_regular_field, at varasm.c:4996
--- 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 written, I think it might be due to that check in: http://gcc.gnu.org/viewcvs?view=revrevision=158253 Thus, the proper way is probably to find out what goes wrong rather than looking for the breaking patch ... By the way, I stumbled over PR 22210, which seems to be vaguely related (or obsoleted). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44857
[Bug target/44844] Wrong _rdrand_uXX intrinsic implementation
--- 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/ 2010-07-07 H.J. Lu hongjiu...@intel.com Backport from mainline 2010-07-07 H.J. Lu hongjiu...@intel.com PR target/44844 * config/i386/i386.md (rdrandmode): Changed to expand to retry if the carry flag isn't valid. (rdrandmode_1): New. 2010-07-05 H.J. Lu hongjiu...@intel.com AVX Programming Reference (June, 2010) * config/i386/cpuid.h (bit_F16C): New. (bit_RDRND): Likewise. (bit_FSGSBASE): Likewise. * config/i386/i386-builtin-types.def: Add DEF_FUNCTION_TYPE (UINT16), function types for float16 - float conversions and DEF_FUNCTION_TYPE (VOID, UINT64). * config/i386/i386-c.c (ix86_target_macros_internal): Support OPTION_MASK_ISA_FSGSBASE, OPTION_MASK_ISA_RDRND and OPTION_MASK_ISA_F16C. * config/i386/i386.c (OPTION_MASK_ISA_FSGSBASE_SET): New. (OPTION_MASK_ISA_RDRND_SET): Likewise. (OPTION_MASK_ISA_F16C_SET): Likewise. (OPTION_MASK_ISA_FSGSBASE_UNSET): Likewise. (OPTION_MASK_ISA_RDRND_UNSET): Likewise. (OPTION_MASK_ISA_F16C_UNSET): Likewise. (OPTION_MASK_ISA_AVX_UNSET): Add OPTION_MASK_ISA_F16C_UNSET. (ix86_handle_option): Handle OPT_mfsgsbase, OPT_mrdrnd and OPT_mf16c. (ix86_target_string): Support -mfsgsbase, -mrdrnd and -mf16c. (pta_flags): Add PTA_FSGSBASE, PTA_RDRND and PTA_F16C. (override_options): Handle them. (ix86_valid_target_attribute_inner_p): Handle fsgsbase, rdrnd and f16c. (ix86_builtins): Add IX86_BUILTIN_RDFSBASE32, IX86_BUILTIN_RDFSBASE64, IX86_BUILTIN_RDGSBASE32, IX86_BUILTIN_RDGSBASE64, IX86_BUILTIN_WRFSBASE32, IX86_BUILTIN_WRFSBASE64, IX86_BUILTIN_WRGSBASE32, IX86_BUILTIN_WRGSBASE64, IX86_BUILTIN_RDRAND16, IX86_BUILTIN_RDRAND32, IX86_BUILTIN_RDRAND64, IX86_BUILTIN_CVTPH2PS, IX86_BUILTIN_CVTPH2PS256, IX86_BUILTIN_CVTPS2PH and IX86_BUILTIN_CVTPS2PH256. (bdesc_args): Likewise. (ix86_expand_args_builtin): Handle V8SF_FTYPE_V8HI, V4SF_FTYPE_V8HI, V8HI_FTYPE_V8SF_INT and V8HI_FTYPE_V4SF_INT. (ix86_expand_special_args_builtin): Handle VOID_FTYPE_UINT64, VOID_FTYPE_UNSIGNED, UNSIGNED_FTYPE_VOID and UINT16_FTYPE_VOID. Handle non-memory store. * config/i386/i386.h (TARGET_FSGSBASE): New. (TARGET_RDRND): Likewise. (TARGET_F12C): Likewise. * config/i386/i386.md (UNSPEC_VCVTPH2PS): New. (UNSPEC_VCVTPS2PH): Likewise. (UNSPECV_RDFSBASE): Likewise. (UNSPECV_RDGSBASE): Likewise. (UNSPECV_WRFSBASE): Likewise. (UNSPECV_WRGSBASE): Likewise. (UNSPECV_RDRAND): Likewise. (rdfsbasemode): Likewise. (rdgsbasemode): Likewise. (wrfsbasemode): Likewise. (wrgsbasemode): Likewise. (rdrandmode): Likewise. * config/i386/i386.opt: Add -mfsgsbase, -mrdrnd and -mf16c. * config/i386/immintrin.h (_rdrand_u16): New. (_rdrand_u32): Likewise. (_readfsbase_u32): Likewise. (_readfsbase_u64): Likewise. (_readgsbase_u32): Likewise. (_readgsbase_u64): Likewise. (_writefsbase_u32): Likewise. (_writefsbase_u64): Likewise. (_writegsbase_u32): Likewise. (_writegsbase_u64): Likewise. (_rdrand_u64): Likewise. (_cvtsh_ss): Likewise. (_mm_cvtph_ps): Likewise. (_mm256_cvtph_ps): Likewise. (_cvtss_sh): Likewise. (_mm_cvtps_ph): Likewise. (_mm256_cvtps_ph): Likewise. * config/i386/sse.md (vcvtph2ps): New. (*vcvtph2ps_load): Likewise. (vcvtph2ps256): Likewise. (vcvtps2ph): Likewise. (*vcvtps2ph): Likewise. (*vcvtps2ph_store): Likewise. (vcvtps2ph256): Likewise. * doc/extend.texi: Document FSGSBASE and RDRND built-in functions. * doc/invoke.texi: Document -mfsgsbase, -mrdrnd and -mf16c. gcc/testsuite/ 2010-07-07 H.J. Lu hongjiu...@intel.com Backport from mainline 2010-07-07 H.J. Lu hongjiu...@intel.com PR target/44844 * gcc.target/i386/rdrand-1.c: Scan jnc. * gcc.target/i386/rdrand-2.c: Likewise. * gcc.target/i386/rdrand-3.c: Likewise. 2010-07-05 H.J. Lu hongjiu...@intel.com AVX Programming Reference (June, 2010) * g++.dg/other/i386-2.C: Add -mfsgsbase -mrdrnd -mf16c. * g++.dg/other/i386-3.C: Likewise. * gcc.target/i386/sse-12.c: Likewise. * gcc.target/i386/f16c-check.h: New. * gcc.target/i386/rdfsbase-1.c: Likewise. *
[Bug target/44850] [4.6 Regression] Many test failures
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44850
[Bug target/44844] Wrong _rdrand_uXX intrinsic implementation
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44844
