[Bug ada/38009] New: Assert_Failure sinfo.adb:1002
$ gnatmake assert_failure_sinfo_1002.adb gnatgcc -c assert_failure_sinfo_1002.adb +===GNAT BUG DETECTED==+ | 4.3.1 (i686-pc-linux-gnu) Assert_Failure sinfo.adb:1002 | | Error detected at assert_failure_sinfo_1002.adb:11:10| | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| ... $ gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.3.1-r1/work/gcc-4.3.1/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.3.1 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.1/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.1 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.1/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.1/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.1/include/g++-v4 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --enable-cld --enable-java-awt=gtk --with-arch=i686 --enable-languages=c,c++,java,treelang,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.3.1-r1 p1.1' Thread model: posix gcc version 4.3.1 (Gentoo 4.3.1-r1 p1.1) gcc-4.3.1/gcc/ada/sinfo.adb: function End_Span (N : Node_Id) return Uint is begin pragma Assert (False -- line 1002 or else NT (N).Nkind = N_Case_Statement or else NT (N).Nkind = N_If_Statement); return Uint5 (N); end End_Span; -- Summary: Assert_Failure sinfo.adb:1002 Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sworley at chkno dot net GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38009
[Bug fortran/37992] [4.4 Regression] ICE segfault for character(len=len(x)) :: foo,x
--- Comment #6 from pault at gcc dot gnu dot org 2008-11-04 07:59 --- (In reply to comment #5) The patch in comment #4 generate a lot of bus errors in my tests. Looking at it, I think there is something missing: gfc_current_ns-old_cl_list is only set to NULL, it should likely be set to gfc_current_ns-cl_list somewhere. It should not be necessary to do anything to the cl_list. As long as nothing points to a member, it can do nothing and gets cleaned up at the end of compilation. The reason for this is that any number, including zero, of typespecs can point to it, so it is very risky to delete a cl_list member. Paul Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37992
[Bug ada/38009] Assert_Failure sinfo.adb:1002
--- Comment #1 from sworley at chkno dot net 2008-11-04 08:36 --- Created an attachment (id=16622) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16622action=view) A source file that triggers the sinfo.adb:1002 assert failure -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38009
[Bug c/38001] regression in 4.3: alignment checks wrongly optimized away (runtime failure)
--- Comment #8 from thomas dot orgis at awi dot de 2008-11-04 08:52 --- Ok, first, let me apologize for the 15 check is miscompiled statement... operator precedence got me there. The feature for stack-realignment I meant is __attribute__((force_align_arg_pointer)) I use this already for the API entry functions of the library when gcc = 4.2 is available. It _does_ solve the issue for misaligned stack from the caller, doesn't it? So, strictly, current gcc does not need the checks, except for the case where the user asked for trouble with -mpreferred-stack-boundary (which still should throw an error: __attribute__((aligned(16))) clearly is in conflict with that). I still need a way to handle the issue with older gccs, as I provide a source package and want to avoid bug reports about mysterious segfaults: The SSE stuff that needs alignment is an internal detail of the library, users should not need to specifically compile their programs for that detail. Now, since older gccs don't optimize away the check, it is still of use there. But I am wondering about the power of __attribute__((aligned(16))); gcc-3.4 seems to be unable to align double __attribute__((aligned(16))) altest[1]; as opposed to double __attribute__((aligned(16))) altest[2]; It sort of makes sense, the data structure should not be smaller than the alignment... but gcc-4.3 does align that correctly. Is that a bug in the older gcc or just coincidence? Well, I think I will go with the simple check with altest[2] for old compilers that don't know force_align_arg_pointer and luckily don't optimize away the check at the same time -- without need for the optimization barrier. Is that a good strategy? I can imagine that gcc folks are not that keen on caring for old gcc versions, but with mpg123 we want to support any C89 compiler, basically, however old. As for -mincoming-stack-boundary=2: __attribute__((force_align_arg_pointer)) does solve the problem equivalently, doesn't it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38001
[Bug c++/38005] inconsistent precedence of operators in namespaces
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-11-04 10:31 ---
namespace A {
class Parent{};
ostream operator(ostreamo,const Parent){return oparent\n;}
}
namespace B {
class Child:public A::Parent{};
}
ostream operator(ostreamo,const B::Child){return ochild\n;}
namespace A{
void foo(){
B::Child child;
coutchild; //prints parent
}
}
unqualified lookup of operator starts in namespace A and stops there.
argument dependent namelookup finds the same. So GCCs behavior is correct.
namespace C{
class Thing{};
void operator(Thingo,Thing){} //completely unrelated operator
void foo(){
coutchild; //prints parent
}
}
likewise. You seem to miss that namelookup stops at the first match.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38005
[Bug rtl-optimization/36350] [4.3 Regression] GCC ICE with -frename-registers
--- Comment #5 from jakub at gcc dot gnu dot org 2008-11-04 12:11 --- Indeed, a DUP of PR35964 (which isn't marked as 4.3 regression though). http://gcc.gnu.org/viewcvs?root=gccview=revrev=137235 backport fixes this on 4.3 branch, on the trunk I cannot reproduce on the given testcase even with that change reverted. Andrew, do you plan to backport this fix to 4.3 branch? -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||andrewjenner at gcc dot gnu ||dot org Known to work|4.2.2 |4.2.2 4.4.0 Summary|[4.3/4.4 Regression] GCC ICE|[4.3 Regression] GCC ICE |with -frename-registers |with -frename-registers http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36350
[Bug c++/38005] inconsistent precedence of operators in namespaces
--- Comment #8 from schwab at suse dot de 2008-11-04 14:21 --- ::operator is hidden by C::operator and cannot be found by name lookup. A::operator is found because child is-a A::parent. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38005
[Bug c/38011] New: vectorizer ignores alignment, useless versioning
When compiling:
void assignMultiplyVec(double* restrict __attribute__ ((aligned (16))) a, const
double * restrict __attribute__ ((aligned (16))) b, double coef, unsigned
count) {
for(unsigned i=0; icount; i++) {
a[i] = b[i]*coef;
}
}
Using: gcc -std=c99 -march=core2 -mtune=core2 -O3 -mfpmath=sse -ftree-vectorize
-ftree-vectorizer-verbose=9
The logs show:
essai_restrict_ref.c:2: note: Alignment of access forced using versioning.
essai_restrict_ref.c:2: note: Versioning for alignment will be applied.
essai_restrict_ref.c:2: note: Vectorizing an unaligned access.
and indeed the assembly code shows a test whether operands are 16-byte aligned.
This versioning is superfluous, since variable attributes guarantee 16-byte
alignment.
--
Summary: vectorizer ignores alignment, useless versioning
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: David dot Monniaux at ens dot fr
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38011
[Bug c++/38005] inconsistent precedence of operators in namespaces
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-11-04 15:15 --- there are two name-lookup stages for unqualified ids, first regular unqualified lookup which finds the local operator then argument-dependent lookup (Koenig lookup) which finds operator in A. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38005
[Bug libgomp/37935] omp_set_schedule not documented in libgomp.texi
--- Comment #1 from burnus at gcc dot gnu dot org 2008-11-04 15:16 --- FIXED on the trunk (4.4). -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37935
[Bug c/38001] regression in 4.3: alignment checks wrongly optimized away (runtime failure)
--- Comment #9 from hjl dot tools at gmail dot com 2008-11-04 15:20 --- (In reply to comment #8) As for -mincoming-stack-boundary=2: __attribute__((force_align_arg_pointer)) does solve the problem equivalently, doesn't it? They are the same in gcc 4.4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38001
[Bug tree-optimization/38011] vectorizer ignores alignment, useless versioning
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|minor |enhancement Component|c |tree-optimization Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38011
[Bug middle-end/37861] Bogus array bounds warning
--- Comment #5 from jamborm at gcc dot gnu dot org 2008-11-04 15:51 --- Right, so this is the most simple (albeit not yet tested) patch I've been able to come up with. I am not sure what overall impact this is going to have. I'll briefly try to come up with something more sophisticated... Index: gcc/tree-ssa-forwprop.c === --- gcc/tree-ssa-forwprop.c (revision 141546) +++ gcc/tree-ssa-forwprop.c (working copy) @@ -812,6 +812,7 @@ forward_propagate_addr_expr_1 (tree name array_ref = TREE_OPERAND (def_rhs, 0); if (TREE_CODE (array_ref) != ARRAY_REF || TREE_CODE (TREE_TYPE (TREE_OPERAND (array_ref, 0))) != ARRAY_TYPE + || TREE_CODE (TREE_OPERAND (array_ref, 0)) == INDIRECT_REF || !integer_zerop (TREE_OPERAND (array_ref, 1))) return false; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37861
[Bug c++/38012] New: vectorizer ignores 'restrict'
The vectorizer ignores the 'restrict' keyword regarding two pointer destinations, and emits a run-time aliasing text. -- Summary: vectorizer ignores 'restrict' Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: David dot Monniaux at imag dot fr GCC build triplet: i486-linux-gnu GCC host triplet: i486-linux-gnu GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38012
[Bug java/37068] [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected
--- Comment #24 from aph at redhat dot com 2008-11-04 16:09 ---
Subject: Re: [4.4 Regression] libgcj linkage failure: Incorrect
library ABI version detected
mark at codesourcery dot com wrote:
You shouldn't call that function. Instead, you should set
DECL_STATIC_{CONSTRUCTOR,DESTRUCTOR}. Then, cgraph will do the right
thing. If necessary, you can also call decl_init_priority_insert.
This patch works on x86_64 GNU/Linux.
Please HP/UX, AIX, and OSF users make sure it works for them as well.
Thanks,
Andrew.
2008-11-04 Andrew Haley [EMAIL PROTECTED]
* jcf-parse.c (java_emit_static_constructor): Don't call
cgraph_build_static_cdtor. Rewrite.
Index: jcf-parse.c
===
--- jcf-parse.c (revision 141575)
+++ jcf-parse.c (working copy)
@@ -1699,7 +1699,32 @@
write_resource_constructor (body);
if (body)
-cgraph_build_static_cdtor ('I', body, DEFAULT_INIT_PRIORITY);
+{
+ tree name = get_identifier (_Jv_global_static_constructor);
+
+ tree decl = build_decl (FUNCTION_DECL, name,
+ build_function_type (void_type_node,
void_list_node));
+
+ tree resdecl = build_decl (RESULT_DECL, NULL_TREE, void_type_node);
+ DECL_ARTIFICIAL (resdecl) = 1;
+ DECL_RESULT (decl) = resdecl;
+ current_function_decl = decl;
+ allocate_struct_function (decl, false);
+
+ TREE_STATIC (decl) = 1;
+ TREE_USED (decl) = 1;
+ DECL_ARTIFICIAL (decl) = 1;
+ DECL_NO_INSTRUMENT_FUNCTION_ENTRY_EXIT (decl) = 1;
+ DECL_SAVED_TREE (decl) = body;
+ DECL_UNINLINABLE (decl) = 1;
+
+ DECL_INITIAL (decl) = make_node (BLOCK);
+ TREE_USED (DECL_INITIAL (decl)) = 1;
+
+ DECL_STATIC_CONSTRUCTOR (decl) = 1;
+ java_genericize (decl);
+ cgraph_finalize_function (decl, false);
+}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37068
[Bug middle-end/38012] vectorizer ignores 'restrict'
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-11-04 16:10 --- restrict support is only roughly implemented. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|minor |enhancement Component|c++ |middle-end Keywords||alias, missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38012
[Bug c++/36631] [4.3/4.4 Regression] attribute always_inline - sorry, unimplemented: recursive inlining
--- Comment #8 from jakub at gcc dot gnu dot org 2008-11-04 16:03 --- Actually, looking at this some more, the problem is just that g has a wrong DECL_ARG_TYPE. When instantiate_class_template is called on B, it instantiates g; class C is returned by lookup_template_class, but not yet a complete type, so it doesn't have TYPE_HAS_INIT_REF set, nor TYPE_HAS_COMPLEX_INIT_REF, nor TREE_ADDRESSABLE. Then tsubst_decl case PARM_DECL: if (!DECL_TEMPLATE_PARM_P (r)) DECL_ARG_TYPE (r) = type_passed_as (type); is called, but the RECORD_TYPE C is still incomplete at this point, so type_passed_as, seeing no TREE_ADDRESSABLE being set on type, returns type itself. Afterwards when require_complete_types_for_parms is called on trigger's parameters, instantiate_class_template is called on C and all the above mentioned 3 bits are set. But nothing goes back to fix up DECL_ARG_TYPE, at least not until instantiate_pending_templates eventually calls require_complete_types_for_parms on g's params. But that is already way after trigger has been gimplified. So I believe we need to update DECL_ARG_TYPE (parm) from type_passed_as (TREE_TYPE (parm)) for calls a function is making, but am not sure where would that be best done. In genericization? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36631
[Bug c++/38012] vectorizer ignores 'restrict'
--- Comment #1 from David dot Monniaux at imag dot fr 2008-11-04 16:06 --- Created an attachment (id=16623) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16623action=view) source code where va and vb are thought to be aliased The compiler should heed that va and vb cannot point to aliased locations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38012
[Bug preprocessor/38013] New: Option to turn off usage of any precompiled header
There is no option to turn off the use of precompiled headers. This makes generating preprocessed source for bugs harder than necessary (you need to manually remove the pchs). -- Summary: Option to turn off usage of any precompiled header Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38013
[Bug c++/36631] [4.3/4.4 Regression] attribute always_inline - sorry, unimplemented: recursive inlining
--- Comment #9 from jakub at gcc dot gnu dot org 2008-11-04 16:43 --- Created an attachment (id=16624) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16624action=view) gcc44-pr36631.patch Quite ugly fix, Jason, do you have better ideas how to fix this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36631
[Bug libgomp/37938] libgomp testsuite failures on ia64-linux
--- Comment #4 from sje at cup dot hp dot com 2008-11-04 16:54 --- I have submitted a patch at http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00125.html and will check it in tomorrow. It should fix all the libgomp failures on IA64 Linux. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37938
[Bug c++/38005] inconsistent precedence of operators in namespaces
--- Comment #10 from c dot hite at rtsgroup dot net 2008-11-04 17:10 --- So you're saying this isn't a bug because G++ does what it does? Is there no standard specifying what should happen? I would like to think if two different compilers produce different results, one of them has a bug. Would you say Sun has a bug? As far as I'm concerned, it's best to define the operator in the same namespace as its operands. I'm willing to give up. Thanks for your time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38005
Re: [Bug preprocessor/38013] New: Option to turn off usage of any precompiled header
You can also just do -Dineednopchreallyidont :). Sent from my iPhone On Nov 4, 2008, at 8:23 AM, rguenth at gcc dot gnu dot org [EMAIL PROTECTED] wrote: There is no option to turn off the use of precompiled headers. This makes generating preprocessed source for bugs harder than necessary (you need to manually remove the pchs). -- Summary: Option to turn off usage of any precompiled header Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38013
[Bug preprocessor/38013] Option to turn off usage of any precompiled header
--- Comment #1 from pinskia at gmail dot com 2008-11-04 17:46 --- Subject: Re: New: Option to turn off usage of any precompiled header You can also just do -Dineednopchreallyidont :). Sent from my iPhone On Nov 4, 2008, at 8:23 AM, rguenth at gcc dot gnu dot org [EMAIL PROTECTED] wrote: There is no option to turn off the use of precompiled headers. This makes generating preprocessed source for bugs harder than necessary (you need to manually remove the pchs). -- Summary: Option to turn off usage of any precompiled header Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38013 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38013
[Bug middle-end/37914] [4.4 Regression] internal compiler error: vector VEC(basic_block,base) index domain error
--- Comment #2 from jakub at gcc dot gnu dot org 2008-11-04 17:46 --- Bootstrapped it again. Reopen if you still have problems with current snapshots. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37914
[Bug preprocessor/38013] Option to turn off usage of any precompiled header
--- Comment #2 from paolo dot carlini at oracle dot com 2008-11-04 18:01 --- (In reply to comment #1) You can also just do -Dineednopchreallyidont :). .. and in a libstdc++ testcase (17_intro/headers/all_assert_neg.cc) we do something similar... as an hack, to be clear ;) -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||paolo at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38013
[Bug java/37068] [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected
--- Comment #25 from dje dot gcc at gmail dot com 2008-11-04 18:11 --- Subject: Re: [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected This patch works on x86_64 GNU/Linux. Please HP/UX, AIX, and OSF users make sure it works for them as well. I recompiled jc1 and libjava with the patch. I still encounter failures with execution tests. I will be interested to learn Dave's results on HP-UX. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37068
[Bug java/37068] [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected
--- Comment #26 from dje dot gcc at gmail dot com 2008-11-04 18:15 --- Subject: Re: [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected The runtime failure has changed and no longer is complaining about ABI versions on AIX. As I mentioned, I will be interested to learn from Dave's results this new runtime problem is AIX-specific or common to the other platforms. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37068
[Bug java/37068] [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected
--- Comment #27 from aph at redhat dot com 2008-11-04 18:16 --- Subject: Re: [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected dje dot gcc at gmail dot com wrote: --- Comment #25 from dje dot gcc at gmail dot com 2008-11-04 18:11 --- Subject: Re: [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected This patch works on x86_64 GNU/Linux. Please HP/UX, AIX, and OSF users make sure it works for them as well. I recompiled jc1 and libjava with the patch. I still encounter failures with execution tests. I will be interested to learn Dave's results on HP-UX. Oh dear: I followed mmitchel's instructions to the letter. Sooner or later someone is going to have to be allowed access to a suitable machine. Andrew. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37068
[Bug libgomp/37935] omp_set_schedule not documented in libgomp.texi
--- Comment #2 from burnus at gcc dot gnu dot org 2008-11-04 18:17 --- Subject: Bug 37935 Author: burnus Date: Tue Nov 4 18:16:17 2008 New Revision: 141583 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141583 Log: 2008-11-04 Tobias Burnus [EMAIL PROTECTED] PR libgomp/37935 * libgomp.texi (Runtime library routines, environment * variables): Update for OpenMP version 3.0. Modified: trunk/libgomp/ChangeLog trunk/libgomp/libgomp.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37935
[Bug java/37068] [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected
--- Comment #28 from aph at gcc dot gnu dot org 2008-11-04 18:19 --- So I take it that the libgcj linkage failure is fixed, but some other unrelated bug now occurs? Sounds like this one needs to be closed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37068
[Bug middle-end/37883] [graphite] ICE : in scan_tree_for_params, at graphite.c:2274
--- Comment #3 from grosser at gcc dot gnu dot org 2008-11-04 18:25 --- It seems PLUS_EXPR and POINTER_PLUS_EXPR can really handled identically. So I will like to commit this patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37883
[Bug java/37068] [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected
--- Comment #29 from dje at gcc dot gnu dot org 2008-11-04 18:33 --- So I take it that the libgcj linkage failure is fixed, but some other unrelated bug now occurs? Sounds like this one needs to be closed. No. linkage failure does not mean a link-edit failure. It always has been a runtime failure: libgcj failure: gcj linkage error. That error now is gone, but we may only have stepped to the next error on these platforms. We can decide if it should continue in this bug or a new bug should be opened. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37068
[Bug c/37995] using stdio.h fails if gcc invoked in a directory which has a subdirectory called gcc
--- Comment #5 from mvanier at cs dot caltech dot edu 2008-11-04 11:07 --- OK, I built a vanilla gcc system from scratch and it's still exhibiting the same problem. However, here's something new: the problem only manifests itself if . (the current directory) is in the path. If it isn't, no problem. $GCC_EXEC_PATH is not defined. Also, (when . is in the path) if I explicitly give the path to gcc: % /pkg/gcc/bin/gcc hello.c it works. But if I don't: % which gcc /pkg/gcc/bin/gcc % gcc hello.c you get the same error message I reported before. This is really weird. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37995
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Comment #123 from jsm28 at gcc dot gnu dot org 2008-11-04 13:25 --- Subject: Bug 323 Author: jsm28 Date: Tue Nov 4 13:24:30 2008 New Revision: 141578 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141578 Log: PR rtl-optimization/323 * c-common.c (convert_and_check, c_common_truthvalue_conversion): Handle EXCESS_PRECISION_EXPR. * c-common.def (EXCESS_PRECISION_EXPR): New. * c-cppbuiltin.c (builtin_define_float_constants): Define constants with enough digits for long double. * c-lex.c (interpret_float): Interpret constant with excess precision where appropriate. * c-opts.c (c_common_post_options): Set flag_excess_precision_cmdline. * c-parser.c (c_parser_conditional_expression): Handle excess precision in condition. * c-typeck.c (c_fully_fold): Handle EXCESS_PRECISION_EXPR. (c_fully_fold_internal): Disallow EXCESS_PRECISION_EXPR. (convert_arguments): Handle arguments with excess precision. (build_unary_op): Move excess precision outside operation. (build_conditional_expr): Likewise. (build_compound_expr): Likewise. (build_c_cast): Do cast on operand of EXCESS_PRECISION_EXPR. (build_modify_expr): Handle excess precision in RHS. (convert_for_assignment): Handle excess precision in converted value. (digest_init, output_init_element, process_init_element): Handle excess precision in initializer. (c_finish_return): Handle excess precision in return value. (build_binary_op): Handle excess precision in operands and add excess precision as needed for operation. * common.opt (-fexcess-precision=): New option. * config/i386/i386.h (X87_ENABLE_ARITH, X87_ENABLE_FLOAT): New. * config/i386/i386.md (floatSSEMODEI24:modeX87MODEF:mode2): For standard excess precision, output explicit conversion to and truncation from XFmode. (*floatSSEMODEI24:modeX87MODEF:mode2_1, *floatSSEMODEI24:modeX87MODEF:mode2_i387_with_temp, *floatSSEMODEI24:modeX87MODEF:mode2_i387, two unnamed define_splits, floatdiX87MODEF:mode2_i387_with_xmm, two unnamed define_splits, *floatunssimode2_1, two unnamed define_splits, floatunssimode2, addmode3, submode3, mulmode3, divdf3, divsf3, *fop_mode_comm_i387, *fop_mode_1_i387, *fop_MODEF:mode_2_i387, *fop_MODEF:mode_3_i387, *fop_df_4_i387, *fop_df_5_i387, *fop_df_6_i387, two unnamed define_splits, sqrtmode2): Disable where appropriate for standard excess precision. * convert.c (convert_to_real): Do not shorten arithmetic to type for which excess precision would be used. * doc/invoke.texi (-fexcess-precision=): Document option. (-mfpmath=): Correct index entry. * flags.h (enum excess_precision, flag_excess_precision_cmdline, flag_excess_precision): New. * langhooks.c (lhd_post_options): Set flag_excess_precision_cmdline. * opts.c (common_handle_option): Handle -fexcess-precision=. * toplev.c (flag_excess_precision_cmdline, flag_excess_precision, init_excess_precision): New. (lang_dependent_init_target): Call init_excess_precision. * tree.c (excess_precision_type): New. * tree.h (excess_precision_type): Declare. ada: * gcc-interface/misc.c (gnat_post_options): Set flag_excess_precision_cmdline. fortran: * options.c (gfc_post_options): Set flag_excess_precision_cmdline. java: * lang.c (java_post_options): Set flag_excess_precision_cmdline. testsuite: * gcc.target/i386/excess-precision-1.c, gcc.target/i386/excess-precision-2.c, gcc.target/i386/excess-precision-3.c, gcc.target/i386/excess-precision-4.c, gcc.target/i386/excess-precision-5.c, gcc.target/i386/excess-precision-6.c: New tests. Added: branches/c-4_5-branch/gcc/ada/ChangeLog.c45 branches/c-4_5-branch/gcc/fortran/ChangeLog.c45 branches/c-4_5-branch/gcc/java/ChangeLog.c45 branches/c-4_5-branch/gcc/testsuite/gcc.target/i386/excess-precision-1.c branches/c-4_5-branch/gcc/testsuite/gcc.target/i386/excess-precision-2.c branches/c-4_5-branch/gcc/testsuite/gcc.target/i386/excess-precision-3.c branches/c-4_5-branch/gcc/testsuite/gcc.target/i386/excess-precision-4.c branches/c-4_5-branch/gcc/testsuite/gcc.target/i386/excess-precision-5.c branches/c-4_5-branch/gcc/testsuite/gcc.target/i386/excess-precision-6.c Modified: branches/c-4_5-branch/gcc/ChangeLog.c45 branches/c-4_5-branch/gcc/ada/gcc-interface/misc.c branches/c-4_5-branch/gcc/c-common.c branches/c-4_5-branch/gcc/c-common.def branches/c-4_5-branch/gcc/c-cppbuiltin.c branches/c-4_5-branch/gcc/c-lex.c branches/c-4_5-branch/gcc/c-opts.c branches/c-4_5-branch/gcc/c-parser.c
[Bug java/37068] [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected
--- Comment #30 from dave at hiauly1 dot hia dot nrc dot ca 2008-11-04 19:01 --- Subject: Re: [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected That error now is gone, but we may only have stepped to the next error on these platforms. We can decide if it should continue in this bug or a new bug should be opened. If the error is releated to the running of constructors for class registration or resource registration, then I think we should continue with this bug. Otherwise, it's a new bug. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37068
[Bug target/37364] [4.4 Regression] IRA generates inefficient code due to missing regmove pass
--- Comment #25 from hjl dot tools at gmail dot com 2008-11-04 19:28 --- This regression isn't specific to -mtune=core2. I saw 3% regression with -O3 on Intel64. Enable the full regmove pass fixes the regression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37364
[Bug rtl-optimization/37948] [4.4 Regression] IRA generates slower code
--- Comment #7 from hjl dot tools at gmail dot com 2008-11-04 19:36 --- IRA generates much slower codes: [EMAIL PROTECTED] 37364]$ make /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O2 -m32 -fno-ira -o noira foo.c /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O2 -m32 -o ira foo.c time ./noira 7.62user 0.01system 0:07.65elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+88minor)pagefaults 0swaps time ./ira 7.81user 0.01system 0:07.83elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+87minor)pagefaults 0swaps [EMAIL PROTECTED] 37364]$ make time ./noira 7.07user 0.01system 0:07.10elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+88minor)pagefaults 0swaps time ./ira 7.96user 0.00system 0:07.97elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+87minor)pagefaults 0swaps [EMAIL PROTECTED] 37364]$ make time ./noira 7.40user 0.00system 0:07.40elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+87minor)pagefaults 0swaps time ./ira 7.81user 0.00system 0:07.82elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+87minor)pagefaults 0swaps [EMAIL PROTECTED] 37364]$ -- hjl dot tools at gmail dot com changed: What|Removed |Added Summary|[4.4 Regression] IRA|[4.4 Regression] IRA |generates slower code for - |generates slower code |mtune=core2 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37948
[Bug c++/38005] inconsistent precedence of operators in namespaces
--- Comment #5 from c dot hite at rtsgroup dot net 2008-11-04 10:47 --- I'm fine with case #1. I don't know if Sun is wrong, or there is no right. #2 is a BUG. No, the lookup doesn't stop at operator(Thingo,Thing), it keeps going, but it keeps going differently. Please look at it. In namespace C after the compiler realizes that the local operator doesn't match, I expect it to try the other operators in the same order as if that local operator didn't exist. Why do C and D generate different calls? When deciding between the other two operators outside their namespace C and D should reach the same decision. -- c dot hite at rtsgroup dot net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38005
[Bug c++/38007] [4.2/4.3/4.4 Regression] g++ instantiate same operator twice due to bitfield in -O0 mode, causing symbol already defined assembler error
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-11-04 10:39 ---
The following also fails the same way with optimization:
class foo {
public:
template typename T __attribute__((noinline))
operator T () { return (T)0; }
};
struct bar {
unsigned int _bar : 24;
};
int main()
{
foo a;
unsigned int b = a;
bar c;
c._bar = a;
return 0;
}
we instantiate the operator for unsigned int and unsigned int : 24
what we probably should do is treat
c._bar = a;
as
c._bar = (unsigned int : 24)(unsigned int)a;
instead.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38007
[Bug middle-end/35964] ICE with -funroll-loops on arm/arm eabi
--- Comment #17 from jakub at gcc dot gnu dot org 2008-11-04 12:06 --- And even fixed on the trunk: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137235 No idea why it hasn't been applied to 4.3 though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35964
[Bug c++/38005] inconsistent precedence of operators in namespaces
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-11-04 12:51 --- You are wrong. Name-lookup _does_ stop at the first match. Name-lookup has nothing to do with declaration matching - it only looks up names. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38005
[Bug c/37106] [4.4 Regression] ICE with -fpic or -fPIC: in mems_in_disjoint_alias_sets_p, at alias.c:278
--- Comment #17 from jakub at gcc dot gnu dot org 2008-11-04 20:08 --- Subject: Bug 37106 Author: jakub Date: Tue Nov 4 20:06:33 2008 New Revision: 141584 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141584 Log: PR c/37106 * c-common.c (parse_optimize_options): Save and restore flag_strict_aliasing around decode_options call. * gcc.dg/pr37106-1.c: New test. * gcc.dg/pr37106-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr37106-1.c trunk/gcc/testsuite/gcc.dg/pr37106-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-common.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37106
[Bug c/37106] [4.4 Regression] ICE with -fpic or -fPIC: in mems_in_disjoint_alias_sets_p, at alias.c:278
--- Comment #18 from jakub at gcc dot gnu dot org 2008-11-04 20:24 --- 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=37106
[Bug c/35430] [4.2/4.3/4.4 regression] ICE with complex arithmetic
--- Comment #5 from jakub at gcc dot gnu dot org 2008-11-04 20:53 --- Subject: Bug 35430 Author: jakub Date: Tue Nov 4 20:51:38 2008 New Revision: 141587 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141587 Log: PR c/35430 * c-common.c (warn_for_sign_compare): For complex result_type use component's type. * gcc.dg/pr35430.c: New test. * g++.dg/warn/Wsign-compare-2.C: New test. Added: trunk/gcc/testsuite/g++.dg/warn/Wsign-compare-2.C trunk/gcc/testsuite/gcc.dg/pr35430.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-common.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35430
[Bug c/35430] [4.2/4.3 regression] ICE with complex arithmetic
--- Comment #6 from jakub at gcc dot gnu dot org 2008-11-04 21:03 --- Fixed on the trunk. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.4.0 Summary|[4.2/4.3/4.4 regression] ICE|[4.2/4.3 regression] ICE |with complex arithmetic |with complex arithmetic http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35430
[Bug c++/36334] [4.2/4.3/4.4 Regression] typedef to function type leads to problems
--- Comment #3 from jakub at gcc dot gnu dot org 2008-11-04 21:08 --- Caused by PR28588 fix, http://gcc.gnu.org/viewcvs?root=gccview=revrev=116468 -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36334
[Bug fortran/37597] internal procedure fails to access host-associated module procedure
--- Comment #1 from pault at gcc dot gnu dot org 2008-11-04 21:12 --- An 'obvious' fix is on the way. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-09-21 19:38:06 |2008-11-04 21:12:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37597
[Bug c/37995] using stdio.h fails if gcc invoked in a directory which has a subdirectory called gcc
--- Comment #6 from mvanier at cs dot caltech dot edu 2008-11-04 11:08 --- Oops, I meant GCC_EXEC_PREFIX is not defined, not GCC_EXEC_PATH. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37995
[Bug fortran/37597] internal procedure fails to access host-associated module procedure
--- Comment #2 from pault at gcc dot gnu dot org 2008-11-04 21:19 --- Subject: Bug 37597 Author: pault Date: Tue Nov 4 21:17:53 2008 New Revision: 141588 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141588 Log: 2008-11-04 Paul Thomas [EMAIL PROTECTED] PR fortran/37597 * parse.c (gfc_fixup_sibling_symbols ): Fixup contained, even when symbol not found. 2008-11-04 Paul Thomas [EMAIL PROTECTED] PR fortran/37597 * gfortran.dg/host_assoc_call_5.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/host_assoc_call_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/parse.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37597
[Bug c++/38005] inconsistent precedence of operators in namespaces
--- Comment #7 from c dot hite at rtsgroup dot net 2008-11-04 13:36 --- If it stopped at the first match, then the call in C would match the operator in C and say the operands don't match and not compile. Instead C goes on to call an operator defined in A. Why does C check A and not the global space first? Why does D do it the other way around? Note that if we were talking about functions there is no way C or D could call anything in A without a using clause or explicit A::. Operators do a Koenig lookup, which is a bit different. I think there's something buggy about it. -- c dot hite at rtsgroup dot net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38005
[Bug bootstrap/38014] New: [4.4 regression] in-tree gmp and mpfr libraries no longer work
In gcc 4.3, you can unpack the gmp and mpfr libraries into your source tree, and gcc will build, even if gmp and mpfr are not installed on the host system. That appears to be broken in mainline as of 2008-10-22. The problem is that the top level configury passes --with-gmp-build when configuring mpfr. The mpfr library records that in its Makefile using CPPFLAGS. Now the top level Makefile overrides CPPFLAGS. The effect: make[4]: Entering directory `/home/jingyu/projects/gcc/obj-gcc-i686/mpfr' /bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_STDARG=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SETLOCALE=1 -DHAVE_GETTIMEOFDAY=1 -DMPFR_HAVE_FESETROUND=1 -DHAVE_FLOOR=1 -DHAVE_CEIL=1 -DHAVE_LDOUBLE_IEEE_EXT_LITTLE=1 -DHAVE_ATTRIBUTE_MODE=1 -DHAVE_ALLOCA_H=1 -I. -I../../gcc_src/mpfr -g -fkeep-inline-functions -MT exceptions.lo -MD -MP -MF .deps/exceptions.Tpo -c -o exceptions.lo ../../gcc_src/mpfr/exceptions.c gcc -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_STDARG=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SETLOCALE=1 -DHAVE_GETTIMEOFDAY=1 -DMPFR_HAVE_FESETROUND=1 -DHAVE_FLOOR=1 -DHAVE_CEIL=1 -DHAVE_LDOUBLE_IEEE_EXT_LITTLE=1 -DHAVE_ATTRIBUTE_MODE=1 -DHAVE_ALLOCA_H=1 -I. -I../../gcc_src/mpfr -g -fkeep-inline-functions -MT exceptions.lo -MD -MP -MF .deps/exceptions.Tpo -c ../../gcc_src/mpfr/exceptions.c -o exceptions.o In file included from ../../gcc_src/mpfr/exceptions.c:23: ../../gcc_src/mpfr/mpfr-impl.h:74:19: error: gmp.h: No such file or directory In file included from ../../gcc_src/mpfr/mpfr-impl.h:77, from ../../gcc_src/mpfr/exceptions.c:23: ../../gcc_src/mpfr/mpfr.h:39:18: error: gmp.h: No such file or directory -- Summary: [4.4 regression] in-tree gmp and mpfr libraries no longer work Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: drow at gcc dot gnu dot org ReportedBy: ian at airs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38014
[Bug java/37068] [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected
-- aph at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aph at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37068
[Bug bootstrap/38014] [4.4 regression] in-tree gmp and mpfr libraries no longer work
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||build Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38014
[Bug bootstrap/38010] New: gcc/config.gcc needs adjustment for darwin10
Currently gcc/config.gcc in gcc trunk doesn't recognize darwin10 and thus
doesn't use darwin9.h in that case.
Mike Stump recommends the change...
Index: gcc/config.gcc
===
--- gcc/config.gcc (revision 141576)
+++ gcc/config.gcc (working copy)
@@ -408,7 +408,7 @@
*-*-darwin*)
tm_file=${tm_file} darwin.h
case ${target} in
- *-*-darwin9*)
+ *-*-darwin[912]*)
tm_file=${tm_file} darwin9.h
;;
esac
which avoids using darwin9.h on darwin8.
--
Summary: gcc/config.gcc needs adjustment for darwin10
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: howarth at nitro dot med dot uc dot edu
GCC build triplet: i686-apple-darwin10
GCC host triplet: i686-apple-darwin10
GCC target triplet: i686-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38010
[Bug bootstrap/38014] [4.4 regression] in-tree gmp and mpfr libraries no longer work
--- Comment #1 from hp at gcc dot gnu dot org 2008-11-04 22:15 --- Is something missing from the description? In-tree gmp and mpfr seems to work for me as of r141574, for cris-elf, on a Fedora 8 system. Dunno if it matters that there's also: mpfr-2.3.0-1.fc8 gmp-4.2.2-4.fc8 gmp-4.2.2-4.fc8 package mpfr-devel is not installed gmp-devel-4.2.2-4.fc8 gmp-devel-4.2.2-4.fc8 Maybe you configured with a relative configure-path, or is it the nativeness of your build? grep exception.c build-log gives ARG=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SETLOCALE=1 -DHAVE_GETTIMEOFDAY=1 -DMPFR_HAVE_FESETROUND=1 -DHAVE_FLOOR=1 -DHAVE_CEIL=1 -DHAVE_LDOUBLE_IEEE_EXT_LITTLE=1 -DHAVE_ATTRIBUTE_MODE=1 -DHAVE_ALLOCA_H=1 -I. -I/tmp/hpautotest-gcc1/gcc/mpfr -g -O2 -MT exceptions.lo -MD -MP -MF .deps/exceptions.Tpo -c -o exceptions.lo /tmp/hpautotest-gcc1/gcc/mpfr/exceptions.c; \ gcc -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_STDARG=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SETLOCALE=1 -DHAVE_GETTIMEOFDAY=1 -DMPFR_HAVE_FESETROUND=1 -DHAVE_FLOOR=1 -DHAVE_CEIL=1 -DHAVE_LDOUBLE_IEEE_EXT_LITTLE=1 -DHAVE_ATTRIBUTE_MODE=1 -DHAVE_ALLOCA_H=1 -I. -I/tmp/hpautotest-gcc1/gcc/mpfr -g -O2 -MT exceptions.lo -MD -MP -MF .deps/exceptions.Tpo -c /tmp/hpautotest-gcc1/gcc/mpfr/exceptions.c -o exceptions.o if gcc -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_STDARG=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SETLOCALE=1 -DHAVE_GETTIMEOFDAY=1 -DMPFR_HAVE_FESETROUND=1 -DHAVE_FLOOR=1 -DHAVE_CEIL=1 -DHAVE_LDOUBLE_IEEE_EXT_LITTLE=1 -DHAVE_ATTRIBUTE_MODE=1 -DHAVE_ALLOCA_H=1 -I. -I/tmp/hpautotest-gcc1/gcc/mpfr/tests -I/tmp/hpautotest-gcc1/gcc/mpfr -I.. -g -O2 -MT texceptions.o -MD -MP -MF .deps/texceptions.Tpo -c -o texceptions.o /tmp/hpautotest-gcc1/gcc/mpfr/tests/texceptions.c; \ -- hp at gcc dot gnu dot org changed: What|Removed |Added CC||hp at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38014
[Bug middle-end/38004] [4.4 Regression] g++.dg/vect/pr36648.cc
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-11-04 09:29 --- I don't see how the patch can make a difference only on ia64. Note that on x86_64 the loop isn't vectorized either -- even though the stats print there is a vectorized loop. It looks like the vectorized version gets removed by cfgcleanup immediately. Increasing the array size to 8 makes the vectorized loop appear. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC|rguenther at suse dot de|rguenth at gcc dot gnu dot ||org Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38004
[Bug c/38015] New: Converting between int and vector using intrinsics goes through memory
Consider the following function, which adds 1 to its argument using Intel
intrinsics:
#include emmintrin.h
unsigned
add1(unsigned x)
{
__m128i a = _mm_cvtsi32_si128(x);
__m128i b = _mm_add_epi32(a, _mm_set_epi32(0, 0, 0, 1));
return _mm_cvtsi128_si32(b);
}
GCC goes through memory no less than three times: once when converting x to a
vector, once when converting 1 to a vector, and once when converting the result
back to an integer:
add1:
pxor%xmm0, %xmm0
movq%rdi, -16(%rsp)
movq-16(%rsp), %xmm1
movss %xmm1, %xmm0
paddd .LC0(%rip), %xmm0
movd%xmm0, -4(%rsp)
movl-4(%rsp), %eax
ret
For comparison, here is the code generated by the Intel compiler:
add1:
movl $1, %edx
movd %edi, %xmm1
movd %edx, %xmm0
paddd %xmm0, %xmm1
movd %xmm1, %eax
ret
--
Summary: Converting between int and vector using intrinsics goes
through memory
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jch at pps dot jussieu dot fr
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38015
[Bug target/38015] Converting between int and vector using intrinsics goes through memory
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-11-04 22:48 --- I think it depends on the tuning of the processor which decides if it should goto memory or not. -mtune=generic makes it go through memory while -mtune=core2 does not and we get: movd%edi, %xmm0 paddd LC0(%rip), %xmm0 movd%xmm0, %eax ret Note I checking with -fPIC turned on. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38015
[Bug java/37068] [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected
--- Comment #31 from aph at redhat dot com 2008-11-04 23:06 --- Subject: Re: [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected dave at hiauly1 dot hia dot nrc dot ca wrote: --- Comment #30 from dave at hiauly1 dot hia dot nrc dot ca 2008-11-04 19:01 --- Subject: Re: [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected That error now is gone, but we may only have stepped to the next error on these platforms. We can decide if it should continue in this bug or a new bug should be opened. If the error is releated to the running of constructors for class registration or resource registration, then I think we should continue with this bug. Otherwise, it's a new bug. OK, but I need to know if my patch has been tested well enough for me to check it in. I'm fairly certain it doesn't break x86 GNU/Linux. Andrew. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37068
Re: [Bug middle-end/37883] [graphite] ICE : in scan_tree_for_params, at graphite.c:2274
It seems PLUS_EXPR and POINTER_PLUS_EXPR can really handled identically. So I will like to commit this patch. Yes they should be handled in the same way in this context. Please install the patch. Thanks, Sebastian
[Bug middle-end/37883] [graphite] ICE : in scan_tree_for_params, at graphite.c:2274
--- Comment #4 from sebpop at gmail dot com 2008-11-04 23:34 --- Subject: Re: [graphite] ICE : in scan_tree_for_params, at graphite.c:2274 It seems PLUS_EXPR and POINTER_PLUS_EXPR can really handled identically. So I will like to commit this patch. Yes they should be handled in the same way in this context. Please install the patch. Thanks, Sebastian -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37883
[Bug other/32263] Document the required versions of glibc and binutils
--- Comment #8 from appfault at hotmail dot com 2008-11-04 23:47 --- Reopen to at least consider comment 7. -- appfault at hotmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32263
[Bug target/38015] Converting between int and vector using intrinsics goes through memory
--- Comment #2 from jch at pps dot jussieu dot fr 2008-11-05 00:27 --- Then -mtune=generic is not doing something reasonable. If I read correctly the docs I have available, going through memory doesn't win on either Core2 or AMD family 10. It does win on the K8, but only in the xmm-integer direction. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38015
[Bug libstdc++/24803] [c++0x] reference_wrapper and pointers to member functions
--- Comment #9 from jwakely dot gcc at gmail dot com 2008-11-05 01:09 --- Created an attachment (id=16625) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16625action=view) update result_of and reference_wrapper In the current draft, reference_wrapper invocation requires Callable, which means it should not work for pointers to members. The same is true of result_of, which determines the result of an expression that isn't valid syntax for pointers to members. That said, here's a patch that updates result_of and reference_wrapper to work for pointers to members as well as callable types, using result_of in place of the Callable concept. If result_of and reference_wrapper really shouldn't work for pointers to members then this patch would be much simpler, and there's no need for __invoke() either. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24803
[Bug java/37068] [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected
--- Comment #32 from dave at hiauly1 dot hia dot nrc dot ca 2008-11-05 01:11 --- Subject: Re: [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected OK, but I need to know if my patch has been tested well enough for me to check it in. I'm fairly certain it doesn't break x86 GNU/Linux. For me, the change fixes the PR. There are still 10 fails in the testsuite on hppa2.0w-hp-hpux11.11. Four are expected because large file support is not enabled. I don't believe the other fails have anything to do with this PR. I checked that the duplicates are gone in org-xml.s. gcj-dbtool now runs successfully. The testsuite on hppa-unknown-linux-gnu is still clean. There are no ABI version failures. Thanks, Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37068
[Bug libstdc++/37351] [c++0x] std::result_of requires nested template
--- Comment #9 from jwakely dot gcc at gmail dot com 2008-11-05 01:12 --- I've added a patch in bug 24803, comment 9 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37351
[Bug target/38016] New: [4.2/4.3/4.4 Regression] -fno-ivopts exposes CRIS port bug, more with -fno-gcse
(Marked as a regression because the bug wasn't exposed with earlier versions, for example 3.2.1, well before ivopts.) Adding -fno-gcse trigs more FAILs, but -fno-gcse by itself doesn't expose the bug. To reproduce, run the testsuite with RUNTESTFLAGS=--target_board=cris-sim/-fno-ivopts or RUNTESTFLAGS=--target_board=cris-sim/-fno-ivopts/-fno-gcse. Observe, for 4.3 and the latter, for ieee.exp: Running /tmp/hpautotest-gcc43/gcc/gcc/testsuite/gcc.c-torture/execute/ieee/ieee.exp ... FAIL: gcc.c-torture/execute/ieee/fp-cmp-5.c compilation, -O1 (internal compiler error) FAIL: gcc.c-torture/execute/ieee/fp-cmp-5.c compilation, -O2 (internal compiler error) FAIL: gcc.c-torture/execute/ieee/fp-cmp-8.c compilation, -O1 (internal compiler error) FAIL: gcc.c-torture/execute/ieee/fp-cmp-8.c compilation, -O2 (internal compiler error) FAIL: gcc.c-torture/execute/ieee/fp-cmp-8.c compilation, -O3 -fomit-frame-pointer (internal compiler error) FAIL: gcc.c-torture/execute/ieee/fp-cmp-8.c compilation, -O3 -fomit-frame-pointer -funroll-loops (internal compiler error) FAIL: gcc.c-torture/execute/ieee/fp-cmp-8.c compilation, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (internal compiler error) FAIL: gcc.c-torture/execute/ieee/fp-cmp-8.c compilation, -O3 -g (internal compiler error) FAIL: gcc.c-torture/execute/ieee/fp-cmp-8l.c compilation, -O1 (internal compiler error) FAIL: gcc.c-torture/execute/ieee/fp-cmp-8l.c compilation, -O2 (internal compiler error) FAIL: gcc.c-torture/execute/ieee/fp-cmp-8l.c compilation, -O3 -fomit-frame-pointer (internal compiler error) FAIL: gcc.c-torture/execute/ieee/fp-cmp-8l.c compilation, -O3 -g (internal compiler error) The bug itself is an incomplete fix for PR25947; nothing but REG is recognised for operand 1. -- Summary: [4.2/4.3/4.4 Regression] -fno-ivopts exposes CRIS port bug, more with -fno-gcse Product: gcc Version: 4.3.3 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target AssignedTo: hp at gcc dot gnu dot org ReportedBy: hp at gcc dot gnu dot org GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: cris-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38016
[Bug target/38016] [4.2/4.3/4.4 Regression] -fno-ivopts exposes CRIS port bug, more with -fno-gcse
-- hp at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-05 01:23:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38016
[Bug libstdc++/24803] [c++0x] reference_wrapper and pointers to member functions
--- Comment #10 from paolo dot carlini at oracle dot com 2008-11-05 01:25 --- (In reply to comment #9) That said, here's a patch that updates result_of and reference_wrapper to work for pointers to members as well as callable types, using result_of in place of the Callable concept. If result_of and reference_wrapper really shouldn't work for pointers to members then this patch would be much simpler, and there's no need for __invoke() either. Excellent Jon. Please, commit the patch and let's close the PR for 4.4. A couple of minor nits, if you want: you can remove the main of result_of_neg, being a compile-only testcase; also I think a commented-out VERIFY in result_of can be just removed entirely. Thanks again! (let me know if for some reason you have trouble committing) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24803
[Bug bootstrap/38014] [4.4 regression] in-tree gmp and mpfr libraries no longer work
--- Comment #2 from xinliangli at gmail dot com 2008-11-05 01:26 --- The problem reproduces for me -- for both i686 native 32 bit compiler build and x86_64 cross compiler build. David -- xinliangli at gmail dot com changed: What|Removed |Added CC||xinliangli at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38014
[Bug target/38016] [4.2/4.3/4.4 Regression] -fno-ivopts exposes CRIS port bug, more with -fno-gcse
--- Comment #1 from hp at gcc dot gnu dot org 2008-11-05 01:27 --- The description does not expose the bug on trunk, but it still exists there. -- hp at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.3.3 Known to work||3.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38016
[Bug libstdc++/37351] [c++0x] std::result_of requires nested template
--- Comment #10 from redi at gcc dot gnu dot org 2008-11-05 02:06 --- Subject: Bug 37351 Author: redi Date: Wed Nov 5 02:05:59 2008 New Revision: 141596 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141596 Log: PR libstdc++/24803 PR libstdc++/37351 * include/tr1_impl/functional (result_of,reference_wrapper): Update to use C++0x features. * testsuite/20_util/function_objects/return_types/result_of.cc: New. * testsuite/20_util/function_objects/return_types/result_of_neg.cc: New. * testsuite/20_util/function_objects/return_types/result_of_ref.cc: New. * testsuite/20_util/reference_wrapper/24803.cc: Uncomment FIXMEs. Added: trunk/libstdc++-v3/testsuite/20_util/function_objects/return_types/ trunk/libstdc++-v3/testsuite/20_util/function_objects/return_types/result_of.cc trunk/libstdc++-v3/testsuite/20_util/function_objects/return_types/result_of_neg.cc trunk/libstdc++-v3/testsuite/20_util/function_objects/return_types/result_of_ref.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/tr1_impl/functional trunk/libstdc++-v3/testsuite/20_util/reference_wrapper/24803.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37351
[Bug libstdc++/24803] [c++0x] reference_wrapper and pointers to member functions
--- Comment #11 from redi at gcc dot gnu dot org 2008-11-05 02:06 --- Subject: Bug 24803 Author: redi Date: Wed Nov 5 02:05:59 2008 New Revision: 141596 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141596 Log: PR libstdc++/24803 PR libstdc++/37351 * include/tr1_impl/functional (result_of,reference_wrapper): Update to use C++0x features. * testsuite/20_util/function_objects/return_types/result_of.cc: New. * testsuite/20_util/function_objects/return_types/result_of_neg.cc: New. * testsuite/20_util/function_objects/return_types/result_of_ref.cc: New. * testsuite/20_util/reference_wrapper/24803.cc: Uncomment FIXMEs. Added: trunk/libstdc++-v3/testsuite/20_util/function_objects/return_types/ trunk/libstdc++-v3/testsuite/20_util/function_objects/return_types/result_of.cc trunk/libstdc++-v3/testsuite/20_util/function_objects/return_types/result_of_neg.cc trunk/libstdc++-v3/testsuite/20_util/function_objects/return_types/result_of_ref.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/tr1_impl/functional trunk/libstdc++-v3/testsuite/20_util/reference_wrapper/24803.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24803
[Bug libstdc++/37351] [c++0x] std::result_of requires nested template
--- Comment #11 from jwakely dot gcc at gmail dot com 2008-11-05 02:08 --- Fixed for 4.4 -- jwakely dot gcc at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37351
[Bug libstdc++/24803] [c++0x] reference_wrapper and pointers to member functions
--- Comment #12 from redi at gcc dot gnu dot org 2008-11-05 02:10 --- Fixed for 4.4 (including the nits you spotted, thanks Paolo) -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24803
[Bug libstdc++/24803] [c++0x] reference_wrapper and pointers to member functions
--- Comment #13 from redi at gcc dot gnu dot org 2008-11-05 02:27 --- argh! I've broken call_once, re-opening while I look into it. A testsuite_files was causing some tests not to run. -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24803
[Bug libstdc++/24803] [c++0x] reference_wrapper and pointers to member functions
--- Comment #14 from jwakely dot gcc at gmail dot com 2008-11-05 02:54 --- the problem is due to bug 35569 - I'll have to revert my patch until I can fix that properly -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24803
[Bug fortran/37833] internal compiler error: in gfc_conv_function_call, at fortran/trans-expr.c:1108
--- Comment #10 from kargl at gcc dot gnu dot org 2008-11-05 03:50 --- Markus, Thanks for the bug report. Tobias has stated that your code compiles with 4.1 or newer. I'll note that 4.1.x has reached end-of-life and no additional releases are planned. I think 4.2.x may also have reached EOL, and even if it hasn't reach that state there are unfortunately too few gfortran developers to support 4.2.x. Can you test your code against a 4.2.x or newer compiler? You can get a bleeding gfortran from the gfortran wiki. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37833
[Bug fortran/37644] compiler Segmentation fault
--- Comment #3 from kargl at gcc dot gnu dot org 2008-11-05 04:10 --- Can you attach the code instead of embedded in a message? It's a PITA to strip out HTML from your code when I save it as a file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37644
[Bug middle-end/37943] [graphite] ICE : in build_graphite_scops, at graphite.c:1823
--- Comment #4 from grosser at gcc dot gnu dot org 2008-11-05 04:33 --- Subject: Bug 37943 Author: grosser Date: Wed Nov 5 04:32:16 2008 New Revision: 141597 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141597 Log: 2008-11-05 Tobias Grosser [EMAIL PROTECTED] PR middle-end/37943 * graphite.c (scopdet_basic_block_info): Fix loops with multiple exits and conditions. * testsuite/gcc.dg/graphite/pr37943.c: New. Added: branches/graphite/gcc/testsuite/gcc.dg/graphite/pr37943.c Modified: branches/graphite/gcc/ChangeLog.graphite branches/graphite/gcc/graphite.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37943
[Bug fortran/37833] internal compiler error: in gfc_conv_function_call, at fortran/trans-expr.c:1108
--- Comment #11 from markus dot airila at vtt dot fi 2008-11-05 04:46 --- Subject: RE: internal compiler error: in gfc_conv_function_call, at fortran/trans-expr.c:1108 kargl at gcc dot gnu dot org [EMAIL PROTECTED]: Thanks for the bug report. Tobias has stated that your code compiles with 4.1 or newer. I'll note that 4.1.x has reached end-of-life and no additional releases are planned. I think 4.2.x may also have reached EOL, and even if it hasn't reach that state there are unfortunately too few gfortran developers to support 4.2.x. Can you test your code against a 4.2.x or newer compiler? Thanks, I hadn't noted that my old Ubuntu did not upgrade to the latest gcc. I can compile the code with 4.2.4. Markus -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37833
[Bug middle-end/37943] [graphite] ICE : in build_graphite_scops, at graphite.c:1823
--- Comment #5 from grosser at gcc dot gnu dot org 2008-11-05 04:47 --- Subject: Bug 37943 Author: grosser Date: Wed Nov 5 04:45:49 2008 New Revision: 141598 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141598 Log: 2008-11-05 Tobias Grosser [EMAIL PROTECTED] PR middle-end/37943 * graphite.c (scopdet_basic_block_info): Fix loops with multiple exits and conditions. * testsuite/gcc.dg/graphite/pr37943.c: New. Added: trunk/gcc/testsuite/gcc.dg/graphite/pr37943.c Modified: trunk/ChangeLog trunk/gcc/graphite.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37943
[Bug middle-end/37943] [graphite] ICE : in build_graphite_scops, at graphite.c:1823
--- Comment #6 from grosser at gcc dot gnu dot org 2008-11-05 04:48 --- Fix committed -- grosser at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37943
[Bug fortran/37833] internal compiler error: in gfc_conv_function_call, at fortran/trans-expr.c:1108
--- Comment #12 from grosser at gcc dot gnu dot org 2008-11-05 05:05 --- Subject: Bug 37833 Author: grosser Date: Wed Nov 5 05:04:29 2008 New Revision: 141599 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141599 Log: 2008-11-05 Tobias Grosser [EMAIL PROTECTED] PR middle-end/37833 * graphite.c (scan_tree_for_params): Add POINTER_PLUS_EXPR. Modified: trunk/ChangeLog trunk/gcc/ChangeLog trunk/gcc/graphite.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37833
[Bug fortran/37833] internal compiler error: in gfc_conv_function_call, at fortran/trans-expr.c:1108
--- Comment #13 from grosser at gcc dot gnu dot org 2008-11-05 05:25 --- Subject: Bug 37833 Author: grosser Date: Wed Nov 5 05:23:46 2008 New Revision: 141600 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141600 Log: 2008-11-05 Tobias Grosser [EMAIL PROTECTED] PR middle-end/37833 * graphite.c (scan_tree_for_params): Add POINTER_PLUS_EXPR. Modified: branches/graphite/gcc/ChangeLog.graphite branches/graphite/gcc/graphite.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37833
[Bug fortran/37833] internal compiler error: in gfc_conv_function_call, at fortran/trans-expr.c:1108
--- Comment #14 from kargl at gcc dot gnu dot org 2008-11-05 05:25 --- Closing the bug as WONTFIX. The 4.0.x branch is long dead. Long live 4.4+ -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37833
[Bug middle-end/37857] [graphite] Segmentation fault
-- grosser at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37857
[Bug middle-end/37928] [graphite] ICE :Segmentation fault
-- grosser at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |grosser at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-10-30 04:16:30 |2008-11-05 05:28:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37928
[Bug libstdc++/38017] New: [4.4 Regression] 30_threads/thread/cons/X.cc
On Linux/Intel64, revision 141596 gave: +FAIL: 30_threads/call_once/call_once1.cc (test for excess errors) +FAIL: 30_threads/call_once/call_once1.cc (test for excess errors) +FAIL: 30_threads/thread/cons/2.cc (test for excess errors) +FAIL: 30_threads/thread/cons/2.cc (test for excess errors) +FAIL: (test for excess errors) +FAIL: 30_threads/thread/cons/3.cc (test for excess errors) +FAIL: 30_threads/thread/cons/4.cc (test for excess errors) +FAIL: 30_threads/thread/cons/4.cc (test for excess errors) In file included from /export/gnu/import/svn/gcc-test/bld/x86_64-unknown-linux-gnu/32/libstdc++-v3/include/functional:75,^M from /export/gnu/import/svn/gcc-test/bld/x86_64-unknown-linux-gnu/32/libstdc++-v3/include/mutex:49,^M from /export/gnu/import/svn/gcc-test/src-trunk/libstdc++-v3/testsuite/30_threads/call_once/call_once1.cc:35:^M /export/gnu/import/svn/gcc-test/bld/x86_64-unknown-linux-gnu/32/libstdc++-v3/include/tr1_impl/functional: In instantiation of 'std::_Result_of_implfalse, false, std::_Muint, false, false ()(int, std::tuple)':^M /export/gnu/import/svn/gcc-test/bld/x86_64-unknown-linux-gnu/32/libstdc++-v3/include/tr1_impl/functional:154: instantiated from 'std::result_ofstd::_Muint, false, false ()(int, std::tuple)'^M /export/gnu/import/svn/gcc-test/bld/x86_64-unknown-linux-gnu/32/libstdc++-v3/include/mutex:714: instantiated from 'void std::__once_call_impl() [with _Callable = std::_Bindvoid (* ()(int))(int)]'^M /export/gnu/import/svn/gcc-test/bld/x86_64-unknown-linux-gnu/32/libstdc++-v3/include/mutex:730: instantiated from 'void std::call_once(std::once_flag, _Callable, _Args ...) [with _Callable = void (*)(int), _Args = int]'^M /export/gnu/import/svn/gcc-test/src-trunk/libstdc++-v3/testsuite/30_threads/call_once/call_once1.cc:53: instantiated from here^M /export/gnu/import/svn/gcc-test/bld/x86_64-unknown-linux-gnu/32/libstdc++-v3/include/tr1_impl/functional:299: error: no match for call to '(std::_Muint, false, false) (int, std::tuple)'^M /export/gnu/import/svn/gcc-test/bld/x86_64-unknown-linux-gnu/32/libstdc++-v3/include/tr1_impl/functional:1241: note: candidates are: _CVArg std::_Mu_Arg, false, false::operator()(_CVArg, const _Tuple) const volatile [with _CVArg = int, _Tuple = std::tuple, _Arg = int]^M In file included from /export/gnu/import/svn/gcc-test/src-trunk/libstdc++-v3/testsuite/30_threads/call_once/call_once1.cc:35:^M /export/gnu/import/svn/gcc-test/bld/x86_64-unknown-linux-gnu/32/libstdc++-v3/include/mutex: In function 'void std::__once_call_impl() [with _Callable = std::_Bindvoid (* ()(int))(int)]':^M /export/gnu/import/svn/gcc-test/bld/x86_64-unknown-linux-gnu/32/libstdc++-v3/include/mutex:730: instantiated from 'void std::call_once(std::once_flag, _Callable, _Args ...) [with _Callable = void (*)(int), _Args = int]'^M /export/gnu/import/svn/gcc-test/src-trunk/libstdc++-v3/testsuite/30_threads/call_once/call_once1.cc:53: instantiated from here^M /export/gnu/import/svn/gcc-test/bld/x86_64-unknown-linux-gnu/32/libstdc++-v3/include/mutex:714: error: no match for call to '(std::_Bindvoid (* ()(int))(int)) ()'^M Revision 141591 is OK. -- Summary: [4.4 Regression] 30_threads/thread/cons/X.cc Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38017
[Bug libstdc++/38017] [4.4 Regression] 30_threads/thread/cons/X.cc
--- Comment #1 from hjl dot tools at gmail dot com 2008-11-05 05:57 --- Revision 141596 is the cause. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||redi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38017
[Bug c/38018] New: gcc.dg/pr37106-1.c doesn't work
With revision 141596, on Linux/ia64, I got [EMAIL PROTECTED] gcc]$ ./xgcc -B./ -O1 -fpic -S /export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gcc.dg/pr37106-1.c /export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gcc.dg/pr37106-1.c: In function âopt3â: /export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gcc.dg/pr37106-1.c:18: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. [EMAIL PROTECTED] gcc]$ -- Summary: gcc.dg/pr37106-1.c doesn't work Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com GCC target triplet: ia64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38018
[Bug c/38018] gcc.dg/pr37106-1.c doesn't work
--- Comment #1 from hjl dot tools at gmail dot com 2008-11-05 06:09 --- I think it is another instance of PR 37565. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||gnu at the-meissners dot org BugsThisDependsOn||37565 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38018
[Bug bootstrap/38014] [4.4 regression] in-tree gmp and mpfr libraries no longer work
--- Comment #3 from ian at airs dot com 2008-11-05 06:58 --- hp: It will work if gmp is installed on the system. The problem is that mpfr can't find gmp.h. If gmp is installed, then it can, and everything works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38014
[Bug fortran/37644] compiler Segmentation fault
--- Comment #4 from burnus at gcc dot gnu dot org 2008-11-05 07:03 --- I can reproduce the ICE (seg. fault) with 4.3.x, but not with 4.4.0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37644
