Re: Problems with in-tree host libraries (gmp, ppl, etc)
On Sat, 2 May 2009, Anthony Green wrote:
The top level configury suggests that you can simply drop gmp, ppl, etc
into the top level source dir and they will get configured and used.
Does this really work?
It is supposed to. I haven't worked on or tested the ppl machinery so I
don't know what shape it is in.
Index: Makefile.def
===
--- Makefile.def(revision 146995)
+++ Makefile.def(working copy)
@@ -60,7 +60,7 @@
host_modules= { module= gawk; };
host_modules= { module= gettext; };
host_modules= { module= gmp; lib_path=.libs; bootstrap=true;
- extra_configure_flags='--disable-shared';
+ extra_configure_flags='--disable-shared --enable-cxx';
no_install= true;
host=none-${host_vendor}-${host_os};
target=none-${host_vendor}-${host_os}; };
I would only pass in this flag if ppl is being used. Look at what I did
with extra_mpfr_configure_flags in the top level directory. You can use a
similar mechanism to have a flag passed in to the gmp build conditionally.
Even then, the ppl configury isn't detecting the gmp we just built. It
seems as though we should install gmp in a local temporary install tree
and point ppl at that. See below for a trace of the ppl configury as it
attempts to detect an in-tree gmp (after applying the patch above).
AG
I don't know if ppl was ever setup to detect/use an in-tree gmp. It would
need to be able to specify --with-gmp-build= or something equivalent to
get the header and library from a build tree rather than an install tree.
They're laid out slightly differently.
--Kaveh
Re: Unexpected offsets when eliminating SP
Thanks Jim and Ian. I've added a secondary_reload which does this:
...
if (code == MEM)
{
if (fp_plus_const_operand(XEXP(x, 0), mode))
{
sri-icode = in_p ? CODE_FOR_reload_insi : CODE_FOR_reload_outsi;
return NO_REGS;
}
where fp_plus_const_operand is taken from the bfin port - it checks
that this is RTL of the form ((plus (reg const)). The .md file
contains:
---
(define_expand reload_insi
[(parallel [(set (match_operand:SI 0 register_operand =r)
(match_operand:SI 1 memory_operand m))
(clobber (match_operand:SI 2 register_operand =a))])]
{
fprintf(stderr, reload_insi\n);
rtx plus_op = XEXP(operands[1], 0);
rtx fp_op = XEXP (plus_op, 0);
rtx const_op = XEXP (plus_op, 1);
rtx primary = operands[0];
rtx scratch = operands[2];
emit_move_insn (scratch, fp_op);
emit_insn (gen_addsi3 (scratch, scratch, const_op));
emit_move_insn (primary, gen_rtx_MEM(Pmode, scratch));
DONE;
}
)
(define_expand reload_outsi
[(parallel [(match_operand 0 memory_operand =m)
(match_operand 1 register_operand r)
(match_operand:SI 2 register_operand =a)])]
{
fprintf(stderr, reload_outsi\n);
rtx plus_op = XEXP(operands[0], 0);
rtx fp_op = XEXP (plus_op, 0);
rtx const_op = XEXP (plus_op, 1);
rtx primary = operands[1];
rtx scratch = operands[2];
emit_move_insn (scratch, fp_op);
emit_insn (gen_addsi3 (scratch, scratch, const_op));
emit_move_insn (gen_rtx_MEM(Pmode, scratch), primary);
DONE;
}
)
---
The reload_insi is being called and is expanding into the correct code
but for some reason the reload_outsi never gets called. sri-icode is
being set correctly and propagates a few levels up but I couldn't
track it any further.
The s390 port does the reload in the same way as me. The bfin is
similar. I haven't looked further into GO_IF_LEGITIMATE_ADDRESS but
it's the next part to look at. It's a stripped down version of the
mmix one so it should be roughly OK.
I'm a bit confused with the documentation versus the ports. For
example, REGNO_MODE_CODE_OK_FOR_BASE_P doesn't appear to need a strict
form according to the documentation but the bfin port has a strict and
non-strict version. Most of the ports have a REG_OK_FOR_BASE_P macro
with strict and non-strict versions macro but it's not documented,
isn't used, and might have been removed around gcc 4.0.
Any ideas on why the reload_outsi above is being eaten?
Thanks,
-- Michael
2009/4/30 Jim Wilson wil...@codesourcery.com:
Michael Hope wrote:
HI there. I'm working on porting gcc to a new architecture which only
does indirect addressing - there is no indirect with displacement.
The IA-64 target also has only indirect addressing. Well, it has some
auto-increment addressing modes too, but that isn't relevant here. You
could try looking at the IA-64 port to see why it works and yours doesn't.
The problem is with spill locations in GCC 4.4.0. The elimination
code correctly elimates the frame and args pointer and replaces it
with register X. The problem is that it then generates indirect with
offset loads to load spilt values.
Since this is happening inside reload, first thing I would check is to make
sure you handle REG_OK_STRICT correctly. Before reload, a pseudo-reg is a
valid memory address. Inside reload, an unallocated pseudo-reg is actually
a memory location, and hence can not be a valid memory address. This is
controlled by REG_OK_STRICT.
Jim
Re: exception propagation support not enabled in libstdc++ 4.4 on {armeabi,hppa,sparc}-linux
Paolo Carlini wrote: Ok, thanks. Then, I think I'll implement this, for now. Seems in any case conservative to have a link type test identical to the one used in libgomp and libgfortran and a fall back to the .s file (as currently used). I committed the below to mainline. Assuming no issues are noticed with it, I mean to apply it to 4_4-branch too in a few days. Paolo. / 2009-05-03 Paolo Carlini paolo.carl...@oracle.com * acinclude.m4 ([GLIBCXX_ENABLE_ATOMIC_BUILTINS]): Do link tests when possible. * configure: Regenerate. Index: acinclude.m4 === --- acinclude.m4(revision 147071) +++ acinclude.m4(working copy) @@ -2429,8 +2429,7 @@ dnl that are used should be checked. dnl dnl Note: -dnl libgomp and libgfortran do this with a link test, instead of an asm test. -dnl see: CHECK_SYNC_FETCH_AND_ADD +dnl libgomp and libgfortran use a link test, see CHECK_SYNC_FETCH_AND_ADD. dnl dnl Defines: dnl _GLIBCXX_ATOMIC_BUILTINS_1 @@ -2442,12 +2441,110 @@ AC_LANG_SAVE AC_LANG_CPLUSPLUS old_CXXFLAGS=$CXXFLAGS - + + # Do link tests if possible, instead asm tests. + if test x$gcc_no_link != xyes; then + + # Can do link tests. + + CXXFLAGS=$CXXFLAGS -fno-exceptions + + AC_MSG_CHECKING([for atomic builtins for bool]) + AC_CACHE_VAL(glibcxx_cv_atomic_bool, [ +AC_TRY_LINK( + [ ], + [typedef bool atomic_type; + atomic_type c1; + atomic_type c2; + const atomic_type c3(0); + __sync_fetch_and_add(c1, c2); + __sync_val_compare_and_swap(c1, c3, c2); + __sync_lock_test_and_set(c1, c3); + __sync_lock_release(c1); + __sync_synchronize();], + [glibcxx_cv_atomic_bool=yes], + [glibcxx_cv_atomic_bool=no]) + ]) + if test $glibcxx_cv_atomic_bool = yes; then +AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_1, 1, + [Define if builtin atomic operations for bool are supported on this host.]) + fi + AC_MSG_RESULT($glibcxx_cv_atomic_bool) + + AC_MSG_CHECKING([for atomic builtins for short]) + AC_CACHE_VAL(glibcxx_cv_atomic_short, [ +AC_TRY_LINK( + [ ], + [typedef short atomic_type; + atomic_type c1; + atomic_type c2; + const atomic_type c3(0); + __sync_fetch_and_add(c1, c2); + __sync_val_compare_and_swap(c1, c3, c2); + __sync_lock_test_and_set(c1, c3); + __sync_lock_release(c1); + __sync_synchronize();], + [glibcxx_cv_atomic_short=yes], + [glibcxx_cv_atomic_short=no]) + ]) + if test $glibcxx_cv_atomic_short = yes; then +AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_2, 1, + [Define if builtin atomic operations for short are supported on this host.]) + fi + AC_MSG_RESULT($glibcxx_cv_atomic_short) + + AC_MSG_CHECKING([for atomic builtins for int]) + AC_CACHE_VAL(glibcxx_cv_atomic_int, [ +AC_TRY_LINK( + [ ], + [typedef int atomic_type; + atomic_type c1; + atomic_type c2; + const atomic_type c3(0); + __sync_fetch_and_add(c1, c2); + __sync_val_compare_and_swap(c1, c3, c2); + __sync_lock_test_and_set(c1, c3); + __sync_lock_release(c1); + __sync_synchronize();], + [glibcxx_cv_atomic_int=yes], + [glibcxx_cv_atomic_int=no]) + ]) + if test $glibcxx_cv_atomic_int = yes; then +AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_4, 1, + [Define if builtin atomic operations for int are supported on this host.]) + fi + AC_MSG_RESULT($glibcxx_cv_atomic_int) + + AC_MSG_CHECKING([for atomic builtins for long long]) + AC_CACHE_VAL(glibcxx_cv_atomic_long_long, [ +AC_TRY_LINK( + [ ], + [typedef long long atomic_type; + atomic_type c1; + atomic_type c2; + const atomic_type c3(0); + __sync_fetch_and_add(c1, c2); + __sync_val_compare_and_swap(c1, c3, c2); + __sync_lock_test_and_set(c1, c3); + __sync_lock_release(c1); + __sync_synchronize();], + [glibcxx_cv_atomic_long_long=yes], + [glibcxx_cv_atomic_long_long=no]) + ]) + if test $glibcxx_cv_atomic_long_long = yes; then +AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_8, 1, + [Define if builtin atomic operations for long long are supported on this host.]) + fi + AC_MSG_RESULT($glibcxx_cv_atomic_long_long) + + else + + # Do asm tests. + # Compile unoptimized. CXXFLAGS='-O0 -S' - # Fake what AC_TRY_COMPILE does, without linking as this is - # unnecessary for a builtins test. + # Fake what AC_TRY_COMPILE does. cat conftest.$ac_ext EOF [#]line __oline__ configure @@ -2469,14 +2566,14 @@ AC_MSG_CHECKING([for atomic builtins for bool]) if AC_TRY_EVAL(ac_compile); then if grep __sync_ conftest.s /dev/null 21 ; then -enable_atomic_builtinsb=no +glibcxx_cv_atomic_bool=no else AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_1, 1, [Define if builtin atomic operations for bool are supported on this host.])
Re: exception propagation support not enabled in libstdc++ 4.4 on {armeabi,hppa,sparc}-linux
Paolo Carlini wrote: Subject to fixing the bug I think is present with static-only libgcc functions and C++ shared libraries (so that being able to link an executable with the functions means it is also possible to link libstdc++ and have the symbols resolved in that link), it would make sense to test linking if possible, failing that the .s file. Ok, thanks. Then, I think I'll implement this, for now. Seems in any case conservative to have a link type test identical to the one used in libgomp and libgfortran and a fall back to the .s file (as currently used). I think this is a reasonable strategy. It's critical to avoid run-time tests, as they don't work in cross configurations, but link-time tests are not inherently problematic in the same way. I think that link-time tests are a reasonable approach. If I recall correctly, the strongest objection to link-time tests comes from people who do a one-tree build of an entire cross-toolchain. I think that if you can't link a C program (including using functions from the C library) by the time you get to the point of building libstdc++, that's a bug in the one-tree build procedure, but that's probably not a fight worth having. There's a secondary issue with link-time tests because you then up determining things about the C library that may not be true if you use a different C library, or a different version of the same C library, or whatever. I think some of those concerns are reasonable, but I think the right way to deal with them is probably explicit configure options for the benefit of people who want to make the C++ run-time use (or not use) some feature of the C library that is different from what would be determined by the link-time probe. So, I think that this is an orthogonal issue to the question of how we should probe. FWIW, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: [gnat] reuse of ASTs already constructed
On 2009-04-19, at 23:19 +0200, Oliver Kellogg wrote: [...] How about not doing the name expansion in-place but rather storing the expanded name in an extra node field? I haven't received any reaction on this question yet. Perhaps I could reuse the Str3 field instead? (I haven't looked into the depths of its usage yet.) Please advise. BTW, I added the invocation of 'as' for assembly files 2 to N in gcc.c, this means that the multi-source mechanism can now be used in a normal gcc -c invocation using the -multi switch. Up next would be gnatmake: I would like to add a switch to gnatmake that enables multi- source mode. What should I use for the switch name? Also, I'm thinking that in multi-source mode, the switch -o can perhaps continue to be used - not by giving a filename but instead by giving a directory. All object files would then be placed in the given directory. What do you think? Thanks, Oliver On 2009-04-18 at 21:35 +0200, Oliver Kellogg wrote: I've run up against a problem with reusing the GNAT trees: Apparently during semantic analysis entity names are expanded to their fully qualified names in the tree. For example, when compiling the following file with the node for System already installed by a previous compilation, -- file: ext.ads with System; procedure Ext (Addr : System.Address); I get the following error from sem_ch8.adb Find_Expanded_Name during semantic analysis of the above System.Address, ext.ads:3:29: Address is not a visible entity of System This is because in sem_ch8.adb:4482, if No (Id) or else Chars (Id) /= Chars (Selector) then ... the second part of the condition becomes true as Chars(Id) is system__address [and Chars(Selector) is address]. When compiling the same file afresh without preinstalled nodes, Chars(Id) is just address and all is fine. Oliver
Re: [gnat] reuse of ASTs already constructed
Oliver Kellogg wrote: On 2009-04-19, at 23:19 +0200, Oliver Kellogg wrote: [...] How about not doing the name expansion in-place but rather storing the expanded name in an extra node field? I haven't received any reaction on this question yet. Perhaps I could reuse the Str3 field instead? (I haven't looked into the depths of its usage yet.) I don't see any room in the node for this extra field ...
Re: [gnat] reuse of ASTs already constructed
Sorry if I'm slow in understanding: Are you saying that introducing an extra field would cause problems (memory or other) ? Do you think it would be okay to use the Str3 field, then? Thanks. Robert Dewar wrote: Oliver Kellogg wrote: On 2009-04-19, at 23:19 +0200, Oliver Kellogg wrote: [...] How about not doing the name expansion in-place but rather storing the expanded name in an extra node field? I haven't received any reaction on this question yet. Perhaps I could reuse the Str3 field instead? (I haven't looked into the depths of its usage yet.) I don't see any room in the node for this extra field ...
gfortran-dev branch bootstrap breakage
I just completed a sync to trunk that I have not committed back yet and I get the following error during bootstrap on the local branch. libbackend.a(plugin.o): In function `plugin_default_version_check': /home/jerry/gcc/objdev/gcc/../../gccdev/gcc/plugin.c:825: undefined reference to `plugin_gcc_version' There was a patch that went in about 3 days ago related to this. r146962. That patch is in place in my local gfortran-dev branch. local branch svn is at r147078 Suggestions anyone? Jerry
gcc-4.3-20090503 is now available
Snapshot gcc-4.3-20090503 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20090503/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 147085 You'll find: gcc-4.3-20090503.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20090503.tar.bz2 C front end and core compiler gcc-ada-4.3-20090503.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20090503.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20090503.tar.bz2 C++ front end and runtime gcc-java-4.3-20090503.tar.bz2 Java front end and runtime gcc-objc-4.3-20090503.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20090503.tar.bz2The GCC testsuite Diffs from 4.3-20090426 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Empty loops removal (Was Re: Some extra decorations)
Jan Hubicka: There are also few annotations that I would like to add to functions declared in headers where GCC don't know if they are finite so it is not sure it can remove call to them even if it can prove there are no side effects otherwise. Hi, You may be interested in 6.5p5 of the latest standard draft (N2857) which states: A loop that, outside of the for-init-statement in the case of a for statement, - makes no calls to library I/O functions, and - does not access or modify volatile objects, and - performs no synchronization operations (1.10) or atomic operations (Clause 29) may be assumed by the implementation to terminate. [ Note: This is intended to allow compiler transformations, such as removal of empty loops, even when termination cannot be proven. -end note ] This new rule has been introduced by the memory model changes. This indeed is interesting :) It would make those pure/const annotations on STL loops redundant and save us some SCEV analyzis in pure/const pass as well as in empty loop removal and CD-DCE. (in fact they are kind of optimization challenge as by inlining function we lose the hint, so I would need to work out some extra code maintaining info about finiteness of the function). On mainline I enabled infinite loop removal at -funsafe-loop-optimizations. I would suggest adding -fempty-loops-terminate and make it default for C++? It does not apply for C, right? What about loops formed by infinite recursion? Honza
Re: Empty loops removal (Was Re: Some extra decorations)
2009/5/4 Joseph S. Myers: On Mon, 4 May 2009, Jan Hubicka wrote: On mainline I enabled infinite loop removal at -funsafe-loop-optimizations. I would suggest adding -fempty-loops-terminate and make it default for C++? It does not apply for C, right? You mean for C++0x (I see no such rule in C++03), and there is no such rule for C at present. Yes, the rule is new for C++0x, and it is in the context of for, while and do-while loops only, not recursive calls.
Re: Empty loops removal (Was Re: Some extra decorations)
2009/5/4 Joseph S. Myers: On Mon, 4 May 2009, Jan Hubicka wrote: On mainline I enabled infinite loop removal at -funsafe-loop-optimizations. I would suggest adding -fempty-loops-terminate and make it default for C++? It does not apply for C, right? You mean for C++0x (I see no such rule in C++03), and there is no such rule for C at present. Yes, the rule is new for C++0x, and it is in the context of for, while and do-while loops only, not recursive calls. And when compiler forms a loop via tail call removal? In general recursion can not be infinite, since stack space is finite, but somehow it was earlier concluded that this does not allow elimination of calls to recursive functions that do otherwise nothing. Honza
Re: Empty loops removal (Was Re: Some extra decorations)
On Mon, 4 May 2009, Jan Hubicka wrote: On mainline I enabled infinite loop removal at -funsafe-loop-optimizations. I would suggest adding -fempty-loops-terminate and make it default for C++? It does not apply for C, right? You mean for C++0x (I see no such rule in C++03), and there is no such rule for C at present. -- Joseph S. Myers jos...@codesourcery.com
Re: Empty loops removal (Was Re: Some extra decorations)
On Sun, May 3, 2009 at 4:17 PM, Jonathan Wakely jwakely@gmail.com wrote: Yes, the rule is new for C++0x, and it is in the context of for, while and do-while loops only, not recursive calls. Does this include loops form from gotos also? Because this seems like it is very limited and not useful for optimizations in general. GCC loop optimizations are not based on the source level constructs but instead of based on the CFG. -- Pinski
Re: Empty loops removal (Was Re: Some extra decorations)
Jonathan Wakely: 2009/5/4 Joseph S. Myers: On Mon, 4 May 2009, Jan Hubicka wrote: On mainline I enabled infinite loop removal at -funsafe-loop-optimizations. I would suggest adding -fempty-loops-terminate and make it default for C++? It does not apply for C, right? You mean for C++0x (I see no such rule in C++03), and there is no such rule for C at present. Yes, the rule is new for C++0x, and it is in the context of for, while and do-while loops only, not recursive calls. It might be worth raising this issue on c++std-core, because it's easy for a compiler to transform recursion to a loop using tail call elimination, and I suspect that it is in line with the original intent to treat recursion with no side effects as finite in the same way.
Re: [gnat] reuse of ASTs already constructed
Oliver Kellogg wrote: Sorry if I'm slow in understanding: Are you saying that introducing an extra field would cause problems (memory or other) ? Do you think it would be okay to use the Str3 field, then? I don't see that Str3 is free in any of these nodes, what nodes are you talking about (remember that Str3 overlaps Node3, List3 etc). Thanks. Robert Dewar wrote: Oliver Kellogg wrote: On 2009-04-19, at 23:19 +0200, Oliver Kellogg wrote: [...] How about not doing the name expansion in-place but rather storing the expanded name in an extra node field? You could have a separate vector for expanded names I suppose ...
Re: [gnat] reuse of ASTs already constructed
Robert Dewar wrote: I don't see that Str3 is free in any of these nodes, what nodes are you talking about (remember that Str3 overlaps Node3, List3 etc). Okay. How about not doing the name expansion in-place but rather storing the expanded name in an extra node field? You could have a separate vector for expanded names I suppose ... So be it. I will change the code to not overwrite the Name field with the expanded name but rather store the expanded name in a data structure separate from the Node. Any thoughts on my questions related to gnatmake? Further question, what is the process for integrating my changes into the GCC trunk? I would assume that I need to 1) Make my modifications complete and functioning 2) Make sure bootstrap works for all languages 3) Run the gcc testsuite and make sure I do not introduce regressions 4) What about testing on different platforms? I'm only testing on x86 SuSE Linux and setting up other platforms could be a problem. (Coming to think, I could actually test on x86_64 SuSE Linux with small effort, though.) 5) Copyright assignment should be on file at FSF, please check 6) Anything else? Thanks, Oliver
[Bug middle-end/39943] [4.5 Regression] Failed SPEC CPU 2000
--- Comment #7 from dominiq at lps dot ens dot fr 2009-05-03 10:24 --- The test gcc.c-torture/compile/pr39943.c fails on powerpc-apple-darwin9.6, see http://gcc.gnu.org/ml/gcc-testresults/2009-05/msg00169.html: FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer (internal compiler error) FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer -funroll-loops (internal compiler error) FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (internal compiler error) FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gcc.c-torture/compile/pr39943.c -O3 -g (internal compiler error) FAIL: gcc.c-torture/compile/pr39943.c -O3 -g (test for excess errors) The failure is: [karma] f90/bug% gcc45 -O3 /opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr39943.c /opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr39943.c: In function 'gl_fog_index_pixels': /opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr39943.c:1: error: invalid conversion in gimple call vector unsigned int __vector signed int # .MEM_98 = VDEF .MEM_97 vect_var_.47_88 = __builtin_altivec_vctuxs (vect_var_.46_87); /opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr39943.c:1: internal compiler error: verify_stmts failed -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39943
[Bug target/40009] altivec __builtin_vec_ctu has wrong tyes
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-03 11:06 --- Looking at rs6000.c likely many more builtins are affected. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40009
[Bug target/40009] altivec __builtin_vec_ctu has wrong tyes
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-03 11:12 --- Huh. It uses build_opaque_vector_type, but /* Nonzero in an IDENTIFIER_NODE if the name is a local alias, whose uses are to be substituted for uses of the TREE_CHAINed identifier. */ #define TYPE_VECTOR_OPAQUE(NODE) \ (VECTOR_TYPE_CHECK (NODE)-base.deprecated_flag) WTF?? It looks like frontend concept - see c-common.c:vector_targets_convertible_p. Why is this frontend specific when a _backend_ sets it? What semantics is it supposed to have - yeah well, proper documentation for the flag would have been a start... -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40009
[Bug target/40009] altivec __builtin_vec_ctu has wrong tyes
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-05-03 11:16 --- IMHO the frontend should, for TYPE_VECTOR_OPAQUE conversions emit VIEW_CONVERT_EXPRs to honour GIMPLE/GENERIC type system requirements. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40009
[Bug target/40009] New: altivec __builtin_vec_ctu has wrong tyes
It should have an unsigned vector result def_builtin (MASK_ALTIVEC, __builtin_vec_ctu, opaque_ftype_opaque_int, ALTIVEC_BUILTIN_VEC_CTU); this casues FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer (internal compiler error) FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer -funroll-loops (internal compiler error) FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (internal compiler error) FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gcc.c-torture/compile/pr39943.c -O3 -g (internal compiler error) FAIL: gcc.c-torture/compile/pr39943.c -O3 -g (test for excess errors) The failure is: [karma] f90/bug% gcc45 -O3 /opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr39943.c /opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr39943.c: In function 'gl_fog_index_pixels': /opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr39943.c:1: error: invalid conversion in gimple call vector unsigned int __vector signed int # .MEM_98 = VDEF .MEM_97 vect_var_.47_88 = __builtin_altivec_vctuxs (vect_var_.46_87); -- Summary: altivec __builtin_vec_ctu has wrong tyes Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org GCC target triplet: powerpc*-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40009
[Bug middle-end/39943] [4.5 Regression] Failed SPEC CPU 2000
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-05-03 11:06 --- Please do not clutter existing (closed) bugreports like this. - PR40009. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39943
[Bug target/40009] altivec __builtin_vec_ctu has wrong tyes
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-05-03 11:18 --- For the case in question, vctuxs doesn't look like an instruction that has an opaque return type. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40009
[Bug fortran/36260] Audit intrinsic.texi and check whether keyword= names match
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-01-03 23:59:27 |2009-05-03 12:09:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36260
[Bug target/40009] altivec __builtin_vec_ctu has wrong tyes
--- Comment #5 from bonzini at gnu dot org 2009-05-03 12:11 --- In many cases, opaque types are used in the prototypes just to avoid warnings. You're right that the front-end should insert VIEW_CONVERT_EXPRs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40009
[Bug fortran/36260] Audit intrinsic.texi and check whether keyword= names match
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2009-05-03 12:37 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00076.html -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36260
[Bug fortran/38830] Document lack of Variable Format Expression support
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2009-05-03 12:40 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00077.html -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Keywords||patch Last reconfirmed|2009-03-29 08:44:26 |2009-05-03 12:40:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38830
[Bug fortran/36382] Support $ as first character in symbol names and in IMPLICT
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2009-05-03 12:52 --- Doc patch here: http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00078.html I am against allowing $ as first letter in identifiers, as there now are much better ways to do that (and it's not such a common practice anyway). -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Keywords||documentation, patch Last reconfirmed|2009-03-28 13:58:14 |2009-05-03 12:52:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36382
[Bug target/40009] altivec __builtin_vec_ctu has wrong tyes
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-05-03 13:29 --- Ok, so the builtins should have a proper, but opaque vector type (like for VEC_CTU it should be an unsigned vector type, not a signed one). Thus, the TYPE_VECTOR_OPAQUE description should read like /* Nonzero in a VECTOR_TYPE if the frontends should not emit warnings about missing conversions to other vector types of the same size. */ #define TYPE_VECTOR_OPAQUE(NODE) \ (VECTOR_TYPE_CHECK (NODE)-base.deprecated_flag) ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40009
[Bug middle-end/23169] Fortran INTENT information not used in the middle-end for optimizations
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2009-05-03 13:32 --- (In reply to comment #11) The original testcase in #0 appears to be fixed if compiled with -fwhole-file. Andrew's comment #4 appears to be still an issue?! Here's a full testcase showing the remaining issue: integer function foo() interface integer function bar(b) integer, intent(in) :: b end function end interface integer :: b, d, k b = 12 d = b k = bar(b) foo = d - b end function In this code, the return value of function foo should not be computed, because it's guaranteed to be 0. The missed optimization is still present. This is something that the middle-end should be taught to honour, so I'm switching the component to middle-end. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Component|fortran |middle-end Last reconfirmed|2006-01-08 05:22:43 |2009-05-03 13:32:52 date|| Summary|INTENT information not used |Fortran INTENT information |in the middle-end for |not used in the middle-end |optimizations |for optimizations http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23169
[Bug fortran/30668] -fwhole-file should catch function of wrong type
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2009-05-03 13:53 --- I guess -fwhole-file should catch this one, but it does not. The testcase I used is: integer function two() two = 2 end function two program xx ! real, external :: two print *, two(), kind(two()) end program xx You can comment or uncomment the line with external, both versions should be caught. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||pault at gcc dot gnu dot org Severity|enhancement |minor Last reconfirmed|2007-03-18 17:53:03 |2009-05-03 13:53:02 date|| Summary|catch function of wrong type|-fwhole-file should catch ||function of wrong type http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30668
[Bug target/40009] altivec __builtin_vec_ctu has wrong tyes
--- Comment #7 from bonzini at gnu dot org 2009-05-03 14:00 --- Ok, so the builtins should have a proper, but opaque vector type (like for VEC_CTU it should be an unsigned vector type, not a signed one). No, there's no reason to have 1 opaque vector type for a single mode (or even for a single width). BTW, the opaque vector types were actually invented for SPE, and only later recycled for the implementation of Altivec. Nonzero in a VECTOR_TYPE if the frontends should not emit warnings about missing conversions to other vector types of the same size. Yes, will commit a patch to change it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40009
[Bug target/40009] altivec __builtin_vec_ctu has wrong tyes
--- Comment #8 from bonzini at gnu dot org 2009-05-03 14:25 --- What's remaining was already in the database. *** This bug has been marked as a duplicate of 30210 *** -- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40009
[Bug target/30210] Altivec builtins have inaccurate return types
--- Comment #9 from bonzini at gnu dot org 2009-05-03 14:25 --- *** Bug 40009 has been marked as a duplicate of this bug. *** -- bonzini at gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30210
[Bug target/30210] Altivec builtins have inaccurate return types
--- Comment #10 from bonzini at gnu dot org 2009-05-03 14:26 --- The wrong types in __builtin_altivec_ctu cause this: FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer (internal compiler error) FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer -funroll-loops (internal compiler error) FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (internal compiler error) FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gcc.c-torture/compile/pr39943.c -O3 -g (internal compiler error) FAIL: gcc.c-torture/compile/pr39943.c -O3 -g (test for excess errors) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30210
[Bug target/40009] altivec __builtin_vec_ctu has wrong tyes
--- Comment #9 from bonzini at gnu dot org 2009-05-03 14:34 --- To be more specific, the builtin call is created by the vectorizer, and the vectorizer is quite careless in matching types. The front-end *does* insert VIEW_CONVERT_EXPRs and so does rs6000-c.c. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40009
[Bug target/30210] Altivec builtins have inaccurate return types
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-05-03 15:54 --- And as there is _builtin_altivec_cts in addition to _builtin_altivec_ctu these builtins should better have correct types from the start. In fact they look more constrained than opaque anyway - so why are they using opaque arguments / return types at all? Not an enhancement, wrong-code in the middle-end sense. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|enhancement |normal Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30210
[Bug tree-optimization/22372] Vectorizer produces mis-match types
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-05-03 15:56 --- *** This bug has been marked as a duplicate of 30210 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22372
[Bug target/30210] Altivec builtins have inaccurate return types
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-05-03 15:56 --- *** Bug 22372 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30210
[Bug target/30210] [4.5 Regression] Altivec builtins have inaccurate return types
--- Comment #13 from rguenth at gcc dot gnu dot org 2009-05-03 15:57 --- And now causing regressions with type checking enabled. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|Altivec builtins have |[4.5 Regression] Altivec |inaccurate return types |builtins have inaccurate ||return types Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30210
[Bug middle-end/22370] Vec lower produces mis-match types
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-05-03 15:59 --- Seems to be fixed at least in 4.5. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22370
[Bug tree-optimization/22373] loop linear produces type mis-match
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-03 16:01 --- Seems to work with 4.5. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22373
[Bug c/23145] struct {int i;} is not compatiable with struct {int i,j}
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-05-03 16:04 --- With --combine? It indeed doesn't complain. But I also don't see type mismatches with type checking. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23145
[Bug tree-optimization/23166] SCCP causes type mismatch
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-05-03 16:05 --- Fixed at least with 4.5. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23166
[Bug tree-optimization/23347] PRE produces type mismatch in PHIs when compiling java from bytecode
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-05-03 16:06 --- It is supposedly fixed as we can bootstrap libjava with type checking enabled. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23347
[Bug middle-end/25269] gcc.target/x86_64/abi/test_passing_unions.c fails with some type mismatches
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-03 16:07 --- Works for me. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25269
[Bug tree-optimization/28721] SRA vs Ada and type mismatches
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-03 16:07 --- Works for me. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28721
[Bug middle-end/28723] Fortran vs Inliner creates mismatch types
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-03 16:08 --- Works for me. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28723
[Bug tree-optimization/23329] hack in may_propagate_copy should be able to removed
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-05-03 16:13 --- Mine. I have a patch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-07-09 05:20:06 |2009-05-03 16:13:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23329
[Bug libfortran/22423] Warnings when building libgfortran
--- Comment #16 from fxcoudert at gcc dot gnu dot org 2009-05-03 16:28
---
Many new warnings:
../../../trunk/libgfortran/runtime/string.c: In function compare0:
../../../trunk/libgfortran/runtime/string.c:39: warning: comparison between
signed and unsigned integer expressions
Fixed by:
Index: runtime/string.c
===
--- runtime/string.c(revision 147057)
+++ runtime/string.c(working copy)
@@ -36,7 +36,10 @@
/* Strip trailing blanks from the Fortran string. */
len = fstrlen (s1, s1_len);
- if (len != strlen(s2)) return 0; /* don't match */
+
+ if ((size_t) len != strlen(s2))
+return 0; /* don't match */
+
return strncasecmp (s1, s2, len) == 0;
}
../../../trunk/libgfortran/io/transfer.c: In function read_block_direct:
../../../trunk/libgfortran/io/transfer.c:468: warning: comparison between
signed and unsigned integer expressions
Fixed by:
Index: io/transfer.c
===
--- io/transfer.c (revision 147057)
+++ io/transfer.c (working copy)
@@ -465,7 +465,7 @@
/* Check whether we exceed the total record length. */
if (dtp-u.p.current_unit-flags.has_recl
- (nbytes dtp-u.p.current_unit-bytes_left))
+ ((gfc_offset) nbytes dtp-u.p.current_unit-bytes_left))
{
to_read_record = dtp-u.p.current_unit-bytes_left;
short_record = 1;
../../../trunk/libgfortran/io/list_read.c: In function nml_read_obj:
../../../trunk/libgfortran/io/list_read.c:2464: warning: comparison between
bt and enum anonymous
../../../trunk/libgfortran/io/list_read.c: In function nml_get_obj_data:
../../../trunk/libgfortran/io/list_read.c:2712: warning: comparison between
bt and enum anonymous
../../../trunk/libgfortran/io/list_read.c:2734: warning: comparison between
bt and enum anonymous
../../../trunk/libgfortran/io/list_read.c:2768: warning: comparison between
bt and enum anonymous
../../../trunk/libgfortran/io/write.c: In function nml_write_obj:
../../../trunk/libgfortran/io/write.c:1261: warning: comparison between bt
and enum anonymous
../../../trunk/libgfortran/io/write.c:1339: warning: comparison between bt
and enum anonymous
All these come from the use of two different enums for one purpose: the bt enum
in libgfortran/io/io.h and the anonymous enum containing GFC_DTYPE_UNKNOWN,
GFC_DTYPE_INTEGER and friends in gcc/fortran/libgfortran.h. I'm not sure at all
why there are two different enums, why their constants are sometimes used as if
they were interchangeable (all the warnings above come from such uses), but
what I know is that they shouldn't: the constants don't even come in the same
order!
Compare:
GFC_DTYPE_UNKNOWN = 0,
GFC_DTYPE_INTEGER,
GFC_DTYPE_LOGICAL,
GFC_DTYPE_REAL,
GFC_DTYPE_COMPLEX,
GFC_DTYPE_DERIVED,
GFC_DTYPE_CHARACTER
with
BT_NULL, /* ok, null and unknown are close enough */
BT_INTEGER,
BT_LOGICAL,
BT_CHARACTER, /* oops */
BT_REAL, /* re-oops */
BT_COMPLEX /* final oops */
/* and where is derived? */
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Last reconfirmed|2007-10-18 13:22:40 |2009-05-03 16:28:50
date||
Version|4.0.2 |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22423
[Bug target/39975] Support big endian ARM by default.
--- Comment #1 from mikpe at it dot uu dot se 2009-05-03 19:39 --- (In reply to comment #0) Create a default configuration that honours big endian ARM by default. PR31938 refers to this. Looks like a dupe of PR16350. And most of the de-facto standard patch people have been applying to get this support is in gcc-4.3. But see comment #22 in PR16350 for a missing hunk (MULTILIB_DEFAULTS should also use TARGET_ENDIAN_OPTION and not hard-code mlittle-endian). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39975
[Bug rtl-optimization/39914] [4.4 Regression] 96% performance regression in floating point code; part of the problem started 2009/03/12-13
--- Comment #15 from uros at gcc dot gnu dot org 2009-05-03 19:40 --- Subject: Bug 39914 Author: uros Date: Sun May 3 19:40:35 2009 New Revision: 147081 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147081 Log: Backport from mainline: 2009-04-28 Uros Bizjak ubiz...@gmail.com PR rtl-optimization/39914 * ira-conflicts.c (ira_build_conflicts): Prohibit call used registers for allocnos created from user-defined variables only when not optimizing. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/ira-conflicts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39914
[Bug rtl-optimization/39914] [4.4 Regression] 96% performance regression in floating point code; part of the problem started 2009/03/12-13
--- Comment #16 from ubizjak at gmail dot com 2009-05-03 19:41 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39914
[Bug fortran/40011] New: Problems with -fwhole-file
Summary of the problems with -fwhole-file I have found so far.
From http://gcc.gnu.org/ml/fortran/2009-03/msg00310.html:
(1) From a first look the several Segmentation fault are coming from
recursive functions, the simplest code being the following:
[ibook-dhum] f90/bug% cat recurs_test_1.f90
! { dg-do compile }
RECURSIVE FUNCTION eval_args(q) result (r)
INTEGER NNODE
PARAMETER (NNODE = 10)
TYPE NODE
SEQUENCE
INTEGER car
INTEGER cdr
END TYPE NODE
TYPE(NODE) heap(NNODE)
INTEGER r, q
r = eval_args(heap(q)%cdr)
END FUNCTION eval_args
[ibook-dhum] f90/bug% gfc -c -fwhole-file recurs_test_1.f90
gfc: Internal error: Segmentation fault (program f951)
Please submit a full bug report.
See http://gcc.gnu.org/bugs.html for instructions.
(2) I have also an ICE (already reported in PR26227
http://gcc.gnu.org/ml/gcc-bugs/2009-03/msg02321.html) for
[ibook-dhum] f90/bug% cat arr_fun.f90
function test(n)
real, dimension(2) :: test
integer:: n
test = n
! print *, test
return
end function test
program arr
real, dimension(2) :: res
res = test(2)
print *, res
end program
[ibook-dhum] f90/bug% gfc -fwhole-file arr_fun.f90
arr_fun.f90: In function 'arr':
arr_fun.f90:8: internal compiler error: in fold_convert, at fold-const.c:2547
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
(3) And I think the following are false positives:
[ibook-dhum] f90/bug% cat specifics_red_4.f90
subroutine test_d(fn, val, res)
double precision fn
double precision val, res
print *, fn(val), res
end subroutine
subroutine test_c(fn, val, res)
complex fn
complex val, res
print *, fn(val), res
end subroutine
program specifics
intrinsic dcos
intrinsic dcosh
intrinsic dexp
intrinsic conjg
call test_d (dcos, 1d0, dcos(1d0))
call test_d (dcosh, 1d0, dcosh(1d0))
call test_d (dexp, 1d0, dexp(1d0))
call test_c (conjg, (1.0,1.0) , conjg((1.0,1.0)))
end program
[ibook-dhum] f90/bug% gfc -fwhole-file specifics_red_4.f90
specifics_red_4.f90:25.15:
call test_d (dcos, 1d0, dcos(1d0))
1
Error: Type/rank mismatch in argument 'fn' at (1)
specifics_red_4.f90:26.15:
call test_d (dcosh, 1d0, dcosh(1d0))
1
Error: Type/rank mismatch in argument 'fn' at (1)
specifics_red_4.f90:27.15:
call test_d (dexp, 1d0, dexp(1d0))
1
Error: Type/rank mismatch in argument 'fn' at (1)
specifics_red_4.f90:29.15:
call test_c (conjg, (1.0,1.0) , conjg((1.0,1.0)))
1
Error: Type/rank mismatch in argument 'fn' at (1)
From http://gcc.gnu.org/ml/fortran/2009-03/msg00316.html
Your patch fixes some Segmentation faults (a couple), but not this one:
! { dg-do compile }
program test
interface
function bad_stuff(n)
integer :: bad_stuff (2)
integer :: n(2)
end function bad_stuff
recursive function rec_stuff(n) result (tmp)
integer :: n(2), tmp(2)
end function rec_stuff
end interface
integer :: res(2)
res = bad_stuff((/-19,-30/))
end program test
recursive function bad_stuff(n)
integer :: bad_stuff (2)
integer :: n(2), tmp(2), ent = 0, sent = 0
save ent, sent
ent = -1
entry rec_stuff(n) result (tmp)
if (ent == -1) then
sent = ent
ent = 0
end if
ent = ent + 1
tmp = 1
if(maxval (n) 5) then
tmp = tmp + rec_stuff (n+1)
ent = ent - 1
endif
if (ent == 1) then
if (sent == -1) then
bad_stuff = tmp + bad_stuff (1)
end if
ent = 0
sent = 0
end if
end function bad_stuff
From http://gcc.gnu.org/ml/fortran/2009-03/msg00317.html
A simpler test:
recursive function fac(i) result (res)
integer :: i, j, k, res
k = 1
goto 100
entry bifac(i,j) result (res)
k = j
100 continue
if (i k) then
res = 1
else
res = i * bifac(i-k,k)
end if
end function
program test
external fac
external bifac
integer :: fac, bifac
print *, fac(5)
print *, bifac(5,2)
print*, fac(6)
print *, bifac(6,2)
print*, fac(0)
print *, bifac(1,2)
end program test
From http://gcc.gnu.org/ml/fortran/2009-04/msg00031.html
some ICEs on the polyhedron test suite (see also pr39896):
[ibook-dhum] lin/test% gfc -fwhole-file aermod.f90
f951: internal compiler error: Bus error
[ibook-dhum] lin/test% gfc -fwhole-file air.f90
f951: internal compiler error: Bus error
[ibook-dhum] lin/test% gfc -O0
[Bug target/10242] [ARM] subsequent use of plus and minus operators could be improved
--- Comment #7 from mikpe at it dot uu dot se 2009-05-03 19:53 --- (In reply to comment #6) Created an attachment (id=17475) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17475action=view) [edit] Proposed fix -- will commit after trunk reopens Ping, trunk is open now, no? I've been using this proposed fix in my gcc-4.3.4 based compiler for more than a month now without ill effects. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10242
[Bug c/39983] ICE: type mismatch in address expression
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-05-03 19:57 --- Subject: Bug 39983 Author: rguenth Date: Sun May 3 19:57:32 2009 New Revision: 147083 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147083 Log: 2009-05-03 Richard Guenther rguent...@suse.de PR c/39983 * c-typeck.c (array_to_pointer_conversion): Do not built ADDR_EXPRs of arrays of pointer-to-element type. * c-gimplify.c (c_gimplify_expr): Revert change fixing up wrong ADDR_EXPRs after-the-fact. * c-common.c (strict_aliasing_warning): Strip pointer conversions for obtaining the original type. * builtins.c (fold_builtin_memset): Handle array types. (fold_builtin_memory_op): Handle folded POINTER_PLUS_EXPRs and array types * gcc.c-torture/compile/pr39983.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr39983.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/c-common.c trunk/gcc/c-gimplify.c trunk/gcc/c-typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39983
[Bug c/39983] ICE: type mismatch in address expression
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-05-03 19:57 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39983
[Bug tree-optimization/23329] hack in may_propagate_copy should be able to removed
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-05-03 19:58 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23329
[Bug target/26463] -O2, -O3, -Os segment fault due to bad array index on ARM
--- Comment #4 from mikpe at it dot uu dot se 2009-05-03 20:05 --- (In reply to comment #3) Comment #2 indicates that there isn't a problem with a 4.x series compiler . I'd like some feedback if this problem exists today with a more recent version of the compiler. I can't reproduce the problem with either gcc-4.3.4 20090405 or gcc-4.4.1 20090428 on an armv5tel-unknown-linux-gnueabi system. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26463
[Bug debug/40012] New: Bad debug info for local variables
Given the attached program compiled with gcc -ggdb3 -o dlmod dlmod.i the DW_AT_location for the variable 'problem' seems to be off by 16 bytes, so when I try to examine the variable from the debugger that returns the wrong value. Below is some information about my compiler: svnversion reports that I am using revision 147075. $ gcc --version --verbose Using built-in specs. gcc (GCC) 4.5.0 20090503 (experimental) Copyright (C) 2009 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Target: i686-pc-linux-gnu Configured with: ../trunk/configure --enable-languages=c,c++ --prefix=/usr/local /gcc-head --enable-shared --with-system-zlib --without-included-gettext --enable -threads --disable-nls --enable-__cxa_atexit --enable-clocale=gnu --enable-libst dcxx-debug --with-arch=core2 --with-tune=core2 --enable-checking=release --enabl e-concept-checks --disable-libgomp --disable-libmudflap --disable-libssp Thread model: posix -- Summary: Bad debug info for local variables Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gcc at magfr dot user dot lysator dot liu dot se GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40012
[Bug debug/40012] Bad debug info for local variables
--- Comment #1 from gcc at magfr dot user dot lysator dot liu dot se 2009-05-03 22:05 --- Created an attachment (id=17794) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17794action=view) Test case demonstrating the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40012
[Bug c++/40013] New: [4.4 regression] ICE when creating a local array with size from the return value of a member function of an object in a nested class in a template class
I get an ICE when compiling this code using GCC 4.4 from svn:
template class I class TestClass {
public:
struct Subclass { struct { int c() {return 0;} } b; };
void test();
};
template class I void TestClassI::test() {
Subclass a;
int d[a.b.c()];
}
int main() {
TestClasschar that;
that.test();
}
goff...@asplode tmp % g++ -v testcase.cpp -o testcase --save-temps
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.4.1_pre/work/gcc-4.4.1-/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.4.1-pre
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.1-pre/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.1-pre
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.1-pre/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.1-pre/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.1-pre/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-fixed-point --enable-nls --without-included-gettext
--with-system-zlib --disable-checking --disable-werror --enable-secureplt
--enable-multilib --enable-libmudflap --disable-libssp --enable-libgomp
--enable-cld --disable-libgcj --enable-languages=c,c++,fortran --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo SVN' --with-ppl
--with-cloog
Thread model: posix
gcc version 4.4.1-pre built 20090502 (prerelease) rev. 147067 (Gentoo SVN)
COLLECT_GCC_OPTIONS='-v' '-o' 'testcase' '-save-temps' '-shared-libgcc'
'-mtune=generic'
/usr/libexec/gcc/x86_64-pc-linux-gnu/4.4.1-pre/cc1plus -E -quiet -v
-D_GNU_SOURCE testcase.cpp -mtune=generic -fpch-preprocess -o testcase.ii
ignoring nonexistent directory /usr/local/include
ignoring nonexistent directory
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.1-pre/../../../../x86_64-pc-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.1-pre/include/g++-v4
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.1-pre/include/g++-v4/x86_64-pc-linux-gnu
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.1-pre/include/g++-v4/backward
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.1-pre/include
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.1-pre/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-o' 'testcase' '-save-temps' '-shared-libgcc'
'-mtune=generic'
/usr/libexec/gcc/x86_64-pc-linux-gnu/4.4.1-pre/cc1plus -fpreprocessed
testcase.ii -quiet -dumpbase testcase.cpp -mtune=generic -auxbase testcase
-version -o testcase.s
GNU C++ (Gentoo SVN) version 4.4.1-pre built 20090502 (prerelease) rev.
147067 (x86_64-pc-linux-gnu)
compiled by GNU C version 4.4.1-pre built 20090502 (prerelease)
rev. 147067, GMP version 4.3.0, MPFR version 2.4.1-p5.
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128109
Compiler executable checksum: 0168ca3d6bfe22e6160ea49ab7a5ec7b
testcase.cpp: In member function âvoid TestClassI::test() [with I =
char]â:
testcase.cpp:12: instantiated from here
testcase.cpp:8: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugs.gentoo.org/ for instructions.
It works fine with Gentoo's GCC 4.3.3-r2. I don't know if their patches affect
this, though.
This causes Dillo to fail to compile on its dw/fltkui.cc.
--
Summary: [4.4 regression] ICE when creating a local array with
size from the return value of a member function of an
object in a nested class in a template class
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: goffrie at gmail dot com
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40013
[Bug bootstrap/40014] New: GGC build on Solaris 8 system fails
Hi I tried to build GCC 4.4.0 on my Solaris 8 system. Output from uname -a: SunOS catnip.eecg 5.8 Generic_117350-61 sun4u sparc SUNW,Sun-Blade-1500 I used GCC 3.4.6 for the build. The build compiled fine for about 4 hours then I received the following error: configure: error: GNU Fortran is not working; please report a bug in http://gcc.gnu.org/bugzilla, attaching /local/s rc/gcc/obj_solaris/obj_4.4.0/sparc-sun-solaris2.8/libgfortran/config.log gmake[1]: *** [configure-target-libgfortran] Error 1 I used the following commands for the build. The same commands worked fine when building GCC 3.4.6. --- setenv LD_LIBRARY_PATH /local/lib /local/src/gcc/gcc-4.4.0/configure --prefix=/local/gcc/gcc-4.4.0 --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --with-libiconv-prefix=/local gmake MAKE=gmake LDFLAGS=-L/local/lib -R/local/lib bootstrap --- I tried to add on the config.log top this description but it was rejected because of the number of lines. How do I add an attachment of the config.log file on the bugzilla web page? -thanks peterp Dept. of Computer and Electrical Eng. 10 King's College Rd., University of Toronto, Toronto, Ontario CANADA M5S 3G4 Peter Pereira pet...@eecg.utoronto.ca -- Summary: GGC build on Solaris 8 system fails Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: peterp at eecg dot utoronto dot ca http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40014
[Bug target/38570] [arm] -mthumb generates sub-optimal prolog/epilog
--- Comment #6 from carrot at google dot com 2009-05-04 02:21 --- We can compute the maximum possible function length first. If the length is not large enough far jump is not necessary, and we can do this optimization safely. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38570
[Bug middle-end/39973] [4.5 Regression] Revision 146817 miscompiled 416.gamess in SPEC CPU 2006
--- Comment #2 from hjl dot tools at gmail dot com 2009-05-04 03:30 --- It is reproducible with test data, -i test. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39973
[Bug middle-end/40015] New: [4.5.0 Regression] Revision 147083 failed gfortran.dg/array_memcpy_4.f90
Revision 147083: http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00057.html triggered: FAIL: gfortran.dg/array_memcpy_4.f90 -O scan-tree-dump-times original d = 1 -- Summary: [4.5.0 Regression] Revision 147083 failed gfortran.dg/array_memcpy_4.f90 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end 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=40015
[Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
--- Comment #9 from jv244 at cam dot ac dot uk 2009-05-04 04:39 --- (In reply to comment #8) Thus, the question is what are we recursing on here? type.next_variant if my sources are matching yours (look at gt-fortran-f95-lang.h:337). gt_ggc_m_9tree_node ((*x).generic.type.next_variant); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
[Bug middle-end/40015] [4.5.0 Regression] Revision 147083 failed gfortran.dg/array_memcpy_4.f90
--- Comment #1 from hp at gcc dot gnu dot org 2009-05-04 05:54 --- Seen for cris-elf too... -- hp at gcc dot gnu dot org changed: What|Removed |Added CC||hp at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-04 05:54:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40015
