Re: powerpc-eabi-gcc no implicit FPU usage
On Fri, Jan 15, 2010 at 6:42 PM, Robert Grimm rfgr...@gmail.com wrote: Greetings all, I'm working with the powerpc-eabi architecture (specifically, the MPC563 processor). For some time we have been using GCC 3.4.3 and I noticed gcc generating code that makes use of the floating point registers for 64-bit integer loads and whatnot... which we don't want it to do as there are times when we disable the FPU. I'm aware of the -msoft-float option but we didn't want to use that as we only wanted it to not use FP registers in certain functions and not entire files. I was under the impression that a newer GCC wouldn't do this based on some old mailing posts I've read. I've just tried out GCC 4.4.2 and notice that the FP registers are still being used even though there is no explicit FPU usage going on in this particular part of the code. Is there a way to get GCC to only use the FPU when we explicitly want to use it (i.e. when we use doubles/floats)? Is -msoft-float my only option here? Is there any sort of #pragma that could do the same thing as -msoft-float (I didn't see one)? Recent versions of GCC greatly decrease the use of FPRs for non-floating point code, but do not prevent it. To absolutely prevent use of FPRs, one must use -msoft-float. The hard-float and soft-float ABIs are incompatible and one cannot mix object files. GCC is a compiler, not an assembler. It tries to optimize programs, not read programmers' minds. If the person invoking the compiler does not deny the resource to the compiler, it will try to use it when profitable, which is what it should do. David
Re: powerpc-eabi-gcc no implicit FPU usage
On 1/16/10, David Edelsohn dje@gmail.com wrote: Is there a way to get GCC to only use the FPU when we explicitly want to use it (i.e. when we use doubles/floats)? Is -msoft-float my only option here? Is there any sort of #pragma that could do the same thing as -msoft-float (I didn't see one)? To absolutely prevent use of FPRs, one must use -msoft-float. The hard-float and soft-float ABIs are incompatible and one cannot mix object files. There is a third option -mfloat-abi=softfp which stipulates that FP instructions can be used within functions but the parameter and return values are passed using the same conventions as soft float. soft and softfp-compiled files can be linked together, allowing you to mix code using FP instructions and not with source file granularity. I dunno if that affects the use of FP registers to load /store 64-bit integer values as you originally described, but may be the closest you can get without modifying GCC to insert new #pragmas. M
[Bug c++/42765] New: If the compile fails, the gch is still produced.
Even if the compile fails, the gch is produced! mdup...@introspector-desktop:~/2010/01/extern/mapnik/include/mapnik$ make datasource_cache.hpp.gch g++ -x c++-header -I ../.. -I .. -I -Winvalid-pch -pg \ -DMAPNIK_DEBUG \ -I/usr/include/libpng12 \ -I/usr/include/freetype2 -DHAVE_CONFIG_H \ -I/home/mdupont/2010/01/mapnik/mapnik/agg/include \ -I/usr/local/include \ -I/usr/include/libxml2 \ -D_REENTRANT -I/usr/include/cairomm-1.0 -I/usr/include/cairo -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -c datasource_cache.hpp In file included from datasource_cache.hpp:31:0: ../mapnik/plugin.hpp:44:42: error: Plugin has not been declared make: *** [datasource_cache.hpp.gch] Error 1 mdup...@introspector-desktop:~/2010/01/extern/mapnik/include/mapnik$ make datasource_cache.hpp.gch make: `datasource_cache.hpp.gch' is up to date. -- Summary: If the compile fails, the gch is still produced. Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: JamesMikeDuPont at googlemail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42765
[Bug middle-end/42760] [4.4 Regression] ICE in convert_move
--- Comment #3 from jakub at gcc dot gnu dot org 2010-01-16 09:45 --- Subject: Bug 42760 Author: jakub Date: Sat Jan 16 09:44:57 2010 New Revision: 155959 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155959 Log: PR middle-end/42760 Backport from trunk 2009-06-17 Steve Ellcey s...@cup.hp.com * expr.c (expand_assignment): Change complex type check. * g++.dg/torture/pr42760.C: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/torture/pr42760.C Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/expr.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42760
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
--- Comment #28 from paolo dot carlini at oracle dot com 2010-01-16 10:10 --- Feedback not forthcoming. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
[Bug middle-end/42749] [4.5 Regression] -O2 and verify_stmts failed again
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-01-16 10:35 --- Indeed it's harder that I thought originally as well ;) I wonder why we re-create a simple form of the return value adjustment instead of just copying the existing statements. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42749
[Bug middle-end/42749] [4.5 Regression] -O2 and verify_stmts failed again
-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-01-15 10:30:57 |2010-01-16 10:41:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42749
[Bug bootstrap/42735] Error: symbol `pread64' is already defined
--- Comment #3 from dick at mrns dot nl 2010-01-16 10:50 --- What can I do to fix this bug? I can't update glibc because the latest glibc doesn't compile with gcc 4.1.2. Grepping through the buildtree on pread64 returns: i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu/bits/stdtr1c++.h.gch/O2g.gch i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu/bits/extc++.h.gch/O2g.gch i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu/bits/stdc++.h.gch/O0g.gch i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu/bits/stdc++.h.gch/O2g.gch You can download my buildroot (chrootable) at: http://routi.mrns.nl/~meeuw/gcc-4.tar.bz2 (183 MB compressed, 832 MB uncompressed) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42735
[Bug c++/42766] New: tree check fail in build_expr_type_conversion
I just tried to compile the package qsvn-0.8.2-0.pm.1.1 with the GNU C++ compiler version 4.5 snapshot 20100114 and the compiler said /usr/src/packages/BUILD/qsvn-0.8.2/src/svnclient.cpp: In destructor 'virtual SvnClient::~SvnClient()': /usr/src/packages/BUILD/qsvn-0.8.2/src/svnclient.cpp:68:12: internal compiler error: tree check: expected tree that contains 'decl common' structure, have 'overload' in build_expr_type_conversion, at cp/cvt.c:1210 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Preprocessed source code attached. No special flags required. -- Summary: tree check fail in build_expr_type_conversion Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42766
[Bug c++/42766] tree check fail in build_expr_type_conversion
--- Comment #1 from dcb314 at hotmail dot com 2010-01-16 11:12 --- Created an attachment (id=19619) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19619action=view) gzipped C++ source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42766
[Bug middle-end/42068] [4.5 regression] ICE in function_and_variable_visibility breaks Ada bootstrap
--- Comment #15 from hubicka at ucw dot cz 2010-01-16 12:30 --- Subject: Re: [4.5 regression] ICE in function_and_variable_visibility breaks Ada bootstrap No doubt about that. The problem is, this was installed without mention in the ChangeLog so looks quite unintentional. If this is intentional, you should fix the ChangeLog. Will do, the earlier version of sanity check was wrong. Actually looking into DECL_COMMON implementation, it seems that even for static variables this seems to work as intended at least on i386, so perhaps the sanity check is overactive. I am double checking that now. I will have time to try to reproduce the problem only tomorrow or during weekend (it will be bit tricky as I know of no machine known to fail here I can access easily), Please read comment #5. I am not questioning that. I have somewhat hectic time now and did not notice situation earlier. I am finishing some papers and my thesis now. My apologize for missing this. Will finish patch today. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42068
[Bug debug/42767] New: ICE in mem_loc_descriptor
ICE when compiling the attached test case with -O -g. $ ./cc1 -O -g /tmp/testcase-ice-mem_loc_descriptor.c _bfd_link_section_stabs Analyzing compilation unit Performing interprocedural optimizations visibility *free_lang_data early_local_cleanups whole-program inline static-var pure-constAssembling functions: _bfd_link_section_stabs(us_truncate:SI (reg:PDI 32 A0)) /tmp/testcase-ice-mem_loc_descriptor.c: In function _bfd_link_section_stabs: /tmp/testcase-ice-mem_loc_descriptor.c:14:1: internal compiler error: in mem_loc_descriptor, at dwarf2out.c:13487 -- Summary: ICE in mem_loc_descriptor Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jzhang918 at gmail dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: bfin-uclinux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42767
[Bug debug/42767] ICE in mem_loc_descriptor
--- Comment #1 from jzhang918 at gmail dot com 2010-01-16 12:35 --- Created an attachment (id=19620) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19620action=view) The test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42767
[Bug debug/42767] ICE in mem_loc_descriptor
--- Comment #2 from jzhang918 at gmail dot com 2010-01-16 12:36 --- Created an attachment (id=19621) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19621action=view) The patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42767
[Bug debug/42767] ICE in mem_loc_descriptor
--- Comment #3 from jzhang918 at gmail dot com 2010-01-16 12:37 --- I'm testing the attached patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42767
[Bug middle-end/42749] [4.5 Regression] -O2 and verify_stmts failed again
--- Comment #10 from rakdver at gcc dot gnu dot org 2010-01-16 12:53 --- /* Reject a tailcall if the type conversion might need 285 additional code. */ 286if (gimple_assign_cast_p (stmt) 287 TYPE_MODE (TREE_TYPE (dest)) != TYPE_MODE (TREE_TYPE (src_var))) 288 return false; This is suspicious; replacing the weird TYPE_MODE check with useless_type_conversion_p fixes the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42749
[Bug c++/42766] [4.5 Regression] tree check fail in build_expr_type_conversion
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-16 12:57 --- Reducing. 4.4 compiles it fine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to work||4.4.2 Last reconfirmed|-00-00 00:00:00 |2010-01-16 12:57:39 date|| Summary|tree check fail in |[4.5 Regression] tree check |build_expr_type_conversion |fail in ||build_expr_type_conversion Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42766
[Bug middle-end/42749] [4.5 Regression] -O2 and verify_stmts failed again
--- Comment #11 from rguenther at suse dot de 2010-01-16 13:19 --- Subject: Re: [4.5 Regression] -O2 and verify_stmts failed again On Sat, 16 Jan 2010, rakdver at gcc dot gnu dot org wrote: --- Comment #10 from rakdver at gcc dot gnu dot org 2010-01-16 12:53 --- /* Reject a tailcall if the type conversion might need 285 additional code. */ 286if (gimple_assign_cast_p (stmt) 287 TYPE_MODE (TREE_TYPE (dest)) != TYPE_MODE (TREE_TYPE (src_var))) 288 return false; This is suspicious; replacing the weird TYPE_MODE check with useless_type_conversion_p fixes the problem. Correct, but for useless_type_conversion_p we can reject any conversions in the IL since only !useless_type_conversion_p remain. I suppose the code was explicitly trying to allow sign-changing (but not precision changing as it does), or conversion to/from pointers. Thus, if you want to go the useless_type_conversion_p route simply reject all conversions and only allow plain SSA name copies... Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42749
[Bug middle-end/42749] [4.5 Regression] -O2 and verify_stmts failed again
--- Comment #12 from rakdver at kam dot mff dot cuni dot cz 2010-01-16 13:24 --- Subject: Re: [4.5 Regression] -O2 and verify_stmts failed again --- Comment #10 from rakdver at gcc dot gnu dot org 2010-01-16 12:53 --- /* Reject a tailcall if the type conversion might need 285 additional code. */ 286if (gimple_assign_cast_p (stmt) 287 TYPE_MODE (TREE_TYPE (dest)) != TYPE_MODE (TREE_TYPE (src_var))) 288 return false; This is suspicious; replacing the weird TYPE_MODE check with useless_type_conversion_p fixes the problem. Correct, but for useless_type_conversion_p we can reject any conversions in the IL since only !useless_type_conversion_p remain. right I suppose the code was explicitly trying to allow sign-changing (but not precision changing as it does), or conversion to/from pointers. Thus, if you want to go the useless_type_conversion_p route simply reject all conversions and only allow plain SSA name copies... this might be overly restrictive; it should be quite easy to add the appropriate casts, instead. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42749
[Bug middle-end/42615] Even with -fwrapv, (3*x%3) is assumed to always be equal to 0
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-16 13:34 --- Actually it doesn't optimize 3*x%3 as if it were 0 but simply uses signed arithmetic for the modulo operation resulting in a -2 modulus. Using ((unsigned)(3 * x)) % 3 will get what you expect. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42615
[Bug c++/42768] New: libstdc++-v3/libsupc++/vec.cc:354: internal compiler error: Segmentation fault
crashed while building g++ -- Summary: libstdc++-v3/libsupc++/vec.cc:354: internal compiler error: Segmentation fault Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: t7 at gmail dot com GCC build triplet: x86_64-w64-mingw32 GCC host triplet: x86_64-slackware-linux GCC target triplet: x86_64-w64-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42768
[Bug c++/42768] libstdc++-v3/libsupc++/vec.cc:354: internal compiler error: Segmentation fault
--- Comment #1 from t7 at gmail dot com 2010-01-16 13:39 --- Created an attachment (id=19622) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19622action=view) saves -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42768
[Bug c/42544] Bad codegen with signed short cast to unsigned int, then promoted to unsigned long long
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-01-16 13:45 --- I'm not working on this anymore. The proper thing to do is to move most if not all of shorten-compare to the middle-end (by re-implementing the little pieces that are missing there). The hard thing about this is retaining the -Wconversion warnings. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42544
[Bug c++/42766] [4.5 Regression] tree check fail in build_expr_type_conversion
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-16 14:12 ---
templateclass T class smart_pointer {
public:
operator T* () const { }
operator bool () const { }
operator bool () { }
};
class Context { };
typedef smart_pointerContext ContextP;
class SvnClient {
~SvnClient();
ContextP svnContext;
};
SvnClient::~SvnClient() {
delete svnContext;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42766
[Bug target/42753] _Complex_I is reported as undeclared. Code builds with Sun compiler.
--- Comment #11 from david dot kirkby at onetel dot net 2010-01-16 14:27 --- (In reply to comment #10) Subject: Re: _Complex_I is reported as undeclared. Code builds with Sun compiler. On Fri, 15 Jan 2010, david dot kirkby at onetel dot net wrote: Is this is trivial fix that could be implemted quickly, or it will require quite a bit of work, and so I should not expect a solution soon? It could be implemented quickly if someone familiar with fixincludes wishes to fix it. Do you know of anyone with the necessary knowledge? If so, I'll drop them an email and ask if they would mind looking at it. It is a *major* headache for the GPL Sage maths project, http://www.sagemath.org/ as we are having to disable working code on Solaris due to a bug in gcc. Unfortunately, not all of Sage will build with Sun's compiler, so that is not an option. BTW, the bug is still marked as 'UNCONFIRMED'. Is that still appropriate? Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42753
[Bug c++/21057] iso C99 complex double: problems with g++
--- Comment #3 from david dot kirkby at onetel dot net 2010-01-16 14:29 --- (In reply to comment #2) Confirmed. However, this has really low priority: the C++ standard is not a superset of the C99 standard, so a number of things new to C99 are not part of C++, and this is one of them. If you want to write portable code, you should use the std::complex class. If you have cases where you can show that std::complex is slower than using the C99 means, we'd be happy to accept bug reports. Thanks Wolfgang Note this bug, which you considered as low priority since it applied to using C code with the C++ compiler, is not limited to the C++ compiler. Take a look at #42753 where you will see this bug stops one building C code if using gcc. -- david dot kirkby at onetel dot net changed: What|Removed |Added CC||david dot kirkby at onetel ||dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21057
[Bug other/42525] gtyp-input.list contains 'n' instead of '\n' as separator
--- Comment #3 from rwild at gcc dot gnu dot org 2010-01-16 14:42 --- Subject: Bug 42525 Author: rwild Date: Sat Jan 16 14:42:32 2010 New Revision: 155963 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155963 Log: Avoid tr '\n', for Solaris /usr/bin/tr. contrib/ * check_warning_flags.sh: Use \012 instead of \n with tr. gcc/: PR gcc/42525 * Makefile.in (write_entries_to_file, install-plugin): Use \012 instead of \n with tr. libjava/: * Makefile.am (write_entries_to_file): Use \012 instead of \n with tr. * scripts/makemake.tcl: Likewise. * sources.am: Regenerate. * Makefile.in: Regenerate. Modified: trunk/contrib/ChangeLog trunk/contrib/check_warning_flags.sh trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/libjava/ChangeLog trunk/libjava/Makefile.am trunk/libjava/Makefile.in trunk/libjava/scripts/makemake.tcl trunk/libjava/sources.am -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42525
[Bug target/42664] ICE on compilation of polyhedron benchmarks with -mfma4
--- Comment #9 from spop at gcc dot gnu dot org 2010-01-16 14:46 --- Subject: Bug 42664 Author: spop Date: Sat Jan 16 14:46:19 2010 New Revision: 155964 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155964 Log: Fix PR42664. 2010-01-16 Harsha Jagasia harsha.jaga...@amd.com PR target/42664 * config/i386/i386.c (ix86_fixup_binary_operands): Revert FMA4 fixup of operands. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42664
[Bug libstdc++/35942] Self Reference In Dynamic Linked Library builds for building Cross-Compiler
--- Comment #17 from rwild at gcc dot gnu dot org 2010-01-16 14:47 --- Subject: Bug 35942 Author: rwild Date: Sat Jan 16 14:46:57 2010 New Revision: 155965 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155965 Log: Fix PR 35942: remove -lstdc++ from libtool postdeps for CXX. libstdc++-v3/: PR libstdc++/35942 * configure.ac: Remove -lstdc++ from libtool's postdeps_CXX. * configure: Regenerate. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/configure trunk/libstdc++-v3/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35942
[Bug target/42664] ICE on compilation of polyhedron benchmarks with -mfma4
--- Comment #10 from spop at gcc dot gnu dot org 2010-01-16 14:49 --- Fixed. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42664
[Bug libstdc++/35942] Self Reference In Dynamic Linked Library builds for building Cross-Compiler
--- Comment #18 from rwild at gcc dot gnu dot org 2010-01-16 14:49 --- Fixed for 4.5. -- rwild at gcc dot gnu dot org changed: What|Removed |Added Known to work|4.2.0 |4.2.0 4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35942
[Bug other/42525] gtyp-input.list contains 'n' instead of '\n' as separator
--- Comment #4 from rwild at gcc dot gnu dot org 2010-01-16 14:50 --- Fixed for 4.5. -- rwild at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42525
[Bug middle-end/42068] [4.5 regression] ICE in function_and_variable_visibility breaks Ada bootstrap
--- Comment #16 from hubicka at gcc dot gnu dot org 2010-01-16 14:54 --- Created an attachment (id=19623) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19623action=view) patch I am testing -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42068
[Bug middle-end/42068] [4.5 regression] ICE in function_and_variable_visibility breaks Ada bootstrap
--- Comment #17 from hubicka at gcc dot gnu dot org 2010-01-16 14:54 --- Hi, strictly speaking, I would argue that Ada should not set COMMON flag for !PUBLIC variables since it has no effect: all static variables that have no initializer go to .common anyway. However same ICE is possible to trigger via static int a __attribute__ ((common)) and looking at varasm.c threre are multitude of reasons why COMMON flag is disqualified later. The checks are spred across the varasm.c and some of them are arguably late since things should be finalized after make_decl_rtl. So following patch moves the logic into visibility pass so it will now clear the flag instead of ICEing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42068
[Bug middle-end/42068] [4.5 regression] ICE in function_and_variable_visibility breaks Ada bootstrap
--- Comment #18 from ebotcazou at gcc dot gnu dot org 2010-01-16 15:11 --- strictly speaking, I would argue that Ada should not set COMMON flag for !PUBLIC variables since it has no effect: all static variables that have no initializer go to .common anyway. That seems reasonable. The Ada part is OK if you write it: DECL_INITIAL (var_decl) = var_init; TREE_READONLY (var_decl) = const_flag; DECL_EXTERNAL (var_decl) = extern_flag; TREE_PUBLIC (var_decl) = public_flag || extern_flag; TREE_CONSTANT (var_decl) = constant_p; TREE_THIS_VOLATILE (var_decl) = TREE_SIDE_EFFECTS (var_decl) = TYPE_VOLATILE (type); /* Ada doesn't feature Fortran-like COMMON variables so we shouldn't try to fiddle with DECL_COMMON. However, on platforms that don't support global BSS sections, uninitialized global variables would go in DATA instead, thus increasing the size of the executable. */ if (!flag_no_common TREE_CODE (var_decl) == VAR_DECL TREE_PUBLIC (var_decl) !have_global_bss_p ()) DECL_COMMON (var_decl) = 1; Thanks for fixing the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42068
[Bug c++/42761] std::bind doesn't work for simple class types
--- Comment #3 from jason at gcc dot gnu dot org 2010-01-16 15:23 --- Subject: Bug 42761 Author: jason Date: Sat Jan 16 15:23:19 2010 New Revision: 155966 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155966 Log: PR c++/42761 * semantics.c (finish_decltype_type): Within a template, treat unresolved CALL_EXPR as dependent. Added: trunk/gcc/testsuite/g++.dg/cpp0x/decltype22.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42761
[Bug c++/42761] std::bind doesn't work for simple class types
--- Comment #4 from jason at gcc dot gnu dot org 2010-01-16 15:24 --- Fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42761
[Bug middle-end/42760] [4.4 Regression] ICE in convert_move
--- Comment #5 from jakub at gcc dot gnu dot org 2010-01-16 15: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=42760
[Bug rtl-optimization/42691] [4.4/4.5 regression] problematic REG_EQUAL note added to SUBREG
--- Comment #24 from jakub at gcc dot gnu dot org 2010-01-16 16:05 ---
In the preprocessor you can do #if __SIZEOF_DOUBLE__ == 4 * __SIZEOF_SHORT__
(and in #else just have a int main (void) { return 0; }).
Or you could in main do if (sizeof (double) != 4 * sizeof (short)) return 0;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42691
[Bug c++/42766] [4.5 Regression] tree check fail in build_expr_type_conversion
--- Comment #4 from hjl dot tools at gmail dot com 2010-01-16 16:42 --- It is caused by revision 147677: http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00653.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||jason at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42766
[Bug driver/42690] Undefined reference errors with -flto -fuse-linker-plugin
--- Comment #13 from d dot g dot gorbachev at gmail dot com 2010-01-16
16:55 ---
(In reply to comment #12)
What options other than -nostdlib prevent gcc from linking libgcc and
libc in the produced binary?
I know of -nodefaultlibs.
To implement this we should always pass -plugin-opt=-pass-through=
%(lto_libgcc) and -plugin-opt=-pass-through=-lc to the linker unless
something like -nostdlib is used.
Wouldn't it be better to add %{fuse-linker-plugin:
-plugin-opt=-pass-through=...} to LIBGCC_SPEC and to LIB_SPEC?
However, the driver does not really know, whether we link with libgcc and/or
libc. Someone can use -nodefaultlibs together with -lc -lgcc and the linker
will still fail.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42690
[Bug fortran/42769] New: ICE in resolve_typebound_procedure
The attached source file produces the error with a fresh trunk checkout at r155958. [sfili...@localhost bugr1]$ gfortran -c psb_s_tools_mod.f90 psb_s_tools_mod.f90:6363:0: internal compiler error: in resolve_typebound_procedure, at fortran/resolve.c:10023 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. [sfili...@localhost bugr1]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gnu45/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr/local/gnu45 --enable-languages=c,c++,fortran Thread model: posix gcc version 4.5.0 20100116 (experimental) (GCC) -- Summary: ICE in resolve_typebound_procedure Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sfilippone at uniroma2 dot it GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769
[Bug fortran/42769] ICE in resolve_typebound_procedure
--- Comment #1 from sfilippone at uniroma2 dot it 2010-01-16 17:02 --- Created an attachment (id=19624) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19624action=view) test case Sorry, the test case is a bit lengthy, but I have no time to reduce it further, and I'll be away next week. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769
[Bug fortran/42769] ICE in resolve_typebound_procedure
--- Comment #2 from sfilippone at uniroma2 dot it 2010-01-16 17:05 --- As mentioned in http://gcc.gnu.org/ml/fortran/2010-01/msg00075.html the code works with Nag; it is not supposed to behave correctly at runtime under gfortran, not until the vtables from fortran-dev are fixed and merged, but it is supposed to compile correctly, and it did until early December (sorry, I don't remember more precisely). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769
[Bug c++/42766] [4.5 Regression] tree check fail in build_expr_type_conversion
--- Comment #5 from simartin at gcc dot gnu dot org 2010-01-16 17:11
---
Currently testing:
Index: gcc/cp/search.c
===
--- gcc/cp/search.c (revision 155965)
+++ gcc/cp/search.c (working copy)
@@ -2353,7 +2353,7 @@
if (check_hidden_convs (binfo, virtual_depth, virtualness,
type, parent_convs, other_convs))
{
- my_convs = tree_cons (binfo, conv, my_convs);
+ my_convs = tree_cons (binfo, cur, my_convs);
TREE_TYPE (my_convs) = type;
if (virtual_depth)
{
--
simartin at gcc dot gnu dot org changed:
What|Removed |Added
CC||simartin at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42766
[Bug c++/42761] std::bind doesn't work for simple class types
--- Comment #5 from redi at gcc dot gnu dot org 2010-01-16 17:19 --- Thanks, Jason! Paolo, what's the trick I missed to make the volatile overloads work? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42761
[Bug other/42756] Build fails if gold is used as linker and some libraries reside is /usr/local/lib
--- Comment #4 from d dot g dot gorbachev at gmail dot com 2010-01-16 17:22 --- This looks like a bug in gold rather then in GCC. Try the latest development version of gold http://sourceware.org/binutils/. If it still fails, please file a bug report with more details at http://sourceware.org/bugzilla/enter_bug.cgi?product=binutils. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42756
[Bug fortran/42769] ICE in resolve_typebound_procedure
--- Comment #3 from hjl dot tools at gmail dot com 2010-01-16 17:22 --- (In reply to comment #1) Created an attachment (id=19624) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19624action=view) [edit] test case Sorry, the test case is a bit lengthy, but I have no time to reduce it further, and I'll be away next week. I got use psb_error_mod 1 Fatal Error: Can't open module file 'psb_error_mod.mod' for reading at (1): No such file or directory -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769
[Bug fortran/42769] ICE in resolve_typebound_procedure
--- Comment #4 from dominiq at lps dot ens dot fr 2010-01-16 17:39 --- I got use psb_error_mod 1 Fatal Error: Can't open module file 'psb_error_mod.mod' for reading at (1): No such file or directory Me too! After removing all the 'use psb_error_mod' I get the same error (at line 9990) with the fortran-exp branch (r155767) and a segmetation fault with fortran-dev (r155781) and my patched tree. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769
[Bug libfortran/42742] [4.5 Regression] SIGSEGV at libgfortran/io/format.c:111
--- Comment #10 from manfred99 at gmx dot ch 2010-01-16 18:13 --- Created an attachment (id=19625) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19625action=view) test case 2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42742
[Bug libfortran/42742] [4.5 Regression] SIGSEGV at libgfortran/io/format.c:111
--- Comment #11 from manfred99 at gmx dot ch 2010-01-16 18:35 --- With test case 2, I get ./writebug2 writebug2.txt Interation1 : 25 Interation2 : 32 Interation3 : 39 Interation4 : 46 Interation5 : 53 Interation6 : 60 Interation7 : 67 Interation8 : 74 Interation9 : 81 Interation 10 : 88 Interation 11 : 95 Interation 12 : 102 Interation 13 : 109 Interation 14 : 116 Interation 15 : 123 Interation 16 : 130 Interation 17 : 137 Interation 18 : 144 Interation 19 : 151 Interation 20 : 158 Interation 21 : 165 Interation 22 : 172 Interation 23 : 179 Interation 24 : 186 Interation 25 : 193 Interation 26 : 200 Interation 27 : 207 Interation 28 : 214 Interation 29 : 221 Interation 30 : 228 Segmentation fault It stops at length 228 after the 5th iteration of the inner loop. I tried 32bit and 64bit, no difference. Also, varying values of ulimit -s and -fmax-stack-var-size made no difference. Maybe your FORMAT_CACHE_STRING_LIMIT is not the same thing as the user space format length, so I can not judge your patch. It seems however, that the bug is not stack size dependent. And my box has more than enough memory. So I'm not completely convinced that the issue is a stack or heap size limitation. I further noticed, that the reached last iteration of the inner loop depends on the loop stop value. If I do DO i=1,100, then the inner loop stops after iteration 85 (but for the same j=30). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42742
[Bug middle-end/19988] [4.3/4.4/4.5 Regression] pessimizes fp multiply-add/subtract combo
--- Comment #18 from rguenth at gcc dot gnu dot org 2010-01-16 19:09 --- Created an attachment (id=19626) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19626action=view) VN based fix This extends the value-numberers value insertion facility to handle this special case. Well, it needs TLC obviously - it was just a quick hack. We now end up with bb 2: D.2649_2 = y_1(D) * 1.23395803356966916908277198672294617e-1; D.2650_4 = D.2649_2 + x_3(D); pretmp.1_9 = -D.2649_2; D.2652_6 = x_3(D) + pretmp.1_9; D.2648_7 = D.2650_4 * D.2652_6; return D.2648_7; probably the same as 3.3. Another interesting bit is that we do not ever merge the negation into the addition on the tree level (we do that only during combine). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19988
[Bug middle-end/19988] [4.3/4.4/4.5 Regression] pessimizes fp multiply-add/subtract combo
--- Comment #19 from rguenth at gcc dot gnu dot org 2010-01-16 19:15 --- What does (can) the new VN do here? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||matz at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19988
[Bug middle-end/19988] [4.3/4.4/4.5 Regression] pessimizes fp multiply-add/subtract combo
--- Comment #20 from matz at gcc dot gnu dot org 2010-01-16 20:10 --- It obviously could do the same. It all depends on the answer to this question: Do we want to deal with this via canonicalization of expressions, and if yes, then also on the outcome of our discussion of where that should happen (fold or special code in VN dealing with just value numbers). If no, then something like your patch can be done. In this case I'm leaning towards Paolo (comment #14), we possibly might want to canonicalize towards fewer constants (hence towards positive constants), when otherwise the number of operations remains the same (hence treating PLUS_EXPR and MINUS_EXPR as equivalent). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19988
[Bug middle-end/19988] [4.3/4.4/4.5 Regression] pessimizes fp multiply-add/subtract combo
--- Comment #21 from rguenth at gcc dot gnu dot org 2010-01-16 20:30 --- (In reply to comment #20) It obviously could do the same. It all depends on the answer to this question: Do we want to deal with this via canonicalization of expressions, and if yes, then also on the outcome of our discussion of where that should happen (fold or special code in VN dealing with just value numbers). If no, then something like your patch can be done. In this case I'm leaning towards Paolo (comment #14), we possibly might want to canonicalize towards fewer constants (hence towards positive constants), when otherwise the number of operations remains the same (hence treating PLUS_EXPR and MINUS_EXPR as equivalent). Yes, that sounds reasonable. Note that most existing foldings only look for PLUS_EXPR once the 2nd operand is a constant, so auditing of them is required. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19988
[Bug target/42770] New: error: unrecognizable insn for pr11832.c
gcc-4.4 -v Using built-in specs. Target: sparc-sun-solaris2.9 Configured with: ../gcc-4.4.2/configure --prefix=/usr/local --build=sparc-sun-solaris2.9 --enable-languages='c c++ fortran' --enable-long-long --enable-threads --enable-__cxa_atexit --with-gmp=/usr/local --with-mpfr=/usr/local --disable-multilib --program-suffix=-4.4 Thread model: posix gcc version 4.4.2 (GCC) gcc-4.4 -O0 -frtl-abstract-sequences pr11832.c pr11832.c: In function 'foo': pr11832.c:35: error: unrecognizable insn: (insn 247 0 0 (set (reg:SI 0 %g0) (symbol_ref:SI (*.LL9) [flags 0x2])) -1 (nil)) pr11832.c:35: internal compiler error: in insn_default_length, at config/sparc/sparc.md:147 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: error: unrecognizable insn for pr11832.c Product: gcc Version: 4.4.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: foldy at rmki dot kfki dot hu GCC build triplet: sparc-sun-solaris2.9 GCC host triplet: sparc-sun-solaris2.9 GCC target triplet: sparc-sun-solaris2.9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42770
[Bug fortran/42769] ICE in resolve_typebound_procedure
--- Comment #5 from hjl dot tools at gmail dot com 2010-01-16 21:04 --- It is very likely caused by revision : http://gcc.gnu.org/ml/gcc-cvs/2009-10/msg00175.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||janus at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-01-16 21:04:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769
[Bug c++/42768] libstdc++-v3/libsupc++/vec.cc:354: internal compiler error: Segmentation fault
--- Comment #2 from t7 at gmail dot com 2010-01-16 21:09 --- libstdc++-v3/libsupc++/vec.cc: In function 'void __cxxabiv1::T.60(void*, size_t, size_t, __cxxabiv1::__cxa_cdtor_return_type (*)(void*))': libstdc++-v3/libsupc++/vec.cc:354: 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. make[5]: *** [vec.lo] Error 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42768
[Bug middle-end/19988] [4.3/4.4/4.5 Regression] pessimizes fp multiply-add/subtract combo
--- Comment #22 from rguenth at gcc dot gnu dot org 2010-01-16 21:42 --- Created an attachment (id=19627) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19627action=view) fixed patch Fixed patch that actually bootstraps. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Attachment #19626|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19988
[Bug libfortran/42742] [4.5 Regression] SIGSEGV at libgfortran/io/format.c:111
--- Comment #12 from manfred99 at gmx dot ch 2010-01-16 21:43 --- To clarify, this was still with the unpatched gfortran 4.5.0, snapshot of 20100107. BTW, the silly, stray line anzarg2=j in writebug2.f does not alter the result. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42742
[Bug fortran/42769] [4.5 Regression] ICE in resolve_typebound_procedure
--- Comment #6 from burnus at gcc dot gnu dot org 2010-01-16 21:46 --- (Mark as regression (P5); while it was not supported in 4.5, it was working before in 4.5.) -- burnus at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code Priority|P3 |P5 Summary|ICE in |[4.5 Regression] ICE in |resolve_typebound_procedure |resolve_typebound_procedure Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769
[Bug tree-optimization/42771] New: [4.5 Regression] ICE: in graphite_loop_normal_form, at graphite-sese-to-poly.c (2)
The original, unreduced, testcase from pr42521 started crashing again, with the same error message. Only little modification to the reduced testcase is needed to reproduce it. Command line: gcc -O3 -fgraphite-identity -c testcase.c Tested revisions (x86_64): r155945 - crash (x86) r155938 - crash r155902 - crash - r155881 - pr42732 fix (can be related) r155844 - OK (x86) r155833 - OK - r155728 - pr42521 fix r155363 - crash Output: $ /mnt/svn/gcc-trunk/binary-155945-x86-lto/bin/gcc -O3 -fgraphite-identity -c testcase.c testcase.c: In function 'foo': testcase.c:5:6: internal compiler error: in graphite_loop_normal_form, at graphite-sese-to-poly.c:2844 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Valgrind: no errors reported -- Summary: [4.5 Regression] ICE: in graphite_loop_normal_form, at graphite-sese-to-poly.c (2) Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zsojka at seznam dot cz 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=42771
[Bug tree-optimization/42771] [4.5 Regression] ICE: in graphite_loop_normal_form, at graphite-sese-to-poly.c (2)
--- Comment #1 from zsojka at seznam dot cz 2010-01-16 22:03 --- Created an attachment (id=19628) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19628action=view) original, unreduced testcase (from ffmpeg sources) Command line: gcc -O3 -fgraphite-identity -c aes.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42771
[Bug tree-optimization/42771] [4.5 Regression] ICE: in graphite_loop_normal_form, at graphite-sese-to-poly.c (2)
--- Comment #2 from zsojka at seznam dot cz 2010-01-16 22:05 --- Created an attachment (id=19629) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19629action=view) reduced testcase The only difference to the pr42521 testcase is added declaration of and call to bar() Command line: gcc -O3 -fgraphite-identity -c pr42771.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42771
[Bug fortran/42772] New: ICE at fold-const.c:10033
With the test case 2 of bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42742 I get with # gfortran -frecursive -fcheck=all -o writebug2 writebug2.f writebug2.f: In function 'MAIN__': writebug2.f:33:0: internal compiler error: in fold_binary_loc, at fold-const.c:10033 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. This is with gfortran 4.5.0 (20100107) A reduced test case is the most trivial fortran program: Just the line END The ICE depends on the options -frecursive -fcheck=all -- Summary: ICE at fold-const.c:10033 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: manfred99 at gmx dot ch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42772
[Bug tree-optimization/42771] [4.5 Regression] ICE: in graphite_loop_normal_form, at graphite-sese-to-poly.c (2)
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42771
[Bug fortran/42772] ICE at fold-const.c:10033
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-16 22:16 --- I get $ gdb --args ./f951 -quiet t.f90 -frecursive -fcheck=all Program received signal SIGSEGV, Segmentation fault. 0x080fc354 in gfc_add_modify (pblock=0xb234, lhs=0x0, rhs=0xb772f6d8) at /home/richard/src/trunk/gcc/fortran/trans.c:164 164 t2 = TREE_TYPE (lhs); (gdb) up #1 0x08125e00 in gfc_generate_function_code (ns=0x8df4100) at /home/richard/src/trunk/gcc/fortran/trans-decl.c:4451 4451gfc_add_modify (block, recurcheckvar, boolean_false_node); with the most trivial fortran program. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-01-16 22:16:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42772
[Bug tree-optimization/42637] [4.5 Regression][graphite] wrong code for -floop-interchange -ftree-loop-distribution
--- Comment #5 from spop at gcc dot gnu dot org 2010-01-16 22:17 --- I have looked again to this function, and I just realized that there were changes to one of the functions of the data dependence test: build_pairwise_scheduling_inequality used to build strict inequalities for the lexicographic comparison, and then Tobias changed it like this: -cstr = build_pairwise_constraint (dim, pos, pos + offset, 0, PPL_CONSTRAINT_TYPE_GREATER_THAN); +cstr = build_pairwise_constraint (dim, pos, pos + offset, -1, + PPL_CONSTRAINT_TYPE_GREATER_OR_EQUAL); else -cstr = build_pairwise_constraint (dim, pos, pos + offset, 0, PPL_CONSTRAINT_TYPE_LESS_THAN); +cstr = build_pairwise_constraint (dim, pos, pos + offset, 1, + PPL_CONSTRAINT_TYPE_LESS_OR_EQUAL); This is wrong. This change was done when we decided to remove the use of the NNC (Non-Necessarily Closed) polyhedra into C (Closed) polyhedra, that do not allow the strict inequalities. I am working on a fix for this PR. Sebastian -- spop at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|trifunovic at gcc dot gnu |spop at gcc dot gnu dot org |dot org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42637
[Bug tree-optimization/42637] [4.5 Regression][graphite] wrong code for -floop-interchange -ftree-loop-distribution
--- Comment #6 from spop at gcc dot gnu dot org 2010-01-16 22:31 --- Actually the change by Tobias is correct. Still, the problem is around that point. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42637
[Bug tree-optimization/42771] [4.5 Regression] ICE: in graphite_loop_normal_form, at graphite-sese-to-poly.c (2)
--- Comment #3 from hjl dot tools at gmail dot com 2010-01-16 22:36 --- It is caused by the new implementation of Graphite: http://gcc.gnu.org/ml/gcc-cvs/2009-07/msg01187.html -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-01-16 22:36:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42771
[Bug fortran/42550] Unable to give initial value 2**0.5 to a real varable
--- Comment #4 from kargl at gcc dot gnu dot org 2010-01-16 23:18 --- This was fixed in March 2009 on trunk. With the pending release of 4.4.3 and the current state of trunk, I see no reason to back port this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42550
[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
--- Comment #24 from kargl at gcc dot gnu dot org 2010-01-16 23:18 --- Fixed in trunk. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568
[Bug fortran/41198] gfortran 4.5 does not produce Warning: Deleted feature: GOTO at (1) jumps to END of construct at (2)
--- Comment #6 from kargl at gcc dot gnu dot org 2010-01-16 23:25 --- The (non?)issue was fixed on trunk in March 2009. Since this issues concerns only a warning and generating wrong code is not possible, I'm closing this with WONTFIX under the 'too many bugs too fix, too few hands to do the work' excuse. -- 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=41198
[Bug fortran/42772] ICE at fold-const.c:10033
--- Comment #2 from dominiq at lps dot ens dot fr 2010-01-16 23:41 --- This is a regression introduced after revision 154654 (working). Backtrace: (gdb) run -frecursive -fcheck=all pr42772.f90 Starting program: /opt/gcc/gcc4.5w/libexec/gcc/x86_64-apple-darwin10/4.5.0/f951 -frecursive -fcheck=all pr42772.f90 Reading symbols for shared libraries .. done MAIN__ Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0010 gfc_add_modify (pblock=0x7fff5fbfeb40, lhs=0x0, rhs=0x141d213c0) at ../../work/gcc/fortran/trans.c:164 164 t2 = TREE_TYPE (lhs); (gdb) bt #0 gfc_add_modify (pblock=0x7fff5fbfeb40, lhs=0x0, rhs=0x141d213c0) at ../../work/gcc/fortran/trans.c:164 #1 0x0001000c38df in gfc_generate_function_code (ns=value temporarily unavailable, due to optimizations) at ../../work/gcc/fortran/trans-decl.c:4463 #2 0x00010006936f in gfc_parse_file () at ../../work/gcc/fortran/parse.c:4242 #3 0x0001000a153c in gfc_be_parse_file (set_yydebug=value temporarily unavailable, due to optimizations) at ../../work/gcc/fortran/f95-lang.c:239 #4 0x0001006d129a in toplev_main (argc=4, argv=0x7fff5fbfed68) at ../../work/gcc/toplev.c:1053 #5 0x000111e4 in start () -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42772
[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
--- Comment #25 from kargl at gcc dot gnu dot org 2010-01-16 23:47 --- Re-open. Sorry guys, wrong PR. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568
[Bug libfortran/42742] [4.5 Regression] SIGSEGV at libgfortran/io/format.c:111
--- Comment #13 from manfred99 at gmx dot ch 2010-01-16 23:48 --- I now built gfortran 4.5.0 (20100107) + Jerry's patch. Patch works for me, no SIGSEGV any more. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42742
[Bug target/42770] error: unrecognizable insn for pr11832.c
--- Comment #1 from mikpe at it dot uu dot se 2010-01-17 00:01 --- The problematic test tested a known buggy feature which has since been removed, see http://gcc.gnu.org/ml/gcc-patches/2009-10/msg01481.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42770
[Bug fortran/42772] ICE at fold-const.c:10033
--- Comment #3 from hjl dot tools at gmail dot com 2010-01-17 02:53 --- It is cause by revision 155606: http://gcc.gnu.org/ml/gcc-cvs/2010-01/msg00065.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||burnus at net-b dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42772
[Bug target/42753] _Complex_I is reported as undeclared. Code builds with Sun compiler.
--- Comment #12 from joseph at codesourcery dot com 2010-01-17 03:36 --- Subject: Re: _Complex_I is reported as undeclared. Code builds with Sun compiler. On Sat, 16 Jan 2010, david dot kirkby at onetel dot net wrote: Do you know of anyone with the necessary knowledge? If so, I'll drop them an The correct way to communicate with maintainers is via the mailing lists and bug database, not direct contact to individuals. They are however listed in MAINTAINERS. as we are having to disable working code on Solaris due to a bug in gcc. A bug in Solaris's headers and a missing feature in GCC that it doesn't work around that bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42753
[Bug target/42753] _Complex_I is reported as undeclared. Code builds with Sun compiler.
--- Comment #13 from david dot kirkby at onetel dot net 2010-01-17 03:53 --- (In reply to comment #12) Subject: Re: _Complex_I is reported as undeclared. Code builds with Sun compiler. On Sat, 16 Jan 2010, david dot kirkby at onetel dot net wrote: Do you know of anyone with the necessary knowledge? If so, I'll drop them an The correct way to communicate with maintainers is via the mailing lists and bug database, not direct contact to individuals. They are however listed in MAINTAINERS. as we are having to disable working code on Solaris due to a bug in gcc. A bug in Solaris's headers and a missing feature in GCC that it doesn't work around that bug. Marc Glisse said on gcc-help It looks like it was fixed in trunk in Septembre (r151331), did you check? I downloaded gcc-4.4-20100112, but that did not fix the issue. I was hoping it might be fixed in a 4.4.x series, but no such luck. I just downloaded gcc-4.5-20100114 in the vague hope that it might be fixed, and the snapshot not cause more problems than it solves. I've not compiled that yet - just had to install MPC first. If this is fixed in trunk do you do you know I might get that fix? If possible, I'd like to get just the fix applied to the latest stable release (i.e. 4.4.2 plus the fix), so it is as risk-free as reasonably practical. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42753
[Bug driver/42690] Undefined reference errors with -flto -fuse-linker-plugin
--- Comment #14 from espindola at gcc dot gnu dot org 2010-01-17 05:47
---
I don't think that in general we can support things like -nodefaultlibs -lc
-lgcc. Doing that with static libraries and lto is such an uncommon case that
it is probably OK to ask the user to also pass -Wl,-pass-through...
I am not familiar with the driver code, but if we already have SPEC stings that
are used only when linking libgcc or libc, that is the perfect place to add
%{fuse-linker-plugin: -plugin-opt=-pass-through=...}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42690
