[Bug fortran/34785] internal compiler error for array constructor for sequence type
--- Comment #2 from pault at gcc dot gnu dot org 2008-01-16 08:00 --- (In reply to comment #1) It is sufficient that BA_T is referenced in tests; eg. by PRINT *, BA_T for the problem to go away. Thus the problem is that the symbol is not being set as referenced. I will try to find out why but will first set it referenced in gfc_resolve_variable. Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34785
[Bug target/34807] New: SH4 �R0_REGS� spill failure when using asm
Building the attached file (extracted and reduced from the uclibc) with
-O[1,2,3,s] -fPIC fails :
test.c: In function _start:
test.c:14: error: unable to find a register to spill in class R0_REGS
test.c:14: error: this is the insn:
(insn 16 28 17 0 (set (mem/c/i:SI (plus:SI (reg:SI 12 r12)
(reg/f:SI 1 r1 [160])) [0 buf+0 S4 A32])
(reg/v:SI 0 r0 [ __sc0 ])) 179 {movsi_ie} (insn_list:REG_DEP_TRUE 13
(insn_list:REG_DEP_TRUE 11 (nil)))
(expr_list:REG_DEAD (reg/f:SI 1 r1 [160])
(expr_list:REG_DEAD (reg/v:SI 0 r0 [ __sc0 ])
(nil
test.c:14: internal compiler error: in spill_failure
--
Summary: SH4 R0_REGS spill failure when using asm
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: chrbr at gcc dot gnu dot org
ReportedBy: chrbr at gcc dot gnu dot org
GCC target triplet: sh-superh-elf,sh4-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34807
[Bug target/34807] SH4 �R0_REGS� spill failure when using asm
--- Comment #1 from chrbr at gcc dot gnu dot org 2008-01-16 08:47 --- Created an attachment (id=14945) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14945action=view) Test case build with sh-superh-elf-gcc -O1 -fPIC test.c -S -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34807
[Bug c/34748] cc1 fails with Not a directory on trivial file
--- Comment #1 from af804 at bfn dot org 2008-01-16 09:02 --- tried fresh build with --libexecdir=/usr/lib, problem disappeared, suspect contamination from previous build -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34748
[Bug libfortran/34669] libgfortran doesn't build with -pipe
--- Comment #3 from burnus at gcc dot gnu dot org 2008-01-16 09:14 --- Subject: Bug 34669 Author: burnus Date: Wed Jan 16 09:13:39 2008 New Revision: 131567 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131567 Log: 2008-01-16 Steven Bosscher [EMAIL PROTECTED] PR libfortran/34669 * mk-kinds-h.sh: Compile with -S to avoid calling the assembler, to avoid piping the -fdump-parse-tree output to the assembler when configuring with -pipe. * mk-sik-inc.sh: Likewise. * mk-srk-inc.sh: Likewise. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/mk-kinds-h.sh trunk/libgfortran/mk-sik-inc.sh trunk/libgfortran/mk-srk-inc.sh -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34669
[Bug libfortran/34669] libgfortran doesn't build with -pipe
--- Comment #4 from burnus at gcc dot gnu dot org 2008-01-16 09:19 --- FIXED on the trunk (4.3.0). -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34669
[Bug c++/34774] [4.1/4.2/4.3 Regression] templates, enumerations, overflow, ice
--- Comment #15 from rguenther at suse dot de 2008-01-16 09:23 ---
Subject: Re: [4.1/4.2/4.3 Regression] templates, enumerations,
overflow, ice
On Tue, 15 Jan 2008, tbptbp at gmail dot com wrote:
--- Comment #14 from tbptbp at gmail dot com 2008-01-15 20:07 ---
I keep bumping into this issue and i'd really appreciate a clue about how to
workaround for the time being.
As of the analysis, try to avoid non-dependent enum members that
double- (or more) -indirectly depends on a dependent enum member.
For example by propagating the value manually.
Like instead of
template int i
struct foo {
enum { a = i, b = a+1, c = b+2 }
do
enum { a = i, b = i+1, c = i+3 }
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34774
[Bug c/34768] [4.1/4.2/4.3 Regression] Wrong code with conditional function invocation
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-01-16 09:45 --- Subject: Bug 34768 Author: rguenth Date: Wed Jan 16 09:44:23 2008 New Revision: 131568 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131568 Log: 2008-01-16 Richard Guenther [EMAIL PROTECTED] PR c/34768 * c-typeck.c (common_pointer_type): Do not merge inconsistent type qualifiers for function types. * gcc.c-torture/execute/pr34768-1.c: New testcase. * gcc.c-torture/execute/pr34768-2.c: Likewise. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr34768-1.c trunk/gcc/testsuite/gcc.c-torture/execute/pr34768-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34768
[Bug c/34768] [4.1/4.2 Regression] Wrong code with conditional function invocation
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-01-16 09:47 --- Fixed on the trunk. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work|3.4.6 |3.4.6 4.3.0 Summary|[4.1/4.2/4.3 Regression]|[4.1/4.2 Regression] Wrong |Wrong code with conditional |code with conditional |function invocation |function invocation http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34768
[Bug c++/33819] [4.2/4.3 Regression] Miscompiled shift of C++ bitfield
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-01-16 09:47 --- Subject: Bug 33819 Author: rguenth Date: Wed Jan 16 09:46:29 2008 New Revision: 131569 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131569 Log: 2008-01-16 Richard Guenther [EMAIL PROTECTED] PR c++/33819 * typeck.c (is_bitfield_expr_with_lowered_type): Recurse for conversions to type variants. * g++.dg/torture/pr33819.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr33819.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33819
[Bug c++/33819] [4.2 Regression] Miscompiled shift of C++ bitfield
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-01-16 09:51 --- Fixed on the trunk. Unassigning. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|rguenth at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW Known to fail||4.2.3 Known to work||4.1.3 4.3.0 Summary|[4.2/4.3 Regression]|[4.2 Regression] Miscompiled |Miscompiled shift of C++|shift of C++ bitfield |bitfield| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33819
[Bug middle-end/34801] [4.3 Regression] FAIL: gcc.dg/Warray-bounds.c
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-16 10:16 --- On IRC we concluded to XFAIL this warning. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||mueller at gcc dot gnu dot ||org, hubicka at gcc dot gnu ||dot org OtherBugsDependingO||32135 nThis|| Status|UNCONFIRMED |NEW Component|regression |middle-end Ever Confirmed|0 |1 Keywords||diagnostic Priority|P3 |P2 Last reconfirmed|-00-00 00:00:00 |2008-01-16 10:16:16 date|| Summary|FAIL: gcc.dg/Warray-bounds.c|[4.3 Regression] FAIL: ||gcc.dg/Warray-bounds.c Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34801
[Bug c/34803] wrong code for dereferencing type-punned pointer
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-01-16 10:28 --- Looks good on the trunk. Also looks good for 4.2. Can you provide an executable testcase that abort()s if the miscompile happens? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34803
[Bug tree-optimization/34472] [4.3 Regression] gcc.dg/struct/wo_prof_malloc_size_var.c doesn't work
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-01-16 10:33 --- Confirmed on x86_64-unknown-linux-gnu. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet||x86_64-*-* Keywords||ice-on-valid-code Priority|P3 |P2 Last reconfirmed|-00-00 00:00:00 |2008-01-16 10:33:38 date|| Summary|gcc.dg/struct/wo_prof_malloc|[4.3 Regression] |_size_var.c doesn't work|gcc.dg/struct/wo_prof_malloc ||_size_var.c doesn't work Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34472
[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API
--- Comment #17 from rguenth at gcc dot gnu dot org 2008-01-16 10:47 --- So, this is still a P1 regression for 4.3. Ping! (I expect Linux distributors will deal with this problem, but I also expect our customers to scream bloody murder at us for this change) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
[Bug c++/33407] [4.1/4.3 Regression] C++ operator new and new expression do not change dynamic type
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-01-16 10:52 --- Ian, is there any chance you can look at this? Your fix for PR29286 could be extended to handle this as well, right? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33407
[Bug debug/34249] [4.3 Regression] FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE
--- Comment #6 from uros at gcc dot gnu dot org 2008-01-16 11:11 --- Subject: Bug 34249 Author: uros Date: Wed Jan 16 11:10:27 2008 New Revision: 131570 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131570 Log: PR debug/34249 * debug.h (dwarf2out_switch_text_section): Move declaration from ... * dwarf2out.c (dwarf2out_switch_text_section): ... here. Make function global. * final.c (final_scan_insn) [NOTE_INSN_SWITCH_TEXT_SECTIONS]: Depending on dwarf2out_do_frame, call dwarf2out_switch_text_section for DWARF2_UNWIND_INFO targets. Modified: trunk/gcc/ChangeLog trunk/gcc/debug.h trunk/gcc/dwarf2out.c trunk/gcc/final.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34249
[Bug debug/34249] [4.3 Regression] FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE
--- Comment #7 from ubizjak at gmail dot com 2008-01-16 11:15 --- Fixed for 4.3.0. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34249
[Bug target/34807] SH4 �R0_REGS� spill failure when using asm
--- Comment #2 from chrbr at gcc dot gnu dot org 2008-01-16 11:15 --- Created an attachment (id=14946) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14946action=view) fails with 4.2.2 and 4.3.0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34807
[Bug c/34808] New: ICE in prescan_insns_for_dce
Starting program: /scratch/obj.i686/br2/br.update.sh4/build_sh4/staging_dir/usr/libexec/gcc/sh4-linux-uclibcgnueabi/4.3.0/cc1 -fpreprocessed dbxout.i -quiet -dumpbase dbxout.i -auxbase-strip dbx.o -Os -version -fno-tree-dominator-opts -o /tmp/ccb7b5R5.s Failed to read a valid object file image from memory. GNU C (GCC) version 4.3.0 20080115 (experimental) (sh4-linux-uclibcgnueabi) compiled by GNU C version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21), GMP version 4.2.2, MPFR version 2.3.0-p4. warning: GMP header version 4.2.2 differs from library version 4.2.1. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: caac816702a5933f767e8f9443d577b8 Program received signal SIGSEGV, Segmentation fault. prescan_insns_for_dce (fast=1 '\001') at /scratch/obj.i686/br2/br.update.sh4/toolchain_build_sh4/gcc-4.3.0/gcc/dce.c:410 410 if (INSN_P (insn)) (gdb) bt #0 prescan_insns_for_dce (fast=1 '\001') at /scratch/obj.i686/br2/br.update.sh4/toolchain_build_sh4/gcc-4.3.0/gcc/dce.c:410 #1 0x0867d858 in rest_of_handle_fast_dce () at /scratch/obj.i686/br2/br.update.sh4/toolchain_build_sh4/gcc-4.3.0/gcc/dce.c:722 #2 0x0867dfba in run_fast_df_dce () at /scratch/obj.i686/br2/br.update.sh4/toolchain_build_sh4/gcc-4.3.0/gcc/dce.c:830 #3 0x0815ab65 in df_lr_local_finalize (all_blocks=0x8f8872c) at /scratch/obj.i686/br2/br.update.sh4/toolchain_build_sh4/gcc-4.3.0/gcc/df-problems.c:1022 #4 0x08158dc1 in df_analyze_problem (dflow=0x89d7e70, blocks_to_consider=0x8f8872c, postorder=0x8d08b18, n_blocks=194) at /scratch/obj.i686/br2/br.update.sh4/toolchain_build_sh4/gcc-4.3.0/gcc/df-core.c:1065 #5 0x08158ff3 in df_analyze () at /scratch/obj.i686/br2/br.update.sh4/toolchain_build_sh4/gcc-4.3.0/gcc/df-core.c:1155 #6 0x0834d970 in schedule_insns () at /scratch/obj.i686/br2/br.update.sh4/toolchain_build_sh4/gcc-4.3.0/gcc/sched-rgn.c:2939 #7 0x0834de7b in rest_of_handle_sched () at /scratch/obj.i686/br2/br.update.sh4/toolchain_build_sh4/gcc-4.3.0/gcc/sched-rgn.c:3164 #8 0x082de2df in execute_one_pass (pass=0x8809fe0) at /scratch/obj.i686/br2/br.update.sh4/toolchain_build_sh4/gcc-4.3.0/gcc/passes.c:1118 #9 0x082de4e7 in execute_pass_list (pass=0x8809fe0) at /scratch/obj.i686/br2/br.update.sh4/toolchain_build_sh4/gcc-4.3.0/gcc/passes.c:1171 #10 0x082de4fa in execute_pass_list (pass=0x8809440) at /scratch/obj.i686/br2/br.update.sh4/toolchain_build_sh4/gcc-4.3.0/gcc/passes.c:1172 #11 0x083e1a8c in tree_rest_of_compilation (fndecl=0xb7382e80) at /scratch/obj.i686/br2/br.update.sh4/toolchain_build_sh4/gcc-4.3.0/gcc/tree-optimize.c:404 #12 0x085b4f38 in cgraph_expand_function (node=0xb7327300) at /scratch/obj.i686/br2/br.update.sh4/toolchain_build_sh4/gcc-4.3.0/gcc/cgraphunit.c:1152 #13 0x085b750e in cgraph_optimize () at /scratch/obj.i686/br2/br.update.sh4/toolchain_build_sh4/gcc-4.3.0/gcc/cgraphunit.c:1215 #14 0x0805cefc in c_write_global_declarations () at /scratch/obj.i686/br2/br.update.sh4/toolchain_build_sh4/gcc-4.3.0/gcc/c-decl.c:8077 #15 0x08377010 in do_compile () at /scratch/obj.i686/br2/br.update.sh4/toolchain_build_sh4/gcc-4.3.0/gcc/toplev.c:1055 #16 0x083777e7 in toplev_main (argc=13, argv=0xbff46414) at /scratch/obj.i686/br2/br.update.sh4/toolchain_build_sh4/gcc-4.3.0/gcc/toplev.c:2277 #17 0x080df082 in main (argc=Cannot access memory at address 0x1 ) at /scratch/obj.i686/br2/br.update.sh4/toolchain_build_sh4/gcc-4.3.0/gcc/main.c:35 (gdb) p *insn Cannot access memory at address 0x0 (gdb) c Continuing. dbxout.i: In function 'dbxout_symbol_location': dbxout.i:21344: 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. Program exited with code 04. Reducing. -- Summary: ICE in prescan_insns_for_dce Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, build Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aldot at gcc dot gnu dot org GCC build triplet: i386-linux-gnu GCC host triplet: sh4-linux-uclibcgnueabi GCC target triplet: sh4-linux-uclibcgnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34808
[Bug c++/34809] New: Internal error while building loki-library 0.1.6
While building the Loki C++ library (http://loki-lib.sourceforge.net/), an internal error is generated: -- quote start -- gmake[2]: Entering directory `/home/duplaina/src/loki-0.1.6/test/ScopeGuard' g++ -Wall -Wold-style-cast -Wundef -Wsign-compare -Wconversion -Wpointer-arith -pedantic -g -O2 -ffriend-injection -I../../include -DNDEBUG -c -o main.o main.cpp main.cpp: In member function 'void User::AddFriendGuardedMacros(User)': main.cpp:197: internal compiler error: in calc_dfs_tree, at dominance.c:373 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. gmake[2]: *** [main.o] Error 1 gmake[2]: Leaving directory `/home/duplaina/src/loki-0.1.6/test/ScopeGuard' gmake[1]: *** [ScopeGuard] Error 2 gmake[1]: Leaving directory `/home/duplaina/src/loki-0.1.6/test' gmake: *** [check] Error 2 -- quote end -- Note: in order to get it to build this far, it's necessary to change include/loki/SmartPtr.h so the reference from #include stdint.h is tr1/stdint.h. -- Summary: Internal error while building loki-library 0.1.6 Product: gcc Version: 4.2.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: trojanfoe at hotmail dot com 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=34809
[Bug c++/34810] New: G++ accepts wrong code
Hi,
G++ (gcc version 4.3.0 20080104 (experimental) (GCC)) accepts the following
code that Comeau rejects:
template typename T
struct Foo
{
void bar ()
{
typename FooT::Foo ();
}
};
--
Summary: G++ accepts wrong code
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: v dot haisman at sh dot cvut dot cz
GCC build triplet: i386-portbld-freebsd6.2
GCC host triplet: i386-portbld-freebsd6.2
GCC target triplet: i386-portbld-freebsd6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34810
[Bug c++/34103] [4.3 regression] ICE with invalid variadic template functions
--- Comment #7 from ubizjak at gmail dot com 2008-01-16 11:58 --- (In reply to comment #6) Fixed in mainline Not yet: FAIL: g++.dg/cpp0x/vt-34103.C (internal compiler error) FAIL: g++.dg/cpp0x/vt-34103.C (test for excess errors) /home/uros/gcc-svn/trunk/gcc/testsuite/g++.dg/cpp0x/vt-34103.C:7: note: 'T' /home/uros/gcc-svn/trunk/gcc/testsuite/g++.dg/cpp0x/vt-34103.C:7: internal compiler error: canonical types differ for identical types Aexpression error and Aexpression error Please submit a full bug report, -- ubizjak at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Priority|P4 |P3 Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34103
[Bug c++/23257] Incorrect exception-handling behavior with references
--- Comment #3 from chris dot rimmer at antixlabs dot com 2008-01-16 12:08 --- I've just encountered the same issue. My reading of the standard says that it is a bug. 15.3 [except.handle] paragraph 3 A handler is a match for an exception object of type E if - The handler is of type cv T or cv T and [...] - the handler is of type cv T or cv T and [...] - the handler is of type cv1 T* cv2 and E is a pointer type that can be converted to the type of the handler by [...] [...] Note the lack of or cv1 T* cv2 in the third list item. Interestingly, the document The Exception Handling ABI for the ARM Architecture (http://infocenter.arm.com/help/topic/com.arm.doc.ihi0038a/IHI0038A_ehabi.pdf) defines (in 8.4.2 - Personality routine helper functions) a function __cxa_type_match which takes an argument 'bool is_reference_type'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23257
[Bug c++/34811] New: Classes without attributes declared as const need initializer.
The appeded code does not compile without errors:
(Verified on avr-gcc (gcc version 4.2.2)
$ avr-gcc -Wall c++_trial_1.cpp
c++_trial_1.cpp:29: error: uninitialized const 'sM'
Using Visual Studio 2005 Express the same code compiles on the highest
warninglevel without warnings or errors.
#include stdio.h
unsigned char PORTB;
unsigned char PORTC;
class port_b
{
protected:
inline void setPB0( void ) { PORTB |= (unsigned char) (10);};
inline void resetPB0( void ) { PORTB = (unsigned char) ~(10);};
};
class port_c
{
protected:
inline void setPC0( void ) { PORTC |= (unsigned char) (10);};
inline void resetPC0( void ) { PORTC = (unsigned char) ~(10);};
} ;
class signalManager
: protected port_b,
protected port_c
{
public:
inline void alarmLedOn( void ) {port_b::resetPB0();};
inline void alarmLedOff( void ) {port_b::setPB0();};
} const sM ;
int main( void )
{
printf(Port B %d\n, PORTB);
((signalManager)sM).alarmLedOff();
printf(Port B %d\n, PORTB);
((signalManager) sM).alarmLedOn();
printf(Port B %d\n, PORTB);
return 0;
}
--
Summary: Classes without attributes declared as const need
initializer.
Product: gcc
Version: 4.2.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: olof dot tangrot at telia dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34811
[Bug c++/34778] terminate called after throwing an instance of
--- Comment #6 from tkiernan at gmail dot com 2008-01-16 12:29 --- Created an attachment (id=14947) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14947action=view) TestCase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34778
[Bug c++/34778] terminate called after throwing an instance of
--- Comment #7 from tkiernan at gmail dot com 2008-01-16 12:32 --- (From update of attachment 14947) Attached is the source code and binary - issue is on gcc4.1.1 Linux redhat4.5, IBM ppc64. It aborts when tries to rethrow exception across shared libs. Execute ./main -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34778
[Bug rtl-optimization/25609] too agressive printf optimization
--- Comment #22 from manu at gcc dot gnu dot org 2008-01-16 12:36 --- (In reply to comment #21) (In reply to comment #20) Anyway, if you really want to believe that printf(%s\n,s) and puts(s) should not have the same effect for defined behaviour, then we will have to agree to disagree. That's confused, what is being discussed is undefined behavior X optimization trusting it. No, if we follow your reasoning, as you repeat constantly, It is not undefined, per glibc. Still, the manpage for puts() says output of characters and strings, while the one for printf() says formatted output conversion. puts() just sends a string to stdout, printf() converts data into their string representation. So I agree to disagree about the expectation on what they do about NULL: puts() should do nothing or merely return error, while printf() *could* convert or otherwise print a string representation of it. Finally, we agree about something. :-) Anyway, this has little to do with this bug. This is my personal opinion on how glic could fix if they really wanted. I guess other GCC developers think: There is nothing to fix, expecting something from undefined behaviour is wrong and the optimisation is valid for all defined cases. Given the impasse, and given Glibc defines what it does, I understand the next correct thing for someone who cares to do, is to report a bug on GCC about this issue on any specific distributions using GCC together with Glibc. What you want us to do? We should avoid optimising printf(%s\n, s) to puts(s) just because s may be NULL? So, in your opinion, we should punish people that don't rely on printf(%s\n, NULL) being defined, and defined as something different as puts(NULL)? Sorry, we disagree. You are welcome to waste your (and others people) time reporting duplicated bugs. We will point them to this discussion. I think there is far enough information here and, in particular, in http://sourceware.org/bugzilla/show_bug.cgi?id=5618 , for anyone to make their own opinion about the issue. If distributions want to patch GCC or use -fno-builtin-printf by default, they are allow to do it. Good luck with that. Please, I am sure you are not that kind of internet character that needs to have the last word on everything, so accept that this is closed. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25609
[Bug middle-end/31309] [4.1/4.2 regression] reads/writes past end of structure
--- Comment #23 from ebotcazou at gcc dot gnu dot org 2008-01-16 12:26 --- Not knowing the gcc code in question, I can't comment on how much potential regression risk this fix will introduce. Assuming it's safe enough to apply without worry to other releases, I'd hope this would also be applied also to gcc-4.2 . OK, I can backport it to the 4.2 branch if no maintainers disagree. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-01-03 17:06:20 |2008-01-16 12:26:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31309
[Bug middle-end/34801] [4.3 Regression] FAIL: gcc.dg/Warray-bounds.c
--- Comment #2 from dominiq at lps dot ens dot fr 2008-01-16 12:56 --- Subject: Re: [4.3 Regression] FAIL: gcc.dg/Warray-bounds.c On IRC we concluded to XFAIL this warning. Could the relevant parts of the IRC be added to this PR? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34801
[Bug c++/34103] [4.3 regression] ICE with invalid variadic template functions
--- Comment #8 from dgregor at gcc dot gnu dot org 2008-01-16 12:58 --- I'm unable to reproduce this failure now. What platform are you on and what configure flags did you use? -- dgregor at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34103
[Bug c++/34774] [4.1/4.2/4.3 Regression] templates, enumerations, overflow, ice
--- Comment #16 from tbptbp at gmail dot com 2008-01-16 13:04 --- Much helpful, many thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34774
[Bug rtl-optimization/34808] ICE in prescan_insns_for_dce
--- Comment #1 from aldot at gcc dot gnu dot org 2008-01-16 13:21 --- Created an attachment (id=14948) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14948action=view) slightly reduced testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34808
[Bug c++/34810] accepts invalid dependent(?) type in template class method
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-16 13:26 ---
EDG rejects this with
t.C(6): error: class template FooT has no member Foo
typename FooT::Foo ();
^
G++ accepts this even if you instantiate Foo. G++ also accepts
template typename T
struct Foo
{
void bar ()
{
typename FooT::Foox ();
}
};
but rejects that once you instantiate Foo.
template struct Fooint;
It looks like EDG does not treat FooT::Fox as dependent?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||accepts-invalid
Last reconfirmed|-00-00 00:00:00 |2008-01-16 13:26:36
date||
Summary|G++ accepts wrong code |accepts invalid dependent(?)
||type in template class
||method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34810
[Bug middle-end/33195] [4.2 Regression] ICE: calc_dfs_tree, at dominance.c:374
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-01-16 13:28 --- *** This bug has been marked as a duplicate of 31947 *** -- 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=33195
[Bug middle-end/31947] [4.2 Regression] ICE in calc_dfs_tree, at dominance.c:374
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-01-16 13:28 --- *** Bug 33195 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||mi at aldan dot algebra dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31947
[Bug c++/34809] Internal error while building loki-library 0.1.6
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-16 13:30 --- Probably a dup of PR31947. Hard to say without preprocessed source. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34809
[Bug c++/34811] Classes without attributes declared as const need initializer.
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-16 13:32 --- EDG says: t.C(27): error: const variable sM requires an initializer -- class signalManager has no explicitly declared default constructor } const sM ; ^ compilation aborted for t.C (code 2) which is correct. Try } const sM = signalManager(); -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34811
[Bug middle-end/34812] New: [4.3 Regression] gcc.dg/Warray-bounds.c
Revision 131565 generates: FAIL: gcc.dg/Warray-bounds.c (test for warnings, line 59) FAIL: gcc.dg/Warray-bounds.c (test for warnings, line 65) FAIL: gcc.dg/Warray-bounds.c (test for warnings, line 66) Revision 131501 is OK. -- Summary: [4.3 Regression] gcc.dg/Warray-bounds.c Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34812
[Bug c++/34103] [4.3 regression] ICE with invalid variadic template functions
--- Comment #10 from ubizjak at gmail dot com 2008-01-16 13:40 --- (In reply to comment #8) I'm unable to reproduce this failure now. What platform are you on and what configure flags did you use? Target: i686-pc-linux-gnu Configured with: ../gcc-svn/trunk/configure --with-mpfr=/usr/local --enable-languages=c,c++,fortran gcc version 4.3.0 20080116 (experimental) [trunk revision 131569] (GCC) -- ubizjak at gmail dot com changed: What|Removed |Added Status|WAITING |NEW Last reconfirmed|2007-12-20 21:04:26 |2008-01-16 13:40:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34103
[Bug c/34668] [4.3 Regression] ICE in find_compatible_field with -combine
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-01-16 13:41 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34668
[Bug c/34668] [4.3 Regression] ICE in find_compatible_field with -combine
--- Comment #11 from rguenth at gcc dot gnu dot org 2008-01-16 13:42 --- Subject: Bug 34668 Author: rguenth Date: Wed Jan 16 13:41:13 2008 New Revision: 131572 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131572 Log: 2008-01-16 Jakub Jelinek [EMAIL PROTECTED] Richard Guenther [EMAIL PROTECTED] PR c/34668 * gimplify.c (fold_indirect_ref_rhs): Rename to ... (gimple_fold_indirect_ref_rhs): ... this. (gimple_fold_indirect_ref): New function with foldings that preserve lvalueness. (gimplify_modify_expr_rhs): Call gimple_fold_indirect_ref_rhs. * tree-flow.h (gimple_fold_indirect_ref): Declare. * tree-inline.c (copy_body_r): Use gimple_fold_indirect_ref to fold an INDIRECT_REF, fall back to the old use of fold_indirect_ref_1. * gcc.dg/pr34668-1.c: New test. * gcc.dg/pr34668-2.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/pr34668-1.c trunk/gcc/testsuite/gcc.dg/pr34668-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-flow.h trunk/gcc/tree-inline.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34668
[Bug c++/34103] [4.3 regression] ICE with invalid variadic template functions
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-01-16 13:17 --- I also see those two ICEs on x86_64-unknown-linux-gnu. P2 as this shows in testresults on a primary platform. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34103
[Bug middle-end/34801] [4.3 Regression] FAIL: gcc.dg/Warray-bounds.c
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-01-16 14:01 --- *** Bug 34812 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34801
[Bug middle-end/34812] [4.3 Regression] gcc.dg/Warray-bounds.c
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-16 14:01 --- *** This bug has been marked as a duplicate of 34801 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE Summary|[4.3 Regression]|[4.3 Regression] |gcc.dg/Warray-bounds.c |gcc.dg/Warray-bounds.c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34812
[Bug fortran/34672] [4.3 Regression] .mod file misses renamed, USEd symbol
--- Comment #6 from kloedej at knmi dot nl 2008-01-16 14:11 --- Dear people, this comment is just to let you know that the problem is also solved on my side now. My software compiles and runs again as expected. thanks a lot for your effort and fast response. Jos de Kloe -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34672
[Bug c++/34811] Classes without attributes declared as const need initializer.
--- Comment #2 from olof dot tangrot at telia dot com 2008-01-16 14:16 --- I know about that. The class don't need a contructor, it does not have anything that needs to be assigned upon creation. Why should the compiler link in code that does not do anything? I eats memory. Surely that can be resolved at compile time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34811
[Bug tree-optimization/34769] [4.3 Regression] gcc.dg/vect/no-vfa-pr29145.c
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-01-16 14:38 --- Mine. -- 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|2008-01-13 16:45:47 |2008-01-16 14:38:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34769
[Bug tree-optimization/34769] [4.3 Regression] gcc.dg/vect/no-vfa-pr29145.c
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet||i?86-*-* (HWI64) Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34769
[Bug c++/34810] accepts invalid dependent(?) type in template class method
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-01-16 14:53 --- There is a defect report about what is a dependent name. The DR causes some things to be non dependent and not which were in the original standard and is weird as it turns somestuff which really should be dependent into non dependent. I forgot the DR number. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34810
[Bug c++/34778] terminate called after throwing an instance of
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-01-16 15:01 --- This testcase does not work even without shared libraries: terminate called after throwing an instance of 'char const*' Abort -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34778
[Bug c++/34811] Classes without attributes declared as const need initializer.
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-01-16 15:05 --- (In reply to comment #2) I know about that. The class don't need a contructor, it does not have anything that needs to be assigned upon creation. Why should the compiler link in code that does not do anything? Because it is a const. Visual Studio is no where near standards complaint and you have to be explict at enabling its standards complaint mode too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34811
[Bug c++/34103] [4.3 regression] ICE with invalid variadic template functions
--- Comment #11 from pinskia at gcc dot gnu dot org 2008-01-16 15:07 --- I see the failure on i386-apple-darwin8.11.1 also. (In reply to comment #8) I'm unable to reproduce this failure now. What platform are you on and what configure flags did you use? Make sure you did not turn off checking. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34103
[Bug fortran/33375] [4.3 Regression] ICE (segfault) gfortran.dg/common_6.f90
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-01-16 15:25 --- I still see it on x86_64-linux. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||error-recovery Priority|P3 |P5 Summary|ICE (segfault) |[4.3 Regression] ICE |gfortran.dg/common_6.f90|(segfault) ||gfortran.dg/common_6.f90 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33375
[Bug fortran/34813] New: ICE on incorrect type constructor (fold-const.c (fold_convert):2629)
$ cat ice.f90 MODULE kd_kd_tree_type TYPE :: kd_tree_node TYPE(kd_tree_node_private), POINTER :: p END TYPE TYPE :: kd_tree_node_private INTEGER :: dummy END TYPE TYPE :: kd_tree TYPE(kd_tree_node) :: root END TYPE CONTAINS SUBROUTINE kd_tree_init_default(this) TYPE(kd_tree), INTENT(inout) :: this ! this = kd_tree(kd_tree_node(null())) ! correct this = kd_tree(null()) ! ICE END SUBROUTINE END MODULE $ gfortran-svn ice.f90 ice.f90: In function 'kd_tree_init_default': ice.f90:15: internal compiler error: in fold_convert, at fold-const.c:2629 Please submit a full bug report, $ gfortran-svn -v gcc version 4.3.0 20080107 (experimental) Backtrace: (gdb) bt #0 fancy_abort (file=0x87f3ec4 ../../../svn/gcc/gcc/fold-const.c, line=2629, function=0x87f8472 fold_convert) at ../../../svn/gcc/gcc/diagnostic.c:659 #1 0x0824efd1 in fold_convert (type=0xb7d0f548, arg=0xb7cd39d8) at ../../../svn/gcc/gcc/fold-const.c:2629 #2 0x080f378b in gfc_trans_subcomponent_assign (dest=0xb7cde078, cm=0x89ba8d0, expr=0x89bb1c8) at ../../../svn/gcc/gcc/fortran/trans-expr.c:3354 #3 0x080f396a in gfc_trans_structure_assign (dest=0xb7cdd108, expr=value optimized out) at ../../../svn/gcc/gcc/fortran/trans-expr.c:3414 #4 0x080f3b8b in gfc_conv_structure (se=0xbfec283c, expr=0x89bb760, init=0) at ../../../svn/gcc/gcc/fortran/trans-expr.c:3441 #5 0x080ef85c in gfc_conv_expr (se=0xbfec283c, expr=0x89bb760) at ../../../svn/gcc/gcc/fortran/trans-expr.c:3563 #6 0x080f0ab0 in gfc_trans_assignment_1 (expr1=0x89bb100, expr2=0x89bb760, init_flag=0 '\0') at ../../../svn/gcc/gcc/fortran/trans-expr.c:4293 #7 0x080f0c4c in gfc_trans_assignment (expr1=0x89bb100, expr2=0x89bb760, init_flag=72 'H') at ../../../svn/gcc/gcc/fortran/trans-expr.c:4440 #8 0x080f17e1 in gfc_trans_assign (code=0x89bb7d0) at ../../../svn/gcc/gcc/fortran/trans-expr.c:4452 #9 0x080cfe90 in gfc_trans_code (code=0x89bb7d0) at ../../../svn/gcc/gcc/fortran/trans.c:994 #10 0x080e7cc2 in gfc_generate_function_code (ns=0x89ba920) at ../../../svn/gcc/gcc/fortran/trans-decl.c:3298 #11 0x080cd01a in gfc_generate_module_code (ns=0x89b9e20) at ../../../svn/gcc/gcc/fortran/trans.c:1214 #12 0x0809f219 in gfc_parse_file () at ../../../svn/gcc/gcc/fortran/parse.c:3391 #13 0x080c8985 in gfc_be_parse_file (set_yydebug=0) at ../../../svn/gcc/gcc/fortran/f95-lang.c:260 #14 0x0836c6d4 in toplev_main (argc=2, argv=0xbfec2ca4) at ../../../svn/gcc/gcc/toplev.c:1042 #15 0x08114b1f in main (argc=16, argv=0x0) at ../../../svn/gcc/gcc/main.c:35 This might be related to (or be a dupe of) PR33295. -- Summary: ICE on incorrect type constructor (fold-const.c (fold_convert):2629) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dfranke at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34813
[Bug target/34814] New: SDmode function args not passed according to ABI specification
Currently, SDmode (_Decimal32) types are not passed to and returned from functions in FP registers as mandated by the ABI. Instead, they are passed via the integer registers. This bugzilla will be used for tracking my work on fixing this. -- Summary: SDmode function args not passed according to ABI specification Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: bergner at gcc dot gnu dot org ReportedBy: bergner at gcc dot gnu dot org GCC build triplet: powerpc64-linux GCC host triplet: powerpc64-linux GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34814
[Bug tree-optimization/34769] [4.3 Regression] gcc.dg/vect/no-vfa-pr29145.c
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-01-16 16:01 --- Subject: Bug 34769 Author: rguenth Date: Wed Jan 16 16:00:17 2008 New Revision: 131573 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131573 Log: 2008-01-16 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/34769 * tree-data-ref.c (initialize_matrix_A): Revert fix for PR34458. * tree.c (int_cst_value): Instead make this function more permissive in what it accepts as valid input. Document this function always sign-extends the value. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-data-ref.c trunk/gcc/tree.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34769
[Bug debug/34249] [4.3 Regression] FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE
--- Comment #8 from hjl at lucon dot org 2008-01-16 16:16 --- It isn't fixed. The error went from as to ld: /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.dg/tree-prof/bb-reorg.c -O2 -freorder-blocks-and-partition -fprofile-use -D_PROFILE_USE -fno-show-column -lm -o /export/build/gnu/gcc/build-x86_64-linux/gcc/testsuite/gcc/bb-reorg.x02 (timeout = 300) /usr/local/bin/ld: error in /tmp/ccoylUaf.o(.eh_frame); no .eh_frame_hdr table will be created.^M output is: /usr/local/bin/ld: error in /tmp/ccoylUaf.o(.eh_frame); no .eh_frame_hdr table will be created.^M FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE I am using the Linux binutils 2.18.50.0.3. -- hjl at lucon dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34249
[Bug rtl-optimization/31396] Inline code performance much worse than out-of-line
--- Comment #10 from hubicka at gcc dot gnu dot org 2008-01-16 16:32 --- Subject: Bug 31396 Author: hubicka Date: Wed Jan 16 16:32:05 2008 New Revision: 131576 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131576 Log: PR rtl-optimization/31396 * regstat.c (regstat_bb_compute_ri): Compute FREQ_CALLS_CROSSED. * cfg.c (dump_reg_info): Print it. * regs.h (struct reg_info_t): add freq_calls_crossed. (REG_FREQ_CALLS_CROSSED): New macro. * global.c (global_alloc): Compute freq_calls_crossed for allocno. (find_reg): Update call of CALLER_SAVE_PROFITABLE. * regmove.c (optimize_reg_copy_1, optimize_reg_copy_2, fixup_match_2, regmove_optimize): Update call crossed frequencies. * local-alloc.c (struct qty): Add freq_calls_crossed. (alloc_qty): Copute freq_calls_crossed. (update_equiv_regs, combine_regs): Update REG_FREQ_CALLS_CROSSED. (find_free_reg): Update call of CALLER_SAVE_PROFITABLE. * ra.h (struct allocno): Add freq_calls_crossed. Modified: trunk/gcc/ChangeLog trunk/gcc/cfg.c trunk/gcc/global.c trunk/gcc/local-alloc.c trunk/gcc/ra.h trunk/gcc/regmove.c trunk/gcc/regs.h trunk/gcc/regstat.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31396
[Bug rtl-optimization/31396] Inline code performance much worse than out-of-line
--- Comment #11 from hubicka at gcc dot gnu dot org 2008-01-16 16:33 --- Fixed on mainline. -- hubicka at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31396
[Bug fortran/34805] defined assignment not allowed to vector subscripted array
--- Comment #2 from burnus at gcc dot gnu dot org 2008-01-16 16:34 ---
Found the relevant part in the Fortran standard:
Fortran 2003: 12.4.1.2 Actual arguments associated with dummy data objects
If the actual argument is an array section having a vector subscript, the
dummy argument is not definable and shall not have the INTENT (OUT), INTENT
(INOUT), VOLATILE, or ASYNCHRONOUS attributes.
gfortran has this check - but it is not triggered for assignment(=) - or it
happens later than the mismatch.
It would helpful, if you could find the interpretation or re-check the test
case.
(There is a to-be corrected typo:
@@ -2001,7 +2025,7 @@ compare_actual_formal (gfc_actual_arglis
{
if (where)
gfc_error (Array-section actual argument with vector subscripts
- at %L is incompatible with INTENT(IN), INTENT(INOUT)
+ at %L is incompatible with INTENT(OUT), INTENT(INOUT)
or VOLATILE attribute of the dummy argument '%s',
a-expr-where, f-sym-name);
return 0;
)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34805
[Bug tree-optimization/33761] non-optimal inlining heuristics pessimizes gzip SPEC score at -O3
--- Comment #11 from hubicka at gcc dot gnu dot org 2008-01-16 16:46 --- Last time I looked into it, it was code alignment affected by inlining in the string matching loop (longest_match). This code is very atypical, since the internal loop comparing strings is hand unrolled but it almost never rolls, since the compressed strings tends to be all different. GCC mispredicts this moving some stuff out of the loop and bb-reorder aligns the code in a way that the default path not doing the loop is jumping pretty far hurting decode bandwidth of K8 especially because the jumps are hard to predict. I don't see any direct things in the code heuristics can use to realize that the loop is not rooling, except for special casing the particular benchmark. FDO scores of gzip are not doing that bad, but there is still gap relative to ICC (even archaic version of it running 32bit compared to 64bit GCC). http://www.suse.de/~gcctest/SPEC-britten/CINT/sandbox-britten-FDO/index.html It would be nice to convince gzip/zlibc/bzip2 people to use profiling by default in the build process - those packages are ideal targets. But since core is not that much sensitive to code alignment and nuber of jumps as K8, perhaps there are extra problems demonstrated by this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33761
[Bug other/2678] gcc/g++ should stick compilation options into the .o file
--- Comment #21 from tsarkov at cs dot man dot ac dot uk 2008-01-16 17:19 --- (In reply to comment #20) Changing to NEW based on http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00858.html Shouldn't the PR be closed now, after committing the patch from http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00211.html ? -- tsarkov at cs dot man dot ac dot uk changed: What|Removed |Added CC||tsarkov at cs dot man dot ac ||dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2678
[Bug debug/34249] [4.3 Regression] FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE
--- Comment #9 from ubizjak at gmail dot com 2008-01-16 17:25 --- (In reply to comment #8) It isn't fixed. The error went from as to ld: Here is my log: Executing on host: /home/uros/gcc-build-all/gcc/xgcc -B/home/uros/gcc-build-all/gcc/ /home/uros/gcc-svn/trunk/gcc/ testsuite/gcc.dg/tree-prof/bb-reorg.c -O2 -freorder-blocks-and-partition -fprofile-use -D_PROFILE_USE -fno-show- column -lm -o /home/uros/gcc-build-all/gcc/testsuite/gcc/bb-reorg.x02 (timeout = 300) PASS: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE Setting LD_LIBRARY_PATH to :/home/uros/gcc-build-all/gcc:/home/uros/gcc-build-all/gcc/32::/home/uros/gcc-build-all /gcc:/home/uros/gcc-build-all/gcc/32:/usr/local/lib64:/usr/lib/xorg:/usr/lib64/xorg PASS: gcc.dg/tree-prof/bb-reorg.c execution,-fprofile-use -D_PROFILE_USE testcase /home/uros/gcc-svn/trunk/gcc/testsuite/gcc.dg/tree-prof/tree-prof.exp completed in 2 seconds GNU ld version 2.17.50.0.3-6 20060715 The difference between non-working (.s_) and working (.s) asm dump is: --- bb-reorg.s_ 2008-01-16 18:22:01.0 +0100 +++ bb-reorg.s 2008-01-16 18:22:40.0 +0100 @@ -147,9 +147,12 @@ .LASFDE3: .long .LASFDE3-.Lframe1 .long .LFB15 - .long .LFE15-.LFB15 + .long .LHOTB1 + .long .LHOTE1-.LHOTB1 + .long .LCOLDB1 + .long .LCOLDE1-.LCOLDB1 .uleb128 0x0 .align 8 .LEFDE3: - .ident GCC: (GNU) 4.3.0 20080107 (experimental) [trunk revision 131375] + .ident GCC: (GNU) 4.3.0 20080114 (experimental) [trunk revision 131520] .section.note.GNU-stack,,@progbits Is the problem with binutils here? -- ubizjak at gmail dot com changed: What|Removed |Added Status|REOPENED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34249
[Bug fortran/34784] [Rgression 4.2, 4.3] implicit character(s) hides type of selected_int_kind intrinsic
--- Comment #2 from pault at gcc dot gnu dot org 2008-01-16 17:33 --- This regression enters between 4.1/20050803 and 4.2/20061221. gfc_check_constructor_type is applying the wrong type, because the intrinsic has not been resolved. (This is called from gfc_match_init_expr via gfc_resolve_expr.). I'll continue to investigate but think that resolution and check_init_expr are occurring in the wrong order. Cheers Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Summary|implicit character(s) hides |[Rgression 4.2, 4.3] |type of selected_int_kind |implicit character(s) hides |intrinsic |type of selected_int_kind ||intrinsic http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34784
[Bug c++/13717] duplicated parameter name not caught ?
--- Comment #8 from tsarkov at cs dot man dot ac dot uk 2008-01-16 17:39 --- This is fixed in current mainline GCC (as per http://gcc.gnu.org/gcc-4.3/porting_to.html). -- tsarkov at cs dot man dot ac dot uk changed: What|Removed |Added CC||tsarkov at cs dot man dot ac ||dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13717
[Bug debug/34249] [4.3 Regression] FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE
--- Comment #10 from ubizjak at gmail dot com 2008-01-16 17:44 --- (In reply to comment #9) .LASFDE3: .long .LASFDE3-.Lframe1 .long .LFB15 - .long .LFE15-.LFB15 + .long .LHOTB1 + .long .LHOTE1-.LHOTB1 + .long .LCOLDB1 + .long .LCOLDE1-.LCOLDB1 .uleb128 0x0 .align 8 The fact that both dumps contain .long .LFB15 is a bit suspicious. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34249
[Bug target/34814] SDmode function args not passed according to ABI specification
--- Comment #1 from bergner at gcc dot gnu dot org 2008-01-16 17:51 --- I'll be posting a proposed patch today or tomorrow. The patch will allow us to be binary compatible with XLC which is producing binaries that follow the ABI. There have been some reload issues which have made this all difficult to implement, but I think I've done a fair job trying to keep the changes localized to the rs6000 port. -- bergner at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |blocker Keywords||ABI http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34814
[Bug debug/34249] [4.3 Regression] FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE
--- Comment #11 from hjl at lucon dot org 2008-01-16 18:23 --- (In reply to comment #9) GNU ld version 2.17.50.0.3-6 20060715 Your linker doesn't issue the error since it is too old. See http://sourceware.org/bugzilla/show_bug.cgi?id=4454 -- hjl at lucon dot org changed: What|Removed |Added Last reconfirmed|2008-01-14 17:16:25 |2008-01-16 18:23:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34249
[Bug debug/34249] [4.3 Regression] FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE
--- Comment #12 from ubizjak at gmail dot com 2008-01-16 18:25 --- Created an attachment (id=14949) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14949action=view) Patch to fix issue in Comment #8 H.J, could you test if attached patch fixes the problem from Comment #8? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34249
[Bug target/34815] New: [4.1 4.2] endless loop while trying to compile 2.6.23-rc4
[forwarded from http://bugs.debian.org/440287] seen with current 4.1 and 4.2 branches, not seen on the trunk. Matthias While trying to compile the 2.6.23-rc4 snapshots from buildserver.net on hppa, gcc went in some kind of endless loop over the following command hppa64-linux-gnu-gcc-4.1 -Wp,-MD,fs/ocfs2/.alloc.o.d -nostdinc -isystem /usr/lib/gcc/hppa64-linux-gnu/4.1.3/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -fno-cse-follow-jumps -Os -pipe -mno-space-regs -mfast-indirect-calls -mdisable-fpregs -ffunction-sections -march=2.0 -mschedule=8000 -fomit-frame-pointer -fno-stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -Ifs/ocfs2 -DCATCH_BH_JBD_RACES -DMODULE -DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(alloc) -DKBUILD_MODNAME=KBUILD_STR(ocfs2) -c -o fs/ocfs2/.tmp_alloc.o fs/ocfs2/alloc.c this is for the parisc64-smp flavour, all other flavours seem to build fine. I had no time yet to investigate the differences. Building with -O0 seems to work, -O1/-O2/-Os all show the bug. -- Summary: [4.1 4.2] endless loop while trying to compile 2.6.23- rc4 Product: gcc Version: 4.1.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: debian-gcc at lists dot debian dot org GCC target triplet: hppa64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34815
[Bug target/34815] [4.1 4.2] endless loop while trying to compile 2.6.23-rc4
--- Comment #1 from debian-gcc at lists dot debian dot org 2008-01-16 18:38 --- Created an attachment (id=14950) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14950action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34815
[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API
--- Comment #18 from bkoz at gcc dot gnu dot org 2008-01-16 18:46 --- The ammount of breakage for this change is IMHO tolerable and will within the tolerances of other breakages that nobody is talking about reverting, and furthermore solutions for the API change are well documented. Certainly, the demonstrated breakage for the pre-iso header removal in fedora builds is about 8 packages, less than most of the individual FE changes in either 4.2 or 4.3. I believe there is a bit of a bias here, in that it's OK to make FE changes, but even well-documented and warned lib changes are not ok? What's up with that? I assert the right to make API changes, including removal of deprecated items. I believe my rationale in #6 has been missed by all. Please directly respond to this, and tell me why it's ok to remove flags and things like max/min in the C++FE, and not ok to remove deprecated headers in libstdc++. I am opposed to wholesale re-instatement of the pre-iso headers, and would like to close this as WONTFIX. From fedora build failure analysis, only two are important: iostream.h and fstream.h. If i am to be over-ruled on this issue, then please only reinstate these two. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API
--- Comment #19 from bkoz at gcc dot gnu dot org 2008-01-16 18:58 --- I'm asking for a libstdc++ maintainer vote on this issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API
--- Comment #20 from pinskia at gcc dot gnu dot org 2008-01-16 19:06 --- I still see people use the old deprecated headers all over the place, even in newer bug reports. So it is hard to think they will be removed any time soon. I am sorry but from a QA point of view, they should be added back because it is hard to get some folks to update their code (I should know from experience with the PS3 toolchain upgrade going from 4.0.2 to 4.1.1). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
[Bug target/34815] [4.1 4.2] endless loop while trying to compile 2.6.23-rc4
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-01-16 19:18 --- This sounds like an exact duplicate of PR 31944 which was just fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34815
[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API
--- Comment #21 from bkoz at gcc dot gnu dot org 2008-01-16 19:22 --- old deprecated headers all over the place Please give specifics, including what bug reports and what headers. Your experience is much different from my datapoint, which is Jakub building fedora with gcc-43. I see 8 fails 5118 packages, 7 iostream.h and 1 fstream.h. I still see this change as substantially less impactful than most of the FE changes since 3.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API
--- Comment #22 from pinskia at gcc dot gnu dot org 2008-01-16 19:27 --- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34778 is one example, this example just came into today. There are many more. A lot of the windows/xbox360 based games use the deprecated headers also. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API
--- Comment #23 from rguenther at suse dot de 2008-01-16 19:40 --- Subject: Re: [4.3 Regression] Revision 129442 breaks libstc++ API On Wed, 16 Jan 2008, bkoz at gcc dot gnu dot org wrote: --- Comment #21 from bkoz at gcc dot gnu dot org 2008-01-16 19:22 --- old deprecated headers all over the place Please give specifics, including what bug reports and what headers. Your experience is much different from my datapoint, which is Jakub building fedora with gcc-43. I see 8 fails 5118 packages, 7 iostream.h and 1 fstream.h. I still see this change as substantially less impactful than most of the FE changes since 3.3. I agree with that. I am inclined to just accept whatever the libstdc++ maintainers decide on. So I would suggest to gather a vote there and close this bug as WONTFIX if the consensus is to keep the current state. Thanks, Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
[Bug fortran/34816] New: logical kinds for any and all
The patch for PR 34671 created an optimization opportunity that
is currently missed.
The any and all functions with dim=1 now accept an argument that
can be any logical type. Only the lowest-order byte is used for
evaluation.
Now consider the following:
program main
logical(kind=1), dimension(2,2) :: a
logical, dimension(2) :: b
data a / .false., .true., .false., .false. /
b = any(a,dim=1)
end program main
This gets translated to
_gfortran_any_l1 (atmp.2, parm.1, C.511);
{
integer(kind=4) S.4;
S.4 = 0;
while (1)
{
if (S.4 1) goto L.1;
b[S.4] = (logical(kind=4)) (*(logical(kind=1)[2] *)
atmp.2.data)[S.4];
S.4 = S.4 + 1;
}
L.1:;
}
}
where a simple call to _gfortran_any_l4 would have been enough.
--
Summary: logical kinds for any and all
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34816
[Bug tree-optimization/34769] [4.3 Regression] gcc.dg/vect/no-vfa-pr29145.c
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-01-16 20:01 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34769
[Bug fortran/34817] New: [4.3 regression] mixed-kind any and all intrinsics with expressions
Seems I missed a case in my patch for PR 34671:
program main
real, dimension(2,2) :: a
logical, dimension(2) :: b
integer, dimension(2) :: i
equivalence (b,i)
data a /1.0, 2.0, -0.1, -0.2 /
i = 16843009 ! Initialize i to put junk into b
call random_number(a)
b = any(a0.5,dim=1)
if (b(1) .or. .not. b(2)) print *,b
i = 16843009 ! Initialize i to put junk into b
b = all(a0.5,dim=1)
if (b(1) .or. .not. b(2)) print *,b
end program main
Here's a patch (untested, because I am currently
bootstrapping):
Index: iresolve.c
===
--- iresolve.c (revision 131577)
+++ iresolve.c (working copy)
@@ -247,7 +247,10 @@ gfc_resolve_dint (gfc_expr *f, gfc_expr
void
gfc_resolve_all (gfc_expr *f, gfc_expr *mask, gfc_expr *dim)
{
+ int kind;
+
f-ts = mask-ts;
+ kind = mask-ts.kind;
if (dim != NULL)
{
@@ -260,7 +263,7 @@ gfc_resolve_all (gfc_expr *f, gfc_expr *
f-value.function.name
= gfc_get_string (PREFIX (all_%c%d), gfc_type_letter (mask-ts.type),
- mask-ts.kind);
+ kind);
}
@@ -297,7 +300,10 @@ gfc_resolve_dnint (gfc_expr *f, gfc_expr
void
gfc_resolve_any (gfc_expr *f, gfc_expr *mask, gfc_expr *dim)
{
+ int kind;
+
f-ts = mask-ts;
+ kind = mask-ts.kind;
if (dim != NULL)
{
@@ -310,7 +316,7 @@ gfc_resolve_any (gfc_expr *f, gfc_expr *
f-value.function.name
= gfc_get_string (PREFIX (any_%c%d), gfc_type_letter (mask-ts.type),
- mask-ts.kind);
+ kind);
}
--
Summary: [4.3 regression] mixed-kind any and all intrinsics
with expressions
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: tkoenig at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34817
[Bug fortran/34817] [4.3 regression] mixed-kind any and all intrinsics with expressions
-- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-16 20:03:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34817
[Bug fortran/34805] defined assignment not allowed to vector subscripted array
--- Comment #3 from dick dot hendrickson at gmail dot com 2008-01-16 20:07
---
Subject: Re: defined assignment not allowed to vector subscripted array
Why not put this one on hold for a while. I'll check some more.
There never was a
formal interpretation request. It's kind of odd, both NAG and DEC
have (had for DEC)
the SHAPE95 and neither has complained in the last 10 or so years
about this test.
My reading is that you nheed to read 7.5.1.6 to see how defined assignment is
interpreted. After you've read lines 27 to 30, then you go to
chapter 12 to see
how subroutines are called on an element-by-element basis. Malcolm Cohen's
argument long ago was that we had dueling sections. If you start at chapter 12
you'll come to the conclusion that the example is disallowed.
I'll see if I can get J3 to come to a consensus.
Dick
On 16 Jan 2008 16:34:47 -, burnus at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #2 from burnus at gcc dot gnu dot org 2008-01-16 16:34
---
Found the relevant part in the Fortran standard:
Fortran 2003: 12.4.1.2 Actual arguments associated with dummy data objects
If the actual argument is an array section having a vector subscript, the
dummy argument is not definable and shall not have the INTENT (OUT), INTENT
(INOUT), VOLATILE, or ASYNCHRONOUS attributes.
gfortran has this check - but it is not triggered for assignment(=) - or it
happens later than the mismatch.
It would helpful, if you could find the interpretation or re-check the test
case.
(There is a to-be corrected typo:
@@ -2001,7 +2025,7 @@ compare_actual_formal (gfc_actual_arglis
{
if (where)
gfc_error (Array-section actual argument with vector subscripts
- at %L is incompatible with INTENT(IN), INTENT(INOUT)
+ at %L is incompatible with INTENT(OUT), INTENT(INOUT)
or VOLATILE attribute of the dummy argument '%s',
a-expr-where, f-sym-name);
return 0;
)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34805
--- You are receiving this mail because: ---
You reported the bug, or are watching the reporter.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34805
[Bug debug/34249] [4.3 Regression] FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE
--- Comment #13 from hjl at lucon dot org 2008-01-16 20:17 --- (In reply to comment #12) Created an attachment (id=14949) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14949action=view) [edit] Patch to fix issue in Comment #8 H.J, could you test if attached patch fixes the problem from Comment #8? Yes, it works: http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg00695.html -- hjl at lucon dot org changed: What|Removed |Added Last reconfirmed|2008-01-16 18:23:05 |2008-01-16 20:17:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34249
[Bug fortran/34802] Unknown symbol name should be included in Error message
--- Comment #1 from dfranke at gcc dot gnu dot org 2008-01-16 20:29 --- Could you also add an exemplary code snippet, please? -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org GCC host triplet|2.6.22-14-generic kernel| GCC target triplet|i486-linux-gnu | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34802
[Bug bootstrap/34818] New: --with-gmp overrides --with-mpfr
From fink, I have gmp 4.1 in /sw/{lib,include}, but mpfr is ancient. I put a
new mpfr in $HOME, and tried to build with:
../gcc-4.3-20080111/configure --with-gmp=/sw --with-mpfr=$HOME
Unfortunately, that tells me that my mpfr is too old.
The order of the flags does not matter; I always get, in config.log:
gmpinc='-I/sw/include -I/Users/bhudson/include'
gmplibs='-L/sw/lib -L/Users/bhudson/lib -lmpfr -lgmp'
In other words, it's possible to update gmp and use the system mpfr, but not to
update mpfr and use the system gmp. Given that the required mpfr is much newer
(29 August 2007) than the required gmp (circa 2004), the easy fix would be to
reverse this: allow updating mpfr while leaving the system gmp in place.
--
Summary: --with-gmp overrides --with-mpfr
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: benoit dot hudson at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34818
[Bug fortran/34714] ICE-on-invalid in gfc_conv_descriptor_dtype
--- Comment #1 from dfranke at gcc dot gnu dot org 2008-01-16 20:36 --- function func2() type(bar) func2 allocate(func1%baz(1)) end function Here, func1 needs to be func2 to be correct. Confirmed. Backtrace: (gdb) bt #0 fancy_abort (file=0x87d843c ../../../gcc/gcc/fortran/trans-array.c, line=224, function=0x87d8e50 gfc_conv_descriptor_dtype) at ../../../gcc/gcc/diagnostic.c:659 #1 0x080d5811 in gfc_conv_descriptor_dtype (desc=0xb7d3c6e0) at ../../../gcc/gcc/fortran/trans-array.c:224 #2 0x080dc8d3 in gfc_array_allocate (se=0xbfd4d74c, expr=0x89ba9e0, pstat=0x0) at ../../../gcc/gcc/fortran/trans-array.c:3499 #3 0x0810768b in gfc_trans_allocate (code=0x89ba958) at ../../../gcc/gcc/fortran/trans-stmt.c:3809 #4 0x080cfb30 in gfc_trans_code (code=0x89ba958) at ../../../gcc/gcc/fortran/trans.c:1082 #5 0x080e7b52 in gfc_generate_function_code (ns=0x89ba338) at ../../../gcc/gcc/fortran/trans-decl.c:3298 #6 0x080cceaa in gfc_generate_module_code (ns=0x89b8d90) at ../../../gcc/gcc/fortran/trans.c:1214 #7 0x0809f1a9 in gfc_parse_file () at ../../../gcc/gcc/fortran/parse.c:3391 #8 0x080c8815 in gfc_be_parse_file (set_yydebug=0) at ../../../gcc/gcc/fortran/f95-lang.c:260 #9 0x0836c434 in toplev_main (argc=2, argv=0xbfd4daf4) at ../../../gcc/gcc/toplev.c:1042 #10 0x0811493f in main (argc=2097162, argv=0x0) at ../../../gcc/gcc/main.c:35 -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-16 20:36:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34714
[Bug c/34819] New: incomplete enum's assert
$ cat t.c
enum e ve;
void f0 (int i)
{
ve + i;
}
$ gcc -c t.c
enum.c: In function f0:
enum.c:6: internal compiler error: in create_tmp_var, at gimplify.c:368
Please submit a full bug report,
with preprocessed source if appropriate.
Works in c++:
/tmp/t.c:1: error: use of enum e without previous declaration
/tmp/t.c:1: error: invalid type in declaration before ; token
Also fails in 4.3.0 20070713.
--
Summary: incomplete enum's assert
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34819
[Bug c/34819] incomplete enum's assert
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-16 20:45 --- *** This bug has been marked as a duplicate of 32295 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34819
[Bug c/32295] [4.1 Regression] An invalid c code causes an ICE in create_tmp_var, at gimplify.c:489
--- Comment #10 from pinskia at gcc dot gnu dot org 2008-01-16 20:45 --- *** Bug 34819 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||mrs at apple dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32295
[Bug c/34819] incomplete enum's assert
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-01-16 20:46 --- Also fails in 4.3.0 20070713. that 4.3 is way old, over 6 months old now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34819
[Bug tree-optimization/34648] [4.3 Regression] ICE in find_or_generate_expression
--- Comment #8 from amacleod at redhat dot com 2008-01-16 20:53 --- Created an attachment (id=14951) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14951action=view) proposed patch for sccvn I did some analysis, and then verified with dberlin that I was on the right track. The root of the problem is a disconnect between SCCVN and PRE. The function bar() is a function call which is a constant. SCCVN therefore puts it in the tables as a value which can be regenerated by calling bar(). PRE in turn looks at the call and notes that it can throw an exception, and says that it is therefore *not* an expression which can be regenerated. Things then fail in find_or_generate_expression() because the expression is in the table, but PRE is unable to regenerate it. In order to fix the problem, we need to make SCCVN and PRE agree whether a constant function which can throw is an expression which can be regenerated. My initial take on that it is not, because the throw could result in some side effects. The decl for bar() is extern const unsigned short int **bar (void) __attribute__ ((const)); The other question is 'is that really a throwable function?' tree_could_throw_p() currently returns TRUE for bar(). This problem could also be fixed by bar() not being a throwable expression. I'm assuming this is well defined, and currently correct. The final option would be to allow PRE to regenerate expressions which can throw. Thoughts? I've attached a patch to modify SCCVN to say expressions which throw can not be regenerated. Its currently going through testing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34648
[Bug tree-optimization/34648] [4.3 Regression] ICE in find_or_generate_expression
--- Comment #9 from rguenther at suse dot de 2008-01-16 21:18 --- Subject: Re: [4.3 Regression] ICE in find_or_generate_expression On Wed, 16 Jan 2008, amacleod at redhat dot com wrote: --- Comment #8 from amacleod at redhat dot com 2008-01-16 20:53 --- Created an attachment (id=14951) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14951action=view) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14951action=view) proposed patch for sccvn I did some analysis, and then verified with dberlin that I was on the right track. Thanks! The root of the problem is a disconnect between SCCVN and PRE. The function bar() is a function call which is a constant. SCCVN therefore puts it in the tables as a value which can be regenerated by calling bar(). PRE in turn looks at the call and notes that it can throw an exception, and says that it is therefore *not* an expression which can be regenerated. Things then fail in find_or_generate_expression() because the expression is in the table, but PRE is unable to regenerate it. In order to fix the problem, we need to make SCCVN and PRE agree whether a constant function which can throw is an expression which can be regenerated. My initial take on that it is not, because the throw could result in some side effects. The decl for bar() is extern const unsigned short int **bar (void) __attribute__ ((const)); The other question is 'is that really a throwable function?' A const function does not throw. From the docs: ..., and have no effects except the return value. likewise pure functions do not throw. tree_could_throw_p() currently returns TRUE for bar(). This problem could also be fixed by bar() not being a throwable expression. I'm assuming this is well defined, and currently correct. Yes it is. I think adjusting tree_could_throw_p() is the correct thing to do. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34648
[Bug fortran/34547] NULL(): Fortran 2003 changes, accepts invalid, ICE on invalid
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-16 21:20 --- See also http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/f014195ccf7b93e6/ for some other possible diagnostic issues. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34547
[Bug debug/34249] [4.3 Regression] FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE
--- Comment #14 from uros at gcc dot gnu dot org 2008-01-16 21:21 --- Subject: Bug 34249 Author: uros Date: Wed Jan 16 21:20:39 2008 New Revision: 131578 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131578 Log: PR debug/34249 * dwarf2out.c (output_call_frame_info): Move output of FDE initial location address to the correct place. Update copyright year. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34249
[Bug tree-optimization/34648] [4.3 Regression] ICE in find_or_generate_expression
--- Comment #10 from amacleod at redhat dot com 2008-01-16 21:27 --- Sure, if that the case, then the bug is in tree_could_throw_p() and we can fix it there :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34648
[Bug libstdc++/18684] static member function not defined in std::locale::facet class
--- Comment #6 from amit dot mitkar at gmail dot com 2008-01-16 21:28 --- Am seeing the same problem. I understand that its not a bug with g++ but what about the resolution. How should one get around the issue ? In yanliu's second comment the said program doesn't directly reference the function in question, yet the link still fails. How to fix that problem ? -Amit -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18684
[Bug c++/34752] pointer to member rejected in variadic template
--- Comment #2 from reichelt at gcc dot gnu dot org 2008-01-16 21:35 --- Fixed. Probably by the patch for PR34751. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34752
[Bug c++/34752] pointer to member rejected in variadic template
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34752
