[Bug c++/44540] [4.6 Regression] ICE: in add_substitution, at cp/mangle.c:386 with -fkeep-inline-functions
--- Comment #2 from zsojka at seznam dot cz 2010-06-15 07:28 --- Created an attachment (id=20912) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20912action=view) reduced testcase, -fkeep-inline-functions is not needed there As the original testcase, this ICEs only in 4.6 too: $ /mnt/svn/gcc-trunk/binary-160687-lto-fortran-checking-yes-rtl/bin/g++ pr44540.C pr44540.C: In function 'void foo()': pr44540.C:3:6: internal compiler error: in add_substitution, at cp/mangle.c:386 However, in 4.5 and 4.4 (both with checking enabled), the symbol might be mangled wrongly - the volatile looks superfluous. It seems to be caused by the noreturn attribute. $ /mnt/svn/gcc-4_5/binary-160526-lto-fortran-checking-yes-rtl/bin/g++ pr44540.C /usr/lib/../lib64/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' /tmp/ccCkV1Jt.o: In function `foo()': pr44540.C:(.text+0x5): undefined reference to `baz(char const*, ...)' pr44540.C:(.text+0xa): undefined reference to `bar(void ( volatile*)(char const*, ...))' collect2: ld returned 1 exit status 4.6 shows the same message (including volatile) when the printf attribute is removed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44540
[Bug fortran/44541] New: [OOP] wrong code for polymorphic variable with INTENT(OUT)/Alloc w/ MOLD
Follow up to PR 43388 (ALLOCATE with MOLD, a F2008 feature), but it also applies to polymorphic variables with INTENT(OUT) (i.e. to F2003). In either cases, a potentially existing default initializer of the *effective type* needs to be applied. That means that this data has to be available in the vtable. See also: http://j3-fortran.org/pipermail/j3/2010-June/003621.html (Thanks to Janus for spotting the problem (for MOLD) at the first place; thanks to Bill Long for confirmation and mentioning INTENT(OUT); and to Aleksandar Donev for the comments.) Testing shows that other vendors have also overlooked these cases. (For intent out, there seem to be compiler which do not set the variable at all (e.g. gfortran) or those which only use the base type for the initialization; similarly, for MOLD where unspecified initialization happens (via malloc), possibly with base-type initialization on top.) -- INTENT(OUT) test case - ! Expected: a= 1 b= 3 implicit none type t integer :: a = 1 end type t type, extends(t) :: t2 integer :: b = 3 end type t2 type(t2) :: y y%a = 44 y%b = 55 call intent_out (y) print *, 'a=', y%a, ' b=', y%b contains subroutine intent_out(x) class(t), intent(out) :: x select type (x) type is (t2) print *, 'a=', x%a, ' b=', x%b end select end subroutine end -- MOLD test case ! Expected: ! a= 1 b= 3 ! (Wrong is a= 1 b= 0 or a= 0 b= 0 or garbage) implicit none type t integer :: a = 1 end type t type, extends(t) :: t2 integer :: b = 3 end type t2 class(t), allocatable :: x, y allocate (t2 :: y) select type (y) type is (t2) y%a = 44 y%b = 55 end select allocate ( x, mold=y) select type (x) type is (t2) print *, 'a=', x%a, ' b=', x%b end select end -- Summary: [OOP] wrong code for polymorphic variable with INTENT(OUT)/Alloc w/ MOLD Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org BugsThisDependsOn: 43388 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44541
[Bug fortran/44529] [F03] array allocation with SOURCE
-- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Last reconfirmed|-00-00 00:00:00 |2010-06-15 09:39:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44529
[Bug tree-optimization/44423] [4.5/4.6 Regression] Massive performance regression in SSE code due to SRA
--- Comment #18 from jamborm at gcc dot gnu dot org 2010-06-15 09:48 --- Subject: Bug 44423 Author: jamborm Date: Tue Jun 15 09:48:39 2010 New Revision: 160775 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160775 Log: 2010-06-15 Martin Jambor mjam...@suse.cz PR tree-optimization/44423 * tree-sra.c (dump_access): Dump also grp_assignment_read. (analyze_access_subtree): Pass negative allow_replacements to children if the current type is scalar. * testsuite/gcc.dg/tree-ssa/pr44423.c: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/tree-ssa/pr44423.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/tree-sra.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44423
[Bug bootstrap/44458] [4.6 Regression] Bootstrap fails on arm_float_words_big_endian implicit declaration when Ada on arm-linux
--- Comment #5 from laurent at guerby dot net 2010-06-15 09:58 --- Reverting Steven patch with your fix is enough to get back bootstrap: http://gcc.gnu.org/ml/gcc-testresults/2010-06/msg01497.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44458
[Bug tree-optimization/44258] [4.5 Regression] possible SRA wrong-code generation.
--- Comment #15 from jamborm at gcc dot gnu dot org 2010-06-15 10:03 --- Subject: Bug 44258 Author: jamborm Date: Tue Jun 15 10:03:35 2010 New Revision: 160776 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160776 Log: 2010-06-15 Martin Jambor mjam...@suse.cz PR tree-optimization/44258 * tree-sra.c (build_access_subtree): Return false iff there is a partial overlap. (build_access_trees): Likewise. (analyze_all_variable_accesses): Disqualify candidates if build_access_trees returns true for them. * testsuite/gcc.dg/tree-ssa/pr44258.c: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/tree-ssa/pr44258.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/tree-sra.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44258
[Bug tree-optimization/44423] [4.5/4.6 Regression] Massive performance regression in SSE code due to SRA
--- Comment #19 from jamborm at gcc dot gnu dot org 2010-06-15 10:04 --- This is now fixed on both the trunk and the 4.5 branch. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44423
[Bug tree-optimization/44258] [4.5 Regression] possible SRA wrong-code generation.
--- Comment #16 from jamborm at gcc dot gnu dot org 2010-06-15 10:05 --- This is now fixed on both the trunk and the 4.5 branch. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44258
[Bug target/43703] Unexpected floating point precision loss due to ARM NEON autovectorization
--- Comment #4 from siarhei dot siamashka at gmail dot com 2010-06-15 10:34 --- Created an attachment (id=20913) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20913action=view) a fixed testcase A fixed testcase attached. The main problem here is that denormals are not handled in a 'civilized' way by gcc at the moment. They are just silently and unconditionally treated in a relaxed way, and that might be neither wanted nor expected by the user. And 'readelf -A' shows the following EABI tags for the generated object file, even not marking it in a special way with the regards to denormals handling: Tag_ABI_FP_denormal: Needed Tag_ABI_FP_exceptions: Needed Tag_ABI_FP_number_model: IEEE 754 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43703
[Bug target/44542] New: expand_one_stack_var_at may set DECL_ALIGN to a too high value
On say -O0:
void foo (long x)
{
long a, b, c, d;
__builtin_alloca (1);
}
some of the variables get much higher DECL_ALIGN than they in the end really
have. I don't have a testcase which shows miscompilation on the trunk, still
it seems to be a latent bug. IMHO it should instead set DECL_ALIGN to the
maximum of requested DECL_ALIGN and alignment from offset for minimum possible
stack alignment and only after expansion when it is finalized what stack
alignment it will have it can be increased if needed. On 4.4-RH I've run into
another issue (perhaps also latent on the trunk) - if expand_stack_var is
called twice on the same variable, the first time it is given a stack slot and
DECL_ALIGN set to a very high number (e.g. for offset 32 it is 256 bits) and
next time the function doesn't do almost anything (DECL_RTL_SET_P is true),
except for increasing requested alignment to the given one, so it ends up
wanting to realign the stack.
--
Summary: expand_one_stack_var_at may set DECL_ALIGN to a too high
value
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44542
[Bug lto/44464] ICE during linux kernel whopr build
--- Comment #20 from jamborm at gcc dot gnu dot org 2010-06-15 11:09 --- Subject: Bug 44464 Author: jamborm Date: Tue Jun 15 11:09:12 2010 New Revision: 160777 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160777 Log: 2010-06-15 Martin Jambor mjam...@suse.cz PR lto/44464 * tree-sra.c (replace_removed_params_ssa_names): Call release_ssa_name on the newly dead SSA name. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-sra.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44464
[Bug target/44542] expand_one_stack_var_at may set DECL_ALIGN to a too high value
--- Comment #1 from matz at gcc dot gnu dot org 2010-06-15 11:19 --- We have a slightly problematic ordering issue here. Here's what I think should be made the case: DECL_ALIGN should not matter after expansion, we have MEM_ALIGN for that. (and for calculating offsets from stack-ptr we can calculate the alignment directly) If that were the case already we wouldn't have the problem of having to maintain DECL_ALIGN. Of course the problem is, that MEM_ALIGN is actually generated from DECL_ALIGN during expansion itself. It follows that it actually wouldn't help at all to fixup only DECL_ALIGN after the final stack alignment is known. We would also have to walk all RTL and fixup MEM_ALIGN too (in possibly non-obvious ways). If we wouldn't do that but start with minimal DECL_ALIGN we have only managed to produce very suboptimal code. On some architecture even so unoptimal as to use unaligned instructions were aligned ones would be possible. And we wouldn't necessarily be able to fixup _that_ after the fact. Now, the mentioned ordering problem is, that we align the stack only after all instructions are converted (and hence all stack-vars are expanded). We can't do it before, because the necessity for stack-alignment depends on the actually emitted stack-vars. And doing it afterwards will lead to the need for walking all instructions again, fixing DECL_ALIGN and MEM_ALIGN (and changing instructions to use more optimal versions of the alignment now is somehow better). I think the only correct way is for expand_stack_alignment to align the stack exactly so that all DECL_ALIGN and MEM_ALIGN entries are correct. In other words I think it would be a bug for expand_stack_alignment to generate an actual stack alignment that would lessen the alignment of stack vars. To that effect I think I'd rather want to see a reproducer for 4.5/4.6 and fix the bug in expand_stack_alignment (possibly in the target hooks) than trying to fiddle with the insn chain. Weren't there some DRAP fixes after 4.4? I seem to remember some patches flying by at that time-frame. Perhaps you can also create a reproducer for 4.5 just before expand-from-ssa? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44542
[Bug target/44542] expand_one_stack_var_at may set DECL_ALIGN to a too high value
--- Comment #2 from jakub at gcc dot gnu dot org 2010-06-15 11:36 ---
I don't have any wrong-code testcases.
__attribute__((noinline, noclone)) void
f (long x)
{
long a, b, c, d;
asm ();
__builtin_alloca (1);
}
int
main (void)
{
f (1234567890);
return 0;
}
shows the same issue at -O0 -g as I see on redhat/gcc-4_4-branch on the trunk
between r145138 (which I've backported to 4.4-RH, perhaps I'll need to back it
out) and r146817 (SSA expand). In between those two commits the trunk first
sets DECL_ALIGN to 256 bits on one of the variables (as offset 32 gives and is
still smaller or equal to MAX_SUPPORTED_STACK_ALIGNMENT) and then
expand_stack_var is called on it again and bumps
crtl-stack_alignment_estimated
to 256 (something that isn't really needed).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44542
[Bug middle-end/44536] OMP: missing error with default(none)
--- Comment #1 from jakub at gcc dot gnu dot org 2010-06-15 12:15 --- Subject: Bug 44536 Author: jakub Date: Tue Jun 15 12:15:26 2010 New Revision: 160779 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160779 Log: PR fortran/44536 * langhooks.h (struct lang_hooks_for_decls): Add omp_report_decl. * langhooks-def.h (LANG_HOOKS_OMP_REPORT_DECL): Define. (LANG_HOOKS_DECLS): Add it. * gimplify.c (omp_notice_variable): Call lang_hooks.decls.omp_report_decl. * trans-openmp.c (gfc_omp_predetermined_sharing): Don't return OMP_CLAUSE_DEFAULT_SHARED for artificial vars with GFC_DECL_SAVED_DESCRIPTOR set. (gfc_omp_report_decl): New function. * trans.h (gfc_omp_report_decl): New prototype. * f95-lang.c (LANG_HOOKS_OMP_REPORT_DECL): Redefine. * gfortran.dg/gomp/pr44536.f90: New test. * gfortran.dg/gomp/sharing-3.f90: Remove xfail. Added: trunk/gcc/testsuite/gfortran.dg/gomp/pr44536.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/f95-lang.c trunk/gcc/fortran/trans-openmp.c trunk/gcc/fortran/trans.h trunk/gcc/gimplify.c trunk/gcc/langhooks-def.h trunk/gcc/langhooks.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/gomp/sharing-3.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44536
[Bug middle-end/44536] OMP: missing error with default(none)
--- Comment #2 from jakub at gcc dot gnu dot org 2010-06-15 12:17 --- Subject: Bug 44536 Author: jakub Date: Tue Jun 15 12:17:16 2010 New Revision: 160780 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160780 Log: PR fortran/44536 * langhooks.h (struct lang_hooks_for_decls): Add omp_report_decl. * langhooks-def.h (LANG_HOOKS_OMP_REPORT_DECL): Define. (LANG_HOOKS_DECLS): Add it. * gimplify.c (omp_notice_variable): Call lang_hooks.decls.omp_report_decl. * trans-openmp.c (gfc_omp_predetermined_sharing): Don't return OMP_CLAUSE_DEFAULT_SHARED for artificial vars with GFC_DECL_SAVED_DESCRIPTOR set. (gfc_omp_report_decl): New function. * trans.h (gfc_omp_report_decl): New prototype. * f95-lang.c (LANG_HOOKS_OMP_REPORT_DECL): Redefine. * gfortran.dg/gomp/pr44536.f90: New test. * gfortran.dg/gomp/sharing-3.f90: Remove xfail. Added: branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/gomp/pr44536.f90 Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/f95-lang.c branches/gcc-4_5-branch/gcc/fortran/trans-openmp.c branches/gcc-4_5-branch/gcc/fortran/trans.h branches/gcc-4_5-branch/gcc/gimplify.c branches/gcc-4_5-branch/gcc/langhooks-def.h branches/gcc-4_5-branch/gcc/langhooks.h branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/gomp/sharing-3.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44536
[Bug middle-end/44536] OMP: missing error with default(none)
--- Comment #3 from jakub at gcc dot gnu dot org 2010-06-15 12:27 --- Subject: Bug 44536 Author: jakub Date: Tue Jun 15 12:27:01 2010 New Revision: 160783 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160783 Log: PR fortran/44536 * langhooks.h (struct lang_hooks_for_decls): Add omp_report_decl. * langhooks-def.h (LANG_HOOKS_OMP_REPORT_DECL): Define. (LANG_HOOKS_DECLS): Add it. * gimplify.c (omp_notice_variable): Call lang_hooks.decls.omp_report_decl. * trans-openmp.c (gfc_omp_predetermined_sharing): Don't return OMP_CLAUSE_DEFAULT_SHARED for artificial vars with GFC_DECL_SAVED_DESCRIPTOR set. (gfc_omp_report_decl): New function. * trans.h (gfc_omp_report_decl): New prototype. * f95-lang.c (LANG_HOOKS_OMP_REPORT_DECL): Redefine. * gfortran.dg/gomp/pr44536.f90: New test. * gfortran.dg/gomp/sharing-3.f90: Remove xfail. Added: branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/gomp/pr44536.f90 Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/fortran/ChangeLog branches/gcc-4_4-branch/gcc/fortran/f95-lang.c branches/gcc-4_4-branch/gcc/fortran/trans-openmp.c branches/gcc-4_4-branch/gcc/fortran/trans.h branches/gcc-4_4-branch/gcc/gimplify.c branches/gcc-4_4-branch/gcc/langhooks-def.h branches/gcc-4_4-branch/gcc/langhooks.h branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/gomp/sharing-3.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44536
[Bug middle-end/44536] OMP: missing error with default(none)
--- Comment #4 from jakub at gcc dot gnu dot org 2010-06-15 12:49 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44536
[Bug target/44542] expand_one_stack_var_at may set DECL_ALIGN to a too high value
--- Comment #3 from jakub at gcc dot gnu dot org 2010-06-15 12:53 --- Created an attachment (id=20914) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20914action=view) gcc46-pr44542.patch For the don't use changed DECL_ALIGN for stack estimation after expand_one_stack_var_at has been called subprogram we can do something like this. For the other issue, I wonder if we couldn't limit align in expand_one_stack_var_at to minimum of MAX_SUPPORTED_STACK_ALIGNMENT and crtl-stack_alignment_estimated or something similar. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44542
[Bug middle-end/43740] [4.5/4.6 Regression] FAIL: gcc.dg/tree-ssa/20031015-1.c (internal compiler error)
--- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca 2010-06-15 13:15 --- Subject: Re: [4.5/4.6 Regression] FAIL: gcc.dg/tree-ssa/20031015-1.c (internal compiler error) Attached .i. Dave --- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca 2010-06-15 13:15 --- Created an attachment (id=20915) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20915action=view) --- Comment #11 from dave at hiauly1 dot hia dot nrc dot ca 2010-06-15 13:15 --- Created an attachment (id=20916) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20916action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43740
[Bug target/44542] expand_one_stack_var_at may set DECL_ALIGN to a too high value
--- Comment #4 from matz at gcc dot gnu dot org 2010-06-15 13:40 --- Can you try to instead do the stack-estimation only when really_expand is false? The issue is, we see all variables (or we _should_ see) exactly twice, once for estimation, once for generating the DECL_RTL. The code was so twisted that I didn't want to touch it too much during expand-from-ssa, but I planned to return to that somewhen, hence I'm not sure if we really see each variable only twice. But we should be working towards that goal. In any case it should be fine to track crtl-stack_alignment_estimated only in the first pass (really_expand == false), and never touch it again in the second pass (really_expand == true). Then you should also be able to simplify the condition. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44542
[Bug target/44542] expand_one_stack_var_at may set DECL_ALIGN to a too high value
--- Comment #5 from matz at gcc dot gnu dot org 2010-06-15 13:50 --- Oh, and yes, I agree that in expand_one_stack_var_at (only called when really_expand == true) we should limit align to $something. I'm just not sure what $something is. crtl-stack_alignment_estimated is not really it, because that one itself is adjusted by expand_stack_alignment (running after all expansion). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44542
[Bug fortran/44448] 32-bit gfortran.dg/atan2_1.f90 fails on Solaris 1[01]/x86 at -O0
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-15 14:09 --- Subject: Re: 32-bit gfortran.dg/atan2_1.f90 fails on Solaris 1[01]/x86 at -O0 --- Comment #1 from fxcoudert at gcc dot gnu dot org 2010-06-11 13:51 --- if(atan(1.0, i/10.0) -atan2(1.0, i/10.)/= 0.0) call abort() Try to change that into a print *, atan(1.0, i/10.0) -atan2(1.0, i/10.) and see what it outputs. Only changing the first line, I get -4.35482832E-08 Abort Changing the second line, too, gives -4.35482832E-08 -1.08094956596804792E-016 4.33012666E-08 4.38017677684143791E-017 3.05452623E-08 3.33934269125535366E-017 2.96684455E-08 -5.7679762288359E-017 4.87235496E-08 -9.40003283544932344E-017 -1.70394934E-08 2.55871712706579046E-017 1.22149613E-09 -3.88144377749810587E-017 2.30690667E-08 -2.16840434497100887E-018 -1.41206291E-08 -8.18572640226555848E-018 2.18556941E-08 -3.06287113727155003E-017 Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8
gcc typeinfo
Under gcc version 4.3.2 (Debian 4.3.2-1.1) and cc version 4.3.4 20090804 (release) 1 (GCC) Target: i686-pc-cygwin i obtained same result after testing typeinfo features from tutorial http://www.cplusplus.com/doc/tutorial/typecasting/ there : http://old.nabble.com/file/p28892128/tutor.cpp tutor.cpp After g++ tutor.cpp on both debian and cygwin i obtained same result: a is: P5CBase b is: P5CBase c is: P5CBase *a is: 5CBase *b is: 8CDerived *c is: 8CDerived -- View this message in context: http://old.nabble.com/gcc-%3Ctypeinfo%3E-tp28892128p28892128.html Sent from the gcc - bugs mailing list archive at Nabble.com.
[Bug target/44542] expand_one_stack_var_at may set DECL_ALIGN to a too high value
--- Comment #6 from hjl dot tools at gmail dot com 2010-06-15 14:46 --- I watched crtl-stack_alignment_estimated in gdb with the testcase in comment #2. I didn't see it set to 256. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44542
[Bug target/44542] expand_one_stack_var_at may set DECL_ALIGN to a too high value
--- Comment #7 from matz at gcc dot gnu dot org 2010-06-15 14:56 --- Jakub was not talking about crtl-stack_alignment_estimated becoming 256, but rather DECL_ALIGN of certain decls in expand_one_stack_var_at. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44542
[Bug c/44543] New: moving static keyword causes compilation to fail
Hello,
consider the following two declarations, which compile fine
static char f();
static char* f();
Then, if I move the 'static' keyword, like so:
char static f();
char* static f();
The first one still compiles, but the second one fails like this:
error.c:1: error: expected identifier or '(' before 'static'
I think this is a bug because if I use a non-pointer return type, like char or
int, it works fine. But if I use a pointer return type, like char* or void*, I
get the compiler error, depending on whether static is the first or second
word. Additionally, if I typedef char* charstar, and return that instead, it
works fine.
So, the file I am compiling is a one-liner, named error.c
char* static f();
using this command:
gcc error.c -c
Here's what I get from gcc -v
$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.3.3/configure --host=i686-pc-linux-gnu
--build=i686-pc-linux-gnu --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin
--sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share
--includedir=/usr/include --libdir=/usr/lib --localstatedir=/var
--libexecdir=/usr/lib --sharedstatedir=/usr/com --mandir=/usr/man
--infodir=/usr/info --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-c99 --enable-long-long --enable-clocale=gnu
--enable-languages=c,c++ --disable-libstdcxx-pch --program-suffix=-4.3.3
--disable-nls
Thread model: posix
gcc version 4.3.3 (GCC for Cross-LFS 4.3.3.20090323)
--
Summary: moving static keyword causes compilation to fail
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: todd dot freed at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44543
[Bug c++/44328] switch/case optimization produces an invalid lookup table index
--- Comment #5 from jamborm at gcc dot gnu dot org 2010-06-15 15:08 ---
Unfortunately I don't see this happening on the x86_64-linux -
arm-linux-gnueabi cross compiler I built for myself. The generated
assembly has all four elements in the initialization of CSWTCH.2 and
the intermediate tree dumps from the cross compiler are not really
different from the ones from a native x86_64 compiler.
Could you please first try to reproduce the bug with the
-fno-tree-switch-conversion swithch? If that helps, the bug is indeed
in the lookup table generation and then I would like you to provide
the dump files generated by switches -fdump-tree-tailr1-slim
-fdump-tree-switchconv
It would be great if you could do that with a gcc (4.5 or trunk)
patched with the following hunk but maybe we will be able to see
something interesting even without it.
Thanks.
Index: gcc/tree-switch-conversion.c
===
--- gcc/tree-switch-conversion.c(revision 160709)
+++ gcc/tree-switch-conversion.c(working copy)
@@ -517,6 +517,13 @@
array_type = build_array_type (value_type, arr_index_type);
ctor = build_constructor (array_type, info.constructors[num]);
TREE_CONSTANT (ctor) = true;
+ if (dump_file)
+ {
+ fprintf (dump_file, \n\nCONSTRUCTOR %i:\n, num);
+
+ print_node (dump_file, , ctor, 0);
+ fprintf (dump_file, \n);
+ }
decl = build_decl (loc, VAR_DECL, NULL_TREE, array_type);
TREE_STATIC (decl) = 1;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328
[Bug c/44543] moving static keyword causes compilation to fail
--- Comment #1 from redi at gcc dot gnu dot org 2010-06-15 15:28 --- This is due to C's complex declarator syntax, where the * is associated with the identifier f not the return type. You would need to say: char static *f() -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44543
[Bug bootstrap/44544] New: [4.4 Regression] build failure due to lhd_pass_through_t
Build passed last with 160755, first failure 160784 as follows, most likely for all targets: /bin/sh /tmp/hpautotest-gcc44/gcc/gcc/../move-if-change tmp-gcov-iov.h gcov-iov.h echo timestamp s-iov gcc -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute -DHAVE_CONFIG_H -I. -I. -I/tmp/hpautotest-gcc44/gcc/gcc -I/tmp/hpautotest-gcc44/gcc/gcc/. -I/tmp/hpautotest-gcc44/gcc/gcc/../include -I/tmp/hpautotest-gcc44/gcc/gcc/../libcpp/include -I/tmp/hpautotest-gcc44/cris-elf/gccobj/./gmp -I/tmp/hpautotest-gcc44/gcc/gmp -I/tmp/hpautotest-gcc44/cris-elf/gccobj/./mpfr -I/tmp/hpautotest-gcc44/gcc/mpfr -I/tmp/hpautotest-gcc44/gcc/gcc/../libdecnumber -I/tmp/hpautotest-gcc44/gcc/gcc/../libdecnumber/dpd -I../libdecnumber /tmp/hpautotest-gcc44/gcc/gcc/c-lang.c -o c-lang.o /tmp/hpautotest-gcc44/gcc/gcc/c-lang.c:49: error: 'lhd_pass_through_t' undeclared here (not in a function) There's no lhd_pass_through_t in 4.4 and the patch didn't add one. Author of suspect patch CC:ed. -- Summary: [4.4 Regression] build failure due to lhd_pass_through_t Product: gcc Version: 4.4.5 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hp at gcc dot gnu dot org GCC target triplet: cris-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44544
[Bug target/44542] expand_one_stack_var_at may set DECL_ALIGN to a too high value
--- Comment #8 from hjl dot tools at gmail dot com 2010-06-15 15:39 --- (In reply to comment #7) Jakub was not talking about crtl-stack_alignment_estimated becoming 256, but rather DECL_ALIGN of certain decls in expand_one_stack_var_at. I set the breakpoint at expand_one_stack_var_at and ran the testcase in gdb. expand_one_stack_var_at wasn't called. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44542
[Bug bootstrap/44544] [4.4 Regression] build failure due to lhd_pass_through_t
-- hp at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-15 16:11:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44544
[Bug tree-optimization/44391] [4.6 Regression] gcc.dg/graphite/id-19.c ICEs at -Os (in build2_stat, at tree.c:3670)
--- Comment #2 from spop at gcc dot gnu dot org 2010-06-15 16:19 --- Patch http://gcc.gnu.org/ml/gcc-patches/2010-06/msg01519.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44391
[Bug tree-optimization/44545] New: internal compiler error: in remove_unreachable_handlers, at tree-eh
A combination of options can yield the error: internal compiler error: in remove_unreachable_handlers, at tree-eh.c To produce the error, g++ is invoked thus: g++ -c -pipe --trapv --non-call-exceptions --stack-check -O2 Aside from -pipe and -O2, which can be further decomposed, the options are the minimal set to produce the error in this case. Build from URL: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch Repository Root: svn://gcc.gnu.org/svn/gcc Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4 Revision: 160774 unset LDFLAGS export CFLAGS=-pipe export CXXFLAGS=-pipe configure --enable-languages=c++ make bootstrap-lean See attachment for source code of test case. Taken from geany/scintilla. -- Summary: internal compiler error: in remove_unreachable_handlers, at tree-eh Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gxgjyyozme at zrmshffbt dot mine dot nu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44545
[Bug tree-optimization/44545] internal compiler error: in remove_unreachable_handlers, at tree-eh
--- Comment #1 from gxgjyyozme at zrmshffbt dot mine dot nu 2010-06-15 16:22 --- Created an attachment (id=20917) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20917action=view) Instance of source code which causes crash. from geany/scintilla -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44545
[Bug c/44546] New: 4.5 ICE with -ffast-math -Os (compiling graphviz)
libtool: compile: gcc -v -save-temps -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../lib/common -I../../lib/gvc -I../../lib/pack -I../../lib/ortho -I../../lib/pathplan -I../../lib/graph -I../../lib/sparse -I../../lib/rbtree -I../../lib/sfdpgen -I../../lib/cdt -Os -Wall -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Wno-unknown-pragmas -Wstrict-prototypes -Wpointer-arith -Wall -ffast-math -MT stress.lo -MD -MP -MF .deps/stress.Tpo -c stress.c -fPIC -DPIC -o .libs/stress.o Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/i586-pc-linux-gnu/4.5.0/lto-wrapper Target: i586-pc-linux-gnu Configured with: ..//configure --prefix=/usr --libexecdir=/usr/lib --enable-shared --with-system-zlib --enable-languages=c,c++,objc,java,ada,fortran --enable-threads --enable-__cxa_atexit --enable-clocale=gnu --enable-libada --enable-shared --with-ecj-jar=/usr/share/java/ecj.jar i586-pc-linux-gnu Thread model: posix gcc version 4.5.0 (GCC) ... COLLECT_GCC_OPTIONS='-v' '-save-temps' '-DHAVE_CONFIG_H' '-I.' '-I../..' '-I../..' '-I../../lib/common' '-I../../lib/gvc' '-I../../lib/pack' '-I../../lib/ortho' '-I../../lib/pathplan' '-I../../lib/graph' '-I../../lib/sparse' '-I../../lib/rbtree' '-I../../lib/sfdpgen' '-I../../lib/cdt' '-Os' '-D_LARGEFILE_SOURCE' '-D_FILE_OFFSET_BITS=64' '-Wno-unknown-pragmas' '-Wstrict-prototypes' '-Wpointer-arith' '-Wall' '-ffast-math' '-MT' 'stress.lo' '-MD' '-MP' '-MF' '.deps/stress.Tpo' '-c' '-fPIC' '-DPIC' '-o' '.libs/stress.o' '-mtune=pentium' '-march=pentium' /usr/lib/gcc/i586-pc-linux-gnu/4.5.0/cc1 -fpreprocessed stress.i -quiet -dumpbase stress.c -mtune=pentium -march=pentium -auxbase-strip .libs/stress.o -Os -Wno-unknown-pragmas -Wstrict-prototypes -Wpointer-arith -Wall -version -ffast-math -fPIC -o stress.s GNU C (GCC) version 4.5.0 (i586-pc-linux-gnu) compiled by GNU C version 4.5.0, GMP version 5.0.1, MPFR version 2.4.2, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=127922 GNU C (GCC) version 4.5.0 (i586-pc-linux-gnu) compiled by GNU C version 4.5.0, GMP version 5.0.1, MPFR version 2.4.2, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=127922 Compiler executable checksum: 7fe8daf58b4922cb9313351112738768 stress.c: In function #65533;8098mdsModel#65533;8099: stress.c:1373:12: warning: #65533;8098delta#65533;8099 may be used uninitialized in this function stress.c: In function #65533;8098compute_apsp_artifical_weights_packed#65533;8099: stress.c:1494:1: error: unrecognizable insn: (jump_insn 445 444 315 11 stress.c:1454 (set (pc) (if_then_else (lt (reg:CCFP 17 flags) (const_int 0 [0x0])) (label_ref:SI 303) (pc))) -1 (expr_list:REG_BR_PROB (const_int 2900 [0xb54]) (nil)) - 303) stress.c:1494:1: internal compiler error: in extract_insn, at recog.c:2103 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: 4.5 ICE with -ffast-math -Os (compiling graphviz) Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: chexum at gmail dot com GCC build triplet: i586-pc-linux-gnu GCC host triplet: i586-pc-linux-gnu GCC target triplet: i586-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44546
[Bug c/44546] 4.5 ICE with -ffast-math -Os (compiling graphviz)
--- Comment #1 from chexum at gmail dot com 2010-06-15 16:26 --- Created an attachment (id=20918) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20918action=view) Original preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44546
[Bug c/44546] 4.5 ICE with -ffast-math -Os (compiling graphviz)
--- Comment #2 from chexum at gmail dot com 2010-06-15 16:26 --- Created an attachment (id=20919) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20919action=view) Original compilation log with -v -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44546
[Bug c/44546] 4.5 ICE with -ffast-math -Os (compiling graphviz)
--- Comment #3 from chexum at gmail dot com 2010-06-15 16:31 ---
/* minimal source showing (hopefully) the same ICE */
typedef struct { float *ewgts; } vtx_data;
extern int whatever(vtx_data *);
float *compute_apsp_artifical_weights_packed (vtx_data * graph, int n)
{
float *weights;
weights = (float *) zmalloc (n * sizeof (float));
weights[n] =
whatever(graph) graph[n].ewgts[n] ?
whatever(graph) : graph[n].ewgts[n];
}
/* gcc -v -save-temps -Os -ffast-math ffmos.c */
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i586-pc-linux-gnu/4.5.0/lto-wrapper
Target: i586-pc-linux-gnu
Configured with: ..//configure --prefix=/usr --libexecdir=/usr/lib
--enable-shared --with-system-zlib
--enable-languages=c,c++,objc,java,ada,fortran --enable-threads
--enable-__cxa_atexit --enable-clocale=gnu --enable-libada --enable-shared
--with-ecj-jar=/usr/share/java/ecj.jar i586-pc-linux-gnu
Thread model: posix
gcc version 4.5.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Os' '-ffast-math' '-c'
'-mtune=pentium' '-march=pentium'
/usr/lib/gcc/i586-pc-linux-gnu/4.5.0/cc1 -E -quiet -v ffmos.c -mtune=pentium
-march=pentium -ffast-math -Os -fpch-preprocess -o ffmos.i
ignoring nonexistent directory /usr/local/include
ignoring nonexistent directory
/usr/lib/gcc/i586-pc-linux-gnu/4.5.0/../../../../i586-pc-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/lib/gcc/i586-pc-linux-gnu/4.5.0/include
/usr/lib/gcc/i586-pc-linux-gnu/4.5.0/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Os' '-ffast-math' '-c'
'-mtune=pentium' '-march=pentium'
/usr/lib/gcc/i586-pc-linux-gnu/4.5.0/cc1 -fpreprocessed ffmos.i -quiet
-dumpbase ffmos.c -mtune=pentium -march=pentium -auxbase ffmos -Os -version
-ffast-math -o ffmos.s
GNU C (GCC) version 4.5.0 (i586-pc-linux-gnu)
compiled by GNU C version 4.5.0, GMP version 5.0.1, MPFR version 2.4.2,
MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=127922
GNU C (GCC) version 4.5.0 (i586-pc-linux-gnu)
compiled by GNU C version 4.5.0, GMP version 5.0.1, MPFR version 2.4.2,
MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=127922
Compiler executable checksum: 7fe8daf58b4922cb9313351112738768
ffmos.c: In function #8216;compute_apsp_artifical_weights_packed#8217;:
ffmos.c:12:1: error: unrecognizable insn:
(jump_insn 59 58 47 2 ffmos.c:11 (set (pc)
(if_then_else (lt (reg:CCFP 17 flags)
(const_int 0 [0x0]))
(label_ref:SI 45)
(pc))) -1 (expr_list:REG_BR_PROB (const_int 2071 [0x817])
(nil))
- 45)
ffmos.c:12:1: internal compiler error: in extract_insn, at recog.c:2103
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
--
chexum at gmail dot com changed:
What|Removed |Added
Known to fail||4.5.0
Known to work||4.3.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44546
[Bug bootstrap/44544] [4.4 Regression] build failure due to lhd_pass_through_t
--- Comment #1 from jakub at gcc dot gnu dot org 2010-06-15 16:32 --- Subject: Bug 44544 Author: jakub Date: Tue Jun 15 16:32:24 2010 New Revision: 160798 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160798 Log: PR bootstrap/44544 Backport from mainline 2009-09-13 Richard Guenther rguent...@suse.de Rafael Avila de Espindola espind...@google.com * langhooks-def.h (lhd_pass_through_t): Declare. * langhooks.c (lhd_pass_through_t): New function. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/langhooks-def.h branches/gcc-4_4-branch/gcc/langhooks.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44544
[Bug target/44542] expand_one_stack_var_at may set DECL_ALIGN to a too high value
--- Comment #9 from jakub at gcc dot gnu dot org 2010-06-15 16:45 ---
Re: #c4 - !really_expand never occur when !optimize and for optimize they
are called IMHO way too early (during inlining etc.).
Re: #c8 - the testcases were meant for the given range of svn revs of trunk to
show the issue where expand_one_var is called twice and that forces useless
realignment. If you want just see too high DECL_ALIGN setting, try:
void
f (long x)
{
long a, b, c, d;
asm ( : : r (a), r (b), r (c), r (d));
__builtin_alloca (1);
}
at any optimization level on x86_64-linux on the trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44542
[Bug bootstrap/44544] [4.4 Regression] build failure due to lhd_pass_through_t
--- Comment #2 from jakub at gcc dot gnu dot org 2010-06-15 16:57 --- Should be fixed now, sorry. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44544
[Bug c++/44535] [4.6 Regression] g++ -O[ 23] generates undefined symbol
--- Comment #3 from jakub at gcc dot gnu dot org 2010-06-15 17:12 --- Caused by http://gcc.gnu.org/viewcvs?root=gccview=revrev=159362 -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||jamborm at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44535
[Bug target/44542] expand_one_stack_var_at may set DECL_ALIGN to a too high value
--- Comment #10 from hjl dot tools at gmail dot com 2010-06-15 17:13 --- Created an attachment (id=20920) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20920action=view) A patch to use alignment If we already know the alignment we need, why not use it? Here is a patch does it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44542
[Bug target/44542] expand_one_stack_var_at may set DECL_ALIGN to a too high value
--- Comment #11 from hjl dot tools at gmail dot com 2010-06-15 17:20 --- Created an attachment (id=20921) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20921action=view) An updated patch I don't see why expand_one_stack_var_at should compute alignment when its callers know what the alignment should be. We just need to do some sanity check. -- hjl dot tools at gmail dot com changed: What|Removed |Added Attachment #20920|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44542
[Bug target/44542] expand_one_stack_var_at may set DECL_ALIGN to a too high value
--- Comment #12 from hjl dot tools at gmail dot com 2010-06-15 17:25 --- Created an attachment (id=20922) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20922action=view) A new patch Fix typo and update comments. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44542
[Bug c++/44535] [4.6 Regression] g++ -O[ 23] generates undefined symbol
--- Comment #4 from jamborm at gcc dot gnu dot org 2010-06-15 17:55 --- We seem to be folding the virtual call to the wrong method. I'm investigating... -- jamborm at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jamborm at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-06-14 11:23:28 |2010-06-15 17:55:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44535
[Bug c/44546] 4.5 ICE in extract_insn, at recog.c:2103 with -ffast-math -Os (compiling graphviz)
--- Comment #4 from hjl dot tools at gmail dot com 2010-06-15 18:07 --- It is caused by revision 149035: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44546 -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||bonzini at gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-15 18:07:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44546
[Bug c/44546] [4.5/4.6 Regression] ICE in extract_insn, at recog.c:2103 with -ffast-math -Os (compiling graphviz)
-- hjl dot tools at gmail dot com changed: What|Removed |Added Summary|4.5 ICE in extract_insn, at |[4.5/4.6 Regression] ICE in |recog.c:2103 with -ffast- |extract_insn, at |math -Os (compiling |recog.c:2103 with -ffast- |graphviz) |math -Os (compiling ||graphviz) Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44546
[Bug c/44546] [4.5/4.6 Regression] ICE in extract_insn, at recog.c:2103 with -ffast-math -Os (compiling graphviz)
--- Comment #5 from ubizjak at gmail dot com 2010-06-15 18:09 ---
Confirmed.
bbro pass is blindly changing:
(jump_insn 55 57 23 2 pr44546.c:10 (set (pc)
(if_then_else (unle (reg:CCFP 17 flags)
(const_int 0 [0]))
(label_ref:SI 28)
(pc))) 576 {*jcc_1} (expr_list:REG_DEAD (reg:CCFP 17 flags)
(expr_list:REG_BR_PROB (const_int 7929 [0x1ef9])
(nil)))
to
(jump_insn 55 57 28 2 pr44546.c:10 (set (pc)
(if_then_else (gt (reg:CCFP 17 flags)
(const_int 0 [0]))
(label_ref:SI 89)
(pc))) 576 {*jcc_1} (expr_list:REG_DEAD (reg:CCFP 17 flags)
(expr_list:REG_BR_PROB (const_int 2071 [0x817])
(nil)))
This is not valid insn, since GT condition does not satisfy
ix86_trivial_fp_comparison_operator predicate.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Known to fail|4.5.0 |4.5.0 4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44546
[Bug c/44546] [4.5/4.6 Regression] ICE in extract_insn, at recog.c:2103 with -ffast-math -Os (compiling graphviz)
--- Comment #6 from ubizjak at gmail dot com 2010-06-15 18:16 --- (In reply to comment #5) bbro pass is blindly changing: Ooops, scrap this. Post-reload splitter is splitting in a wrong way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44546
[Bug fortran/43388] [F2008][OOP] ALLOCATE with MOLD=
--- Comment #3 from janus at gcc dot gnu dot org 2010-06-15 18:35 --- Subject: Bug 43388 Author: janus Date: Tue Jun 15 18:33:58 2010 New Revision: 160801 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160801 Log: 2010-06-15 Janus Weil ja...@gcc.gnu.org PR fortran/43388 * gfortran.h (gfc_expr): Add new member 'mold'. * match.c (gfc_match_allocate): Implement the MOLD tag. * resolve.c (resolve_allocate_expr): Ditto. * trans-stmt.c (gfc_trans_allocate): Ditto. 2010-06-15 Janus Weil ja...@gcc.gnu.org PR fortran/43388 * gfortran.dg/allocate_alloc_opt_8.f90: New. * gfortran.dg/allocate_alloc_opt_9.f90: New. * gfortran.dg/allocate_alloc_opt_10.f90: New. * gfortran.dg/class_allocate_2.f03: Modified an error message. Added: trunk/gcc/testsuite/gfortran.dg/allocate_alloc_opt_10.f90 trunk/gcc/testsuite/gfortran.dg/allocate_alloc_opt_8.f90 trunk/gcc/testsuite/gfortran.dg/allocate_alloc_opt_9.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/match.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/class_allocate_2.f03 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43388
[Bug fortran/44541] [OOP] wrong code for polymorphic variable with INTENT(OUT)/Alloc w/ MOLD
--- Comment #1 from janus at gcc dot gnu dot org 2010-06-15 18:40 --- (In reply to comment #0) Follow up to PR 43388 (ALLOCATE with MOLD, a F2008 feature) For the MOLD problem we already have a test case in allocate_alloc_opt_10.f90 (which is put behind comments right now, but should be uncommented once this PR is fixed). -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-15 18:40:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44541
[Bug fortran/43388] [F2008][OOP] ALLOCATE with MOLD=
--- Comment #4 from janus at gcc dot gnu dot org 2010-06-15 18:42 --- Fixed with r160801. Remaining problems are tracked by PR 44541. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43388
[Bug c/44547] New: -Wuninitialized reports false warning in nested switch statements
GCC with -Wuninitialized enabled and -On where n= 1 will report falsely that a
variable is uninitialized despite having sufficient information to determine
that the variable must necessarily be initialized.
The erroneous warning is:
In function #8216;main#8217;:
warning: #8216;n#8217; may be used uninitialized in this function
The output from running gcc -v -save-temps -Wuninitialized -O1 source-file
is:
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1.1)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wuninitialized' '-O1' '-mtune=generic'
/usr/lib/gcc/x86_64-linux-gnu/4.3.2/cc1 -E -quiet -v test.c -mtune=generic
-Wuninitialized -O1 -fpch-preprocess -o test.i
ignoring nonexistent directory /usr/local/include/x86_64-linux-gnu
ignoring nonexistent directory
/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../x86_64-linux-gnu/include
ignoring nonexistent directory /usr/include/x86_64-linux-gnu
#include ... search starts here:
#include ... search starts here:
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/4.3.2/include
/usr/lib/gcc/x86_64-linux-gnu/4.3.2/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wuninitialized' '-O1' '-mtune=generic'
/usr/lib/gcc/x86_64-linux-gnu/4.3.2/cc1 -fpreprocessed test.i -quiet -dumpbase
test.c -mtune=generic -auxbase test -O1 -Wuninitialized -version -o test.s
GNU C (Debian 4.3.2-1.1) version 4.3.2 (x86_64-linux-gnu)
compiled by GNU C version 4.3.2, GMP version 4.2.2, MPFR version 2.3.2.
warning: MPFR header version 2.3.2 differs from library version 2.3.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 3741a6052d20b6389f93b1cc4a619780
test.c: In function #8216;main#8217;:
test.c:14: warning: #8216;n#8217; may be used uninitialized in this function
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wuninitialized' '-O1' '-mtune=generic'
as -V -Qy -o test.o test.s
GNU assembler version 2.18.0 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Debian) 2.18.0.20080103
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.3.2/:/usr/lib/gcc/x86_64-linux-gnu/4.3.2/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.3.2/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.3.2/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.3.2/:/usr/lib/gcc/x86_64-linux-gnu/4.3.2/:/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wuninitialized' '-O1' '-mtune=generic'
/usr/lib/gcc/x86_64-linux-gnu/4.3.2/collect2 --eh-frame-hdr -m elf_x86_64
--hash-style=both -dynamic-linker /lib64/ld-linux-x86-64.so.2
/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../lib/crt1.o
/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../lib/crti.o
/usr/lib/gcc/x86_64-linux-gnu/4.3.2/crtbegin.o
-L/usr/lib/gcc/x86_64-linux-gnu/4.3.2 -L/usr/lib/gcc/x86_64-linux-gnu/4.3.2
-L/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../lib -L/lib/../lib
-L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../.. test.o -lgcc
--as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
/usr/lib/gcc/x86_64-linux-gnu/4.3.2/crtend.o
/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../lib/crtn.o
*note: the output above lists version 4.3.2; however I have tested with the
same effect on gcc version 4.5.0 and have no reason to believe it doesn't exist
in trunk.
The minimal source code example:
// ---
/* GCC bug: -Wuninitialized produces false warning
* compile with gcc -Wuninitialized -On where n = 1
*/
int main( int argc, char *argv[] )
{
switch( argc )
{
// note: bug no longer occurs if case values are consective (i.e.
1,2,3)
case 1:
case 2:
case 4:
{
int n;
switch( argc )
{
case 1:
case 2:
case 4:
n = argc;
break;
}
return n;
break;
}
}
return 0;
}
// ---
From the example above, the first switch limits the value of argc to cases 1,
2, or 4, so that in the second switch statement the compiler should be able to
determine that its value must necessarily be 1,2, or 4 and thus
[Bug c++/44548] New: Link error when defining templated static const variable
Complete code is below [just a few lines]. Note-- bug goes away when I
initialize the variable outside the class, not inside.
qpo...@merlin: ~$ cat temp.cc
templateclass T=int class MyTraits {
public:
static const T kValue = 0;
};
template
const int MyTraitsint::kValue; // define it.
int main(){
const void * a = (MyTraitsint::kValue);
}
qpo...@merlin: ~$ g++ temp.cc
/tmp/ccuYrD0D.o: In function `main':
temp.cc:(.text+0x14): undefined reference to `MyTraitsint::kValue'
collect2: ld returned 1 exit status
qpo...@merlin: ~$ g++ -v
Using built-in specs.
Target: i686-linux
Configured with: ../configure --build=i686-linux --with-arch=nocona
--with-tune=core2 --with-thread=posix --with-as=/usr/local/bin/as
--with-ld=/usr/local/bin/ld --with-system-zlib --program-suffix=-4.3
Thread model: posix
gcc version 4.3.5 (GCC)
qpo...@merlin: ~$ uname -a
Linux merlin.fit.vutbr.cz 2.6.32.12 #1 SMP Tue Apr 27 15:10:42 CEST 2010 x86_64
x86_64 x86_64 GNU/Linux
qpo...@merlin: ~$
--
Summary: Link error when defining templated static const variable
Product: gcc
Version: 4.3.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dpovey at gmail dot com
GCC build triplet: i686-linux-gnu
GCC host triplet: i686-linux-gnu
GCC target triplet: i686-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44548
[Bug rtl-optimization/42461] [4.5/4.6 regression] missed optimization for pure functions
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2010-06-15 18:57 --- Subject: Bug 42461 Author: ebotcazou Date: Tue Jun 15 18:56:59 2010 New Revision: 160802 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160802 Log: Backport from mainline 2010-06-09 Eric Botcazou ebotca...@adacore.com PR rtl-optimization/42461 * dce.c (deletable_insn_p): Return true for const or pure calls again. * except.c (insn_could_throw_p): Return false if !flag_exceptions. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr42461.c - copied unchanged from r160790, trunk/gcc/testsuite/gcc.dg/pr42461.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/dce.c branches/gcc-4_5-branch/gcc/except.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42461
[Bug rtl-optimization/42461] [4.5/4.6 regression] missed optimization for pure functions
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2010-06-15 19:00 --- . -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42461
[Bug c++/44548] Link error when defining templated static const variable
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-06-15 19:00 --- No you just specialized the declaration. You want: templateclass T const T MyTraitsT::kValue; // define it. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44548
[Bug fortran/42051] [OOP] ICE on array-valued function with CLASS formal argument
--- Comment #10 from janus at gcc dot gnu dot org 2010-06-15 19:08 --- Comment #1 is fixed by r160622, but the original test case still does not work (hangs in some kind of infinite loop for me, at r160801 on x86_64-unknown-linux-gnu). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42051
[Bug tree-optimization/44391] [4.6 Regression] gcc.dg/graphite/id-19.c ICEs at -Os (in build2_stat, at tree.c:3670)
--- Comment #3 from spop at gcc dot gnu dot org 2010-06-15 19:12 --- Subject: Bug 44391 Author: spop Date: Tue Jun 15 19:11:59 2010 New Revision: 160803 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160803 Log: Fix PR44391: use size_one_node for pointer types. 2010-06-15 Sebastian Pop sebastian@amd.com PR middle-end/44391 * graphite-clast-to-gimple.c (graphite_create_new_loop_guard): Use size_one_node for pointer types. Do not call gmp_cst_to_tree. * gcc.dg/graphite/pr44391.c: New. Added: trunk/gcc/testsuite/gcc.dg/graphite/pr44391.c Modified: trunk/gcc/ChangeLog trunk/gcc/graphite-clast-to-gimple.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44391
[Bug tree-optimization/44391] [4.6 Regression] gcc.dg/graphite/id-19.c ICEs at -Os (in build2_stat, at tree.c:3670)
--- Comment #4 from spop at gcc dot gnu dot org 2010-06-15 19:13 --- Fixed. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44391
[Bug fortran/42051] [OOP] ICE on array-valued function with CLASS formal argument
--- Comment #11 from janus at gcc dot gnu dot org 2010-06-15 19:38 --- Here is a reduced test case, based on comment #0: module grid_module implicit none type grid end type type field type(grid) :: mesh end type contains real function return_x(this) class(grid) :: this end function end module module field_module use grid_module, only: field,return_x implicit none contains subroutine output(this) class(field) :: this print *,return_x(this%mesh) end subroutine end module end This gives me a segfault ICE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42051
[Bug fortran/42051] [OOP] ICE on array-valued function with CLASS formal argument
--- Comment #12 from janus at gcc dot gnu dot org 2010-06-15 19:41 --- (In reply to comment #11) This gives me a segfault ICE. ... with the following backtrace: Program received signal SIGSEGV, Segmentation fault. 0x00553b5d in gfc_find_symtree (st=0x41, name=0x77f2de50 vtype$grid) at /home/jweil/gcc46/trunk/gcc/fortran/symbol.c:2390 2390 c = strcmp (name, st-name); (gdb) bt #0 0x00553b5d in gfc_find_symtree (st=0x41, name=0x77f2de50 vtype$grid) at /home/jweil/gcc46/trunk/gcc/fortran/symbol.c:2390 #1 0x00553b08 in gfc_delete_symtree (root=0x18081d0, name=0x77f2de50 vtype$grid) at /home/jweil/gcc46/trunk/gcc/fortran/symbol.c:2371 #2 0x00554772 in gfc_undo_symbols () at /home/jweil/gcc46/trunk/gcc/fortran/symbol.c:2843 #3 0x00515f65 in decode_statement () at /home/jweil/gcc46/trunk/gcc/fortran/parse.c:271 #4 0x005177be in next_free () at /home/jweil/gcc46/trunk/gcc/fortran/parse.c:723 #5 0x00517b8e in next_statement () at /home/jweil/gcc46/trunk/gcc/fortran/parse.c:908 #6 0x0051c190 in gfc_parse_file () at /home/jweil/gcc46/trunk/gcc/fortran/parse.c:4299 Seems to be related to PR 44064 (or even a duplicate). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42051
[Bug fortran/44549] New: [OOP][F2008] Type-bound procedure: bogus error from list after PROCEDURE
After the fix for pr40117 with r160646, the following code (borrowed from somewhere) MODULE rational_numbers IMPLICIT NONE PRIVATE TYPE,PUBLIC :: rational PRIVATE INTEGER n,d CONTAINS ! ordinary type-bound procedure PROCEDURE :: real = rat_to_real ! specific type-bound procedures for generic support PROCEDURE,PRIVATE :: rat_asgn_i, rat_plus_rat, rat_plus_i PROCEDURE,PRIVATE,PASS(b) :: i_plus_rat ! generic type-bound procedures GENERIC :: ASSIGNMENT(=) = rat_asgn_i GENERIC :: OPERATOR(+) = rat_plus_rat, rat_plus_i, i_plus_rat END TYPE CONTAINS ELEMENTAL REAL FUNCTION rat_to_real(this) RESULT(r) CLASS(rational),INTENT(IN) :: this r = REAL(this%n)/this%d END FUNCTION ELEMENTAL SUBROUTINE rat_asgn_i(a,b) CLASS(rational),INTENT(OUT) :: a INTEGER,INTENT(IN) :: b a%n = b a%d = 1 END SUBROUTINE ELEMENTAL TYPE(rational) FUNCTION rat_plus_i(a,b) RESULT(r) CLASS(rational),INTENT(IN) :: a INTEGER,INTENT(IN) :: b r%n = a%n + b*a%d r%d = a%d END FUNCTION ELEMENTAL TYPE(rational) FUNCTION i_plus_rat(a,b) RESULT(r) INTEGER,INTENT(IN) :: a CLASS(rational),INTENT(IN) :: b r%n = b%n + a*b%d r%d = b%d END FUNCTION ELEMENTAL TYPE(rational) FUNCTION rat_plus_rat(a,b) RESULT(r) CLASS(rational),INTENT(IN) :: a,b r%n = a%n*b%d + b%n*a%d r%d = a%d*b%d END FUNCTION END gives the following bogus error: class_test.f90:31.48: ELEMENTAL TYPE(rational) FUNCTION rat_plus_i(a,b) RESULT(r) 1 Error: Assignment operator interface at (1) must be a SUBROUTINE and gives an ICE when compiled with -std=f2003 class_test.f90:12.49: PROCEDURE,PRIVATE :: rat_asgn_i, rat_plus_rat, rat_plus_i 1 Error: Fortran 2008: PROCEDURE list at (1) class_test.f90:16.29: GENERIC :: OPERATOR(+) = rat_plus_rat, rat_plus_i, i_plus_rat 1 Error: Undefined specific binding 'rat_plus_i' as target of GENERIC '+' at (1) f951: internal compiler error: Segmentation fault -- Summary: [OOP][F2008] Type-bound procedure: bogus error from list after PROCEDURE Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: x86_64-apple-darwin10.3.0 GCC host triplet: x86_64-apple-darwin10.3.0 GCC target triplet: x86_64-apple-darwin10.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44549
[Bug fortran/44448] 32-bit gfortran.dg/atan2_1.f90 fails on Solaris 1[01]/x86 at -O0
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2010-06-15 20:10 --- (In reply to comment #2) Try to change that into a print *, atan(1.0, i/10.0) -atan2(1.0, i/10.) and see what it outputs. Only changing the first line, I get -4.35482832E-08 Abort Changing only the first line, could you compile with -fdump-tree-original and attach the *.f90.003t.original file that gets generated? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8
[Bug target/43364] Suboptimal code for the use of ARM NEON intrinsic vset_lane_f32
--- Comment #3 from siarhei dot siamashka at gmail dot com 2010-06-15
20:14 ---
The whole point of submitting this PR was to find an efficient way to use NEON
instructions to operate on any arbitrary scalar floating point values in order
to overcome Cortex-A8 VFP Lite inherent slowness (maybe make it transparent via
wrapping it into a C++ class and use operator overloading).
Using 'vdup_n_f32' to load a single floating point value seems to be better
than 'vset_lane_f32' here because we don't have to deal with uninitialized part
of the register. But 'vdup_n_f32' suffers from the similar performance issues
(VLD1 instruction is not used directly) and results in redundant instructions
emitted when the value is loaded from memory. Optimistically, something like
this should have been used instead of 'vdup_n_f32' in this case:
static inline float32x2_t vdup_n_f32_mem(float *p)
{
float32x2_t result;
asm (vld1.f32 {%P0[]}, [%1, :32] : =w (result) : r (p) : memory);
return result;
}
If wonder if it is possible to check at compile time whether the operand comes
from memory or from a register? Something similar to '__builtin_constant_p'
builtin-function? Or use multiple alternatives feature for inline assembly
constraints to emit either VMOV or VLD1? Anything else?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43364
[Bug target/43364] Suboptimal code for the use of ARM NEON intrinsic vset_lane_f32
--- Comment #4 from siarhei dot siamashka at gmail dot com 2010-06-15
20:34 ---
(In reply to comment #3)
Or use multiple alternatives feature for inline assembly constraints to emit
either VMOV or VLD1?
Well, this kind of works :) But is very ugly and fragile:
/***/
#include arm_neon.h
/* Override a slow 'vdup_n_f32' intrinsic with something better */
static inline float32x2_t vdup_n_f32_fast(float x)
{
float32x2_t result;
asm (
.set vdup_n_f32_fast_CODE_EMITTED,0\n
.irp regname,r0,r1,r2,r3,r4,r5,r6,r7,r8,r9,r10,r11,r12,r13,r14\n
.ifeqs \\\regname\, \%1\\n
vdup.32 %P0, %1\n
.set vdup_n_f32_fast_CODE_EMITTED,1\n
.endif\n
.ifeqs \[\\regname, #0]\, \%1\\n
vld1.f32 {%P0[]}, [\\regname, :32]\n
.set vdup_n_f32_fast_CODE_EMITTED,1\n
.endif\n
.endr\n
.if vdup_n_f32_fast_CODE_EMITTED == 0\n
.error \Fixme: icky macros from 'vdup_n_f32_fast' failed\\n
.endif\n
: =w,w (result) : r,Q (x) : memory);
return result;
}
#define vdup_n_f32(x) vdup_n_f32_fast(x)
/* Now let's test it for accessing data in registers */
float neon_add_regs(float a, float b)
{
float32x2_t tmp1, tmp2;
tmp1 = vdup_n_f32(a);
tmp2 = vdup_n_f32(b);
tmp1 = vadd_f32(tmp1, tmp2);
return vget_lane_f32(tmp1, 0);
}
/* ... and in memory */
void neon_add_mem(float * __restrict out,
float * __restrict a,
float * __restrict b)
{
float32x2_t tmp1, tmp2;
tmp1 = vdup_n_f32(*a);
tmp2 = vdup_n_f32(*b);
tmp1 = vadd_f32(tmp1, tmp2);
*out = vget_lane_f32(tmp1, 0);
}
/***/
$ objdump -d test.o
neon_add_mem:
0: f4e10c9fvld1.32 {d16[]}, [r1, :32]
4: f4e21c9fvld1.32 {d17[]}, [r2, :32]
8: f2400da1vadd.f32d16, d16, d17
c: f4c0080fvst1.32 {d16[0]}, [r0]
10: e12fff1ebx lr
0014 neon_add_regs:
14: ee800b90vdup.32 d16, r0
18: ee811b90vdup.32 d17, r1
1c: f2400da1vadd.f32d16, d16, d17
20: ee100b90vmov.32 r0, d16[0]
24: e12fff1ebx lr
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43364
[Bug fortran/44549] [OOP][F2008] Type-bound procedure: bogus error from list after PROCEDURE
--- Comment #1 from janus at gcc dot gnu dot org 2010-06-15 21:05 --- Dominique, thanks for reporting this. I can confirm the error you're seeing and I already see what's wrong: In 'match_procedure_in_type' the handling of the gfc_typebound_proc structures is not correct (each procedure in the list gets the same structure). Will post a patch shortly. -- janus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-15 21:05:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44549
[Bug debug/41130] GCC should emit an index of publicly named entities
--- Comment #15 from tromey at gcc dot gnu dot org 2010-06-15 21:51 --- I think we've decided not to pursue this route. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX Target Milestone|--- |4.5.1 Version|tree-ssa|4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41130
[Bug c++/44550] New: Wrong filename in error message when using c++0x + optimised + precompiled headers
I'm noticing wrong filenames and line numbers on error messages when combining
optimised build with c++0x and precompiled headers. Here is a minimal test
case:
All.h:
#include string
test.h:
#include All.h
test.cpp:
#include test.h
Test::Test()
{
}
g++ -std=gnu++0x -O3 All.h
g++ -std=gnu++0x -O3 test.cpp
test.h:2: error: Test has not been declared
test.h:2: error: ISO C++ forbids declaration of Test with no type
If I:
- Don't use gnu++0x
- Or don't use -O3
- Or don't precompile All.h
- Or include All.h directly in test.cpp
then I get the expected error message
test.cpp:3: error: Test has not been declared
test.cpp:3: error: ISO C++ forbids declaration of Test with no type
System: Linux 2.6.32-5-amd64 #1 SMP Tue Jun 1 04:34:03 UTC 2010 x86_64
GNU/Linux
g++ -v -save-temps:
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.4-1'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--with-arch-32=i486 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.4 (Debian 4.4.4-1)
--
Summary: Wrong filename in error message when using c++0x +
optimised + precompiled headers
Product: gcc
Version: 4.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: small_duck at revesdemondes dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44550
[Bug c++/44548] Link error when defining templated static const variable
--- Comment #2 from dpovey at gmail dot com 2010-06-15 22:19 --- I don't agree with you that this is not a bug, although I do agree that I could have coded it differently. Look at http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/index.jsp?topic=/com.ibm.xlcpp8a.doc/language/ref/explicit_specialization.htm the section on Explicit specialization of members of class templates. You are right, my syntax was an explicit specialization, and that was pointless and I could have done it a different way, but I believe what I wrote still counts as a definition of the variable-- what else could the syntax possibly mean? I.e. the line: template const int MyTraitsint::kValue; You say this is an explicit specialization; fine, but it is an explicit specialization of the *definition* of the variable. You can't *declare* a class member outside of the class itself, and I'm not specializing the class itself. So either that line needs to be rejected by the compiler, or it needs to work as I intended-- what other possible meaning could it have than the one I intended? The C++ standard doesn't seem to mention whether or not you are allowed to explicitly specialize static const variables that have been defined inside the class, and it does seem a bit pointless to do so, but I think it should either compile or issue an error or warning. -- dpovey at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44548
[Bug c++/44548] Link error when defining templated static const variable
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-06-15 22:24 --- but it is an explicit specialization of the *definition* of the variable No it is a specialization of the declaration. There are only specialization of declarations; never definitions. Re-read the link you gave and you will see the following: Explicit specialization declaration syntax . -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44548
[Bug middle-end/44551] New: [missed optimization] AVX vextractf128 after vinsertf128
Consider the following testcase:
#include immintrin.h
static inline __m256i __attribute__((always_inline))
my_add(__m256i a0, __m256i b0)
{
__m128i a1 = _mm256_extractf128_si256(a0, 1);
__m128i b1 = _mm256_extractf128_si256(b0, 1);
__m256i r =
_mm256_castsi128_si256(_mm_add_epi32(_mm256_castsi256_si128(a0),
_mm256_castsi256_si128(b0)));
r = _mm256_insertf128_si256(r, _mm_add_epi32(a1, b1), 1);
return r;
}
extern int DATA[];
void use_insert_extract()
{
__m256i x = _mm256_loadu_si256((__m256i*)DATA[0]);
__m256i y = _mm256_loadu_si256((__m256i*)DATA[1]);
x = my_add(x, y);
x = my_add(x, y);
_mm256_storeu_si256((__m256i*)DATA[0], x);
}
int main()
{
return DATA[1];
}
Compiled with g++ -mavx -O3 -Wall -S one gets the following output:
vmovdqu DATA(%rip), %ymm1
pushq %rbp
vmovdqu DATA+4(%rip), %ymm0
vextractf128$0x1, %ymm1, %xmm3
vmovdqa %xmm1, %xmm2
movq%rsp, %rbp
vmovdqa %xmm0, %xmm1
vextractf128$0x1, %ymm0, %xmm0
vpaddd %xmm1, %xmm2, %xmm2
vpaddd %xmm0, %xmm3, %xmm3
vinsertf128 $0x1, %xmm3, %ymm2, %ymm2
vextractf128$0x1, %ymm2, %xmm3
vpaddd %xmm1, %xmm2, %xmm1
vpaddd %xmm0, %xmm3, %xmm0
vinsertf128 $0x1, %xmm0, %ymm1, %ymm0
vmovdqu %ymm0, DATA(%rip)
ICC 11.1 compiles the same source (-xavx -O3 -Wall -S) to:
vmovdqu DATA(%rip), %ymm1
vmovdqu 4+DATA(%rip), %ymm0
vextractf128 $1, %ymm1, %xmm2
vextractf128 $1, %ymm0, %xmm6
vpaddd%xmm0, %xmm1, %xmm3
vpaddd%xmm6, %xmm2, %xmm5
vpaddd%xmm0, %xmm3, %xmm4
vpaddd%xmm6, %xmm5, %xmm7
vinsertf128 $1, %xmm7, %ymm4, %ymm8
vmovdqu %ymm8, DATA(%rip)
Note especially the extract after insert which happens because of the double
application of my_add. This kind of optimization (which ICC is able to apply
here) is important because AVX introduces 256 bit vector registers but
arithmetic/logic/comparison operations on integers remain the 128 bit SSE
variants. Thus if you want to handle integers in YMM registers you will find a
lot of vinsertf128 and vextractf128 operations.
--
Summary: [missed optimization] AVX vextractf128 after vinsertf128
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kretz at kde dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44551
[Bug c++/44552] New: specialization of static const class member declaration should issue warning.
If you compile the following code:
templateclass T=int class MyTraits {
public:
static const T kValue = 0;
};
template
const int MyTraitsint::kValue; // define it.
int main(){
const void * a = (MyTraitsint::kValue);
}
g++ will issue no warnings but give linking errors. The statement
template const int MyTraitsint::kValue;
is in error: it is intended to be a definition of the variable but C++ does
not allow specializations of definitions (thanks to pinksia for pointing this
out). I really should have templated the definition. However, the statement I
did enter can have no possible purpose and I believe a warning should be
issued. It is possible that the statement could be meaningful for a non-const
static member (I don't know C++ well enough to judge) but it is definitely not
meaningful for a static member: thus I believe a warning is in order.
--
Summary: specialization of static const class member declaration
should issue warning.
Product: gcc
Version: 4.3.5
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dpovey at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44552
[Bug c++/44552] specialization of static const class member declaration should issue warning.
--- Comment #1 from dpovey at gmail dot com 2010-06-15 22:47 --- Sorry, I made a mistake in the last line: I meant Definitely not meaningful for a const member. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44552
[Bug c++/44552] specialization of static const class member declaration should issue warning.
--- Comment #2 from paolo dot carlini at oracle dot com 2010-06-15 23:13 --- For the record, neither ICC nor SunStudio warn. I seem to remember that in the past people often commented that it's pretty tough to produce warnings for this kind of mistake. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44552
[Bug c++/44552] specialization of static const class member declaration should issue warning.
-- paolo dot carlini at oracle dot com changed: What|Removed |Added Severity|trivial |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44552
[Bug c++/44552] specialization of static const class member declaration should issue warning.
--- Comment #3 from redi at gcc dot gnu dot org 2010-06-15 23:18 --- It's true that your specialization is only a declaration, but this would be a definition too: template const int MyTraitsint::kValue = 1; It's not true that the declaration has no purpose, it tells the compiler there is an explicit specialization and the primary template should not be implicitly instantiated. That's exactly what's needed if an explicit specialization is defined in another translation unit, otherwise you get multiple definitions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44552
[Bug c++/44552] specialization of static const class member declaration should issue warning.
--- Comment #4 from redi at gcc dot gnu dot org 2010-06-15 23:21 --- N.B. it's not necessarily a mistake. If an explicit specialization is defined in another translation unit then the implicit instantiation of the primary template must be suppressed, or you get multiple definitions and an ODR violation. See pages 197-198 of Vandevoorde Josuttis for a very similar example and explanation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44552
[Bug c++/44552] specialization of static const class member declaration should issue warning.
--- Comment #5 from dpovey at gmail dot com 2010-06-15 23:22 --- OK thanks guys. -- dpovey at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44552
[Bug middle-end/43740] [4.5/4.6 Regression] FAIL: gcc.dg/tree-ssa/20031015-1.c (internal compiler error)
--- Comment #12 from danglin at gcc dot gnu dot org 2010-06-16 01:01 --- The REG_POINTER flag for reg:DI 274 is copied from reg:DI 2374 in pa.c. The flag for reg:DI 2374 is in turn copied from reg:DI 2349 in pa.c. The flag for reg:DI 2349 is set here: (gdb) p debug_rtx (reg) (reg:DI 2349 [ D.35290 ]) $68 = void (gdb) bt #0 mark_reg_pointer (reg=0x83fffd4c0420, align=64) at ../../gcc/gcc/emit-rtl.c:1118 #1 0x41166d94 in set_reg_attrs_from_value (reg=0x83fffd4c0420, x=0x40fd976c40) at ../../gcc/gcc/emit-rtl.c:992 #2 0x41166e14 in gen_reg_rtx_and_attrs (x=0x83fffd976c40) at ../../gcc/gcc/emit-rtl.c:1003 #3 0x4195a8bc in move_invariant_reg (loop=0x83fffdff18f0, invno=64) at ../../gcc/gcc/loop-invariant.c:1416 #4 0x4195ad40 in move_invariants (loop=0x83fffd4c0420) at ../../gcc/gcc/loop-invariant.c:1489 #5 0x4195ad40 in move_invariants (loop=0x83fffd4c0420) at ../../gcc/gcc/loop-invariant.c:1489 #6 0x4195b2bc in move_single_loop_invariants ( loop=0x83fffced9ab0) at ../../gcc/gcc/loop-invariant.c:1558 #7 0x4195cdc8 in move_loop_invariants () at ../../gcc/gcc/loop-invariant.c:1905 #8 0x419302f8 in rtl_move_loop_invariants () at ../../gcc/gcc/loop-init.c:254 #9 0x41b86534 in execute_one_pass (pass=0x83fffdff18f0) at ../../gcc/gcc/passes.c:1568 #10 0x41b86964 in execute_pass_list (pass=0x83fffd4c0420) at ../../gcc/gcc/passes.c:1623 #11 0x41b869a8 in execute_pass_list (pass=0x83fffd4c0420) at ../../gcc/gcc/passes.c:1624 #12 0x41b869a8 in execute_pass_list (pass=0x83fffd4c0420) at ../../gcc/gcc/passes.c:1624 #13 0x427a78b8 in tree_rest_of_compilation (fndecl=0x83fffdff18f0) at ../../gcc/gcc/tree-optimize.c:413 ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43740
[Bug c/44553] New: Cross compiling for ia64 fails as stdlib.h doesn't exist
When trying to cross compile a stage1 (I believe that is the correct terminology) compiler I get the following error. --- /home/tony/buildall/ia64/gcc0/./gcc/xgcc -B/home/tony/buildall/ia64/gcc0/./gcc/ -B/opt/cross/gcc-4.4.4-nolibc/ia64-linux//ia64-linux/bin/ -B/opt/cross/gcc-4.4.4-nolibc/ia64-linux//ia64-linux/lib/ -isystem /opt/cross/gcc-4.4.4-nolibc/ia64-linux//ia64-linux/include -isystem /opt/cross/gcc-4.4.4-nolibc/ia64-linux//ia64-linux/sys-include -g -O2 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -DUSE_LIBUNWIND_EXCEPTIONS -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -isystem ./include -fPIC -DUSE_GAS_SYMVER -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../.././gcc -I/home/tony/buildall/src/gcc/libgcc -I/home/tony/buildall/src/gcc/libgcc/. -I/home/tony/buildall/src/gcc/libgcc/../gcc -I/home/tony/buildall/src/gcc/libgcc/../include -DHAVE_CC_TLS -o unwind-c.o -MT unwind-c.o -MD -MP -MF unwind-c.dep -fexceptions -c /home/tony/buildall/src/gcc/libgcc/../gcc/unwind-c.c In file included from /home/tony/buildall/src/gcc/libgcc/../gcc/unwind-sjlj.c:30: /home/tony/buildall/ia64/gcc0/./gcc/include/unwind.h:214:20: error: stdlib.h: No such file or directory In file included from /home/tony/buildall/src/gcc/libgcc/../gcc/unwind-c.c:29: /home/tony/buildall/ia64/gcc0/./gcc/include/unwind.h:214:20: error: stdlib.h: No such file or directory --- It looks like stdlib.h is included to get the prototype for abort(). I'll attach the buildlogs for binutils and gcc so you have the exact commandline used. Also I have a patch I use to get past the error I cannot speak to it's correctness but it seems safe to me. -- Summary: Cross compiling for ia64 fails as stdlib.h doesn't exist Product: gcc Version: 4.4.4 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tony at bakeyournoodle dot com GCC build triplet: ia64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: ia64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44553
[Bug c/44553] Cross compiling for ia64 fails as stdlib.h doesn't exist
--- Comment #1 from tony at bakeyournoodle dot com 2010-06-16 01:02 --- Created an attachment (id=20923) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20923action=view) Buildlogs -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44553
[Bug c/44553] Cross compiling for ia64 fails as stdlib.h doesn't exist
--- Comment #2 from tony at bakeyournoodle dot com 2010-06-16 01:03 --- Created an attachment (id=20924) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20924action=view) Proposed fix -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44553
[Bug middle-end/43740] [4.5/4.6 Regression] FAIL: gcc.dg/tree-ssa/20031015-1.c (internal compiler error)
--- Comment #13 from danglin at gcc dot gnu dot org 2010-06-16 01:27 --- The flag for reg:DI 2349 is copied from: Breakpoint 7, set_reg_attrs_from_value (reg=0x83fffd4c0420, x=0x83fffd976c40) at ../../gcc/gcc/emit-rtl.c:975 975 if (HARD_REGISTER_P (reg)) (gdb) p debug_rtx (reg) (reg:DI 2349) $69 = void (gdb) p debug_rtx (x) (reg/f:DI 356 [ D.35290 ]) The flag in reg/f:DI 356 is set here: Breakpoint 6, mark_reg_pointer (reg=0x83fffd976c40, align=64) at ../../gcc/gcc/emit-rtl.c:1118 1118 if (! REG_POINTER (reg)) (gdb) p debug_rtx (reg) (reg:DI 356 [ D.35290 ]) $71 = void (gdb) bt #0 mark_reg_pointer (reg=0x83fffd976c40, align=64) at ../../gcc/gcc/emit-rtl.c:1118 #1 0x40dd6c54 in expand_one_register_var (var=0x83fffdff1790) at ../../gcc/gcc/cfgexpand.c:847 #2 0x40dd7574 in expand_one_var (var=0x83fffd976c40, toplevel=0 '\0', really_expand=128 '\200') at ../../gcc/gcc/cfgexpand.c:978 #3 0x40dd8ecc in expand_used_vars () at ../../gcc/gcc/cfgexpand.c:1310 #4 0x40de6118 in gimple_expand_cfg () at ../../gcc/gcc/cfgexpand.c:3779 #5 0x41b86534 in execute_one_pass (pass=0x83fffdff1790) at ../../gcc/gcc/passes.c:1568 (gdb) p debug_tree (var) VEC(rtx,gc) 83fffdff1790 type var_decl 83fffcf8ce60 D.35290 type pointer_type 83fffdd8ad20 tree type union_type 83fffdd8abd0 tree_node sizes-gimplified asm_written public unsigned DI size integer_cst 83fffdec7758 constant 64 unit size integer_cst 83fffdec7780 constant 8 align 64 symtab -2147482625 alias set -1 canonical type 83fffdd8ac78 pointer_to_this pointer_type 83fffde01888 used unsigned ignored DI file ../../gcc/gcc/gimple-pretty-print.c line 1498 col 1 size integer_cst 83fffdec7758 64 unit size integer_cst 83fffdec7780 8 align 64 context function_decl 83fffd691600 dump_gimple_stmt abstract_origin result_decl 83fffd1b8a00 D.21084 (reg:DI 356 [ D.35290 ]) asm_written used nothrow public private protected static deprecated visited tree_0 tree_1 tree_2 tree_3 tree_4 tree_6 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43740
[Bug middle-end/43740] [4.5/4.6 Regression] FAIL: gcc.dg/tree-ssa/20031015-1.c (internal compiler error)
--- Comment #14 from danglin at gcc dot gnu dot org 2010-06-16 02:44 --- I think the setting of reg:DI 2374 from reg:DI 2349 is incorrect. Testing fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43740
[Bug tree-optimization/44507] [4.5/4.6 Regression] vectorization ANDs array elements together incorrectly
--- Comment #12 from amodra at gmail dot com 2010-06-16 03:14 --- testsuite/gcc.dg/vect/pr44507.c is invalid on LP64. This: curVal = *((unsigned long *)(pArray[index])); loads 8 bytes, ie. the last time around the loop this loads 4 bytes past the end of the array. On big-endian machines this is the low 32 bits so the test fails. The obvious fix is to replace the cast with (unsigned int *) and indeed this makes the test pass on powerpc64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44507
[Bug tree-optimization/44507] [4.5/4.6 Regression] vectorization ANDs array elements together incorrectly
--- Comment #13 from amodra at gcc dot gnu dot org 2010-06-16 04:22 --- Subject: Bug 44507 Author: amodra Date: Wed Jun 16 04:22:36 2010 New Revision: 160821 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160821 Log: PR tree-optimization/44507 * gcc.dg/vect/pr44507.c (seeIf256ByteArrayIsConstant): Correct cast. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/pr44507.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44507
[Bug tree-optimization/44507] [4.5/4.6 Regression] vectorization ANDs array elements together incorrectly
--- Comment #14 from amodra at gcc dot gnu dot org 2010-06-16 04:23 --- Subject: Bug 44507 Author: amodra Date: Wed Jun 16 04:23:05 2010 New Revision: 160822 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160822 Log: PR tree-optimization/44507 * gcc.dg/vect/pr44507.c (seeIf256ByteArrayIsConstant): Correct cast. Modified: branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/pr44507.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44507
