[Bug target/35795] [4.4 Regression] Revision 133787 breaks ia64
--- Comment #7 from hubicka at ucw dot cz 2008-04-03 06:12 --- Subject: Re: [4.4 Regression] Revision 133787 breaks ia64 The patch is OK. But won't all targets that have similar code need the same fix? If I cd to the config dir, and try grep final_end_function */* it looks like alpha, ia64, m68k, mips, rs6000, score (both score3 and score7), sh, and sparc all have the same problem. The rs6000 port has already been fixed via PR 35801. We have an ia64 patch here. We also need patches for the rest. Thanks, I've just noticed that too and send patch for all the backends. Looks like we was leaking memory here for ages, probably not that big deal since thunks are pretty small functions, but still keeping all the RTL register tables around seems bit expensive. Honza Jim -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35795 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35795
[Bug rtl-optimization/35785] gcc.c-torture/compile/pr11832.c doesn't work for Linux/ia64
--- Comment #1 from wilson at tuliptree dot org 2008-04-03 06:26 ---
Subject: Re: New: gcc.c-torture/compile/pr11832.c
doesn't work for Linux/ia64
hjl dot tools at gmail dot com wrote:
(set (pc)^M
(reg:DI 2 loc79)) 329 {indirect_jump} (nil))^M
This is a problem with the seqabstr pass, which is confusingly in the
rtl-factoring.c file. It is allocating a hard register, but not
checking that the register is OK for a jump instruction. On IA-64, we
can't use a general reg here, we need one of the branch registers.
I see a REGNO_OK_FOR_INDIRECT_JUMP_P macro which we could define in the
ia64.h file to fix the problem. This macro is of course undocumented.
Someone should file a PR for that and assign it to the author of this code.
I tried adding the obvious definition to ia64.h and now it fails in a
different place. rtl-factoring.c aka seqabstr is doing
/* Emit an insn saving the return address to the link register before the
sequence. */
saveinsn = emit_insn_after (gen_move_insn (pattern_seqs-link_reg,
gen_symbol_ref_rtx_for_label
(retlabel)), BB_END (bb));
It is trying to load a label_ref directly into a branch register which
is certainly not going to work on an IA-64. Since this is after reload,
there is nothing the ia64.md backend can do to fix this. This requires
a rtl-factoring.c aka seqabstr fix. It needs to allocate two registers
for a machine like IA-64, a general reg to load the label into, and a
branch reg to move the label value to for the branch.
I tried writing a quick patch, taking advantage of the fact that
REGNO_OK_FOR_INDIRECT_JUMP_P is undocumented and unused, hence I can
redfine it anyway I need in order to make the IA-64 port work. I didn't
give this much thought; this can clearly be improved.
I'll attach the two patches I have. I'm not sure if this will actually
work, but at least the compiler doesn't crash anymore, and I don't see
anything obviously wrong with the code.
Jim
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35785
[Bug rtl-optimization/35785] gcc.c-torture/compile/pr11832.c doesn't work for Linux/ia64
--- Comment #2 from wilson at gcc dot gnu dot org 2008-04-03 06:27 --- Created an attachment (id=15418) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15418action=view) ia64.h patch to define REGNO_OK_FOR_INDIRECT_JUMP_P Obvious definition of the REGNO_OK_FOR_INDIRECT_JUMP_P macro. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35785
[Bug rtl-optimization/35785] gcc.c-torture/compile/pr11832.c doesn't work for Linux/ia64
--- Comment #3 from wilson at gcc dot gnu dot org 2008-04-03 06:29 --- Created an attachment (id=15419) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15419action=view) rtl-factoring.c patch to allocate second reg for IA-64 This allocates a second register if REGNO_OK_FOR_INDIRECT_JUMP_P is defined, and then adjusts the code appropriately to use the second reg. This obviously needs some cleanup, I didn't give it much thought. It seems to be working for the simple testcase though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35785
[Bug c++/35741] [4.2/4.3/4.4 regression] ICE with offsetof and references
--- Comment #3 from jakub at gcc dot gnu dot org 2008-04-03 07:44 --- Subject: Bug 35741 Author: jakub Date: Thu Apr 3 07:43:46 2008 New Revision: 133863 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133863 Log: PR c++/35741 * semantics.c (finish_offsetof): Undo effect of convert_from_reference before calling fold_offsetof. * g++.dg/other/offsetof5.C: New test. Added: trunk/gcc/testsuite/g++.dg/other/offsetof5.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35741
[Bug c++/35741] [4.2/4.3/4.4 regression] ICE with offsetof and references
--- Comment #4 from jakub at gcc dot gnu dot org 2008-04-03 07:51 --- Subject: Bug 35741 Author: jakub Date: Thu Apr 3 07:51:01 2008 New Revision: 133864 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133864 Log: PR c++/35741 * semantics.c (finish_offsetof): Undo effect of convert_from_reference before calling fold_offsetof. * g++.dg/other/offsetof5.C: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/other/offsetof5.C Modified: branches/gcc-4_3-branch/gcc/cp/ChangeLog branches/gcc-4_3-branch/gcc/cp/semantics.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35741
[Bug c++/35741] [4.2/4.3/4.4 regression] ICE with offsetof and references
--- Comment #5 from jakub at gcc dot gnu dot org 2008-04-03 07:52 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35741
[Bug rtl-optimization/35785] gcc.c-torture/compile/pr11832.c doesn't work for Linux/ia64
--- Comment #4 from loki at gcc dot gnu dot org 2008-04-03 08:24 --- The patch from http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00824.html should fix this kind of problem. *** This bug has been marked as a duplicate of 33642 *** -- loki at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35785
[Bug rtl-optimization/33642] unrecognizable insn for -frtl-abstract-sequences
--- Comment #18 from loki at gcc dot gnu dot org 2008-04-03 08:24 --- *** Bug 35785 has been marked as a duplicate of this bug. *** -- loki at gcc dot gnu dot org changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33642
[Bug libstdc++/35588] [parallel mode] parallel std::sort and bind()
--- Comment #2 from singler at gcc dot gnu dot org 2008-04-03 09:00 --- Same thing for me. -- singler at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |singler at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-04-03 09:00:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35588
[Bug tree-optimization/35811] New: [4.3/4.4 Regression] SCC VN endless recursion
On the attached testcase (from wine) at -O -m32 or higher GCC ICEs, because very deep recursion in tree-ssa-sccvn.c's DFS: ... #49137 0x0078fe7c in DFS (name=0x2aaab0a8dde0) at ../../gcc/tree-ssa-sccvn.c:1898 #49138 0x0078fe7c in DFS (name=0x2f5d7840) at ../../gcc/tree-ssa-sccvn.c:1898 #49139 0x0078fe7c in DFS (name=0x2aaab0add300) at ../../gcc/tree-ssa-sccvn.c:1898 #49140 0x0078fe7c in DFS (name=0x2aaab0ae0120) at ../../gcc/tree-ssa-sccvn.c:1898 #49141 0x00790f80 in run_scc_vn () at ../../gcc/tree-ssa-sccvn.c:2128 #49142 0x00783fc3 in execute_pre (do_fre=1 '\001') at ../../gcc/tree-ssa-pre.c:3923 #49143 0x007841cd in execute_fre () at ../../gcc/tree-ssa-pre.c:4022 #49144 0x00605e81 in execute_one_pass (pass=0xfd4fc0) at ../../gcc/passes.c:1122 #49145 0x00605fd9 in execute_pass_list (pass=0xfd4fc0) at ../../gcc/passes.c:1175 #49146 0x00605ff7 in execute_pass_list (pass=0xfd3b20) at ../../gcc/passes.c:1176 #49147 0x006f5e64 in tree_rest_of_compilation (fndecl=0x2e9fcea0) at ../../gcc/tree-optimize.c:404 #49148 0x0084f7e0 in cgraph_expand_function (node=0x2e930700) at ../../gcc/cgraphunit.c:1157 #49149 0x0084f990 in cgraph_expand_all_functions () at ../../gcc/cgraphunit.c:1220 #49150 0x0084ff45 in cgraph_optimize () at ../../gcc/cgraphunit.c:1427 #49151 0x00418034 in c_write_global_declarations () at ../../gcc/c-decl.c:8080 #49152 0x006aed3f in compile_file () at ../../gcc/toplev.c:1055 #49153 0x006b092d in do_compile () at ../../gcc/toplev.c:2247 #49154 0x006b0991 in toplev_main (argc=4, argv=0x7fffbbedf868) at ../../gcc/toplev.c:2279 #49155 0x0047b0c3 in main (argc=4, argv=0x7fffbbedf868) at ../../gcc/main.c:35 -- Summary: [4.3/4.4 Regression] SCC VN endless recursion Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jakub at gcc dot gnu dot org GCC target triplet: i686-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35811
[Bug tree-optimization/35811] [4.3/4.4 Regression] SCC VN deep recursion
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-04-03 09:53 --- I suppose this is exactly PR35204. *** This bug has been marked as a duplicate of 35204 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE Summary|[4.3/4.4 Regression] SCC VN |[4.3/4.4 Regression] SCC VN |endless recursion |deep recursion http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35811
[Bug fortran/35810] New: [F2003] Automatic reallocation on assignment to allocatable variables
The following is invalid Fortran 95 but valid Fortran 2003 as the variable is reallocated: integer, allocatable :: a(:) allocate(a(1)) print *, size(a) a = [1,2,3] ! Implicit reallocation. ! Wrong: a(:) = [1,2,3] ! Out of bounds 1 vs. 3 print *, size(a) end The Intel compiler already supports this option. It provides the option -assume [no]realloc_lhs to switch the support on/off. Off is useful for bound checks and makes the program faster as the bounds do not need to be checked in that case. See also the comp.lang.fortran post at: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/7d5d1e7f4a48071c/7c63fef65ba5ea70?lnk=gstq=realloc_lhs -- Summary: [F2003] Automatic reallocation on assignment to allocatable variables Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org OtherBugsDependingO 20585 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35810
[Bug tree-optimization/35811] [4.3/4.4 Regression] SCC VN endless recursion
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35811
[Bug middle-end/35204] [4.3/4.4 Regression] crash by too deep recursion in DFS tree-ssa-sccvn.c:1898
--- Comment #24 from rguenth at gcc dot gnu dot org 2008-04-03 10:02 --- It looks ugly as hell, but i have no problem with it because i'm not sure you can do better without completely replacing the algorithm :) as it seems only wine is affected (and there is the -fno-tree-fre -fno-tree-pre workaround) I didn't yet bother to apply this patch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||02/msg00759.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35204
[Bug middle-end/35204] [4.3/4.4 Regression] crash by too deep recursion in DFS tree-ssa-sccvn.c:1898
--- Comment #23 from rguenth at gcc dot gnu dot org 2008-04-03 09:53 --- *** Bug 35811 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35204
[Bug fortran/35810] [F2003] Automatic reallocation on assignment to allocatable variables
--- Comment #1 from burnus at gcc dot gnu dot org 2008-04-03 09:04 --- One thing to add: Seemingly gfortran supports reallocation for allocatable components (by itself a F2003 feature) using the constructor (see example), but not without constructor. Additionally, while a simple example (as below) works, the long example in the thread above is failing in some cases. (See link.) type t integer, allocatable :: a(:) end type t type(t) :: a allocate(a%a(1)) print *, size(a%a) ! print 1 (OK) a = t([1,2,3]) print *, size(a%a) ! prints 2 (OK) end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35810
[Bug c++/35758] [4.3/4.4 Regression] vector_size attribute lost in function arguments for templates
--- Comment #10 from jakub at gcc dot gnu dot org 2008-04-03 10:23 ---
See http://gcc.gnu.org/ml/gcc-patches/2008-04/msg00177.html
for details.
I guess before moving further along with this, attributes for parameter packs
should be decided upon. Do we want to allow them at all? What actually will
they mean, when they in fact change the type?
#define vector __attribute__((__vector_size__ (16)))
template typename... T void foo (int x, vector T... y) { }
void bar (vector long a, vector double b, vector long c, vector double d)
{
foolong, double (5, a, b, c, d);
foolong, double, long, double (6, a, b, c, d);
foolong, double (7, 17, 18.0, 19L, 20.0);
}
ATM g++ will grok just the last foo call (and incorrectly, as the foo function
will expect to get int and 4 vectors as arguments, while the caller passes 5
scalars).
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC||dgregor at gcc dot gnu dot
||org
AssignedTo|jakub at gcc dot gnu dot org|unassigned at gcc dot gnu
||dot org
Status|ASSIGNED|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35758
[Bug middle-end/35809] default case label for casesi should be spliced off from last element
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-04-03 09:52 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-04-03 09:52:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35809
[Bug c++/35758] [4.3/4.4 Regression] vector_size attribute lost in function arguments for templates
--- Comment #11 from jakub at gcc dot gnu dot org 2008-04-03 11:28 ---
Actually, to clarify #c10, attributes on parameter packs just make things
harder on the compiler side, but even in C++98 the same issue is present:
#define vector __attribute__((__vector_size__ (16)))
template typename T void foo (int x, vector T y) { }
void bar (vector long a, vector double b)
{
foolong (5, a);
foo (5, b);
}
If we apply late template attributes in fn_type_unification, then the foolong
(5, a); call will work as expected, but should the second call deduce template
parameter double or vector double? If the latter (which would be weird), then
it will fail, because vector_size attribute can't be applied to a VECTOR_TYPE.
Are there any attributes other than vector_size which affect the decls
similarly?
If not, I'd say that the C++ FE should hardcode some knowledge about this
attribute, e.g. know that it applies to the type, so if
processing_template_decl
move them from DECL_ATTRIBUTES to corresponding type's TYPE_ATTRIBUTES (either
the parameter type such that it would be in TYPE_ARG_TYPES too, or for
FUNCTION_TYPE/METHOD_TYPE stick it into return type's TYPE_ATTRIBUTES).
And in type_unification_real take it into account.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35758
[Bug rtl-optimization/35812] New: redundant range check in trivial switch statements
The code generated for switch (n 7) which has all possible cases (0-7)
includes a redundant range check.
To illustrate, this source code:
void foo(unsigned int *d, const unsigned int *s, unsigned int n)
{
switch (n 7) {
case 7:
d[7] = s[7];
break;
case 6:
d[6] = s[6];
break;
case 5:
d[5] = s[5];
break;
case 4:
d[4] = s[4];
break;
case 3:
d[3] = s[3];
break;
case 2:
d[2] = s[2];
break;
case 1:
d[1] = s[1];
break;
case 0:
d[0] = s[0];
break;
}
}
compiles (gcc-4.2.3 -O2 -fomit-frame-pointer -S) to:
.text
.p2align 4,,15
.globl foo
.type foo, @function
foo:
movl12(%esp), %eax
andl$7, %eax
cmpl$7, %eax
ja .L12
jmp *.L11(,%eax,4)
.section.rodata
.align 4
.align 4
.L11:
.long .L3
.long .L4
.long .L5
.long .L6
.long .L7
.long .L8
.long .L9
.long .L10
(the rest omitted)
In the sequence:
andl$7, %eax
cmpl$7, %eax
ja .L12
the compare-and-jump can never trigger.
--
Summary: redundant range check in trivial switch statements
Product: gcc
Version: 4.2.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikpe at it dot uu dot se
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35812
[Bug target/35795] [4.4 Regression] Revision 133787 breaks ia64
--- Comment #8 from hjl at gcc dot gnu dot org 2008-04-03 12:50 --- Subject: Bug 35795 Author: hjl Date: Thu Apr 3 12:49:27 2008 New Revision: 133868 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133868 Log: 2008-04-03 Jan Hubicka [EMAIL PROTECTED] PR tree-optimization/35795 * alpha/alpha.c (alpha_output_mi_thunk_osf): Free after compilation. * sparc/sparc.c (sparc_output_mi_thunk): Likewise. * ia64/ia64.c (ia64_output_mi_thunk): Likewise. * m68k/m68k.c (m68k_output_mi_thunk): Likewise. * score/score3.c (score3_output_mi_thunk): Likewise. * score/score7.c (score7_output_mi_thunk): Likewise. * mips/mips.c (mips_output_mi_thunk): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/alpha/alpha.c trunk/gcc/config/ia64/ia64.c trunk/gcc/config/m68k/m68k.c trunk/gcc/config/mips/mips.c trunk/gcc/config/score/score3.c trunk/gcc/config/score/score7.c trunk/gcc/config/sparc/sparc.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35795
[Bug c++/35813] New: ICE with partial specialization of variadic templates
code,
template int N, typename... P struct i { typedef i t; };
template typename I struct n;
template typename... E, int N struct niN, E... : iN+1, E... { };
template typename... E struct nisizeof...(E), E... : isizeof...(E),
E... { };
typedef i1, char t;
typedef nt::t x;
leads to internal compiler error: tree check: expected tree_vec, have
type_pack_expansion in tsubst_copy_and_build, at cp/pt.c:10829
--
Summary: ICE with partial specialization of variadic templates
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sultansharem at gmx dot ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35813
[Bug c++/35814] New: demangler fails on variadic template with empty parameter pack
code:
#include typeinfo
#include cassert
namespace __cxxabi {
extern C char* __cxa_demangle(const char* mangled_name, char* buf,
size_t* n, int*status);
}
template typename...
struct p {};
int main()
{
int r;
assert(__cxxabi::__cxa_demangle(typeid(p).name(),0,0,r));
}
--
Summary: demangler fails on variadic template with empty
parameter pack
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sultansharem at gmx dot ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35814
[Bug target/35795] [4.4 Regression] Revision 133787 breaks ia64
--- Comment #9 from joel at gcc dot gnu dot org 2008-04-03 13:44 --- I am pretty sure I saw this one targeting sparc-rtems. Building an updated tree now to confirm it is the fix. ../../../../gcc/libstdc++-v3/src/iostream-inst.cc: In member function 'void std::basic_iostreamchar, std::char_traitschar ::_ZThn8_NSdD1Ev()': ../../../../gcc/libstdc++-v3/src/iostream-inst.cc:51: internal compiler error: in prepare_function_start, at function.c:3940 -- joel at gcc dot gnu dot org changed: What|Removed |Added CC||joel at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35795
[Bug ada/35284] Branch to 0x0 from Ada run-time
--- Comment #35 from joel dot sherrill at oarcorp dot com 2008-04-03 14:30 --- Subject: Re: Branch to 0x0 from Ada run-time laurent at guerby dot net wrote: --- Comment #34 from laurent at guerby dot net 2008-04-03 03:47 --- May be other platform aligned the record 8 byte hence hiding the issue, and x86 only 4 bytes hence showing it. That's got to be it but how so many tests would pass is baffling. This seems like something that should have resulted in more failures. FYI PR35795 kept me from getting test results on the sparc. It was fixed overnight and I want to make sure sparc is OK before submitting test results. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35795 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
[Bug fortran/35786] OpenMP Fortran PRIVATE on parameter gives error in gfc_finish_var_decl
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||04/msg00269.html Status|NEW |ASSIGNED Last reconfirmed|2008-04-01 13:22:13 |2008-04-03 14:57:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35786
[Bug c++/35815] New: partial specialization of variadic templates with different order of parameter results in different semantics
the static 2nd static assertion in x() fails. if the other partial
specialization of template d is used, the code works as expected. As you can
see the only difference between these d's is, that the T parameter is at a
different position which shouldn't make a difference to the outcome of typedef
T t;
code
template class...
struct p;
template class A, class B struct i { typedef i t; };
template class I struct d;
template class I struct n;
template class... L, class T, class... R struct nipL..., pT, R... :
ipL..., T, pR... {};
#if 1
template class... L, class T, class... R
struct dipL..., pT, R...
{
typedef T t;
};
#else
template class T, class... L, class... R
struct dipL..., pT, R...
{
typedef T t;
};
#endif
template class A, class B struct is_same { static const bool v=false; };
template class A struct is_sameA, A { static const bool v=true; };
void x()
{
typedef ip, pshort, int, bool i0;
static_assert(is_samedi0::t, short::v,);
typedef ni0::ti1;
static_assert(is_samedi1::t, int::v,);
}
--
Summary: partial specialization of variadic templates with
different order of parameter results in different
semantics
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sultansharem at gmx dot ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35815
[Bug rtl-optimization/33642] unrecognizable insn for -frtl-abstract-sequences
--- Comment #19 from dominiq at lps dot ens dot fr 2008-04-03 15:04 --- (In reply to comment #17) I tried the patch referenced in comment #16 on powerpc64-linux. It allows tests pr11832.c and pr33009 to pass, but adding -frtl-abstract-sequences to all tests causes several tests to timeout on compilation, and gcc.dg/pr32912-1.c fails at execution for -m32. I built the C tests from SPEC CPU2000 with -O2 -frtl-abstract-sequences using the patched compiler and ran them with the short test input. A couple took a very long time to compile (try, for example, the file toke.c in test perlbmk) and four failed at execution time: vpr and crafty for -m32, gcc and gap for -m64. I am not sure to understand: does it mean that the failures were introduced by the patch? i.e., did you do the same tests for without the patch? I don't know how '-frtl-abstract-sequences' is working, but I won't be surprised if its cost is quadratic in the size of the problem. The gcc manual says: ... -O3 Optimize yet more. -O3 turns on all optimizations specified by -O2 and also turns on the -finline-functions, -funswitch-loops, -fpredictive-commoning, -fgcse-after-reload and -ftree-vectorize options. ... -frtl-abstract-sequences It is a size optimization method. This option is to find identical sequences of code, which can be turned into pseudo-procedures and then replace all occurrences with calls to the newly created subroutine. It is kind of an opposite of -finline-functions. This optimization runs at RTL level. Although I have no doubt that examples can be crafted that show a speed increase with '-O3 -frtl-abstract-sequences', the net result of this combination will probably a (much) longer compilation time and a poor overall result. It seems to me that '-frtl-abstract-sequences' is more intended to complement the '-Os' option, so I did the following comparison on the polyhedron benchmark (I don't have access to SPEC). Three tests failed to compile, two shown a less than 10% decrease in the executable size at the expense of more than a factor 3 in the compile time. Core2Duo 2.16Ghz, i686-apple-darwin9, gcc version 4.4.0 20080403 (experimental) (GCC) + patches (including the patch referenced in comment #16): Polyhedron Benchmark Validator Copyright (C) Polyhedron Software Ltd - 2004 - All rights reserved -Os-Os -frtl-... -m64 -O3 ... Benchmark Compile Executable Compile Executable Compile Executable Name(secs) (bytes)(secs) (bytes)(secs) (bytes) - --- --- --- - --- -- ac 0.92 25748 1.82 25748 4.32 46616 aermod*80.06 980996298.68 931844106.97 1225304 air 4.24 56048 8.41 56048 6.97 73200 capacita 1.86 35232 1.91 35232 3.78 64520 channel 0.85 25888 1.91 0 2.61 42752 doduc 8.47 117396 9.11 117396 15.18 183600 fatigue* 2.94 6 18.51 51460 6.18 76696 gas_dyn 2.20 646272 2.91 642176 6.39 700392 induct 8.50 131152 29.73 0 13.41 160672 linpk 0.78 17508 0.66 17508 1.58 38400 mdbx 2.52 47760 2.64 47760 3.92 68856 nf 0.90 21804 0.93 21804 24.34 153240 protein 3.46 56228 6.49 0 11.10 118240 rnflow 4.07 55936 4.79 55936 11.31 167240 test_fpu 3.29 46996 3.89 46996 10.35 154176 tfft 0.62 17704 0.62 17704 1.42 26392 Benchmark Ave Run Number Estim Ave Run Number Estim Ave Run Number Estim Name(secs) Repeats Err %(secs) Repeats Err %(secs) Repeats Err % - --- --- --- --- --- - --- --- -- ac 23.40 2 0.1197 23.45 2 0.0149 12.59 2 0.0318 aermod 44.30 2 0.0508 44.76 2 0.1251 29.77 2 0.1411 air 14.43 2 0.0139 15.06 5 1.2305 8.57 3 0.1683 capacita 82.95 2 0.0645 82.25 2 0.1088 55.79 2 0.1434 channel 7.34 5 0.1510 -1.00 2 0.1088 2.41 5 1.6186 doduc 61.77 2 0.0559
[Bug bootstrap/35804] Bootstrap of combined gcc + binutils, with --enable-shared, with sysroot fails
--- Comment #7 from oblivian at users dot sourceforge dot net 2008-04-03 15:07 --- They re-closed the binutils bug as invalid again and told me to open a new one. So here's the new one http://sourceware.org/bugzilla/show_bug.cgi?id=6027 We'll see if it gets any more traction. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35804
[Bug rtl-optimization/33642] unrecognizable insn for -frtl-abstract-sequences
--- Comment #20 from dominiq at lps dot ens dot fr 2008-04-03 15:22 --- I have reverted the patch referenced in comment #16 and the 16 tests fail as with gfortran 4.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33642
[Bug target/35795] [4.4 Regression] Revision 133787 breaks ia64
--- Comment #10 from hubicka at ucw dot cz 2008-04-03 15:44 --- Subject: Re: [4.4 Regression] Revision 133787 breaks ia64 I am pretty sure I saw this one targeting sparc-rtems. Building an updated tree now to confirm it is the fix. ../../../../gcc/libstdc++-v3/src/iostream-inst.cc: In member function 'void std::basic_iostreamchar, std::char_traitschar ::_ZThn8_NSdD1Ev()': ../../../../gcc/libstdc++-v3/src/iostream-inst.cc:51: internal compiler error: in prepare_function_start, at function.c:3940 sparc, alpha, m68k, score and mips contained same problem, so hopefully it is fixed now. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35795
[Bug libstdc++/35816] New: libstdc++ built during bootstrap is pulling in host g++ support for atomic builtins
When compiling a combined gcc + g++ + binutils, the configure script for the libstdc++ library is using the host g++ rather than the last stage g++ for determining atomic builtin support status. While I probably need to compile the toolchain with CXXFLAGS=-march=i486, from what I've read, to enable support for atomic builtins in the compiler, I did not. This resulted in a target g++ that did not support atomic builtins and a libstdc++ that expected the compiler did because it got the value from checking the host g++ rather than the final bootstrap stage g++. The configure parameters were: --prefix=/$(TOOLS_DIR)/usr \ --with-sysroot=/$(TOOLS_DIR) \ --with-pic \ --enable-shared \ --enable-clocale=gnu \ --enable-threads=posix \ --enable-__cxa_atexit \ --enable-languages=c,c++ \ --enable-checking=release \ --disable-werror \ --enable-stage1-checking \ --enable-bootstrap -- Summary: libstdc++ built during bootstrap is pulling in host g++ support for atomic builtins Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: oblivian at users dot sourceforge dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35816
[Bug rtl-optimization/35812] redundant range check in trivial switch statements
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-04-03 16:19 --- Fixed in 4.4: foo: .LFB2: andl$7, %edx jmp *.L10(,%rdx,8) ... -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35812
[Bug target/35795] [4.4 Regression] Revision 133787 breaks ia64
--- Comment #11 from joel at gcc dot gnu dot org 2008-04-03 16:19 --- (In reply to comment #10) Subject: Re: [4.4 Regression] Revision 133787 breaks ia64 I am pretty sure I saw this one targeting sparc-rtems. Building an updated tree now to confirm it is the fix. ../../../../gcc/libstdc++-v3/src/iostream-inst.cc: In member function 'void std::basic_iostreamchar, std::char_traitschar ::_ZThn8_NSdD1Ev()': ../../../../gcc/libstdc++-v3/src/iostream-inst.cc:51: internal compiler error: in prepare_function_start, at function.c:3940 sparc, alpha, m68k, score and mips contained same problem, so hopefully it is fixed now. My sparc build is past this point now so I think it is fixed there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35795
[Bug target/35795] [4.4 Regression] Revision 133787 breaks ia64
--- Comment #12 from hjl dot tools at gmail dot com 2008-04-03 16:21 --- 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=35795
[Bug tree-optimization/35817] New: [ira] Error in init_move_cost, at regclass.c:321
Hi, I get an ICE when compiling vector-2.c with -fira: Executing on host: /home/mstein/sim/ira/arm-elf/build/gcc/xgcc -B/home/mstein/sim/ira/arm-elf/build /gcc/ -O0 -w -DSTACK_SIZE=16384 -fno-show-column -c-fira -o vector-2.o /home/mstein/svn/ira/ gcc/testsuite/gcc.c-torture/compile/vector-2.c(timeout = 800) /home/mstein/svn/ira/gcc/testsuite/gcc.c-torture/compile/vector-2.c: In function 'getCapsule': /home/mstein/svn/ira/gcc/testsuite/gcc.c-torture/compile/vector-2.c:12: internal compiler error: in init_move_cost, at regclass.c:321 Please submit a full bug report, rev 133844 -- Summary: [ira] Error in init_move_cost, at regclass.c:321 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mstein dot lists at googlemail dot com GCC target triplet: arm-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35817
[Bug c/35751] ICE with invalid variable after #pragma omp parallel
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-03-30 20:57:39 |2008-04-03 16:44:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35751
[Bug middle-end/35818] New: ICE on incomplete array in shared clause
extern int a[];
void
foo (void)
{
#pragma omp parallel
#pragma omp master
a[3] = 1;
#pragma omp parallel shared(a)
#pragma omp master
a[3] = 1;
}
ICEs, because is_variable_sized doesn't expect incomplete types.
--
Summary: ICE on incomplete array in shared clause
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, openmp
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: jakub at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35818
[Bug rtl-optimization/33642] unrecognizable insn for -frtl-abstract-sequences
--- Comment #21 from janis at gcc dot gnu dot org 2008-04-03 17:04 --- Dominique, in answer to your question in comment #19, without the patch any code for powerpc*-linux gets an ICE as reported originally. The very long compilation times are a concern, but wrong code in four CPU2000 tests is much worse. With the patch, tests vpr and crafty pass with -m32 -Os -frtl-abstract-sequences, but with -m64 -Os -frtl-abstract-sequences test gcc fails at runtime and test gap hangs at runtime. I'm providing this information to let the developers know that the patch isn't ready. I can test later versions. I don't have time, however, to minimize runtime failures in SPEC tests to help pinpoint the problems. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33642
[Bug libstdc++/35816] libstdc++ built during bootstrap is pulling in host g++ support for atomic builtins
--- Comment #1 from oblivian at users dot sourceforge dot net 2008-04-03 17:34 --- After looking back at my 4.2.3 build logs. The above is somewhat incorrect. In 4.2.3, the pass 2 toolchain build of libstdc++ correctly checked the target g++ rather than the host and reported that it would not use atomic builtins. It appears that this has changed in 4.3.0 or is an artifact of using sysroot (which should not look at the host g++ for configuration options). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35816
[Bug fortran/35819] New: internal compiler error with forall
-- Summary: internal compiler error with forall Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dick dot hendrickson at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35819
[Bug fortran/35820] New: internal compiler error with forall
The following program causes an internal compiler error.
Each of the three subroutines causes an ICE. The ICE moves
around or goes away when I try to simplify the test much
more.
! fails on Windows XP
! gcc version 4.4.0 20080312 (experimental) [trunk revision 133139]
Dick Hendrickson
MODULE TESTS
IMPLICIT CHARACTER(LEN=9) (B)
IMPLICIT CHARACTER(LEN=1) (C)
IMPLICIT CHARACTER(LEN=9) (E)
IMPLICIT CHARACTER(LEN=1) (F)
IMPLICIT REAL(KIND=4)(R)
IMPLICIT REAL(KIND=8)(D)
IMPLICIT INTEGER (I)
IMPLICIT INTEGER (H)
IMPLICIT LOGICAL (L)
IMPLICIT LOGICAL (G)
IMPLICIT COMPLEX(KIND=4) (Z)
IMPLICIT COMPLEX(KIND=8) (Y)
IMPLICIT CHARACTER (A,J,K,M,N,O,P,S,T,U,V,W)
INTEGER,PARAMETER,PUBLIC :: NF_KV = KIND(1)
INTEGER,PARAMETER,PUBLIC :: I1_KV = KIND(1)
INTEGER,PARAMETER,PUBLIC :: I2_KV = I1_KV
INTEGER,PARAMETER,PUBLIC :: R1_KV = KIND(1.0)
INTEGER,PARAMETER,PUBLIC :: R2_KV = KIND(1.0D0)
INTEGER,PARAMETER,PUBLIC :: L1_KV = KIND(.TRUE.)
INTEGER,PARAMETER,PUBLIC :: L2_KV = L1_KV
INTEGER,PARAMETER,PUBLIC :: C1_KV = KIND('A')
INTEGER,PARAMETER,PUBLIC :: C2_KV = C1_KV
INTEGER, PARAMETER, PUBLIC :: NPBIG=1000
INTEGER, PARAMETER, PUBLIC :: NPSIZE = 5
INTEGER, PARAMETER, PUBLIC :: NPBIGM = NPBIG-1
INTEGER, PUBLIC, PARAMETER ::
$ NP0 = 0,
$ NP1 = 1,
$ NP2 = 2,
$ NP3 = 3,
$ NP4 = 4,
$ NP5 = 5,
$ MP1 = -1,
$ MP2 = -2,
$ MP3 = -3,
$ MP4 = -4,
$ MP5 = -5
INTEGER, SAVE :: NF0,NF1,NF2,NF3,NF4,NF5,
$ NF6,NF7,NF8,NF9,NF10,
$ NFBIGM,NFBIG,
$ MF1,MF2,MF3,MF4,MF5,
$ MF6,MF7,MF8,MF9,MF10,
$ MFBIGM,MFBIG
CHARACTER, PRIVATE :: I,J,K,L,M,N
INTEGER, PRIVATE :: J1,J2,J3,J4,J5,J6,J7,JJJ
INTEGER, PRIVATE :: ISTAT
INTEGER(NF_KV), PRIVATE, PARAMETER ::
$ NP6=6, NP7=7, NP8=8, NP9=9, NP10=10,
$ MP6=-6, MP7=-7, MP8=-8, MP9=-9, MP10=-10
CONTAINS
SUBROUTINE SA0136(RDA,IDA,BDA)
REAL(R1_KV) RDA(10)
INTEGER(I1_KV) IDA(10,9)
CHARACTER(9,C1_KV) BDA(10,9,5)
INTEGER(I1_KV) ICA(10,9)
COMMON /IF/ IF(NPBIG*NPSIZE)
EQUIVALENCE (ICA,IF(1))
REAL(R1_KV) RCA(10)
COMMON /RF/ RF(NPBIG*NPSIZE)
EQUIVALENCE (RCA,RF(1))
CHARACTER(9,C1_KV) BCA(10,9,5)
COMMON /BF/ BF(NPBIG*NPSIZE)
EQUIVALENCE (BCA,BF(1))
! I N I T I A L I Z A T I O N S E C T I O N
RDA = RCA
IDA = ICA
BDA = BCA
! T E S T S T A T E M E N T S
FORALL (J1 = 1:10)
RDA(J1) = RCA(J1) + 1.0_R1_KV
FORALL (J2 = 1:9)
FORALL (J3 = 1:5)
BDA(J1,J2,J3) = X//BCA(J1,J2,J3)
END FORALL
IDA(J1,J2) = ICA(J1,J2) + 1
END FORALL
ENDFORALL
END SUBROUTINE
SUBROUTINE SA0137(RDA,YDA,BDA,IDA,NDS10,NDS9)
INTEGER(NF_KV) :: NDS10
INTEGER(NF_KV) :: NDS9
REAL(R1_KV) RDA(NF10)
COMPLEX(R2_KV) YDA(NDS10,NF9)
CHARACTER(9,C1_KV) BDA(NF10,NDS9,NF5)
INTEGER(I1_KV) IDA(NF10)
COMPLEX(R2_KV) YCA(10,9)
COMMON /YF/ YF(NPBIG*NPSIZE)
EQUIVALENCE (YCA,YF(1))
REAL(R1_KV) RCA(10)
COMMON /RF/ RF(NPBIG*NPSIZE)
EQUIVALENCE (RCA,RF(1))
INTEGER(I1_KV) ICA(10)
COMMON /IF/ IF(NPBIG*NPSIZE)
EQUIVALENCE (ICA,IF(1))
CHARACTER(9,C1_KV) BCA(10,9,5)
COMMON /BF/ BF(NPBIG*NPSIZE)
EQUIVALENCE (BCA,BF(1))
! I N I T I A L I Z A T I O N S E C T I O N
RDA(1:10) = RCA
YDA(1:10,1:9) = YCA
BDA(1:10,1:9,1:5) = BCA
IDA(1:10) = ICA
! T E S T S T A T E M E N T S
FORALL (J1 = NF1:NF10)
RDA(J1) = RCA(J1) + 1.0_R1_KV
FORALL (J2 = NF1:NF9)
FORALL (J3 = NF1:NF5)
BDA(J1,J2,J3) = X//BCA(J1,J2,J3)
END FORALL
YDA(J1,J2) = YCA(J1,J2) + 1
END FORALL
IDA(J1) = ICA(J1) + 1
ENDFORALL
END SUBROUTINE
SUBROUTINE SA0138(RDA,YDA,BDA,IDA,NDS10,NDS9)
INTEGER(NF_KV) :: NDS10
INTEGER(NF_KV) :: NDS9
REAL(R1_KV) RDA(NF10)
COMPLEX(R2_KV) YDA(NDS10,NF9)
CHARACTER(9,C1_KV) BDA(NF10,NDS9,NF5)
INTEGER(I1_KV) IDA(NF10)
COMPLEX(R2_KV) YCA(10,9)
COMMON /YF/ YF(NPBIG*NPSIZE)
EQUIVALENCE (YCA,YF(1))
REAL(R1_KV) RCA(10)
COMMON /RF/ RF(NPBIG*NPSIZE)
EQUIVALENCE (RCA,RF(1))
CHARACTER(9,C1_KV) BCA(10,9,5)
COMMON /BF/ BF(NPBIG*NPSIZE)
EQUIVALENCE (BCA,BF(1))
INTEGER(I1_KV) ICA(10)
COMMON /IF/ IF(NPBIG*NPSIZE)
EQUIVALENCE (ICA,IF(1))
! I N I T I A L I Z A T I O N S E C T I O N
RDA(1:10) = RCA
YDA(1:10,1:9)
[Bug fortran/35819] internal compiler error with forall
--- Comment #1 from dick dot hendrickson at gmail dot com 2008-04-03 18:37 --- Obviously, ignore this one. I must have hit enter by mistake -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35819
[Bug c/35738] ICE with #pragma omp atomic and conversion from pointer to int
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-03-30 20:50:03 |2008-04-03 19:22:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35738
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #68 from rguenth at gcc dot gnu dot org 2008-04-03 19:52 --- I am no longer working on specifically this. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|rguenth at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug fortran/35820] internal compiler error with forall
--- Comment #1 from dominiq at lps dot ens dot fr 2008-04-03 20:30 --- The code compiles fine on (powerpc|i686)-apple-darwin9. Would it be possible to check how the executable works? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35820
[Bug libstdc++/35816] libstdc++ build during bootstrap is optimizing away atomic builtin check
--- Comment #2 from oblivian at users dot sourceforge dot net 2008-04-03 20:45 --- Ok so the gcc/g++ i build has optimization on by default. The configuration scripts don't seem to take this into account and the call to CXX for the atomic check is optimizing away the check in the output assembly code; thus, the grep for __sync_fetch_and_add fails and does not turn off atomic builtins. the following is right before the code generation in the configure file # Fake what AC_TRY_COMPILE does. XXX Look at redoing this new-style. The check probably needs to also take into account optimization so that the check for __sync_fetch_and_add can not be removed regardless of optimization flags. To revert to 4.2.3 behavior I inserted a -O0 in the ac_compile command for the check. -- oblivian at users dot sourceforge dot net changed: What|Removed |Added Summary|libstdc++ built during |libstdc++ build during |bootstrap is pulling in host|bootstrap is optimizing away |g++ support for atomic |atomic builtin check |builtins| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35816
[Bug middle-end/35818] ICE on incomplete array in shared clause
--- Comment #1 from jakub at gcc dot gnu dot org 2008-04-03 21:03 --- Subject: Bug 35818 Author: jakub Date: Thu Apr 3 21:02:44 2008 New Revision: 133875 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133875 Log: PR middle-end/35818 * omp-low.c (scan_sharing_clauses) case OMP_CLAUSE_SHARED: Don't call is_variable_sized if decl has incomplete type. * gcc.dg/gomp/pr35818.c: New test. Added: trunk/gcc/testsuite/gcc.dg/gomp/pr35818.c Modified: trunk/gcc/ChangeLog trunk/gcc/omp-low.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35818
[Bug c/35738] ICE with #pragma omp atomic and conversion from pointer to int
--- Comment #2 from jakub at gcc dot gnu dot org 2008-04-03 21:04 --- Subject: Bug 35738 Author: jakub Date: Thu Apr 3 21:03:54 2008 New Revision: 133876 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133876 Log: PR c/35738 * c-parser.c (c_parser_omp_atomic): Call default_function_array_conversion on the RHS. * gcc.dg/gomp/pr35738.c: New test. Added: trunk/gcc/testsuite/gcc.dg/gomp/pr35738.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-parser.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35738
[Bug fortran/35786] OpenMP Fortran PRIVATE on parameter gives error in gfc_finish_var_decl
--- Comment #4 from jakub at gcc dot gnu dot org 2008-04-03 21:21 --- Subject: Bug 35786 Author: jakub Date: Thu Apr 3 21:20:53 2008 New Revision: 133877 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133877 Log: PR fortran/35786 * openmp.c (resolve_omp_clauses): Diagnose if a clause symbol isn't a variable. * gfortran.dg/gomp/pr35786-1.f90: New test. * gfortran.dg/gomp/pr35786-2.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/gomp/pr35786-1.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/gomp/pr35786-2.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/openmp.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35786
[Bug middle-end/35818] ICE on incomplete array in shared clause
--- Comment #2 from jakub at gcc dot gnu dot org 2008-04-03 21:23 --- Subject: Bug 35818 Author: jakub Date: Thu Apr 3 21:22:41 2008 New Revision: 133878 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133878 Log: PR middle-end/35818 * omp-low.c (scan_sharing_clauses) case OMP_CLAUSE_SHARED: Don't call is_variable_sized if decl has incomplete type. * gcc.dg/gomp/pr35818.c: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/gomp/pr35818.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/omp-low.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35818
[Bug c/35738] ICE with #pragma omp atomic and conversion from pointer to int
--- Comment #3 from jakub at gcc dot gnu dot org 2008-04-03 21:25 --- Subject: Bug 35738 Author: jakub Date: Thu Apr 3 21:24:28 2008 New Revision: 133879 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133879 Log: PR c/35738 * c-parser.c (c_parser_omp_atomic): Call default_function_array_conversion on the RHS. * gcc.dg/gomp/pr35738.c: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/gomp/pr35738.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/c-parser.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35738
[Bug middle-end/35818] ICE on incomplete array in shared clause
--- Comment #3 from jakub at gcc dot gnu dot org 2008-04-03 21:25 --- 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=35818
[Bug fortran/35786] OpenMP Fortran PRIVATE on parameter gives error in gfc_finish_var_decl
--- Comment #5 from jakub at gcc dot gnu dot org 2008-04-03 21:25 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35786
[Bug c/35738] ICE with #pragma omp atomic and conversion from pointer to int
--- Comment #4 from jakub at gcc dot gnu dot org 2008-04-03 21:26 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35738
[Bug fortran/35786] OpenMP Fortran PRIVATE on parameter gives error in gfc_finish_var_decl
--- Comment #3 from jakub at gcc dot gnu dot org 2008-04-03 21:02 --- Subject: Bug 35786 Author: jakub Date: Thu Apr 3 21:01:26 2008 New Revision: 133874 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133874 Log: PR fortran/35786 * openmp.c (resolve_omp_clauses): Diagnose if a clause symbol isn't a variable. * gfortran.dg/gomp/pr35786-1.f90: New test. * gfortran.dg/gomp/pr35786-2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/gomp/pr35786-1.f90 trunk/gcc/testsuite/gfortran.dg/gomp/pr35786-2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/openmp.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35786
[Bug fortran/35820] internal compiler error with forall
--- Comment #2 from dick dot hendrickson at gmail dot com 2008-04-03 22:12 --- Subject: Re: internal compiler error with forall On Thu, Apr 3, 2008 at 3:30 PM, dominiq at lps dot ens dot fr [EMAIL PROTECTED] wrote: --- Comment #1 from dominiq at lps dot ens dot fr 2008-04-03 20:30 --- The code compiles fine on (powerpc|i686)-apple-darwin9. Would it be possible to check how the executable works? Not easily, from my point of view. This is an isolated part of a large test suite. I spent a couple of half days getting it down to this level. The problem is that the ICE moves around if I do anything. I've deleted about 160 of the original set of tests for this isolation. If I leave the 160 in and delete only 2 of the 3 subroutines I sent in the results are With SA0136 not removed gfortran%try_gfortranr s_sa0 working\s_sa0_mods.f working\s_sa0_tests.f working\s_sa0_exts.f 1 file(s) copied. rem.f: In function 'sa0160': rem.f:5327: internal compiler error: Segmentation fault [snip] With SA0137 not removed gfortran%try_gfortranr s_sa0 working\s_sa0_mods.f working\s_sa0_tests.f working\s_sa0_exts.f 1 file(s) copied. rem.f: In function 'sa0131': rem.f:4412: internal compiler error: Segmentation fault [snip] With SA0138 not removed gfortran%try_gfortranr s_sa0 working\s_sa0_mods.f working\s_sa0_tests.f working\s_sa0_exts.f 1 file(s) copied. rem.f: In function 'sa0128': rem.f:4325: internal compiler error: Segmentation fault [snip] That is, the ICE appears in 3 different places, depending on which bad subroutine I leave in the test set. If I delete the 3 bad routines, the other 160 all work correctly. I'm reluctant to send in the whole set for two reasons. It's large, the 160 subroutines are 19 characters or so and they need a substantial amount of structure code to work. Also, the suite is my bread-and-butter product and I'm reluctant to put part of it in the public domain. If no one can reproduce the problem on a Windows machine, I can try to make an executable that fails. Dick Hendrickson -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35820 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35820
[Bug fortran/35819] internal compiler error with forall
--- Comment #2 from burnus at gcc dot gnu dot org 2008-04-03 22:20 --- Close then as INVALID. Actual bug report is PR 35820 -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35819
[Bug fortran/35820] internal compiler error with forall
--- Comment #3 from burnus at gcc dot gnu dot org 2008-04-03 22:27 --- Confirm. While I do not get any crash like Dominique, valgrind shows that that there is a problem: ==20532== Invalid write of size 8 ==20532==at 0x463933: resolve_code (resolve.c:5902) ==20532==by 0x4661DB: gfc_resolve_blocks (resolve.c:5988) ==20532== Invalid read of size 8 ==20532==at 0x45B12E: gfc_resolve_assign_in_forall (resolve.c:5744) ==20532==by 0x463A5C: resolve_code (resolve.c:5833) I cannot look at the source as the computer where I've build gfortran is currently off. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2008-04-03 22:27:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35820
[Bug target/35013] Incomplete check in RTL for pm() annotation
-- eric dot weddington at atmel dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-04-03 22:28:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35013
[Bug c/35712] decimal float literal constant zero loses significant trailing zeroes
--- Comment #1 from janis at gcc dot gnu dot org 2008-04-03 23:50 --- Subject: Bug 35712 Author: janis Date: Thu Apr 3 23:49:35 2008 New Revision: 133881 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133881 Log: 2008-04-03 Janis Johnson [EMAIL PROTECTED] gcc/ PR c/35712 * dfp.c (decimal_from_decnumber): Retain trailing zeroes for decimal-float literal constant zero. testsuite/ PR c/35712 * gcc.dg/dfp/constants-zero.c: New test. Added: trunk/gcc/testsuite/gcc.dg/dfp/constants-zero.c Modified: trunk/gcc/ChangeLog trunk/gcc/dfp.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35712
[Bug target/35713] [4.4 Regression] invalid type for va_arg with _Decimal128
--- Comment #3 from janis at gcc dot gnu dot org 2008-04-04 00:21 --- Subject: Bug 35713 Author: janis Date: Fri Apr 4 00:20:48 2008 New Revision: 133887 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133887 Log: PR target/35713 * config/rs6000/rs6000.c (rs6000_gimplify_va_arg): Use integer constants of the appropriate size for runtime calculations. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35713
[Bug rtl-optimization/35817] [ira] Error in init_move_cost, at regclass.c:321
--- Comment #1 from vmakarov at gcc dot gnu dot org 2008-04-04 02:05 --- Subject: Bug 35817 Author: vmakarov Date: Fri Apr 4 02:04:25 2008 New Revision: 133888 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133888 Log: 2008-04-03 Vladimir Makarov [EMAIL PROTECTED] PR rtl-optimization/35817 * ira-costs.c (ira-costs.c): Check have_regs_of_mode. Modified: branches/ira/gcc/ChangeLog branches/ira/gcc/ira-costs.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35817
[Bug bootstrap/35155] Ada not building on gcc-4.2.3
--- Comment #1 from pogma at gcc dot gnu dot org 2008-04-04 05:30 --- Fixed in r125309 -- pogma at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pogma at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Known to fail||4.2.3 Known to work||4.3.0 4.4.0 Last reconfirmed|-00-00 00:00:00 |2008-04-04 05:30:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35155
[Bug target/20366] AIX g++ -D_LARGE_FILES fails to compile #include iostream
-- pogma at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pogma at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Known to work||4.4.0 Last reconfirmed|2007-12-21 00:29:21 |2008-04-04 05:31:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20366
[Bug middle-end/35818] ICE on incomplete array in shared clause
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35818
