[Bug fortran/21875] [meta-bug] NIST test suite failures
--- Additional Comments From jvdelisle at verizon dot net 2005-07-20 06:06 --- The snippet in Comment #6 fails correctly because the format is calling for a field width of 8 characters. The first read goes past the first number and into the second and you basically are reading garbage. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21875
[Bug target/13749] Internal compiler error when cross-compiling C code for IP2K processor
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-20 06:44 --- Closing as will not fix as this target has been removed from the mainline for 4.1.0. -- What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13749
[Bug target/20582] ip2k-elf doesn't build
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-20 06:44 --- Closing as will not fix as this target has been removed from the mainline for 4.1.0. -- What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20582
[Bug target/13754] [3.4/4.0/4.1 regression] ip2k-elf ICE on multiple gotos
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-20 06:44 --- Closing as will not fix as this target has been removed from the mainline for 4.1.0. -- What|Removed |Added Status|SUSPENDED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13754
[Bug other/13817] IP2K GCC cross-compiler intallation does not install crt0.o, libgcc.a or libc.a properly
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-20 06:44 --- Closing as will not fix as this target has been removed from the mainline for 4.1.0. -- What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13817
[Bug bootstrap/8909] sparc-openbsd does not define TEXT_SECTION_ASM_OP or DATA_SECTION_ASM_OP so an error in varasm.c
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-20 06:48 --- Closing as will not fix as this target has been removed from the mainline (for 4.1.0). -- What|Removed |Added Status|SUSPENDED |RESOLVED Resolution||WONTFIX Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8909
[Bug target/18863] [4.0/4.1 Regression] ICE in find_reloads
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-20 06:50 --- Closing as will not fix as this target has now been removed from the mainline (for 4.1.0). -- What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18863
[Bug testsuite/20454] gcc.dg/20001117-1.c is broken for callee cleanup calling convention
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-20 06:54 --- I will apply this patch later today (Wednesday). Note IP2k was removed from the mainline as it was not been maintained and it did not even build any more. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20454
[Bug tree-optimization/22564] New: [4.1 Regression] Compilation time increased about 11%
The compilation time graphs for all target in CSiBE have been drastically increased from 2005-03-01. For example: Os / O2 / O3 i686-linux: 11% 11% 17% arm-elf: 10% 11% 18% m68k-elf:12% 12% 18% (See CSiBE for more detailed results) -- Summary: [4.1 Regression] Compilation time increased about 11% Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: compile-time-hog Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: loki at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22564
[Bug tree-optimization/22564] [4.1 Regression] Compilation time increased about 11%
--- Additional Comments From giovannibajo at libero dot it 2005-07-20 08:15 --- Of course: March 1st is when GCC went back to Stage 1. There have been dozen and dozen of projects contributed for GCC 4.1, and probably some still require tuning. The best way to attack this is to find and analyze *specific* regressions. Would you please submit a couple of preprocessed sources which clearly show a compile time increase? -- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22564
[Bug c/22565] New: GCC 3.4.1 Complex cast error in a kernel module compilation
I've found the following bug compiling the c code below:
/root/Interface_thread_buffered/RTAI_GYRO.c: In function `fill_data_gyro':
/root/Interface_thread_buffered/RTAI_GYRO.c:68: error: unrecognizable insn:
(insn:HI 87 86 88 0 (set (reg:DF 112)
(float:DF (reg:HI 113))) -1 (insn_list 86 (nil))
(expr_list:REG_DEAD (reg:HI 113)
(nil)))
/root/Interface_thread_buffered/RTAI_GYRO.c:68: internal compiler error: in
extract_insn, at recog.c:2083
Please submit a full bug report,
with preprocessed source if appropriate.
The fill_data_gyro function contain the following code:
int fill_data_gyro(unsigned char *buf, double *angle){
unsigned char c;
unsigned char R[2];
char cs; //CheckSum recupere
unsigned char cs_add; //Checkum calcule
//Constantes constructeur
double LSB_Angle=0.000305;
---
R[1] = (buf[5]6) | (buf[6]1); //c=R15-R8
cs_add+=R[1] 0xff ;
R[0] = buf[6]7 | buf[7]; //c=R7-R0
cs_add+=R[0] 0xff;
* angle= -LSB_Angle * (* (short *) R);
---
return 0;
}
Commenting the * angle= -LSB_Angle * (* (short *) R); the complilation work
perfectly
The makefile is the following:
SOURCES = RTAI_GYRO.c
obj-m := $(SOURCES:.c=.o)
RTAI = /usr/realtime
EXTRA_CFLAGS = -I$(RTAI)/include -I/usr/include/
KDIR:= /lib/modules/$(shell uname -r)/build
PWD := $(shell pwd)
default:
$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
(it's a kernel module for RTAI...)
I've compiled this code inside an other application and it works perfectly
even with the * angle= -LSB_Angle * (* (short *) R); line...
The gcc options associated: gcc -Wall -g -lm
I'm a neaby in Linux and it's possible that this kind of cast (* (short *) R)
is not very clear for the compiler (the star represents alternatively a
pointeur and the multiplication symbol...)
I hope not to report a know bug...
My system is a Mdk 10.1 with a 2.6.7 kernel from kernel.org(I need a
standard kernel for RTAI developping)
bye
Erwann
--
Summary: GCC 3.4.1 Complex cast error in a kernel module
compilation
Product: gcc
Version: 3.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: erwann dot houzay at laposte dot net
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22565
[Bug c++/22566] New: Incorrect overload resolution on mutable field.
The following program prints a hex address. I expected it to print Hello,
world
nm | c++filt|grep operator shows that the operator used is:
std::basic_ostreamchar, std::char_traitschar ::operator(void const*)
I expected operator(char const*)
This is with Fedora's gcc-4.0.1-3.i386.rpm
The program:
#include sstream
#include stdio.h
struct cerror {
~cerror() { printf (%s\n, s.str().c_str()); }
mutable std::ostringstream s;
};
int main()
{
cerror().s Hello, world\n;
return 0;
}
--
Summary: Incorrect overload resolution on mutable field.
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: suckfish at ihug dot co dot nz
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i386-redhat-linux
GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22566
[Bug c/22565] GCC 3.4.1 Complex cast error in a kernel module compilation
--- Additional Comments From giovannibajo at libero dot it 2005-07-20 09:53 --- Try again with GCC 3.4.4, and come back to us. You should always try the latest version of the compiler line you're using, otherwise we could all be wasting time on the bug report. -- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22565
[Bug debug/21828] [4.0/4.1 Regression] debug info omitted for uninitialized variables
--- Additional Comments From jakub at redhat dot com 2005-07-20 11:41 --- I have done a binary search and at least for the failures and at least those problems mentioned in PR c++/18556 are fixed by PR middle-end/17799 without the need for PR c++/18556 patch. Now, the question is I think if there is a testcase that still needs PR c++/18556 patch. If not, at least for gcc-4_0-branch IMHO the easiest would be simply to revert that patch. If yes, but it is C++ only and there can't be a case when something like that is needed in C, a quick fix would be /* Do not emit debug information about variables that are in static storage, but not defined. */ if (TREE_CODE (decl) == VAR_DECL + (cgraph_global_info_ready || !flag_unit_at_a_time) TREE_STATIC (decl) !TREE_ASM_WRITTEN (decl)) DECL_IGNORED_P (decl) = 1; so we would not force no debugging for a var decl that has not been written, unless cgraph_optimize has been called already or -fno-unit-at-a-time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21828
[Bug tree-optimization/22564] [4.1 Regression] Compilation time increased about 11%
--- Additional Comments From loki at gcc dot gnu dot org 2005-07-20 12:31 --- (In reply to comment #1) You are probably right, but it is hard to find such a test case, because there is only one significant daily regression (I guess from merging), but this one doesn't explain the overall change. IMHO the graphs suggest that the daily bugfixes increased the compilation time day after day. So, it's maybe difficult to clearly show which algorithms are responsible for this regression. Soever, I will search for some tests which will demonstarte this compile-time-hog. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22564
[Bug SWING/22567] New: JCheckBox's check box is missing
Steps to reproduce:
1. Compile and run the attached testcase.
Expected results:
1. A window with a check box and text1 shows up.
Actual results:
1. A window with text1 shows up. No check box is visible.
Testcase:
import java.awt.*;
import javax.swing.*;
public class testcase extends JFrame {
public static void main(String[] args) {
new testcase().show();
}
public testcase() {
JCheckBox checkbox = new JCheckBox(text1 , true);
setContentPane(checkbox);
setSize(new Dimension(300, 300));
}
}
The check box is visible with gnu classpath cvs 2005-07-15T11:38:00+ but
missing with gnu classpath cvs 2005-07-15T11:45:00+. Diff between these
versions shows the following changelog entry:
+2005-07-15 Roman Kennke [EMAIL PROTECTED]
+
+ * javax/swing/AbstractButton.java
+ (AbstractButton): Directly call init() and updateUI().
+ (AbstractButton(String, Icon)): Removed. This is not necessary
+ since we have init(String, Icon) for that purpose.
+ (getActionCommand): Reverted to previous behaviour: If
+ actionCommand is set, return this, otherwise return text, even
+ if text is null.
+ * javax/swing/JButton.java
+ (JButton(String, Icon)): Call super() and init(String, Icon)
+ instead of super(String, Icon).
+ * javax/swing/JMenuItem.java
+ (JMenuItem): Call super() instead of super(String, Icon).
+ (JMenuItem(Icon)): Call this(String, Icon) instead of
+ super(String, Icon).
+ (JMenuItem(String)): Call this(String, Icon) instead of
+ super(String, Icon).
+ (JMenuItem(Action)): Call super() instead of
+ super(String, Icon).
+ (JMenuItem(String, Icon)): Call super() and init(String, Icon)
+ instead of super(String, Icon).
+ (JMenuItem(String, int)): Call this(String, Icon) instead of
+ super(String, Icon).
+ * javax/swing/JToggleButton.java
+ (ToggleButtonModel.setPressed): Fire an ActionEvent if button
+ is released. According to my Mauve tests, it seems that this
+ is what the JDK does, so do we.
+ (ToggleButtonModel.setSelected): Removed.
+ (JToggleButton): Call super() and init(String, Icon) instead
+ of super(String, Icon).
+
--
Summary: JCheckBox's check box is missing
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: SWING
AssignedTo: graydon at redhat dot com
ReportedBy: timo dot lindfors at iki dot fi
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22567
[Bug c++/15938] ICE with anonymous unions
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-07-20 13:17 --- On mainline the code is accepted since today. This is probably due to Giovanni's patch http://gcc.gnu.org/ml/gcc-cvs/2005-07/msg00718.html -- What|Removed |Added CC||giovannibajo at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15938
[Bug c++/22568] New: Should use cmov in some stituations
With (ulong a, ulong b) and code like
if ( ab ) { ulong t=a; a=b; b=t; }
gcc should (if a and b are in registers already)
not emit a conditional jump but code like
MOV a, t;
CMP a, b;
CMOVcc b, a;
CMOVcc t, b;
Other such examples are easily found. If I got it correctly, gcc
emits CMOVcc in just one situation, the conditional assignment.
Machine is AMD64, OS is SuSE Linux 9.3
gcc (GCC) 3.3.5 20050117 (prerelease) (SUSE Linux)
--
Summary: Should use cmov in some stituations
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: arndt at jjj dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22568
[Bug c++/22568] Should use cmov in some stituations
--- Additional Comments From matz at suse dot de 2005-07-20 14:20 ---
This still happens with 4.1. I also can't make it use two cmovs, by changing
the source a bit, e.g. like:
typedef unsigned long ulong;
extern ulong use (ulong, ulong);
ulong f(ulong a, ulong b)
{
ulong tmp = a;
if (a b) {
a = b;
b = tmp;
}
return use (a, b);
}
--
What|Removed |Added
CC||matz at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22568
[Bug libstdc++/22554] [4.1 Regression] pb_assoc header build and install overflows exec
--- Additional Comments From dje at watson dot ibm dot com 2005-07-20 14:26 --- Subject: Re: [4.1 Regression] pb_assoc header build and install overflows exec Please for completeness sake put in the generated command that kills AIX, and the AIX output. make[1]: Entering directory `/tmp/powerpc-ibm-aix5.2.0.0-20050720/powerpc-ibm-aix5.2.0.0/libstdc++-v3' make AR_FLAGS=rc CC_FOR_BUILD=gcc CC_FOR_TARGET=/tmp/powerpc-ibm-aix5.2.0.0-20050720/./gcc/xgcc -B/tmp/powerpc-ibm-aix5.2.0.0-20050720/./gcc/ -B/farm/dje/install/powerpc-ibm-aix5.2.0.0-20050720/powerpc-ibm-aix5.2.0.0/bin/ -B/farm/dje/install/powerpc-ibm-aix5.2.0.0-20050720/powerpc-ibm-aix5.2.0.0/lib/ -isystem /farm/dje/install/powerpc-ibm-aix5.2.0.0-20050720/powerpc-ibm-aix5.2.0.0/include -isystem /farm/dje/install/powerpc-ibm-aix5.2.0.0-20050720/powerpc-ibm-aix5.2.0.0/sys-include CFLAGS=-O2 -g -O2 CXXFLAGS=-g -O2 CFLAGS_FOR_BUILD=-g -O2 CFLAGS_FOR_TARGET=-O2 -g -O2 INSTALL=/farm/dje/src/src/install-sh -c INSTALL_DATA=/farm/dje/src/src/install-sh -c -m 644 INSTALL_PROGRAM=/farm/dje/src/src/install-sh -c INSTALL_SCRIPT=/farm/dje/src/src/install-sh -c LDFLAGS= LIBCFLAGS=-O2 -g -O2 LIBCFLAGS_FOR_TARGET=-O2 -g -O2 MAKE=make MAKEINFO=makeinfo --split-size=500 PICFLAG= PICFLAG_FOR_TARGET= SHELL=/bin/sh RUNTESTFLAGS= exec_prefix=/farm/d! je/install/powerpc-ibm-aix5.2.0.0-20050720 infodir=/farm/dje/install/powerpc-ibm-aix5.2.0.0-20050720/info libdir=/farm/dje/install/powerpc-ibm-aix5.2.0.0-20050720/lib includedir=/farm/dje/install/powerpc-ibm-aix5.2.0.0-20050720/include prefix=/farm/dje/install/powerpc-ibm-aix5.2.0.0-20050720 tooldir=/farm/dje/install/powerpc-ibm-aix5.2.0.0-20050720/powerpc-ibm-aix5.2.0.0 gxx_include_dir=/farm/dje/install/powerpc-ibm-aix5.2.0.0-20050720/include/c++/4.1.0 AR=ar -X32_64 AS=/tmp/powerpc-ibm-aix5.2.0.0-20050720/./gcc/as LD=ld RANLIB=ranlib NM=/tmp/powerpc-ibm-aix5.2.0.0-20050720/./gcc/nm -B -X32_64 NM_FOR_BUILD= NM_FOR_TARGET=/tmp/powerpc-ibm-aix5.2.0.0-20050720/./gcc/nm -B -X32_64 DESTDIR= WERROR= all-recursive make[2]: Entering directory `/tmp/powerpc-ibm-aix5.2.0.0-20050720/powerpc-ibm-aix5.2.0.0/libstdc++-v3' Making all in include /tmp/powerpc-ibm-aix5.2.0.0-20050720/powerpc-ibm-aix5.2.0.0/libstdc++-v3/include make[3]: Entering directory `/tmp/powerpc-ibm-aix5.2.0.0-20050720/powerpc-ibm-aix5.2.0.0/libstdc++-v3/include' cd ./ext/pb_assoc for h in /farm/dje/src/src/libstdc++-v3/include/ext/pb_assoc/detail/tree_assoc_cntnr/constructor_destructor_fn_imps.hpp /farm/dje/src/src/libstdc++-v3/include/ext/pb_assoc/detail/type_utils.hpp /farm/dje/src/src/libstdc++-v3/include/ext/pb_assoc/detail/order_statistics_imp.hpp /farm/dje/src/src/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/d_find_fn_imps.hpp /farm/dje/src/src/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/d_insert_fn_imps.hpp /farm/dje/src/src/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/extract_key.hpp /farm/dje/src/src/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/erase_fn_imps.hpp /farm/dje/src/src/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/insert_fn_imps.hpp /farm/dje/src/src/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/constructor_destructor_fn_imps.hpp /farm/dje/src/src/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/info_fn_imps.hpp /farm/! dje/src/src/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/iterators_fn_imps.hpp /farm/dje/src/src/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/d_extract_key.hpp /farm/dje/src/src/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/constructors_destructor_fn_imps.hpp /farm/dje/src/src/libstdc++-v3/include/ext/pb_assoc/detail/splay_tree_/erase_fn_imps.hpp /farm/dje/src/src/libstdc++-v3/include/ext/pb_assoc/detail/splay_tree_/splay_tree_.hpp /farm/dje/src/src/libstdc++-v3/include/ext/pb_assoc/detail/splay_tree_/node.hpp /farm/dje/src/src/libstdc++-v3/include/ext/pb_assoc/detail/splay_tree_/insert_fn_imps.hpp /farm/dje/src/src/libstdc++-v3/include/ext/pb_assoc/detail/splay_tree_/find_fn_imps.hpp /farm/dje/src/src/libstdc++-v3/include/ext/pb_assoc/detail/splay_tree_/splay_fn_imps.hpp /farm/dje/src/src/libstdc++-v3/include/ext/pb_assoc/detail/splay_tree_/split_join_fn_imps.hpp /farm/dje/src/src/libstdc++-v3/include/ext/pb_assoc/detail/splay_tree_! /info_fn_imps.hpp /farm/dje/src/src/libstdc++-v3/include/ext/p! b_assoc/ detail/splay_tree_/debug_fn_imps.hpp /farm/dje/src/src/libstdc++-v3/include/ext/pb_assoc/detail/splay_tree_/constructors_destructor_fn_imps.hpp /farm/dje/src/src/libstdc++-v3/include/ext/pb_assoc/detail/typelist/typelist_transform.hpp /farm/dje/src/src/libstdc++-v3/include/ext/pb_assoc/detail/typelist/typelist_apply.hpp /farm/dje/src/src/libstdc++-v3/include/ext/pb_assoc/detail/typelist/typelist_filter.hpp /farm/dje/src/src/libstdc++-v3/include/ext/pb_assoc/detail/typelist/typelist_at_index.hpp /farm
[Bug debug/21828] [4.0/4.1 Regression] debug info omitted for uninitialized variables
--- Additional Comments From mark at codesourcery dot com 2005-07-20 14:40 --- Subject: Re: [4.0/4.1 Regression] debug info omitted for uninitialized variables jakub at redhat dot com wrote: --- Additional Comments From jakub at redhat dot com 2005-07-20 11:41 --- I have done a binary search and at least for the failures and at least those problems mentioned in PR c++/18556 are fixed by PR middle-end/17799 without the need for PR c++/18556 patch. Now, the question is I think if there is a testcase that still needs PR c++/18556 patch. If not, at least for gcc-4_0-branch IMHO the easiest would be simply to revert that patch. If yes, but it is C++ only and there can't be a case when something like that is needed in C, a quick fix would be /* Do not emit debug information about variables that are in static storage, but not defined. */ if (TREE_CODE (decl) == VAR_DECL + (cgraph_global_info_ready || !flag_unit_at_a_time) TREE_STATIC (decl) !TREE_ASM_WRITTEN (decl)) DECL_IGNORED_P (decl) = 1; so we would not force no debugging for a var decl that has not been written, unless cgraph_optimize has been called already or -fno-unit-at-a-time. I will look at this in more detail today. Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21828
[Bug tree-optimization/22438] [4.1 Regression] ICE SEGV in is_gimple_variable at tree-gimple.c:239
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-07-20 14:46 ---
// even smaller testcase, compile with -O1:
int foo (char k)
{
int i = 0, j;
for (j = 0; j 10; j++)
i += k;
return i;
}
--
What|Removed |Added
GCC target triplet|x86_64-*-linux-gnu |
Last reconfirmed|2005-07-12 22:13:17 |2005-07-20 14:46:59
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22438
[Bug bootstrap/22569] New: 4.1-20050716 bootstrap failure
When trying to bootstrap new GCC 4.1 20050716 I get this: test -f config.h || (rm -f stamp-h1 make stamp-h1) make[1]: Leaving directory `/mnt/lfs/usr/build/gcc-4.1-20050716/host-i686-pc-linux-gnu/libcpp' Bootstrapping the compiler make[1]: Entering directory `/mnt/lfs/usr/build/gcc-4.1-20050716/gcc' make[1]: *** No rule to make target `bootstrap'. Stop. make[1]: Leaving directory `/mnt/lfs/usr/build/gcc-4.1-20050716/gcc' make: *** [bootstrap] Error 2 But look at this: [EMAIL PROTECTED]:/mnt/lfs/build/gcc-4.1-20050716 ls -l gcc/ | grep Makefile -rw-r--r-- 1 lfs lfs 194866 Jul 20 17:12 Makefile.in There is just no Makefile! I've configured GCC with ./configure --prefix=/tools \ --libexecdir=/tools/lib --with-local-prefix=/tools \ --disable-nls --enable-shared --enable-languages=c Which is standard for LFS pass 1. GCC 3.4.3 works like charm, but I think it's a bug that should be fixed. Host system is SuSE 9.1, GCC 3.3.3, Make 3.80, Binutils 2.15.90.0.1.1 (2.16.91.0.1 in LFS). -- Summary: 4.1-20050716 bootstrap failure Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rik at osrc dot info CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22569
[Bug tree-optimization/22564] [4.1 Regression] Compilation time increased about 11%
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-20 15:08 --- Also is the -O3 from yesterday before tree-promote-statics was removed, if so that precentage is misleading. Today's timing should come back down to around 10%. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22564
[Bug rtl-optimization/22568] Should use cmov in some stituations
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-20 15:11 --- IIRC ifcvt is not smart enough to do this. Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Component|c++ |rtl-optimization Ever Confirmed||1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2005-07-20 15:11:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22568
[Bug bootstrap/22569] 4.1-20050716 bootstrap failure
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-20 15:14 --- Almost nobody builds in the src directory which is why this is known to break every once in a while -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22569
[Bug target/21149] invalid code generation for _mm_movehl_ps SSE intrisinc
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-20 15:20 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01318.html. -- What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||07/msg01318.html Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||patch Last reconfirmed|-00-00 00:00:00 |2005-07-20 15:20:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21149
[Bug tree-optimization/22438] [4.1 Regression] ICE SEGV in is_gimple_variable at tree-gimple.c:239
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru 2005-07-20 15:26 --- setting severety to 'critical' because fails almost everywhere with -O1 -- What|Removed |Added Severity|normal |critical http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22438
[Bug libfortran/22570] New: Null Characters instead of blanks in text output.
I down loaded and built gfortran today on Suse Linux with - configure --prefix=/home/dir/gfortran --enable-languages=c,f95 make -j 4 make install The first problem was that it did not find the shared libraries until I set setenv LD_LIBRARY_PATH ~/gfortran/lib Then when the program did run the output had null characters in the place blanks for some of the 21x format statements. Here is the sequence and a hex dump of the output - dir/tests gfortran -o write01 write01.f dir/tests write01 out STOP 0 dir/tests cat out 1 ** ** ** ** ** ** ** ** ** ** aad nnnn aa ** ** dd nnn nn ** **aaaa dd dd ii nn aa aa** **aaaa ddddiinn nn nn aa aa** **aaaa ddddiinn nnnn aa aa** ** ddddiinn nn nn ** dir/tests dump -i out File name: out Block number: 0 Byte number: 0 31 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 00 20 1... ... 0010 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0020 20 20 20 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a * 0030 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 0040 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 0050 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 0060 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 0070 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 0a ***. 0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0090 00 00 00 00 00 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a .*** 00a0 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 00b0 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 00c0 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 00d0 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 00e0 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 00f0 2a 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 *... File name: out Block number: 1 Byte number: 256 00 00 00 00 00 00 00 2a 2a 20 20 20 20 20 20 20 ...* * 0010 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0020 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0030 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0040 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0050 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0060 20 2a 2a 0a 00 00 00 00 00 00 00 00 00 00 00 00 **. 0070 00 00 00 00 00 00 00 00 00 2a 2a 20 20 20 20 20 .** 0080 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0090 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 00a0 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 00b0 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 00c0 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 00d0 20 20 20 2a 2a 0a 00 00 00 00 00 00 00 00 00 00 **... 00e0 00 00 00 00 00 00 00 00 00 00 2a 2a 0a 00 00 00 ..** 00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 q dir/tests cat write01.f program main write(6,2000) stop 2000 format (1h1,/,21x,92(1h*),/,21x,92(1h*),/,2(21x,2h**, 1 88x,2h**,/), 2 20x,2h**,/,2(21x,2h**,88x,2h**,/),21x,2h**,9x, 310(1ha),4x,9(1hd),6x,12(1hi),3x,2hnn,8x,2hnn,4x,10(1ha),9x,2h**,/, 4 21x,2h**,8x,12(1ha),3x,10(1hd),5x,12(1hi),3x,3hnnn,7x,2hnn,3x, 5 12(1ha),8x,2h**,/,21x,2h**,8x,2haa,8x,2haa,3x,2hdd,7x,2hdd,9x, 6 2hii,8x,4(1hn),6x,2hnn,3x,2haa,8x,2haa,8x,2h**,/,21x,2h**,8x, 7 2haa,8x,2haa,3x,2hdd,8x,2hdd,8x,2hii,8x,2hnn,1x,2hnn,5x,2hnn,3x, 82haa,8x,2haa,8x,2h**,/,21x,2h**,8x,2haa,8x,2haa,3x,2hdd,8x,2hdd, 9 8x,2hii,8x,2hnn,2x,2hnn,4x,2hnn,3x,2haa,8x,2haa,8x,2h**,/,21x,2h* 1*,8x,12(1ha),3x,2hdd,8x,2hdd,8x,2hii,8x,2hnn,3x,2hnn,3x,2hnn,3x, 2 12(1ha),8x,2h**) end -- Summary: Null Characters instead of blanks in text output. Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal
[Bug c++/22566] Incorrect overload resolution on mutable field.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-20 15:36 --- *** This bug has been marked as a duplicate of 9925 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22566
[Bug c++/9925] ostrstream (buf, size) ... does not work properly
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-20 15:36 --- *** Bug 22566 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||suckfish at ihug dot co dot ||nz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9925
[Bug bootstrap/22569] 4.1-20050716 bootstrap failure
--- Additional Comments From rik at osrc dot info 2005-07-20 15:36 --- (In reply to comment #1) Almost nobody builds in the src directory which is why this is known to break every once in a while Aha... Damn, it looks that *now* I understand what it is to build outside the source tree... And it's just passed that point in compilation. Thank you very much for your attention to such foolish reports. :) -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22569
[Bug libfortran/16435] gfortran X edit descriptor failure: test f77-edit-x-out.f
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-20 15:38 --- (In reply to comment #9) I can help you with a test case if you need it. Yup, can't do a durned thing unless you show me where it hurts. I checked every aspect of the standard that I could. I think PR 22570 is an example of the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16435
[Bug libfortran/22570] Null Characters instead of blanks in text output.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-20 15:41 --- Confirmed, I think this was caused by: 2005-07-12 Paul Thomas [EMAIL PROTECTED] PR libfortran/16435 * transfer.c (formatted_transfer): Correct the problems with X- and T-editting that caused TLs followed by TRs to overwrite data, which caused NIST FM908.FOR to fail on many tests. (data_transfer_init): Zero X- and T-editting counters at the start of formatted IO. * write.c (write_x): Write specified number of skips with specified number of spaces at the end. -- What|Removed |Added CC||pault at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-07-20 15:41:58 date|| Version|4.0.0 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22570
[Bug fortran/22571] New: error needed
related to inlining of fortran functions : http://gcc.gnu.org/ml/gcc/2005-07/msg00860.html the following code is non-standard (but gfortran 'fails' to generate an error): subroutine a(p) type t integer :: t1 end type type(t) :: p p%t1 = 42 end subroutine subroutine b type u integer :: u1 end type type (u) :: q call a(q) print * q%u1 end subroutine NAG: Error: mytest.f90: Argument P (no. 1) in reference to A from B has the wrong data type LAHEY:line 14: Argument number '1' type of procedure 'a' shall be the same between definition and reference. Only the following is accepted by both compilers (and is standard conforming): subroutine a(p) type t sequence integer :: t1 end type type(t) :: p p%t1 = 42 end subroutine subroutine b type t sequence integer :: t1 end type type (t) :: q call a(q) end subroutine in particular same name of the types, sequence type, and same name of the components, see 4.4.2 for a precise definition about when two derived types are the same. Joost -- Summary: error needed Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22571
[Bug fortran/21875] [meta-bug] NIST test suite failures
--- Additional Comments From janis at gcc dot gnu dot org 2005-07-20 15:54 --- After I sent the test case in comment #6 I realized that it failed with other versions as well. The input line from comment #8 is the important one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21875
[Bug fortran/22571] error needed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-20 15:55 --- Hmm, ICC accepts the code too. -- What|Removed |Added Keywords||accepts-invalid, diagnostic http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22571
[Bug libfortran/22570] Null Characters instead of blanks in text output.
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-07-20 16:35 --- (In reply to comment #1) Confirmed, I think this was caused by: 2005-07-12 Paul Thomas [EMAIL PROTECTED] It sure as heck looks like me. I'm on to it! Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22570
[Bug libfortran/16435] gfortran X edit descriptor failure: test f77-edit-x-out.f
--- Additional Comments From stevenb at suse dot de 2005-07-20 16:49 --- Subject: Re: gfortran X edit descriptor failure: test f77-edit-x-out.f On Wednesday 20 July 2005 06:21, Paul Thomas wrote: Please send me the test cases and preferably, post them on Bugzilla. This is now http://gcc.gnu.org/PR22570. Gr. Steven -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16435
[Bug tree-optimization/22564] [4.1 Regression] Compilation time increased about 11%
--- Additional Comments From giovannibajo at libero dot it 2005-07-20 17:32 --- OK thanks. But let me stress one point: IMHO the graphs suggest that the daily bugfixes increased the compilation time day after day. In those days, we added something like 20 new projects to GCC (new optimization passes, algorithms and features). So it is kind of normal that new passes slow down the compiler day after day. Nonetheless, if you find specific testcases, we can probably optimize compile time here and there to compensate the general intrinsic slowdown. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22564
[Bug fortran/22572] New: Double occurrence of matmul intrinsic not optimised
GNU Fortran 95 (GCC 4.1.0 20050715 (experimental)), when run with the options -Wall -O3 -march=pentium4 -S, optimises one of the two calls to the sin intrinsic away in the following function: function optsin (x) implicit none double precision :: optsin double precision, intent(in) :: x optsin = sin(x) / (1 + sin(x)) end function optsin In the equivalent function function optmatmul (a, b, ni, nj) implicit none integer, intent(in) :: ni, nj double precision :: optmatmul(ni, nj) double precision, intent(in) :: a(ni, nj), b(ni, nj) optmatmul = matmul(a, b) / (1 + matmul(a, b)) end function optmatmul the two calls to matmul both remain present in the assembler output, although they are known to return the same result. -- Summary: Double occurrence of matmul intrinsic not optimised Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: schnetter at aei dot mpg dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22572
[Bug fortran/22572] Double occurrence of matmul intrinsic not optimised
-- What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22572
[Bug fortran/22572] Double occurrence of matmul intrinsic not optimised
-- What|Removed |Added Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22572
[Bug c++/22573] New: typedef in class scope not reported by error message
Consider the following code snippet:
--
namespace N {
typedef int Int;
struct A {
typedef float Float;
void f(Int, Float);
};
}
int main() {
N::A a;
a.f(1);
return 0;
}
--
The command
g++ -c gccBug1.cxx
produces the error message
gccBug1.cxx: In function 'int main()':
gccBug1.cxx:11: error: no matching function for call to 'N::A::f(int)'
gccBug1.cxx:5: note: candidates are: void N::A::f(N::Int, float)
The signature reported for the candidate f uses the typedef name from the
namespace-scope typedef but not from the class-scope typedef.
-
I'm using gcc version 4.0.1 configured like this
../src/configure -v --enable-languages=c,c++,java,f95,objc,ada,treelang
--prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib
--enable-nls --without-included-gettext --enable-threads=posix
--program-suffix=-4.0 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt
--enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm
--enable-java-awt=gtk --enable-mpfr --disable-werror --enable-checking=release
i486-linux
though the bug does not seem to depend on the platform or configuration at all.
--
Summary: typedef in class scope not reported by error message
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: brad dot king at kitware dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i486-linux
GCC host triplet: i486-linux
GCC target triplet: i486-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22573
[Bug c++/22573] typedef in class scope not reported by error message
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-20 18:08 --- Confirmed, before 3.4.0, we produced something different: t.cc: In function `int main()': t.cc:11: error: no matching function for call to `N::A::f(int)' t.cc:5: error: candidates are: void N::A::f(int, float) Which is really much worse. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||diagnostic Known to fail||3.4.0 4.0.0 4.1.0 Last reconfirmed|-00-00 00:00:00 |2005-07-20 18:08:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22573
[Bug c++/22573] typedef in class scope not reported by error message
--- Additional Comments From giovannibajo at libero dot it 2005-07-20 18:22 --- Absolutely not! There is no best way: sometimes it is better to go through the typedef, sometimes it is better to print the typedef. To tell you the truth, I consider the fact that GCC prints both a *feature*. However, we should decide whether the inconsistency is a bug. Gaby? -- What|Removed |Added CC||gdr at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22573
[Bug tree-optimization/22574] New: ICE when using -fwhole-program
When trying to compile xterm-202 using -fwhole-program --combine I get an internal compiler error: VTPrsTbl.c:7215: internal compiler error: in propagate_bits, at ipa-reference.c:669 This worked fine with gcc from CVS about 2 weeks ago, it fails now. The command line used is: gcc -fwhole-program --combine -I. -I. -DHAVE_CONFIG_H -I/usr/X11R6/include -I/usr/include/freetype2 -I/usr/include/freetype2/config -I/usr/X11R6/include -I. -I/usr/include/freetype2 -I/usr/include/freetype2/config -I./exports/include/X11 -I/usr/X11R6/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -DFUNCPROTO=15 -DNARROWPROTO -DXFREE86_FT2 -DOSMAJORVERSION=2 -DOSMINORVERSION=6 -I/usr/X11R6/include -D_GNU_SOURCE -DPROJECTROOT='/usr/X11R6' -D__vendorversion__='Version 6.8.2 X.Org' -g -O2 -L/usr/X11R6/lib -o xterm button.i charproc.i charsets.i cursor.i data.i doublechr.i fontutils.i input.i main.i menu.i misc.i print.i ptydata.i screen.i scrollbar.i tabs.i util.i xstrings.i VTPrsTbl.i -L/usr/X11R6/lib -L/usr/X11R6/lib -lXft -lX11 -lfreetype -lfontconfig -L/usr/X11R6/lib -lXrender -lXaw -lXmu -lXext -lXt -lSM -lICE -lX11 -ltermcap I will attach the preprocessed sources. -- Summary: ICE when using -fwhole-program Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dann at godzilla dot ics dot uci dot edu CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22574
[Bug tree-optimization/22574] ICE when using -fwhole-program
--- Additional Comments From dann at godzilla dot ics dot uci dot edu 2005-07-20 18:29 --- Created an attachment (id=9308) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9308action=view) Preprocessed sources to reproduce the bug (tar.bz2 file) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22574
[Bug c++/22575] New: immutable object placed in .bss section.
class obj {
private:
int value;
private:
obj() { }
obj(int v) : value(v) { }
public:
int getValue() const { return value; }
const static obj seven;
};
const obj obj::seven = obj(7);
int getSeven()
{
return obj::seven.getValue();
}
gcc (3.3.6,4.1.0) places this immutable const static object
in .bss section and calls constructor(int) in .ctors section.
why it isn't placed in .rodata ?
--
Summary: immutable object placed in .bss section.
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pld-linux
GCC host triplet: i686-pld-linux
GCC target triplet: i686-pld-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22575
[Bug c++/22575] immutable object placed in .bss section.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-20 18:44 --- *** This bug has been marked as a duplicate of 4131 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22575
[Bug c++/4131] Why the C++ compiler don't place a const class object to .rodata section?
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-20 18:44 --- *** Bug 22575 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||pluto at agmk dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4131
[Bug c++/4131] Why the C++ compiler don't place a const class object to .rodata section?
--- Additional Comments From pluto at agmk dot net 2005-07-20 18:53 --- hmm, i think someone should reopen this bug. 4.1 is a good place for major changes in c++ front-end ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4131
[Bug c++/22575] immutable object placed in .bss section.
--- Additional Comments From schlie at comcast dot net 2005-07-20 18:57 --- (In reply to comment #1) *** This bug has been marked as a duplicate of 4131 *** Please correct me if I misunderstand, but it doen't seem reasonable to close this bug as won't fix, based on it being difficult to fix for v2.95? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22575
[Bug c++/4131] Why the C++ compiler don't place a const class object to .rodata section?
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-20 18:58 --- (In reply to comment #4) hmm, i think someone should reopen this bug. 4.1 is a good place for major changes in c++ front-end ;) Not any more since we are in stage3 already. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4131
[Bug c++/4131] Why the C++ compiler don't place a const class object to .rodata section?
--- Additional Comments From schlie at comcast dot net 2005-07-20 19:03 --- (In reply to comment #5) (In reply to comment #4) hmm, i think someone should reopen this bug. 4.1 is a good place for major changes in c++ front-end ;) Not any more since we are in stage3 already. - given that 4.1's front end has already evolved from that in 2.95, it's not clear that a conclusion based on 2.95 is even valid for 4.1. (so should no likely assumed as being so). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4131
[Bug tree-optimization/22574] ICE when using -fwhole-program
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-20 19:04 --- Reducing right now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22574
[Bug libfortran/22570] Null Characters instead of blanks in text output.
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-07-20
19:07 ---
Subject: Re: Null Characters instead of blanks in text
output.
pinskia at gcc dot gnu dot org wrote:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-20
15:41 ---
Confirmed, I think this was caused by:
2005-07-12 Paul Thomas [EMAIL PROTECTED]
Guilty, as charged.
Please find attached, ChangeLog entries, patch, the output that was
incorrect and now looks the same as ifc, plus a testcase.
I just never checked what slash editing did to the position counters.
duuuh!
Regtests OK on RH9.
OK for mainline and 4.0?
Paul T
PS Steven, it's not so much a one spacer but a one liner...
2005-07-19 Paul Thomas [EMAIL PROTECTED]
PR fortran/22570
* transfer.c (formatted_transfer): Correct the problem
with X- editting due to slashes not zeroing the space
and maximum position counters.
.
PR fortran/22570
* gfortran.dg/x_slash.f: New Test.
Index: gcc/libgfortran/io/transfer.c
===
RCS file: /cvs/gcc/gcc/libgfortran/io/transfer.c,v
retrieving revision 1.48
diff -c -3 -p -r1.48 transfer.c
*** gcc/libgfortran/io/transfer.c14 Jul 2005 06:21:58 -1.48
--- gcc/libgfortran/io/transfer.c20 Jul 2005 17:57:48 -
*** formatted_transfer (bt type, void *p, in
*** 776,781
--- 776,782
case FMT_SLASH:
consume_data_flag = 0 ;
+ max_pos = skips = pending_spaces = 0;
next_record (0);
break;
Now results in..
1
**
**
**
**
**
**
**
**
**
** aad
nnnnaa **
** dd
nnn nn **
**aaaa dd dd
ii nn aaaa**
**aaaa dddd
iinn nn nn aaaa**
**aaaa dddd
iinn nnnn aaaa**
** dddd
iinn nn nn **
Test case
c { dg-do run }
c This program tests the fix to PR22570.
c
c provided by Paul Thomas - [EMAIL PROTECTED]
c
program x_slash
character*60 a
open (10, status=scratch)
write (10, 100)
100 format (1h1,59x,1h*,/,60x,/,58x,1h*,/)
rewind (10)
read (10, 200) a
read (10, 200) a
read (10, 200) a
200 format (a60)
close (10)
if (ichar(a(10:10)).ne.32) call abort ()
end
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22570
Re: [Bug c++/4131] Why the C++ compiler don't place a const class object to .rodata section?
On Jul 20, 2005, at 3:03 PM, schlie at comcast dot net wrote: - given that 4.1's front end has already evolved from that in 2.95, it's not clear that a conclusion based on 2.95 is even valid for 4.1. (so should no likely assumed as being so). It still is true since the front-end still does exactly what it did in 2.95 for this testcase and there have been no changes in this area really. Since the mainline is in stage3 which means no more improvements except for fixing bugs which are either regressions or non enhancement bugs. -- Pinski
[Bug c++/4131] Why the C++ compiler don't place a const class object to .rodata section?
--- Additional Comments From pinskia at physics dot uc dot edu 2005-07-20 19:11 --- Subject: Re: Why the C++ compiler don't place a const class object to .rodata section? On Jul 20, 2005, at 3:03 PM, schlie at comcast dot net wrote: - given that 4.1's front end has already evolved from that in 2.95, it's not clear that a conclusion based on 2.95 is even valid for 4.1. (so should no likely assumed as being so). It still is true since the front-end still does exactly what it did in 2.95 for this testcase and there have been no changes in this area really. Since the mainline is in stage3 which means no more improvements except for fixing bugs which are either regressions or non enhancement bugs. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4131
[Bug SWING/22567] JCheckBox's check box is missing
--- Additional Comments From roman at kennke dot org 2005-07-20 19:26 --- I'll take care if this. I already checked in the icon that should display the CheckBox in the MetalLookAndFeel, now it only needs to get wired to the actual CheckBox. Note that there is no CheckBox icon in the BasicLookAndFeel for JCheckBox. Someone with the proper permissions could assign this bug to me, set it to CONFIRMED and give me some more permissions please? ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22567
[Bug c/22576] New: ICE with simple factorial program compiled with -ffast-math on gcc 4.0.2
Hello. Sorry if the summary is a little vague, I dont really know a whole bunch about gcc terminology ;) So anyway, I wrote a simple program in C that computes the factorials of numbers 1 through 100 (yes, after 7 they get super big). When this program is compiled as gcc -ffast-math factorial.c I get an ICE; [EMAIL PROTECTED]:~/c$ gcc -Wall -ffast-math factorials.c factorials.c:8: warning: return type defaults to int factorials.c: In function main: factorials.c:24: internal compiler error: in instantiate_virtual_regs_lossage, at function.c:1442 [EMAIL PROTECTED]:~/c$ gcc -dumpversion 4.0.2 This gcc is from Ubuntu-breezy, gcc-4.0 branch, CVS 20050718. Running on a Pentium 4. It told me to report this bug, so here I am :) Regardless of whether this can be done in a simpler manner, and I'm /sure/ it can, I dont think gcc should die because of it. The offending code is attached. -save-temps output also attached. -- Summary: ICE with simple factorial program compiled with -ffast- math on gcc 4.0.2 Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: black dot hole dot sun16 at gmail dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22576
[Bug c/22576] ICE with simple factorial program compiled with -ffast-math on gcc 4.0.2
--- Additional Comments From black dot hole dot sun16 at gmail dot com 2005-07-20 19:29 --- Created an attachment (id=9309) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9309action=view) bug causing program... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22576
[Bug c/22576] ICE with simple factorial program compiled with -ffast-math on gcc 4.0.2
--- Additional Comments From black dot hole dot sun16 at gmail dot com 2005-07-20 19:29 --- Created an attachment (id=9310) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9310action=view) -save-temps output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22576
[Bug c/22576] ICE with simple factorial program compiled with -ffast-math on gcc 4.0.2
--- Additional Comments From black dot hole dot sun16 at gmail dot com 2005-07-20 19:30 --- Created an attachment (id=9311) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9311action=view) -save-temps output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22576
[Bug c/22576] ICE with simple factorial program compiled with -ffast-math on gcc 4.0.2
--- Additional Comments From black dot hole dot sun16 at gmail dot com 2005-07-20 19:32 --- If it is at all relevant, I'm using the glibc that breezy provides (2.3.5). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22576
[Bug target/22576] ICE with simple factorial program compiled with -ffast-math on gcc 4.0.2
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-20 19:33 --- This is a target bug. -- What|Removed |Added Component|c |target GCC target triplet||i686-pc-linux-gnu Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22576
[Bug target/22576] ICE with simple factorial program compiled with -ffast-math on gcc 4.0.2
--- Additional Comments From black dot hole dot sun16 at gmail dot com 2005-07-20 19:33 --- Created an attachment (id=9312) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9312action=view) #included file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22576
[Bug AWT/16708] NullPointerException while creating an image with GTK peer
--- Additional Comments From fitzsim at redhat dot com 2005-07-20 19:39 --- Fixed by Sven de Marothy in GNU Classpath. Closing. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16708
[Bug AWT/17008] GdkGraphics: drawImage tries to cast Image to GtkImage.
--- Additional Comments From fitzsim at redhat dot com 2005-07-20 19:39 --- Fixed by Sven de Marothy in GNU Classpath. Closing. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17008
[Bug AWT/17060] AWT: problems with drawImage and transparent images
--- Additional Comments From fitzsim at redhat dot com 2005-07-20 19:40 --- Fixed by Sven de Marothy in GNU Classpath. Closing. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17060
[Bug AWT/17008] GdkGraphics: drawImage tries to cast Image to GtkImage.
-- What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17008
[Bug AWT/17060] AWT: problems with drawImage and transparent images
-- What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17060
[Bug AWT/19838] Repaint-Loop due to setBackground()
--- Additional Comments From fitzsim at redhat dot com 2005-07-20 19:41 --- Fixed by Sven de Marothy in GNU Classpath. Closing. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19838
[Bug AWT/19846] AWT Toolkit.createImage very slow
--- Additional Comments From fitzsim at redhat dot com 2005-07-20 19:42 --- Fixed by Sven de Marothy in GNU Classpath. Closing. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19846
[Bug AWT/19847] AWT drawImage fails to render transparent GIFs
--- Additional Comments From fitzsim at redhat dot com 2005-07-20 19:43 --- Fixed by Sven de Marothy in GNU Classpath. Closing. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19847
[Bug AWT/16708] NullPointerException while creating an image with GTK peer
-- What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16708
[Bug AWT/19838] Repaint-Loop due to setBackground()
-- What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19838
[Bug AWT/19846] AWT Toolkit.createImage very slow
-- What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19846
[Bug AWT/19847] AWT drawImage fails to render transparent GIFs
-- What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19847
[Bug c++/4131] Why the C++ compiler don't place a const class object to .rodata section?
--- Additional Comments From bangerth at dealii dot org 2005-07-20 19:47 --- It may be true that this bug isn't going to be fixed in this cycle, but there's no reason not to keep it open instead of suspending it. The suspend state is mean for PRs where we need external things to happen, such as a defect report to be accepted. This clearly isn't the case here. I'll close this PR and reopen 22575 instead. W. *** This bug has been marked as a duplicate of 22575 *** -- What|Removed |Added Status|SUSPENDED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4131
[Bug c++/22575] immutable object placed in .bss section.
--- Additional Comments From bangerth at dealii dot org 2005-07-20 19:47 --- *** Bug 4131 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||k_satoda at f2 dot dion dot ||ne dot jp http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22575
[Bug c++/22575] immutable object placed in .bss section.
--- Additional Comments From bangerth at dealii dot org 2005-07-20 19:48 --- This is a valid bug, however hard it may be to solve (see PR 4131). -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22575
[Bug c++/22575] immutable object placed in .bss section.
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-07-20 19:49:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22575
[Bug SWING/22567] JCheckBox's check box is missing
-- What|Removed |Added AssignedTo|graydon at redhat dot com |roman at kennke dot org Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-07-20 19:50:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22567
[Bug AWT/22163] scrollbars appear and disappear
-- What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-07-20 19:53:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22163
[Bug c++/22575] immutable object placed in .bss section.
-- What|Removed |Added Severity|normal |enhancement Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22575
[Bug libfortran/22570] Null Characters instead of blanks in text output.
--- Additional Comments From stevenb at suse dot de 2005-07-20 20:03 --- Subject: Re: Null Characters instead of blanks in text output. On Wednesday 20 July 2005 21:07, Paul Thomas wrote: pinskia at gcc dot gnu dot org wrote: --- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-20 15:41 --- Confirmed, I think this was caused by: 2005-07-12 Paul Thomas [EMAIL PROTECTED] Guilty, as charged. Please find attached, ChangeLog entries, patch, the output that was incorrect and now looks the same as ifc, plus a testcase. This still doesn't fix mgrid either. Gr. Steven -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22570
[Bug AWT/22162] double-click fails to select entire word
--- Additional Comments From fitzsim at redhat dot com 2005-07-20 20:04 --- The same problem occurs in standalone GTK text areas, so I'm going to close this as invalid here. If you feel strongly that the behaviour should be to select up to the next space we can re-file this in GNOME bugzilla under GTK. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22162
[Bug bootstrap/22577] New: [4.1 Regression] PA bootstrap fails
Bootstrap is failing on mainline on 20050720 on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11. hppa2.0w: /scratch/gcc/nightly-2005-07-20-mainline/src/gcc-mainline/gcc/libgcc2.c:661: internal compiler error: tree check: expected tree_list, have predecrement_expr in reloc_needed, at config/pa/pa.c:2003 hppa64: /scratch/gcc/nightly-2005-07-20-mainline/src/gcc-mainline/gcc/libgcc2.c:661: internal compiler error: tree check: expected tree_list, have try_finally in reloc_needed, at config/pa/pa.c:2003 The code in questions looks into CONSTRUCTORs, but wasn't updated by the CONSTRUCTOR patch. (I didn't spot any other problem references to CONSTRUCTOR in config/, but it needs checking.) -- Summary: [4.1 Regression] PA bootstrap fails Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org,giovannibajo at libero dot it http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22577
[Bug libfortran/22570] Null Characters instead of blanks in text output.
--- Additional Comments From stevenb at suse dot de 2005-07-20 20:17 --- Subject: Re: Null Characters instead of blanks in text output. On Wednesday 20 July 2005 22:03, Steven Bosscher wrote: On Wednesday 20 July 2005 21:07, Paul Thomas wrote: pinskia at gcc dot gnu dot org wrote: --- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-20 15:41 --- Confirmed, I think this was caused by: 2005-07-12 Paul Thomas [EMAIL PROTECTED] Guilty, as charged. Please find attached, ChangeLog entries, patch, the output that was incorrect and now looks the same as ifc, plus a testcase. This still doesn't fix mgrid either. FWIW I get the feeling that the sixtrack and mgrid problems are the same bug. For mgrid we have spurious '\0' characters in the output, and for sixtrack a read of an internal file with a format with an 'X' specifier in it (READ(5,'(18X,I4)') NNO) fails... I still haven't been able to reduce this to a useful testcase :-( Gr. Steven -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22570
[Bug target/22577] [4.1 Regression] PA bootstrap fails
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-20 20:18 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Component|bootstrap |target Ever Confirmed||1 GCC target triplet||hppa*-* Keywords||build, ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2005-07-20 20:18:51 date|| Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22577
[Bug AWT/21882] Wrong Frame size if a frame has been created previously
--- Additional Comments From fitzsim at redhat dot com 2005-07-20 20:24 --- I can't reproduce this. Closing. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME Summary|Wrong Frame size if a frame |Wrong Frame size if a frame |has been created previously |has been created previously http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21882
[Bug SWING/21880] javax.swing.text.JTextComponent has no read() method
--- Additional Comments From fitzsim at redhat dot com 2005-07-20 20:31 --- Fixed by classpath - libgcj merge. Closing. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21880
[Bug SWING/21880] javax.swing.text.JTextComponent has no read() method
-- What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21880
[Bug AWT/21882] Wrong Frame size if a frame has been created previously
-- What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21882
[Bug other/22533] [4.1 regression] ada / raised STORAGE_ERROR : stack overflow (or erroneous memory access)
-- What|Removed |Added Summary|ada / raised STORAGE_ERROR :|[4.1 regression] ada / |stack overflow (or erroneous|raised STORAGE_ERROR : stack |memory access) |overflow (or erroneous ||memory access) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22533
[Bug java/22578] New: should inline floatToIntBits et al
Currently Float and Double diverge from classpath. I think we could safely inline these methods wherever they are called, and then fully merge with Classpath. The result would not appreciably affect performance, I think (and these aren't called much anyway). -- Summary: should inline floatToIntBits et al Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tromey at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22578
[Bug other/22533] [4.1 regression] ada / raised STORAGE_ERROR : stack overflow (or erroneous memory access)
--- Additional Comments From pluto at agmk dot net 2005-07-20 20:41 --- known to work: 4.1.0-20050711 known to fail: 4.1.0-20050717+ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22533
[Bug libgcj/22579] New: URLClassLoader re-merge plan
Right now URLClassLoader diverges from Classpath. The primary reason for this is that we have our own special URL handlers which aren't appropriate for classpath. One approach to fixing this would be to break out the inner class URLLoaders into package-private classes and allow VMs to register other URLLoaders. -- Summary: URLClassLoader re-merge plan Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tromey at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22579
[Bug java/22578] should inline floatToIntBits et al
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-20 20:42 --- Confirmed, make sure they get inlined using either VIEW_CONVERT_EXPR or using an union, otherwise aliasing problems will show up. -- What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2005-07-20 20:42:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22578
