[Bug c/24570] New: unit-at-a-time: debug info not emitted for unused global variables
Both
Target: i686-pc-linux-gnu
Configured with: ../configure --disable-nls --with-dwarf2
Thread model: posix
gcc version 4.0.2
and
Target: avr
Configured with: ../configure --prefix=/usr/local/avr --target=avr
--disable-nls --with-dwarf2 --enable-languages=c
Thread model: single
gcc version 4.0.2
do not emit stabs or emit incomplete dwarf debug info for an unused global
variable when compiled unit-at-a-time (-O2 or -Os).
var.c:
int used_variable;
int unused_variable __attribute__((unused));
int use_one(void)
{
return used_variable;
}
gcc -S var.c -gstabs
and avr-gcc -S -mmcu=atmega8 var.c -gstabs
works good and generates stabs for both variables
.Lscope0:
.comm used_variable,4,4
.comm unused_variable,4,4
.stabs used_variable:G(0,1),32,0,0,0
.stabs unused_variable:G(0,1),32,0,0,0
.stabs ,100,0,0,.Letext0
.Letext0:
gcc -S var.c -gstabs -funit-at-a-time
or avr-gcc -S -mmcu=atmega8 var.c -gstabs -funit-at-a-time
As soon as unit-at-a-time is active, stabs for unused var is gone
.Lscope0:
.stabs used_variable:G(0,1),32,0,0,0
.comm unused_variable,4,4
.comm used_variable,4,4
.stabs ,100,0,0,.Letext0
.Letext0:
gcc -S var.c -gdwarf-2 -dA -funit-at-a-time
or avr-gcc -S -mmcu=atmega8 var.c -gdwarf-2 -dA -funit-at-a-time
With dwarf, the unused variable is emited without location as if it was
external.
.uleb128 0x4# (DIE (0x63) DW_TAG_variable)
.ascii used_variable\0# DW_AT_name
.byte 0x1 # DW_AT_decl_file
.byte 0x1 # DW_AT_decl_line
.long 0x5c# DW_AT_type
.byte 0x1 # DW_AT_external
.byte 0x5 # DW_AT_location
.byte 0x3 # DW_OP_addr
.long used_variable
.uleb128 0x5# (DIE (0x7f) DW_TAG_variable)
.ascii unused_variable\0 # DW_AT_name
.byte 0x1 # DW_AT_decl_file
.byte 0x2 # DW_AT_decl_line
.long 0x5c# DW_AT_type
.byte 0x1 # DW_AT_external
.byte 0x0 # end of children of DIE 0xb
.section.debug_abbrev
The problem is caused by calling c_write_global_declarations_2 () before
cgraph_varpool_assemble_pending_decls (), which generates rtx for unused
variables.
I tried a dirty hack: insert an extra call of
cgraph_varpool_assemble_pending_decls () into
procedure c_write_global_declarations() in c-decl.c just before the last block
if - for - c_write_global_declarations_2
and it solved the problem. Of course I don't know what it breaks...
--
Summary: unit-at-a-time: debug info not emitted for unused global
variables
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tomas dot vanek at fbl dot cz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24570
[Bug middle-end/24570] unit-at-a-time: debug info not emitted for unused global variables
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-28 16:50 --- I don't think this is a bug as the unused global variables are removed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end Summary|unit-at-a-time: debug info |unit-at-a-time: debug info |not emitted for unused |not emitted for unused |global variables|global variables http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24570
[Bug c/24571] New: error: pthread.h: No such file or directory while building core gcc for cross-compiler
In using crosstool to build a cross-compiler for the SH3, I get the following error in building the early bootstrap gcc: /home/rpjday/results/edge/build-tools/build-gcc-core/./gcc/xgcc -B/home/rpjday/results/edge/build-tools/build-gcc-core/./gcc/ -B/home/rpjday/results/edge/build-tools/gcc-core-prefix/sh3-unknown-linux-gnu/bin/ -B/home/rpjday/results/edge/build-tools/gcc-core-prefix/sh3-unknown-linux-gnu/lib/ -isystem /home/rpjday/results/edge/build-tools/gcc-core-prefix/sh3-unknown-linux-gnu/include -isystem /home/rpjday/results/edge/build-tools/gcc-core-prefix/sh3-unknown-linux-gnu/sys-include -O2 -O2 -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fpic -DNO_FPSCR_VALUES -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I/home/rpjday/results/edge/build-tools/gcc-4.1-20051022/gcc -I/home/rpjday/results/edge/build-tools/gcc-4.1-20051022/gcc/. -I/home/rpjday/results/edge/build-tools/gcc-4.1-20051022/gcc/../include -I/home/rpjday/results/edge/build-tools/gcc-4.1-20051022/gcc/../libcpp/include -fexceptions -c /home/rpjday/results/edge/build-tools/gcc-4.1-20051022/gcc/unwind-dw2.c -o libgcc/./unwind-dw2.o In file included from ./gthr-default.h:1, from /home/rpjday/results/edge/build-tools/gcc-4.1-20051022/gcc/gthr.h:114, from /home/rpjday/results/edge/build-tools/gcc-4.1-20051022/gcc/unwind-dw2.c:42: /home/rpjday/results/edge/build-tools/gcc-4.1-20051022/gcc/gthr-posix.h:43:21: error: pthread.h: No such file or directory I'll shortly attach a script that isolates the error by compiling that single file. -- Summary: error: pthread.h: No such file or directory while building core gcc for cross-compiler Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rpjday at mindspring dot com GCC host triplet: i686-unknown-linux GCC target triplet: sh3-unknown-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24571
[Bug target/24230] [4.1 Regression] ICE in extract_insn with altivec
--- Comment #15 from steven at gcc dot gnu dot org 2005-10-28 16:59 --- The trouble appears to come from this: case V16QImode: case V8HImode: case V4SFmode: case V4SImode: case V4HImode: case V2SFmode: case V2SImode: case V1DImode: if (CONSTANT_P (operands[1]) !easy_vector_constant (operands[1], mode)) operands[1] = force_const_mem (mode, operands[1]); break; We get here with: Breakpoint 14, rs6000_emit_move (dest=0x4010e7f8, source=0x40110670, mode=V16QImode) at rs6000.c:3867 3867 if (CONSTANT_P (operands[1]) (gdb) p debug_rtx(dest) (reg:V16QI 77 0) $3 = void (gdb) p debug_rtx(source) (const_vector:V16QI [ (const_int 0 [0x0]) (const_int 5 [0x5]) (const_int 0 [0x0]) (const_int 5 [0x5]) (const_int 0 [0x0]) (const_int 5 [0x5]) (const_int 0 [0x0]) (const_int 5 [0x5]) (const_int 0 [0x0]) (const_int 5 [0x5]) (const_int 0 [0x0]) (const_int 5 [0x5]) (const_int 0 [0x0]) (const_int 5 [0x5]) (const_int 0 [0x0]) (const_int 5 [0x5]) ]) $4 = void (gdb) And we go to emit_set with: (gdb) p debug_rtx (operands[0]) (reg:V16QI 77 0) $5 = void (gdb) p debug_rtx (operands[1]) (mem/u/c/i:V16QI (symbol_ref/u:SI (*.LC0) [flags 0x2]) [0 S16 A128]) $6 = void (gdb) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24230
[Bug c/24571] error: pthread.h: No such file or directory while building core gcc for cross-compiler
--- Comment #1 from rpjday at mindspring dot com 2005-10-28 17:00 --- Created an attachment (id=10078) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10078action=view) A script that generates the error described by this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24571
[Bug target/24230] [4.1 Regression] ICE in extract_insn with altivec
--- Comment #16 from steven at gcc dot gnu dot org 2005-10-28 17:01 --- On IRC it was suggested that we just need to get a version of easy_vector_constant which does the right thing in any mode. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24230
[Bug c/24571] error: pthread.h: No such file or directory while building core gcc for cross-compiler
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-28 17:01 --- This is not a bug as you need to install glibc's headers. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24571
[Bug java/24572] New: [4.0 regression] ICE in gimplify_expr, at gimplify.c:3983
seen with 4.0 CVS 20051023, compiling antlr 2.7.5. /usr/bin/gcj-4.0 -shared --classpath= -fassume-compiled -I./src -I. -I/usr/share/java/antlr.jar -I. -g -O2 -c -o antlr.so /usr/share/java/antlr.jar antlr/StringUtils.java: In class 'antlr.StringUtils': antlr/StringUtils.java: In method 'antlr.StringUtils.stripBack(java.lang.String,java.lang.String)': antlr/StringUtils.java:24: internal compiler error: in gimplify_expr, at gimplify.c:3983 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. copy of the jar file at http://people.debian.org/~doko/tmp/antlr.jar -- Summary: [4.0 regression] ICE in gimplify_expr, at gimplify.c:3983 Product: gcc Version: 4.0.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: debian-gcc at lists dot debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24572
[Bug middle-end/24570] unit-at-a-time: debug info not emitted for unused global variables
--- Comment #2 from tomas dot vanek at fbl dot cz 2005-10-28 17:14 --- I'm sure it is. I have to declare variables in other segment than .data for my AVR project and if they are declared in one module and __used__ in some others, they cannot be showed in gdb and AVRstudio (however they definitelly are there!!) Just to simplify the example, I left vars in common, where they probably gets removed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24570
[Bug middle-end/24570] unit-at-a-time: debug info not emitted for unused global variables
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-28 17:18 --- never mind, I read unused and I thought unused static variables. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24570
[Bug middle-end/24570] [4.0 Regression] unit-at-a-time: debug info not emitted for unused global variables
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-28 17:23 --- Confirmed, only on the 4.0 branch. It works in 3.4.x and also on the mainline. This is on x86_64-linux-gnu too. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-debug Last reconfirmed|-00-00 00:00:00 |2005-10-28 17:23:06 date|| Summary|unit-at-a-time: debug info |[4.0 Regression] unit-at-a- |not emitted for unused |time: debug info not emitted |global variables|for unused global variables Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24570
[Bug middle-end/24570] [4.0 Regression] unit-at-a-time: debug info not emitted for unused global variables
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-28 17:24 --- That is the mainline and 3.4.x give: .ascii unused_variable\0 # DW_AT_name .byte 0x1 # DW_AT_decl_file .byte 0x2 # DW_AT_decl_line .long 0x7c# DW_AT_type .byte 0x1 # DW_AT_external .byte 0x9 # DW_AT_location .byte 0x3 # DW_OP_addr .quad unused_variable .byte 0x0 # end of children of DIE 0xb -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.0.3 Known to work||3.4.5 4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24570
[Bug c++/24573] New: g++: Internal error message while building openh323
* the exact version of GCC; g++ (GCC) 3.3.5 (Debian 1:3.3.5-13) * the system type; Linux 2.6.8 #1 SMP Tue Oct 4 13:15:08 CEST 2005 i686 GNU/Linux Intel(R) Pentium(R) 4 CPU 2.80GHz hyperthreading * the options given when GCC was configured/built; GCC got from debian packages (testing) * the complete command line that triggers the bug; g++ -I/usr/lib/pwlib/libavcodec/ -DP_USE_PRAGMA -D_REENTRANT -Wall -fPIC -DPTRACING -I/home/dave/gm/openh323-1.15.6/include -DHAS_OSS -I/usr/share/pwlib//include -Os -DH323_RFC2190_AVCODEC=1 -DP_EXPAT=1 -DP_HAS_QOS=1 -g -DMEDIANET_PATCH=1 -D_DEBUG=1 -save-temps -felide-constructors -x c++ -c h323.cxx -o /home/dave/gm/openh323-1.15.6/lib/obj_linux_x86_r/h323.o * the compiler output: make[2]: Entering directory `/home/dave/gm/openh323-1.15.6/src' g++ -I/usr/lib/pwlib/libavcodec/ -DP_USE_PRAGMA -D_REENTRANT -Wall -fPIC -DPTRACING -I/home/dave/gm/openh323-1.15.6/include -DHAS_OSS -I/usr/share/pwlib//include -Os -DH323_RFC2190_AVCODEC=1 -DP_EXPAT=1 -DP_HAS_QOS=1 -g -DMEDIANET_PATCH=1 -D_DEBUG=1 -save-temps -felide-constructors -x c++ -c h323.cxx -o /home/dave/gm/openh323-1.15.6/lib/obj_linux_x86_r/h323.o g++: Internal error: Terminated (program cc1plus) Please submit a full bug report. See URL:http://gcc.gnu.org/bugs.html for instructions. For Debian GNU/Linux specific bug reporting instructions, see URL:file:///usr/share/doc/gcc-3.3/README.Bugs. * the preprocessed file (*.i*) that triggers the bug, Don't know how can to attach it ? -- Summary: g++: Internal error message while building openh323 Product: gcc Version: 3.3.5 Status: UNCONFIRMED Severity: blocker Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: qijcqj8lcwka56m at jetable dot com GCC build triplet: linux 2.6.8 SMP i686 GCC host triplet: linux 2.6.8 SMP i686 GCC target triplet: linux 2.6.8 SMP i686 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24573
[Bug gcov/profile/24487] [3.4/4.0/4.1 Regression] Basic block frequencies inaccurate
--- Comment #3 from dje at gcc dot gnu dot org 2005-10-28 17:30 --- The misprediction causes (or at least contributes to) compute_alignments in final.c not aligning the critical loop in longest_match. The recent changes to bb-reorder.c moved the start of the loop from an ideal alignment to the worst alignment, causing a 8-10% performance drop due to instruction fetch problems. Without the explicit alignment directives omitted because of misprediction, the alignment of the loop is random. -- dje at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24487
[Bug c++/24573] g++: Internal error message while building openh323
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal Keywords||memory-hog http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24573
[Bug c++/24573] g++: Internal error message while building openh323
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-28 17:35 --- (In reply to comment #0) * the preprocessed file (*.i*) that triggers the bug, Don't know how can to attach it ? You attach it afterwards. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24573
[Bug c++/24573] g++: Internal error message while building openh323
--- Comment #2 from qijcqj8lcwka56m at jetable dot com 2005-10-28 17:40 --- Created an attachment (id=10079) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10079action=view) gcc temporary .ii file compressed -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24573
[Bug libstdc++/24559] Incorrect definition of wcspbrk in cwchar
--- Comment #3 from pcarlini at suse dot de 2005-10-28 17:45 --- Fixed for 4.0.3. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24559
[Bug c++/24573] g++: Internal error message while building openh323
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-28 17:51 --- This works for me in 3.3.3. How much memory do you have? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24573
[Bug c++/22153] [3.4/4.0/4.1 regression] ICE on invalid template specialization
--- Comment #3 from jconner at gcc dot gnu dot org 2005-10-28 17:59 --- Subject: Bug 22153 Author: jconner Date: Fri Oct 28 17:58:59 2005 New Revision: 105944 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=105944 Log: PR c++/22153 * cp/parser.c (cp_parser_member_declaration): Detect and handle a template specialization. * testsuite/g++.dg/template/crash38.C: New test. * testsuite/g++.dg/parse/explicit1.C: Change expected errors. Added: trunk/gcc/testsuite/g++.dg/crash38.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/parse/explicit1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22153
[Bug tree-optimization/24568] Missed optimization: trivialization of silly code
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-28 18:01 --- There is a couple of different bugs in the is code snipit really. Let me file new bugs for each of them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24568
[Bug tree-optimization/24574] New: a!=0?0:a/10 is not reduced to a/10
Reduced from PR 24568:
the followin three fucntions should be equivalent:
int f(int i)
{
if (i == 0) return 0;
return i/10;
}
int f1(int i)
{
return i?i/10:0;
}
int f2(int i)
{
return i/10;
}
--
Summary: a!=0?0:a/10 is not reduced to a/10
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24574
[Bug tree-optimization/24568] Missed optimization: trivialization of silly code
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-28 18:05 --- (In reply to comment #1) There is a couple of different bugs in the is code snipit really. Let me file new bugs for each of them. PR 24574 is the first issue which seems like it could happen in really code (though not as much as one thinks). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||24574 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24568
[Bug c++/22153] [3.4/4.0/4.1 regression] ICE on invalid template specialization
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-28 18:09 --- Fixed. Thanks Josh. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22153
[Bug tree-optimization/24568] Missed optimization: trivialization of silly code
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24568
[Bug tree-optimization/24568] Missed optimization: trivialization of silly code
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-28 18:11 --- (In reply to comment #2) PR 24574 is the first issue which seems like it could happen in really code (though not as much as one thinks). That was for the inner if. I have to see how to reduce the outer ones. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24568
[Bug tree-optimization/24575] New: -(-i / 10) is not foldded to i/10
Another reduced testcase from PR 24568:
Note this is only valid for overflow is undefined or for
unsafe_math_transformations.
nt f(int i)
{
return -((-i)/10);
}
int f2(int i)
{
return i/10;
}
--
Summary: -(-i / 10) is not foldded to i/10
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24575
[Bug tree-optimization/24568] Missed optimization: trivialization of silly code
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-28 18:15 --- Another issue is PR 24575: -(-a/10) is not converted into a/10. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||24575 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24568
[Bug tree-optimization/24568] Missed optimization: trivialization of silly code
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-28 18:18 ---
Last but not least is:
int f(int i)
{
if (i 0) return i/10;
return i/10;
}
int f2(int i)
{
return i/10;
}
Which is converted at the rtl level but not at the tree level (I think there is
a bug about this already).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24568
[Bug tree-optimization/24568] [meta-bugs] Missed optimization: trivialization of silly code
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-28 18:19 --- Confirmed, I am changing this into a meta-bug because there are three different issues that this bug depends on now. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-10-28 18:19:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24568
[Bug tree-optimization/24568] [meta-bugs] Missed optimization: trivialization of silly code
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-10-28 18:21 --- Oh, for PR 24575 to do anything useful in this case, we need to a tree based combiner. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||15459 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24568
[Bug c++/20912] C++ FE emitting assignments to read-only global symbols
--- Comment #11 from pinskia at gcc dot gnu dot org 2005-10-28 18:25 --- Right now after fixing this and PR 23777 should become fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||23777 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20912
[Bug tree-optimization/23286] missed fully redundant expression
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-10-28 18:43
---
Here is another example which comes from PR 24568 (which really comes from
thedailywtf):
int f(int i)
{
if (i 0) return i/10+ i;
return i/10 + i;
}
int f2(int i)
{
return i/10 + i;
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||24568
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23286
[Bug c++/22153] [3.4/4.0/4.1 regression] ICE on invalid template specialization
--- Comment #5 from jconner at gcc dot gnu dot org 2005-10-28 18:47 --- Subject: Bug 22153 Author: jconner Date: Fri Oct 28 18:47:28 2005 New Revision: 105946 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=105946 Log: Merged from mainline change #105944: PR c++/22153 * cp/parser.c (cp_parser_member_declaration): Detect and handle a template specialization. * testsuite/g++.dg/template/crash38.C: New test. * testsuite/g++.dg/parse/explicit1.C: Change expected errors. Added: branches/gcc-3_4-branch/gcc/testsuite/g++.dg/crash38.C - copied unchanged from r105944, trunk/gcc/testsuite/g++.dg/crash38.C Modified: branches/gcc-3_4-branch/gcc/cp/ChangeLog branches/gcc-3_4-branch/gcc/cp/parser.c branches/gcc-3_4-branch/gcc/testsuite/ChangeLog branches/gcc-3_4-branch/gcc/testsuite/g++.dg/parse/explicit1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22153
[Bug c++/22153] [3.4/4.0/4.1 regression] ICE on invalid template specialization
--- Comment #6 from jconner at gcc dot gnu dot org 2005-10-28 18:57 --- Subject: Bug 22153 Author: jconner Date: Fri Oct 28 18:57:33 2005 New Revision: 105947 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=105947 Log: Merged from mainline change #105944: PR c++/22153 * cp/parser.c (cp_parser_member_declaration): Detect and handle a template specialization. * testsuite/g++.dg/template/crash38.C: New test. * testsuite/g++.dg/parse/explicit1.C: Change expected errors. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/crash38.C - copied unchanged from r105944, trunk/gcc/testsuite/g++.dg/crash38.C Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/parser.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog branches/gcc-4_0-branch/gcc/testsuite/g++.dg/parse/explicit1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22153
[Bug c++/22153] [3.4/4.0/4.1 regression] ICE on invalid template specialization
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-10-28 18:58 --- Fixed in all open branches. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail|3.4.0 4.0.0 4.1.0 |3.4.0 4.0.0 Known to work|3.3.3 |3.3.3 3.4.5 4.0.3 4.1.0 Target Milestone|4.1.0 |3.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22153
[Bug target/24230] [4.1 Regression] ICE in extract_insn with altivec
--- Comment #17 from paolo dot bonzini at lu dot unisi dot ch 2005-10-28 19:16 --- Subject: Re: [4.1 Regression] ICE in extract_insn with altivec On IRC it was suggested that we just need to get a version of easy_vector_constant which does the right thing in any mode. Yes, it looks like the bug is that the constant is declared easy until it is in V8HI mode, but not when the reload is done in V16QI mode. It may make sense to assert !reload_in_progress !reload_completed before force_const_mem is called. Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24230
[Bug fortran/24545] gfortran bug regarding interface block with named END INTERFACE statements
--- Comment #3 from kargl at gcc dot gnu dot org 2005-10-28 20:06 --- Subject: Bug 24545 Author: kargl Date: Fri Oct 28 20:05:56 2005 New Revision: 105953 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=105953 Log: PR fortran/24545 * interface.c (gfc_match_end_interface): Fix typo in INTERFACE_USER_OP case. Added: trunk/gcc/testsuite/gfortran.dg/interface_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24545
[Bug fortran/24545] gfortran bug regarding interface block with named END INTERFACE statements
--- Comment #4 from sgk at troutmask dot apl dot washington dot edu
2005-10-28 20:07 ---
Subject: Re: gfortran bug regarding interface block with named END INTERFACE
statements
On Wed, Oct 26, 2005 at 06:54:10PM -, steven at gcc dot gnu dot org wrote:
Index: interface.c
===
RCS file: /cvs/gcc/gcc/gcc/fortran/interface.c,v
retrieving revision 1.21
diff -u -3 -p -r1.21 interface.c
--- interface.c 21 Oct 2005 18:50:52 - 1.21
+++ interface.c 26 Oct 2005 18:53:39 -
@@ -295,7 +295,7 @@ gfc_match_end_interface (void)
/* Comparing the symbol node names is OK because only use-associated
symbols can be renamed. */
if (type != current_interface.type
- || strcmp (current_interface.sym-name, name) != 0)
+ || strcmp (current_interface.uop-name, name) != 0)
{
gfc_error (Expecting 'END INTERFACE OPERATOR (.%s.)' at %C,
current_interface.sym-name);
Bootstrapped and regression tested on amd64-*-freebsd.
I've committed the patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24545
[Bug c++/24511] [4.0/4.1 Regression] explicit instantiation/extern template unsats on symbols defined later
--- Comment #2 from jason at gcc dot gnu dot org 2005-10-28 20:25 --- This is not a bug. All member templates must be defined before an explicit instantiation of the class. The existing standard requires an error on this case, but a future DR will change the standard to match the g++ behavior. It's desirable to not require all member templates to be defined in the case of private copy constructors declared only to prevent copying the class. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24511
[Bug c++/23229] [4.0/4.1 Regression] g++ gives incorrect error message with void main() and a void function
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-28 20:26 --- Subject: Bug 23229 Author: pinskia Date: Fri Oct 28 20:25:55 2005 New Revision: 105960 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=105960 Log: 2005-10-28 Andrew Pinski [EMAIL PROTECTED] PR C++/23229 * decl.c (grokfndecl): Create a new function type after erroring out about main not returning int. 2005-10-28 Andrew Pinski [EMAIL PROTECTED] PR C++/23229 * g++.dg/warn/main-2.C: New test. Added: trunk/gcc/testsuite/g++.dg/warn/main-2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23229
[Bug c++/24511] [4.0/4.1 Regression] explicit instantiation/extern template unsats on symbols defined later
--- Comment #3 from sebor at roguewave dot com 2005-10-28 20:34 --- Jason, I respectfully disagree. In bug 22263 I explained why I believe gcc is wrong. Do you see a problem with my reasoning there? If not, you must surely agree that this is just another example of the same bug. -- sebor at roguewave dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24511
[Bug c++/23229] [4.0/4.1 Regression] g++ gives incorrect error message with void main() and a void function
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-28 20:52 --- Subject: Bug 23229 Author: pinskia Date: Fri Oct 28 20:52:44 2005 New Revision: 105961 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=105961 Log: 2005-10-28 Andrew Pinski [EMAIL PROTECTED] PR C++/23229 * decl.c (grokfndecl): Create a new function type after erroring out about main not returning int. 2005-10-28 Andrew Pinski [EMAIL PROTECTED] PR C++/23229 * g++.dg/warn/main-2.C: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/warn/main-2.C - copied unchanged from r105960, trunk/gcc/testsuite/g++.dg/warn/main-2.C Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/decl.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23229
[Bug fortran/24545] gfortran bug regarding interface block with named END INTERFACE statements
--- Comment #5 from kargl at gcc dot gnu dot org 2005-10-28 20:57 --- Subject: Bug 24545 Author: kargl Date: Fri Oct 28 20:57:17 2005 New Revision: 105962 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=105962 Log: PR fortran/24545 * interface.c (gfc_match_end_interface): Fix typo in INTERFACE_USER_OP case. Added: branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/interface_2.f90 Modified: branches/gcc-4_0-branch/gcc/fortran/ChangeLog branches/gcc-4_0-branch/gcc/fortran/interface.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24545
[Bug fortran/24545] gfortran bug regarding interface block with named END INTERFACE statements
--- Comment #6 from kargl at gcc dot gnu dot org 2005-10-28 20:58 --- Fixed. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24545
[Bug fortran/24545] gfortran bug regarding interface block with named END INTERFACE statements
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.1.0 |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24545
[Bug c++/23229] [4.0/4.1 Regression] g++ gives incorrect error message with void main() and a void function
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-10-28 21:02 --- Fixed in 4.0.3. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23229
[Bug c++/24569] [4.0/4.1 regression] ICE in add_AT_specification, at dwarf2out.c:4966
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-10-28 16:43:20 |2005-10-28 21:05:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24569
[Bug c++/24511] [4.0/4.1 Regression] explicit instantiation/extern template unsats on symbols defined later
--- Comment #4 from jason at gcc dot gnu dot org 2005-10-28 21:19 --- I do disagree with your reasoning on the other bug. This DR clarifies 14.7.2: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#470 If indeed all other compilers accept this code, then perhaps the DR is not what we want, but you should bring that up with Core. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24511
[Bug fortran/24576] New: Fortran I/O to same unit number in main program and in a shared library
A fortran main program and a fortran shared library dlopen'ed from the main
program use the same unit number to report results to two different files
(explicitely opened in the main program and in the library, see example below)
With GCC 3.x when one links with libg2c.a to produce the shared library
(i.e.
g77 -shared -fPIC -Wl,-Bsymbolic -o libtest.so test.f /usr/lib64/libg2c.a
)
output goes to the two files as intended.
With gfortran 4.0.2 and also snapshot 4.1.0 20051022 the attempt to write
to the file in the shared library fails with
Fortran runtime error: End of record
In this case I have used
gfortran -fPIC -shared -Wl,-Bsymbolic -o libtest.so test.f
/usr/lib64/libgfortran.a
gcc -c testx.c
gfortran main.f testx.o -ldl
to produce the executable and the shared library.
When the shared library is built without libgfortran.a,
once unit 1 is opened in the shared library, all output goes
to this file, not the file connected to unit 1 in the main program.
I'm not sure if this is a bug or intended behavior.
c--- test.f
subroutine test
open(1,file='junk_shared')
write(1,*) 'In subroutine test'
return
end
/*- testx.c
#include dlfcn.h
#include stdio.h
typedef void (*MyFunc)();
void testx_() {
void *h; MyFunc func;
h = dlopen(./libtest.so,RTLD_LAZY);
if( !h ) {
printf(Failed to open libtest: %s\n,dlerror());
return;
}
func = (MyFunc) dlsym(h,test_);
if( !func ) {
printf(Failed to resolve test: %s\n,dlerror());
return;
}
func();
}
c-- main.f
program io_test
open(1,file='junk_main')
write(1,*) 'In main program, calling testx'
call testx
write(1,*) 'Back in main program after call to testx: '
end
--
Summary: Fortran I/O to same unit number in main program and in a
shared library
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: iwan at irs dot phy dot nrc dot ca
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=24576
[Bug awt/16741] Toolkit.loadSystemColor unimplemented
--- Comment #2 from sven at physto dot se 2005-10-28 21:27 --- Can we close this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16741
[Bug gcov/profile/24487] [3.4/4.0/4.1 Regression] Basic block frequencies inaccurate
--- Comment #4 from hubicka at ucw dot cz 2005-10-28 21:29 --- Subject: Re: [Bug gcov/profile/24487] [3.4/4.0/4.1 Regression] Basic block frequencies inaccurate --- Comment #3 from dje at gcc dot gnu dot org 2005-10-28 17:30 --- The misprediction causes (or at least contributes to) compute_alignments in final.c not aligning the critical loop in longest_match. The recent changes to bb-reorder.c moved the start of the loop from an ideal alignment to the worst alignment, causing a 8-10% performance drop due to instruction fetch problems. Without the explicit alignment directives omitted because of misprediction, the alignment of the loop is random. I see, Athlon is less sensitive to alignment that might explain it. I will try to fix my SPEC testing setup on PPC after SVN revamp and benchmark it there too... Honza -- dje at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24487 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. You are the assignee for the bug, or are watching the assignee. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24487
[Bug c++/24511] explicit instantiation/extern template unsats on symbols defined later
--- Comment #5 from jason at gcc dot gnu dot org 2005-10-28 21:34 --- Actually, I'm sympathetic to the behavior you would like to see, so I'm reopening the bug. But I think the current behavior is clearly correct under the DR, so I'm changing the severity to enhancement. -- jason at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|enhancement Status|SUSPENDED |NEW Last reconfirmed|2005-10-25 01:00:51 |2005-10-28 21:34:24 date|| Summary|[4.0/4.1 Regression]|explicit |explicit|instantiation/extern |instantiation/extern|template unsats on symbols |template unsats on symbols |defined later |defined later | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24511
[Bug libfortran/24576] Fortran I/O to same unit number in main program and in a shared library
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-28 21:40 --- Why are you not linking against the shared library version of libgfortran? What you are doing seems wrong and unsupported. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|fortran |libfortran http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24576
[Bug c++/24511] explicit instantiation/extern template unsats on symbols defined later
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.3 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24511
[Bug libfortran/24576] Fortran I/O to same unit number in main program and in a shared library
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-28 21:43 --- Anyways I think this is really a dup of bug 22298. Also note the static library really needs to be compiled with -fPIC if you are linking it in a shared library (by default it is not). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24576
[Bug target/24230] [4.1 Regression] ICE in extract_insn with altivec
--- Comment #18 from pinskia at gcc dot gnu dot org 2005-10-28 21:47 --- Aldy, Can you look into this bug? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||aldyh at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24230
[Bug middle-end/24573] g++: Internal error message while building openh323
--- Comment #4 from qijcqj8lcwka56m at jetable dot com 2005-10-28 22:13 --- (In reply to comment #3) This works for me in 3.3.3. How much memory do you have? I have 248 Mb of memory -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24573
[Bug c++/24577] New: diagnostic informative note labelled error
void foo(){ int a = b; }
gets you:
foo.cc: In function `void foo()':
foo.cc:1: error: `b' undeclared (first use this function)
foo.cc:1: error: (Each undeclared identifier is reported only once for each
function it appears in.)
Other informative notes are labeled note:. Because this is labelled error,
scripts that scan generated compiler output to count errors get wrong counts.
Ivan
--
Summary: diagnostic informative note labelled error
Product: gcc
Version: 3.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24577
[Bug libfortran/24576] Fortran I/O to same unit number in main program and in a shared library
--- Comment #3 from iwan at irs dot phy dot nrc dot ca 2005-10-28 23:22 --- Subject: Re: Fortran I/O to same unit number in main program and in a shared library --- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-28 21:40 Why are you not linking against the shared library version of libgfortran? What you are doing seems wrong and unsupported. If I do that, after the shared library has opened unit 1, all output from the main program goes there and this is not what I want. With the Intel and PGI compilers linking the shared library with -Wl,-Bsymbolic is sufficient to make the main program and the shared library to have independent I/O. With the GCC 3.x compilers one needed to link against the static g2c. This no longer works with GCC 4.x. Both the shared library and the main program are huge packages using tens of different I/O units = It i not easy to simply find and replace I/O units everywhere. --- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-28 21:43 --- Anyways I think this is really a dup of bug 22298. Also note the static library really needs to be compiled with -fPIC if you are linking it in a shared library (by default it is not). The static gfortran library is made with -fPIC (otherwise the linker refuses to create a shared library on x86_64 when linking against it) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24576
[Bug c++/24569] [4.0/4.1 regression] ICE in add_AT_specification, at dwarf2out.c:4966
--- Comment #4 from jason at gcc dot gnu dot org 2005-10-28 23:38 --- Yes, this was introduced by 2005-10-10 Mark Mitchell [EMAIL PROTECTED] PR c++/24277 * pt.c (instantiate_decl): Call finish_static_data_member_decl for static data members. After this change, we call that function twice for static data members, once when instantiating the class and again when instantiating the member itself. As a result, the member gets added to pending_statics twice. I think we only want to call finish_static_data_member_decl once per static data member. -- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|jason at gcc dot gnu dot org|mmitchel at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24569
[Bug c/24577] diagnostic informative note labelled error
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-28 23:44 --- This is only a C bug now: t.c:1: error: 'b' undeclared (first use in this function) t.c:1: error: (Each undeclared identifier is reported only once t.c:1: error: for each function it appears in.) Confirmed, the C++ front-end now gives t.c: In function 'void foo()': t.c:1: error: 'b' was not declared in this scope -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c++ |c Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2005-10-28 23:44:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24577
[Bug c/24577] diagnostic informative note labelled error
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |trivial http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24577
[Bug c++/11987] [3.4/4.0/4.1 regression] Accepts-invalid with inherited nested type
-- jason at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11987
[Bug libfortran/24576] Fortran I/O to same unit number in main program and in a shared library
--- Comment #4 from kargl at gcc dot gnu dot org 2005-10-29 00:14 --- Intel and PGI are wrong according to the standard. Gfortran is doing the right thing. See section 9.4 File Connection. In particular The external unit identified by a particular value of a scalar-int-expr is the same external unit in all program units of the program. Also, read Note 9.13. I'm here referencing material from the Final Committee Draft for the Fortran 2003 standard. You'll also find Section 9.4.3 Connection of a file to a unit An external unit has a property of being connected or not connected. If connected, it refers to an external file. An external unit may become connected by preconnection or by the execution of an OPEN statement. The property of connection is symmetric; the unit is connected to a file if and only if the file is connected to the unit. In short, if you want to different files, then you need to have unique unit numbers. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24576
[Bug c/24578] New: compiler emits call to floorf() instead of floor()
Compiling the following code on MIPS emits a function call to floorf (not
floor). This is a problem when one's libc does not contain a floorf function.
void func (float *dest, float *src)
{
*dest = floor (*src);
}
Compile using 'mipsel-linux-uclibc-gcc -O2 -save-temps -c it.c'.
--
Summary: compiler emits call to floorf() instead of floor()
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ds at schleef dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24578
[Bug target/24578] compiler emits call to floorf() instead of floor()
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-29 00:52 --- First this is a target bug and second floorf is a C99 function and really uclibc should have it. If you want to declare this a gcc bug, you first need to add an uclibc target and make it so it does not declare that you have C99 math functions. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |target GCC target triplet||mipsel-linux-uclibc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24578
[Bug tree-optimization/23346] [4.1 Regression] FRE before DCE makes a mess of loads or need to sink loads
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23346
[Bug c++/24009] [4.0/4.1 regression] C++ fails to print #include stack
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24009
[Bug c++/23287] [3.4/4.0/4.1 regression] Explicitly invoking destructor of template class
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-29 01:38 --- I am looking to fix this (hopefully I can fix it). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23287
[Bug fortran/24579] New: error on list directed read
when it comes to a list directed I/O, it reports an error. It is in the J3 spec, I think R901 read(unit=50,FMT=*,END=100)a,b,c it will not run. I have found that if I remove the 'unit=', then it will work, but that is a default value, and is not according to the spec, which goes back to F77 it works fine on namelist I/O and on fomratted input. But not list directed. please correct thank you -- Summary: error on list directed read Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: major Priority: P1 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: morantzb at nemesis dot tucson dot saic dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24579
[Bug c++/23287] [3.4/4.0/4.1 regression] Explicitly invoking destructor of template class
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-29 01:40 --- Related to PR 12333. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||12333 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23287
[Bug c++/17256] [3.4/4.0/4.1 Regression] undefined but used static or inline functions should be diagnosed
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-07-12 06:35:36 |2005-10-29 01:50:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17256
[Bug libfortran/24576] Fortran I/O to same unit number in main program and in a shared library
--- Comment #5 from iwan at irs dot phy dot nrc dot ca 2005-10-29 01:52 --- Subject: Re: Fortran I/O to same unit number in main program and in a shared library I guess, it all comes down to what is a program. If I look at section 5.5.2.3 of the 2003 Standard about common blocks, I find that Within a program, the common block storage sequences of of all non-zero sized common blocks with the same name have the same first storage unit Yet, if I have common/a/ in some subroutine and create a shared library using -Wl,-Bsymbolic (or whatever linker options are needed to make symbols local to the shared library), this is not the same common block as common/a/ in the main program using the shared library. Therefore, if one takes the standard seriously, the shared library is not part of the program in this case and therefore I/O in the shared library should not interfere with I/O in the main program. This is the behavior one gets with the Intel and PGI compilers on Linux and this is the behavior I remember from years ago on IRIX and SunOS workstations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24576
[Bug awt/16741] Toolkit.loadSystemColor unimplemented
--- Comment #3 from fitzsim at redhat dot com 2005-10-29 01:55 --- I want to leave it open until we have a pure-java implementation that reads colors from a .properties file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16741
[Bug libfortran/24576] Fortran I/O to same unit number in main program and in a shared library
--- Comment #6 from sgk at troutmask dot apl dot washington dot edu 2005-10-29 02:34 --- Subject: Re: Fortran I/O to same unit number in main program and in a shared library On Sat, Oct 29, 2005 at 01:52:48AM -, iwan wrote: If I look at section 5.5.2.3 of the 2003 Standard about common blocks, The standard has no concept of program. It does have a concept of program units See section 11 and 12. I find that Within a program, the common block storage sequences of of all non-zero sized common blocks with the same name have the same first storage unit Non-sequitur. storage unit != external unit (which is connected to a file). This is the behavior one gets with the Intel and PGI compilers on Linux and this is the behavior I remember from years ago on IRIX and SunOS workstations. It is not uncommon for vendors to add extensions to their products even when the extension violates the standards. Following Note 9.9 in the Final Committe Draft of the Fortran 95 standard, one finds: A unit shall not be connected to more than one file at the same time. It does not matter if the subprogram is dynamically loaded into memory. If the main program has associated unit=1 with a file and you call a subprogram from the shared library and it associates unit=1 with a different file, then your program is nonconforming. To make your program portable, you should use the inquire function to obtain an unused unit. function getunit() implicit none integer getunit logical inuse getunit = 1 do inquire(unit = getunit, opened = inuse) if (inuse .eqv. .false.) exit getunit = getunit + 1 end do end function getunit program a integer fd integer, external :: getunit fd = getunit() open(unit=fd, file'yada') end program a -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24576
[Bug fortran/24579] error on list directed read
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2005-10-29 02:51 --- You need to provide a complete code example. I can not reproduce an error here. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added CC||jvdelisle at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24579
[Bug fortran/24579] error on list directed read
--- Comment #2 from kargl at gcc dot gnu dot org 2005-10-29 02:52 --- Can you add a short program with the problem? The single read statement may not be sufficient to reconstruct your problem. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24579
[Bug c++/23287] [3.4/4.0/4.1 regression] Explicitly invoking destructor of template class in a template
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-29 03:57 --- Hmm, pseudo_destructor_p is not being set to true. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23287
[Bug c++/23287] [3.4/4.0/4.1 regression] Explicitly invoking destructor of template class in a template and is dependent
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-29 03:59 --- The issue is this is a depedent name. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[3.4/4.0/4.1 regression]|[3.4/4.0/4.1 regression] |Explicitly invoking |Explicitly invoking |destructor of template class|destructor of template class |in a template |in a template and is ||dependent http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23287
[Bug c++/23287] [3.4/4.0/4.1 regression] Explicitly invoking destructor of template class in a template and is dependent
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-10-29 04:15 --- This problem is much harder than I though but basicially there are two issues, we need to parse A in ~A as AT which we don't as we require a class-type. The second issue is that we don't even get to the parsing of ~ because scope is NULL as this is a dependent type. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23287
