[Bug tree-optimization/19778] Unnecessary jumps for comparisons
--- Additional Comments From falk at debian dot org 2005-05-20 07:43 --- It's slightly improved now on mainline, but still an unneccesary branch: le1_bit: lda v0,1 lda t0,-1(a0) beq a0,L1 and a0,t0,t0 cmpeq t0,0,v0 L1: ret -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19778
[Bug rtl-optimization/21676] New: Optimizer regression: SciMark sparse matrix benchmark
I see a 14% slowdown with the SciMark sparse matrix multiplication benchmark when going from 3.4.3 to 4.0.0 on my Gentoo box. Flags are -O3 -march=athlon-xp -fomit-frame-pointer. I compiled and linked in one run of gcc, and ran the executable from the command line with "time". 4.0's performance gets better (closer to 3.4's, which remains roughly constant) as functions from the other files are moved into main.c. On those grounds, my own inexpert opinion is that this regression stems from function inlining. Earlier tests showed that the two versions are much closer when -fomit-frame-pointer isn't used. Will upload the preprocessed test cases that you're so fond of ;). -- Summary: Optimizer regression: SciMark sparse matrix benchmark Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jbucata at tulsaconnect dot com CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21676
[Bug rtl-optimization/21676] Optimizer regression: SciMark sparse matrix benchmark
--- Additional Comments From jbucata at tulsaconnect dot com 2005-05-20 08:34 --- Created an attachment (id=8933) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8933&action=view) preprocessed testcase files -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21676
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From lanius at gentoo dot org 2005-05-20 08:35 --- no workaround, the flag was just disabled on the affected architectures -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Additional Comments From mario dot tragni at planetek dot it 2005-05-20 08:40 --- (In reply to comment #2) > State-Changed-From-To: open->closed > State-Changed-Why: See any faq on numerical analysis that mentions the x86. > You are seeing the results of excess precision in the FPU. > Either change the rounding precision in the FPCR, or work > around the problem with -ffloat-store. > I had this bug on x86 architecture, with no optimization of the code (no -OX) and with float-store on. My workaround was to store the return of the double function in a auxliar double variable before comparison. Have you an other suggestion ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From pluto at agmk dot net 2005-05-20 08:58 --- (In reply to comment #54) > Subject: Re: libstdc++ headers should have pop/push > of the visibility around the declarations > > bernie at develer dot com wrote: > > > It's not a regresion, but it causes KDE to miscompile > > with GCC 4.0.0. Could we apply it for 4.0 anyway? > > No; we confine ourselves to regressions. If it wasn't a regression, > there must be some workaround that KDE is using for previous releases > that it can continue to use here. kde-core team already blacklisted gcc-4.0.0 due to detected bugs. they'll probably do the same thing with incoming 4.0.x releases due to gcc's rules which block major bugfixes != regression fixes. there is no logic reason for making workarounds for valid c++ code and releasing buggy 4.0.x branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From pluto at agmk dot net 2005-05-20 09:02 ---
(In reply to comment #52)
> Great! I forgot to thank you for all your testing efforts: thanks! (...)
i'll test these fixes on alpha/sparc{32,64} too in near feature.
i have machines but no time :/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From pcarlini at suse dot de 2005-05-20 09:03 --- FWIW, I agree, as far as the visibility issues are concerned (I don't want to say something more general): the issues are *long* standing, important projects are already using the features and nobody (almost ;) cares about the bugs in the existing implementation. This is BAD. Either we fix those bugs ASAP, everywhere the feature is present, or (we scrap away everything and/or advertise the feature itself as broken). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug tree-optimization/21638] [4.1 regression] ADDR_EXPR invariancy not recomputed
--- Additional Comments From giovannibajo at libero dot it 2005-05-20 09:54 --- A patch was posted by Richard Sandiford: http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02029.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21638
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Additional Comments From cognot at earthdecision dot com 2005-05-20
10:03 ---
(In reply to comment #59)
>
> I had this bug on x86 architecture, with no optimization of the code (no -OX)
> and with float-store on. My workaround was to store the return of the double
> function in a auxliar double variable before comparison.
> Have you an other suggestion ?
>
The way I've "fixed" (more like avoided) this problem is to have:
#include
void set_math_double_precision() {
fpu_control_t fpu_control = 0x027f ;
_FPU_SETCW(fpu_control);
}
and make sure this function is called before doing any FP operations. It only
needs to be called once.
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug libstdc++/21677] New: simply including ext/bitmap_allocator.h causes link-time errors
Compiling the two following trivial files together causes link-time errors due
to multiply-defined symbols in bitmap_allocator.h. What am I missing here?
// t.cc
#include
int main ()
{
}
// EOF
// t1.cc
#include
// EOF
$ /usr/local/gcc-3.4.4/bin/g++ -v -save-temps t.cc t1.cc
Reading specs from
/usr/local0/gcc-3.4.4/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/specs
Configured with: ../configure --prefix=/usr/local/gcc-3.4.4
--enable-threads=posix --enable-version-specific-runtime-libs
--enable-languages=c,c++,f77
Thread model: posix
gcc version 3.4.4
/usr/local0/gcc-3.4.4/bin/../libexec/gcc/i686-pc-linux-gnu/3.4.4/cc1plus -E
-quiet -v -iprefix /usr/local0/gcc-3.4.4/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/
-D_GNU_SOURCE t.cc -mtune=pentiumpro -o t.ii
ignoring nonexistent directory
"/usr/local0/gcc-3.4.4/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/../../../../i686-pc-linux-gnu/include"
ignoring duplicate directory
"/usr/local/gcc-3.4.4/lib/gcc/i686-pc-linux-gnu/3.4.4/include/c++"
ignoring duplicate directory
"/usr/local/gcc-3.4.4/lib/gcc/i686-pc-linux-gnu/3.4.4/include/c++/i686-pc-linux-gnu"
ignoring duplicate directory
"/usr/local/gcc-3.4.4/lib/gcc/i686-pc-linux-gnu/3.4.4/include/c++/backward"
ignoring duplicate directory
"/usr/local/gcc-3.4.4/lib/gcc/i686-pc-linux-gnu/3.4.4/include"
ignoring nonexistent directory
"/usr/local/gcc-3.4.4/lib/gcc/i686-pc-linux-gnu/3.4.4/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local0/gcc-3.4.4/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/include/c++
/usr/local0/gcc-3.4.4/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/include/c++/i686-pc-linux-gnu
/usr/local0/gcc-3.4.4/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/include/c++/backward
/usr/local0/gcc-3.4.4/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/include
/usr/local/include
/usr/local/gcc-3.4.4/include
/usr/include
End of search list.
/usr/local0/gcc-3.4.4/bin/../libexec/gcc/i686-pc-linux-gnu/3.4.4/cc1plus
-fpreprocessed t.ii -quiet -dumpbase t.cc -mtune=pentiumpro -auxbase t -version
-o t.s
GNU C++ version 3.4.4 (i686-pc-linux-gnu)
compiled by GNU C version 3.4.4.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
as -V -Qy -o t.o t.s
GNU assembler version 2.15 (i386-linux) using BFD version 2.15
/usr/local0/gcc-3.4.4/bin/../libexec/gcc/i686-pc-linux-gnu/3.4.4/cc1plus -E
-quiet -v -iprefix /usr/local0/gcc-3.4.4/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/
-D_GNU_SOURCE t1.cc -mtune=pentiumpro -o t1.ii
ignoring nonexistent directory
"/usr/local0/gcc-3.4.4/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/../../../../i686-pc-linux-gnu/include"
ignoring duplicate directory
"/usr/local/gcc-3.4.4/lib/gcc/i686-pc-linux-gnu/3.4.4/include/c++"
ignoring duplicate directory
"/usr/local/gcc-3.4.4/lib/gcc/i686-pc-linux-gnu/3.4.4/include/c++/i686-pc-linux-gnu"
ignoring duplicate directory
"/usr/local/gcc-3.4.4/lib/gcc/i686-pc-linux-gnu/3.4.4/include/c++/backward"
ignoring duplicate directory
"/usr/local/gcc-3.4.4/lib/gcc/i686-pc-linux-gnu/3.4.4/include"
ignoring nonexistent directory
"/usr/local/gcc-3.4.4/lib/gcc/i686-pc-linux-gnu/3.4.4/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local0/gcc-3.4.4/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/include/c++
/usr/local0/gcc-3.4.4/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/include/c++/i686-pc-linux-gnu
/usr/local0/gcc-3.4.4/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/include/c++/backward
/usr/local0/gcc-3.4.4/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/include
/usr/local/include
/usr/local/gcc-3.4.4/include
/usr/include
End of search list.
/usr/local0/gcc-3.4.4/bin/../libexec/gcc/i686-pc-linux-gnu/3.4.4/cc1plus
-fpreprocessed t1.ii -quiet -dumpbase t1.cc -mtune=pentiumpro -auxbase t1
-version -o t1.s
GNU C++ version 3.4.4 (i686-pc-linux-gnu)
compiled by GNU C version 3.4.4.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
as -V -Qy -o t1.o t1.s
GNU assembler version 2.15 (i386-linux) using BFD version 2.15
/usr/local0/gcc-3.4.4/bin/../libexec/gcc/i686-pc-linux-gnu/3.4.4/collect2
--eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o
/usr/lib/crti.o
/usr/local0/gcc-3.4.4/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/crtbegin.o
-L/usr/local0/gcc-3.4.4/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4
-L/usr/local0/gcc-3.4.4/bin/../lib/gcc
-L/usr/local/gcc-3.4.4/lib/gcc/i686-pc-linux-gnu/3.4.4
-L/usr/local0/gcc-3.4.4/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/../../..
-L/usr/local/gcc-3.4.4/lib/gcc/i686-pc-linux-gnu/3.4.4/../../.. t.o t1.o
-lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/usr/local0/gcc-3.4.4/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/crtend.o
/usr/lib/crtn.o
t1.o(.bss+0x0): multiple definition of `__gnu_cxx::_OOM_handler::_S_old_handler'
t.o(.bss+0x0): first defined here
t1.o(.bss+0x4): multiple definition of `__gnu_cxx::_OOM_handler::_S_handled_oom'
t.o(.bss+0x4): first defined here
t1.o(.bss+0x8): multiple definition of `
[Bug libstdc++/21677] simply including ext/bitmap_allocator.h causes link-time errors
--- Additional Comments From oms at home dot nl 2005-05-20 12:24 --- Created an attachment (id=8935) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8935&action=view) test source 1 of 2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21677
[Bug libstdc++/21677] simply including ext/bitmap_allocator.h causes link-time errors
--- Additional Comments From oms at home dot nl 2005-05-20 12:25 --- Created an attachment (id=8936) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8936&action=view) test source 2 of 2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21677
[Bug c/21678] New: Using inline + always_inline disables warnings about missing return statements
There is a weird interaction in using both inline and always_inline:
=
static inline __attribute__((always_inline)) int foo(int a)
{
if (a==0)
return 0;
}
=
Compiling with -Wall gives no warning. If you remove either "inline" or the
attribute "always_inline", you get the expected warning:
thermo.i: In function 'foo':
thermo.i:5: warning: control reaches end of non-void function
This happens on both GCC 3.4.3 and 4.1.0.
--
Summary: Using inline + always_inline disables warnings about
missing return statements
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: giovannibajo at libero dot it
CC: batt at develer dot com,bernie at develer dot com,gcc-
bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21678
[Bug libstdc++/21677] simply including ext/bitmap_allocator.h causes link-time errors
--- Additional Comments From pcarlini at suse dot de 2005-05-20 12:54 --- I cannot reproduce the problem: besides, we have simple testcases in our testsuite for this usage and we have no problems on many different architectures. Which version of binutils are you using? -- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21677
[Bug libstdc++/21677] simply including ext/bitmap_allocator.h causes link-time errors
--- Additional Comments From pcarlini at suse dot de 2005-05-20 13:01 --- Can be related to 20979, fixed for 4.0 and mainline. Still cannot reproduce. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21677
[Bug libstdc++/21677] simply including ext/bitmap_allocator.h causes link-time errors
--- Additional Comments From oms at home dot nl 2005-05-20 13:14 --- 2.15. It's an up-to-date debian testing install, nothing special. # ld --version GNU ld version 2.15 Copyright 2002 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. # dpkg -s binutils Package: binutils Status: install ok installed Priority: standard Section: devel Installed-Size: 5972 Maintainer: James Troup <[EMAIL PROTECTED]> Architecture: i386 Version: 2.15-5 Provides: elf-binutils Depends: libc6 (>= 2.3.2.ds1-4) Suggests: binutils-doc (= 2.15-5) Conflicts: gas, elf-binutils, modutils (<< 2.4.19-1) Description: The GNU assembler, linker and binary utilities The programs in this package are used to assemble, link and manipulate binary and object files. They may be used in conjunction with a compiler and various libraries to build programs. # -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21677
[Bug c++/16171] [ABI] Problems with standard names in different namespaces
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-05-20
13:36 ---
The original testcase and the testcase from comment #2 compile on mainline.
The underlying ABI problem still remains, however.
The following updated testcase still gives assembler errors on mainline:
===
namespace std
{
template struct char_traits;
template struct basic_iostream { basic_iostream(){} };
basic_iostream > s1;
}
template struct basic_iostream { basic_iostream(){} };
basic_iostream > s2;
===
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16171
[Bug libstdc++/21677] simply including ext/bitmap_allocator.h causes link-time errors
--- Additional Comments From pcarlini at suse dot de 2005-05-20 13:50 --- I see. I tried both stock 2.15 and 2.16, no problems... -- What|Removed |Added Status|WAITING |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-20 13:50:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21677
[Bug web/21679] New: Download > Releases doesn't take me to appropriate info
If I wanted to download a GCC release, I'd follow the link under Download labelled "releases," but that link doesn't lead to any information about how to download a release or any links that lead to releases. -- Summary: Download > Releases doesn't take me to appropriate info Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: web AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dave at boost-consulting dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21679
[Bug web/21679] Download > Releases doesn't take me to appropriate info
--- Additional Comments From pcarlini at suse dot de 2005-05-20 15:20 --- Hi Dave: I think you have point. What I find misleading is so much space devoted to GCC Timeline - in the Download page - and only one line (on top, ok...) redirecting to the list of mirrors (actually holding the files). Moving the historical elsewhere and having the list of mirrors right here would be better, I guess?!? Or something similar. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21679
[Bug c/21680] New: GCC-4.0 vs GCC-3.3.6 ia32 -Os: code size increase from 261 to 5339 bytes
This stripped down extract of a real file (main.c of Gujin-1.1 in
sourceforge) gives:
$ gcc -Os tst.c -c -o tst.o && size tst.o
textdata bss dec hex filename
261 0 0 261 105 tst.o
$ ../toolchain/bin/gcc -Os tst.c -c -o tst.o && size tst.o
textdata bss dec hex filename
5339 0 0533914db tst.o
Here it is:
>>>
typedef struct
{
struct gujin_param_attrib
{
unsigned verbose:1;
unsigned lock_bpp:1;
unsigned lock_text_graphic:1;
unsigned menu_with_disk:1;
unsigned menu_with_parttype:1;
unsigned menu_with_partition:1;
unsigned menu_with_initrd:1;
unsigned force_textmode:1;
unsigned force_probe_root:1;
unsigned IDE_in_BIOS_order:1;
unsigned ignore_kernel_option:1;
unsigned disk_write_enable:1;
unsigned VGA_interface:1;
unsigned download_ansi_font:1;
unsigned VESA_interface:1;
unsigned enable_VESA_hardwin:1;
unsigned VESA2_interface:1;
unsigned enable_joystick:1;
unsigned search_disk_mbr:1;
unsigned search_part_mbr:1;
unsigned hide_unhide_partitions:1;
unsigned keep_all_part_mbr:1;
unsigned search_topdir_kernel:1;
unsigned search_subdir_kernel:1;
unsigned probe_bios_floppy_disk:1;
unsigned probe_bios_hard_disk:1;
unsigned probe_ide_disk:1;
unsigned probe_cdrom:1;
unsigned probe_dos_disk:1;
unsigned short write_disabled_written_once:1;
} __attribute__ ((packed)) attrib;
struct autoload_str
{
unsigned char last_loaded;
unsigned char total_loadable;
unsigned char init_page;
unsigned char total_page;
} __attribute__ ((packed)) autoload;
unsigned char timeout_autoload;
} __attribute__ ((packed)) gujin_param_t;
static inline int
diskconfig_changed (struct gujin_param_attrib first,
struct gujin_param_attrib second)
{
union
{
struct gujin_param_attrib bits;
unsigned all;
} one, two, mask =
{ bits: {
IDE_in_BIOS_order: 1,
probe_dos_disk: 1,
probe_cdrom: 1,
probe_ide_disk: 1,
probe_bios_hard_disk: 1,
probe_bios_floppy_disk:1,
}};
one.bits = first;
two.bits = second;
return (one.all & mask.all) != (two.all & mask.all);
}
static inline int
searchconfig_changed (struct gujin_param_attrib first,
struct gujin_param_attrib second)
{
union
{
struct gujin_param_attrib bits;
unsigned all;
} one, two, mask =
{ bits:{
search_disk_mbr: 1,
search_part_mbr: 1,
keep_all_part_mbr: 1,
search_topdir_kernel: 1,
search_subdir_kernel:1,
}};
one.bits = first;
two.bits = second;
return (one.all & mask.all) != (two.all & mask.all);
}
struct gujin_param_attrib get_gujin_param_attrib (void);
void set_last_boot_default (unsigned char last_loaded,
unsigned char total_loadable,
unsigned char init_page, unsigned char total_page);
struct autoload_str get_last_boot_default (void);
struct
{
unsigned short curpage, totalpage, nbperpage, nbtotal, interline;
} Menu;
struct todraw_str
{
unsigned firstlines:1;
unsigned topmenu:1;
unsigned bottommenu:1;
unsigned advertisement:1;
unsigned copyright:1;
unsigned update_bootparam:1;
unsigned refresh:1;
unsigned presskey:1;
};
unsigned is_valid_chgmode_keycode (unsigned short key);
unsigned menu (struct gujin_param_attrib gujin_attr)
{
unsigned timeout = 0;
unsigned last_boot_default_last_loaded_if_valid = 0x;
struct todraw_str toredraw = { 1, 1, 1, 1, 1,.refresh = 1,.presskey = 0
};
if (gujin_attr.verbose || gujin_attr.disk_write_enable)
{
struct autoload_str data = get_last_boot_default ();
if (data.last_loaded == 0 && data.total_loadable == 1
&& data.init_page == 0 && data.total_page == 1)
puts ("");
}
for (;;)
{
unsigned short key;
toredraw = (struct todraw_str) { 0, 0, 0, 0, 0,.presskey = 0 };
if (timeout != 0)
{
key = UI_getkey (18);
if (key != 0xFFFE)
{
timeout = 0;
toredraw.advertisement = 1;
last_boot_default_last_loaded_if_valid = 0x;
continue;
}
else if (--timeout != 0)
{
toredraw.advertisement = 1;
last_boot_default_last_loaded_if_valid =
get_last_boot_default().last_loaded;
continue;
}
}
else
key = UI_getkey (0xU);
if (key == 0x260C)
{
UI_clearscreen ();
toredraw = (struct todraw_str) {
.firstlines = 1,
.topmenu = 1,
.bottommenu = 1,
.advertisement = 1,
.copyright = 1,
.update_bootparam = 0,
.refresh = 1,
[Bug web/21679] Download > Releases doesn't take me to appropriate info
--- Additional Comments From dave at boost-consulting dot com 2005-05-20 15:38 --- Subject: Re: Download > Releases doesn't take me to appropriate info "pcarlini at suse dot de" <[EMAIL PROTECTED]> writes: > --- Additional Comments From pcarlini at suse dot de 2005-05-20 15:20 > --- > Hi Dave: I think you have point. What I find misleading is so much space > devoted > to GCC Timeline - in the Download page - and only one line (on top, ok...) > redirecting to the list of mirrors (actually holding the files). Moving the > historical elsewhere and having the list of mirrors right here would be > better, > I guess?!? Or something similar. I don't know, but I completely missed the list of mirrors. What I see is a list of releases, and I naturally try to click on the release I'm interested in so I can download it... doesn't work out too well. Also there's nothing telling me how to navigate the mirrors and find the release I'm interested in. Yes, I've figured it out, but what about Joe average? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21679
[Bug c/21680] GCC-4.0 vs GCC-3.3.6 ia32 -Os: code size increase from 261 to 5339 bytes
--- Additional Comments From giovannibajo at libero dot it 2005-05-20 15:49 --- A duplicate of 21529. I have attached this testcase into that bug. *** This bug has been marked as a duplicate of 21529 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE Summary|GCC-4.0 vs GCC-3.3.6 ia32 - |GCC-4.0 vs GCC-3.3.6 ia32 - |Os: code size increase from |Os: code size increase from |261 to 5339 bytes |261 to 5339 bytes http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21680
[Bug middle-end/21529] [4.0/4.1 Regression] code size regression (+40%) with -Os from GCC-3.4.3 to 4.1
--- Additional Comments From giovannibajo at libero dot it 2005-05-20 15:49 --- *** Bug 21680 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21529
[Bug middle-end/21529] [4.0/4.1 Regression] code size regression (+40%) with -Os from GCC-3.4.3 to 4.1
--- Additional Comments From giovannibajo at libero dot it 2005-05-20 15:50 --- Notice that both testcases come from the same program (Gujin). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21529
[Bug tree-optimization/21218] [4.1 regression] ICE using -ftree-vectorize
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-05-20 16:56 --- The problem disappeared with Jan Hubicka's patch http://gcc.gnu.org/ml/gcc-cvs/2005-05/msg00805.html Is the patch a proper fix (i.e. can we close the PR) or does it only paper over the problem? -- What|Removed |Added CC||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21218
[Bug c++/21681] New: Internal Compiler Error
Compile the enclosed source for an ICE -- Summary: Internal Compiler Error Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: critical Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dave at boost-consulting dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21681
[Bug c++/21681] Internal Compiler Error
--- Additional Comments From dave at boost-consulting dot com 2005-05-20 17:08 --- Created an attachment (id=8938) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8938&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21681
[Bug c++/21682] New: Disallowed using declaration
GCC reports ../../../../boost/sequence/begin.hpp:53: error: 'begin' is already declared in this scope When creating an overload set by bringing a function into a namespace via using-declaration. Compile the enclosed source to demonstrate. -- Summary: Disallowed using declaration Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dave at boost-consulting dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21682
[Bug c++/21682] Disallowed using declaration
--- Additional Comments From dave at boost-consulting dot com 2005-05-20 17:13 --- Created an attachment (id=8939) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8939&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21682
[Bug tree-optimization/21218] [4.1 regression] ICE using -ftree-vectorize
--- Additional Comments From hubicka at ucw dot cz 2005-05-20 17:22 --- Subject: Re: [4.1 regression] ICE using -ftree-vectorize > > --- Additional Comments From reichelt at gcc dot gnu dot org 2005-05-20 > 16:56 --- > The problem disappeared with Jan Hubicka's patch > http://gcc.gnu.org/ml/gcc-cvs/2005-05/msg00805.html > > Is the patch a proper fix (i.e. can we close the PR) > or does it only paper over the problem? I would say that it just masks the problem somehow. The non-dominated use would be probably produced much later in optimization queue than my patch affects. Honza > > > -- >What|Removed |Added > > CC||hubicka at gcc dot gnu dot >||org > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21218 > > --- You are receiving this mail because: --- > You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21218
[Bug c++/1016] [DR 166] friend class declarations not observing namespace rules.
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-20 17:29 --- Subject: Bug 1016 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-05-20 17:28:56 Modified files: gcc/cp : cp-tree.h decl.c name-lookup.c name-lookup.h parser.c pt.c rtti.c semantics.c ChangeLog gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/lookup: hidden-class1.C hidden-class2.C hidden-class3.C hidden-class4.C hidden-class5.C hidden-class6.C hidden-class7.C hidden-class8.C hidden-class9.C hidden-temp-class10.C hidden-temp-class11.C hidden-temp-class1.C hidden-temp-class2.C hidden-temp-class3.C hidden-temp-class4.C hidden-temp-class5.C hidden-temp-class6.C hidden-temp-class7.C hidden-temp-class8.C hidden-temp-class9.C Log message: Friend class name lookup 5/n PR c++/1016 * cp-tree.h (pushtag): Adjust declaration. * decl.c (lookup_and_check_tag): Call lookup_type_scope if lookup_name fails. (xref_tag): Adjust call to pushtag. Make hidden class visible. (start_enum): Adjust call to pushtag. * name-lookup.c (ambiguous_decl): Ignore hidden names. (qualify_lookup): Change return type to bool. (hidden_name_p): New function. (lookup_namespace_name, unqualified_namespace_lookup, lookup_name_real): Use it. (lookup_type_scope): Update comments. (maybe_process_template_type_declaration): Change parameter name from globalize to is_friend. (pushtag): Change globalize parameter of type int to tag_scope. Hide name if introduced by friend declaration. * name-lookup.h (hidden_name_p): Add declaration. * parser.c (cp_parser_lookup_name): Don't deal with hidden name here. * pt.c (push_template_decl_real): Make hidden class template visible. (lookup_template_class, instantiate_class_template): Adjust call to pushtag. * semantics.c (begin_class_definition): Likewise. * rtti.c (init_rtti_processing, build_dynamic_cast_1, tinfo_base_init, emit_support_tinfos): Use ts_current instead of ts_global. * g++.dg/lookup/hidden-class1.C: New test. * g++.dg/lookup/hidden-class2.C: Likewise. * g++.dg/lookup/hidden-class3.C: Likewise. * g++.dg/lookup/hidden-class4.C: Likewise. * g++.dg/lookup/hidden-class5.C: Likewise. * g++.dg/lookup/hidden-class6.C: Likewise. * g++.dg/lookup/hidden-class7.C: Likewise. * g++.dg/lookup/hidden-class8.C: Likewise. * g++.dg/lookup/hidden-class9.C: Likewise. * g++.dg/lookup/hidden-temp-class1.C: Likewise. * g++.dg/lookup/hidden-temp-class2.C: Likewise. * g++.dg/lookup/hidden-temp-class3.C: Likewise. * g++.dg/lookup/hidden-temp-class4.C: Likewise. * g++.dg/lookup/hidden-temp-class5.C: Likewise. * g++.dg/lookup/hidden-temp-class6.C: Likewise. * g++.dg/lookup/hidden-temp-class7.C: Likewise. * g++.dg/lookup/hidden-temp-class8.C: Likewise. * g++.dg/lookup/hidden-temp-class9.C: Likewise. * g++.dg/lookup/hidden-temp-class10.C: Likewise. * g++.dg/lookup/hidden-temp-class11.C: Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.1106.2.5&r2=1.1106.2.6 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.1371.2.10&r2=1.1371.2.11 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/name-lookup.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.109.4.2&r2=1.109.4.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/name-lookup.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.37&r2=1.37.8.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.319.2.6&r2=1.319.2.7 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.978.2.9&r2=1.978.2.10 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/rtti.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.210&r2=1.210.6.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/semantics.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.463.2.2&r2=1.463.2.3 http://gcc.gnu
[Bug c++/21681] Internal Compiler Error
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-20 17:33 --- This code is invalid. -- What|Removed |Added Severity|critical|normal Keywords||ice-on-invalid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21681
[Bug c++/1016] [DR 166] friend class declarations not observing namespace rules.
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-05-20 17:42 --- Also fixed in 4.0.1. -- What|Removed |Added Target Milestone|4.1.0 |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1016
[Bug target/21616] ICE: unable to find a register to spill in class `FLOAT_REGS'
--- Additional Comments From guptan at hotmail dot com 2005-05-20 17:43 --- Alan, Andrew, If any one of you have setup with gcc-4.0 handy, could you verify if this bug exists there as well? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21616
[Bug c++/21681] Internal Compiler Error
--- Additional Comments From dave at boost-consulting dot com 2005-05-20 18:05 --- (In reply to comment #2) > This code is invalid. How did you come to that determination? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21681
[Bug rtl-optimization/17810] [3.4 Regression] internal compiler error: in verify_local_live_at_start for arm-rtems, arm-linux
--- Additional Comments From dank at kegel dot com 2005-05-20 18:05 --- http://sources.redhat.com/ml/crossgcc/2005-05/msg00154.html is a report of a similar problem with gcc-3.4.3. xfree86-4.5.0's fontutils.c causes an ICE when compiled with -O3 -fno-strict-aliasing. Backing down to xfree86-4.4.0, or using -O2, or not using -no-strict-aliasing, or using gcc-4.0.0, makes the problem go away. I'll attach a reduced testcase. To reproduce, do $ arm-unknown-linux-gnu-gcc -O3 -fno-strict-aliasing -c fontutils.i Error is fontutils.i:44: internal compiler error: in verify_local_live_at_start, at flow.c:546 Is this the same problem, or should I file a new report? -- What|Removed |Added CC||dank at kegel dot com, ||nagaraja at ncoretech dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17810
[Bug bootstrap/21683] New: [Regression] build failure on i386-mingw (sys/wait.h header)
The following patch causes a build failure on i386-mingw: 2005-05-15 Gabriel Dos Reis <[EMAIL PROTECTED]> * fixincl.c: #include Build was successful before, but now fails when compiling fixincl.c, since MinGW doesn't have a sys/wait.h headers file. With this #include statement removed, build is successful. -- Summary: [Regression] build failure on i386-mingw (sys/wait.h header) Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org,gdr at integrable- solutions dot net GCC build triplet: i386-mingw GCC host triplet: i386-mingw GCC target triplet: i386-mingw http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21683
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From mark at codesourcery dot com 2005-05-20 18:48 --- Subject: Re: libstdc++ headers should have pop/push of the visibility around the declarations lanius at gentoo dot org wrote: > --- Additional Comments From lanius at gentoo dot org 2005-05-20 08:35 > --- > no workaround, the flag was just disabled on the affected architectures Then, can it not be left disabled for 4.0.x as well? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug c++/21681] [4.0/4.1 Regression] Internal Compiler Error
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-20 19:27 --- Maybe not. But in 3.4.0, I do get a warning: copy.cpp: In function `int test_main(int, char**)': copy.cpp:25: error: no match for call to `(const boost::sequence::algorithm::copy_) (const boost:: array&, boost::array&)' copy.cpp:29: error: no match for 'operator+' in 'buf + 11u' copy.cpp:32: error: no matching function for call to `equal(boost::array&, char*, const char[5])' And from ICC (with modifing the source removing some GCCisms): copy.cpp(25): error: no instance of function template "boost::sequence::algorithm::copy_::operator()" matches the argument list argument types are: (const boost::array, boost::array) object type is: const boost::sequence::algorithm::copy_ sequence::algorithm::copy(hello, buf) ^ -- What|Removed |Added Keywords|ice-on-invalid-code | Known to fail||4.0.0 Known to work||3.4.0 Summary|Internal Compiler Error |[4.0/4.1 Regression] ||Internal Compiler Error http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21681
[Bug c++/21681] [4.0/4.1 Regression] Internal Compiler Error
--- Additional Comments From dave at boost-consulting dot com 2005-05-20 19:56 --- The code is definitely invalid; I was just wondering how you decided that so quickly ;-) It still should never cause an ICE, of course ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21681
[Bug c++/21681] [4.0/4.1 Regression] Internal Compiler Error
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-20 19:59 --- (In reply to comment #5) > The code is definitely invalid; I was just wondering how you decided that so > quickly ;-) I looked into the source and found where it crashing. It was obvious from where the crash was it was invalid code as there was a function call as a template argument. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21681
[Bug libgcj/21637] URL.openStream doesn't throw a FileNotFoundException with some urls
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-20 20:02 --- Subject: Bug 21637 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-05-20 20:02:16 Modified files: libjava: ChangeLog libjava/gnu/java/net/protocol/jar: Connection.java Log message: PR libgcj/21637: * gnu/java/net/protocol/jar/Connection.java (getInputStream): Throw FileNotFoundException if jar entry not found. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.3391.2.73&r2=1.3391.2.74 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/gnu/java/net/protocol/jar/Connection.java.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.8&r2=1.8.6.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21637
[Bug libgcj/21637] URL.openStream doesn't throw a FileNotFoundException with some urls
--- Additional Comments From tromey at gcc dot gnu dot org 2005-05-20 20:03 --- I've checked in a patch to the 4.0 branch. A different approach seems best for the trunk, so I'm going to leave the PR open until I write that. -- What|Removed |Added Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21637
[Bug c/21684] New: MCore testsuite file gcc.c-torture/execute/lshrdi3-1.c compiles to incorrect assembly
/opt/winchester/mcore/mcore-elf/bin/mcore-elf-gcc-4.0.0 -v --save-temps lshrdi-1.c Using built-in specs. Target: mcore-elf Configured with: ../../src/gcc/gcc-4.0.0/configure --target=mcore-elf --prefix=/opt/winchester/mcore/mcore-elf/ --enable-languages=c --with-newlib Thread model: single gcc version 4.0.0 /opt/winchester/mcore/mcore-elf/bin/../libexec/gcc/mcore-elf/4.0.0/cc1 -E -quiet -v -iprefix /opt/winchester/mcore/mcore-elf/bin/../lib/gcc/mcore-elf/4.0.0/ lshrdi-1.c -funsigned-bitfields -fpch-preprocess -o lshrdi-1.i ignoring nonexistent directory "/opt/winchester/mcore/mcore-elf/bin/../lib/gcc/mcore-elf/4.0.0/../../../../mcore-elf/sys-include" ignoring duplicate directory "/opt/winchester/mcore/mcore-elf//lib/gcc/mcore-elf/4.0.0/include" ignoring nonexistent directory "/opt/winchester/mcore/mcore-elf//lib/gcc/mcore-elf/4.0.0/../../../../mcore-elf/sys-include" ignoring duplicate directory "/opt/winchester/mcore/mcore-elf//lib/gcc/mcore-elf/4.0.0/../../../../mcore-elf/include" #include "..." search starts here: #include <...> search starts here: /opt/winchester/mcore/mcore-elf/bin/../lib/gcc/mcore-elf/4.0.0/include /opt/winchester/mcore/mcore-elf/bin/../lib/gcc/mcore-elf/4.0.0/../../../../mcore-elf/include End of search list. /opt/winchester/mcore/mcore-elf/bin/../libexec/gcc/mcore-elf/4.0.0/cc1 -fpreprocessed lshrdi-1.i -funsigned-bitfields -quiet -dumpbase lshrdi-1.c -auxbase lshrdi-1 -version -o lshrdi-1.s GNU C version 4.0.0 (mcore-elf) compiled by GNU C version 3.3.5 (Debian 1:3.3.5-8). GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=129126 /opt/winchester/mcore/mcore-elf/bin/../lib/gcc/mcore-elf/4.0.0/../../../../mcore-elf/bin/as -o lshrdi-1.o lshrdi-1.s /opt/winchester/mcore/mcore-elf/bin/../libexec/gcc/mcore-elf/4.0.0/collect2 -X /opt/winchester/mcore/mcore-elf/bin/../lib/gcc/mcore-elf/4.0.0/../../../../mcore-elf/lib/crt0.o /opt/winchester/mcore/mcore-elf/bin/../lib/gcc/mcore-elf/4.0.0/crti.o /opt/winchester/mcore/mcore-elf/bin/../lib/gcc/mcore-elf/4.0.0/crtbegin.o -L/opt/winchester/mcore/mcore-elf/bin/../lib/gcc/mcore-elf/4.0.0 -L/opt/winchester/mcore/mcore-elf/bin/../lib/gcc -L/opt/winchester/mcore/mcore-elf//lib/gcc/mcore-elf/4.0.0 -L/opt/winchester/mcore/mcore-elf/bin/../lib/gcc/mcore-elf/4.0.0/../../../../mcore-elf/lib -L/opt/winchester/mcore/mcore-elf//lib/gcc/mcore-elf/4.0.0/../../../../mcore-elf/lib lshrdi-1.o -lgcc -lc -lgcc -lsim /opt/winchester/mcore/mcore-elf/bin/../lib/gcc/mcore-elf/4.0.0/crtend.o /opt/winchester/mcore/mcore-elf/bin/../lib/gcc/mcore-elf/4.0.0/crtn.o The assembly code for this is incorrect. Specifically, the following gets generated for variable_shift: .type variable_shift, @function variable_shift: subisp,32 stw r8,(sp,24) mov r8,sp stw r2,(r8) stw r3,(r8,4) stw r4,(r8,8) ldw r7,(r8,8) movir6,32 and r7,r6 cmpnei r7,0 jbf .L2 ### Here if we didn't jump to .L2 we are shifting by more than 32, so we should just take the high word and shift it by (the shift value - 32), but we shift it by the shift value itself, which results in 0. ldw r6,(r8,4) ldw r7,(r8,8) lsr r6,r7 stw r6,(r8,16) movir7,0 stw r7,(r8,20) jbr .L3 -- Summary: MCore testsuite file gcc.c-torture/execute/lshrdi3-1.c compiles to incorrect assembly Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: winchester at amirix dot com 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: mcore-unknown-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21684
[Bug target/21684] MCore testsuite file gcc.c-torture/execute/lshrdi3-1.c compiles to incorrect assembly
-- What|Removed |Added Component|c |target Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21684
[Bug c++/21685] New: Internal compiler error on correct code
On g++ versions 3.4.3, 3.4.4 and 4.0.0 the following code
#include
#include
#include
#include
#include
#include
#include
namespace OKlib {
namespace TestSystem {
typedef unsigned int LineNumber;
class ErrorDescription {
public :
ErrorDescription() {}
ErrorDescription(const char* const file, const char* const line, const
char* const type_test_class) {}
friend std::ostream& operator <<(std::ostream& out, const
ErrorDescription& D) {}
};
class TestException : public std::runtime_error {
public :
explicit TestException(const std::string& special_circumstances) :
std::runtime_error(special_circumstances) {}
~TestException() throw() {}
TestException& add(const ErrorDescription e) {}
friend std::ostream& operator <<(std::ostream& out, const TestException&
E) {}
};
}
}
namespace OKlib {
namespace TestSystem {
typedef double TestSingleParameter;
typedef std::vector TestParameter;
class TestBase {
protected :
void insert(TestBase* const p) const {}
public :
static int run_tests_default(std::ostream& out) {}
void perform_test(const TestParameter& P = TestParameter()) {}
TestBase() {}
virtual ~TestBase() {}
private :
virtual void perform_test_trivial() = 0;
};
}
}
namespace OKlib {
namespace SetAlgorithms {
template
struct Union {
public :
OutputIterator operator() (const InputIterator_sets begin, const
InputIterator_sets end, OutputIterator out) const {}
};
}
}
namespace OKlib {
namespace SetAlgorithms {
template class Union>
class Test_Union : public ::OKlib::TestSystem::TestBase {
private :
void perform_test_trivial() {
typedef int value_type;
typedef std::set Set;
typedef Set::iterator set_iterator;
typedef std::pair Range;
typedef std::vector VectorSets;
typedef VectorSets::iterator vector_iterator;
typedef std::vector VectorValues;
typedef VectorValues::iterator value_iterator;
typedef Union
union_type;
union_type union_f;
struct check_union : public ::OKlib::TestSystem::TestBase {
VectorSets& sets;
VectorValues& output;
Set& reference;
check_union(VectorSets& sets, VectorValues& output, Set&
reference) : sets(sets), output(output), reference(reference) {}
void perform_test_trivial() {
const value_iterator end = union_f(sets.begin(), sets.end(),
output.begin());
}
};
VectorSets sets;
VectorValues output;
Set reference;
check_union check(sets, output, reference);
}
};
}
}
namespace OKlib {
namespace SetAlgorithms {
Test_Union test_union;
}
}
int main() {}
---
produces
> g++ Test_g++.cpp
Test_g++.cpp: In member function ‘void
OKlib::SetAlgorithms::Test_Union::perform_test_trivial()::check_union::perform_test_trivial()
[with Union = OKlib::SetAlgorithms::Union]’:
Test_g++.cpp:78: internal compiler error: in make_decl_rtl, at varasm.c:868
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
To the best of my knowledge the code is syntactically correct (I removed
all function bodies, so it won't do something sensible).
Since I'm stuck now with my development, I would be glad if at least a
workaround would be found.
Oliver
--
Summary: Internal compiler error on correct code
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: o dot kullmann at swansea dot ac dot uk
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21685
[Bug c++/21685] Internal compiler error on correct code
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-20 21:16 --- This code is invalid, you are trying to use union_f in an "inner" class but unlike Java, "inner" classes in C++, you cannot access the outer class's members. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21685
[Bug bootstrap/21683] [Regression] build failure on i386-mingw (sys/wait.h header)
--- Additional Comments From dannysmith at users dot sourceforge dot net 2005-05-20 21:17 --- A patch was submitted here: http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01794.html and a different one here: http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02074.html Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21683
[Bug c++/21685] Internal compiler error on correct code
--- Additional Comments From o dot kullmann at swansea dot ac dot uk 2005-05-20 21:30 --- Oh, yes, I did overlook that I had to pass also that object union_f as parameter --- thanks for telling me! Now the code compiles again. So it's an "internal compiler error on incorrect code". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21685
[Bug bootstrap/21683] [Regression] build failure on i386-mingw (sys/wait.h header)
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-05-20 21:35 --- I think the first of those is the best. Tested on i386-mingw32. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-20 21:35:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21683
[Bug c++/21686] New: [4.0/4.1 Regression] weird quoting in an error message
Take the following code (which I found while reducing PR 21685):
template
int f(void)
{
int i;
struct f1
{
int f(void){return i;}
};
}
We get:
t1.cc: In member function 'int f()::f1::f()':
t1.cc:7: error: use of % variable from containing function
t1.cc:4: error: 'int i' declared here
Notice the use of %< and %>
--
Summary: [4.0/4.1 Regression] weird quoting in an error message
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,gdr at gcc dot gnu dot
org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21686
[Bug c++/21686] [4.0/4.1 Regression] weird quoting in an error message
-- What|Removed |Added Known to fail||4.0.0 4.1.0 Known to work||3.4.0 Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21686
[Bug c++/21685] [3.4/4.0/4.1 Regression] Internal compiler error on invalid code
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-20
21:42 ---
Confirmed, reduced testcase:
template
struct g
{
int operator()(int i){return i;}
};
template
struct h
{
int f(void)
{
g i;
struct f1
{
int f(void){return i(0);}
};
f1 aa;
aa.f();
}
};
h<1> i;
void f() { i.f(); }
3.3.3 gave an error:
t1.cc: In member function `int h::f()::f1::f()':
t1.cc:16: error: use of `auto' variable from containing function
t1.cc:13: error: `g i' declared here
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Keywords||accepts-invalid, ice-
||checking, ice-on-invalid-
||code
Last reconfirmed|-00-00 00:00:00 |2005-05-20 21:42:02
date||
Summary|Internal compiler error on |[3.4/4.0/4.1 Regression]
|correct code|Internal compiler error on
||invalid code
Target Milestone|--- |3.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21685
[Bug c++/21687] New: [4.0/4.1 Regression] ICE on valid code
I know this goes against all the rules for filing bugs but when I supply -save-temps, I don't get an ICE. The code is the code from PR 21685 with one exception, the following 2 lines are commented out (this makes this code valid): const value_iterator end = union_f(sets.begin(), sets.end(), output.begin()); It fails with "4.0.0 20050113" The ICE is: t.cc: In member function 'void OKlib::SetAlgorithms::Test_Union::perform_test_trivial()': t.cc:94: internal compiler error: tree check: expected statement_list, have type_expr in finish_compound_stmt, at cp/semantics.c:1113 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- Summary: [4.0/4.1 Regression] ICE on valid code Product: gcc Version: 4.0.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: critical Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: powerpc-apple-darwin7.8.0 GCC host triplet: powerpc-apple-darwin7.8.0 GCC target triplet: powerpc-apple-darwin7.8.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21687
[Bug libfortran/19016] [4.0 only] maxloc ignores mask
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-20 22:52 --- Subject: Bug 19016 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-05-20 22:51:46 Modified files: libgfortran: ChangeLog Log message: PR libfortran/19016 Added entry to Changelog (bug fixed). Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.163.2.34&r2=1.163.2.35 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19016
[Bug libfortran/19016] [4.0 only] maxloc ignores mask
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-05-20 22:52 --- Fixed in 4.0. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19016
[Bug middle-end/21688] [4.0 Regression] gcc miscompiles with -funit-at-a-time
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-20 23:02 --- Oh, even at -O0 -funit-at-a-time, we get this missed compiled. There are buffer overflows somewhere: *** mudflap violation 1 (check/write): time=1116629904.932813 ptr=0x80ce540 size=33 pc=0x45b4a8 location=`crypt-bug.c:206 (encrypt)' /home/peshtigo/pinskia/linux/lib/libmudflap.so.0(__mf_check+0x48) [0x45b4a8] ./a.out(encrypt+0x1c7) [0x80499c4] ./a.out(crypt+0xaaf) [0x804be45] Nearby object 1: checked region begins 0B into and ends 1B after mudflap object 0xa095a08: name=`crypt-bug.c:190 L' bounds=[0x80ce540,0x80ce55f] size=32 area=static check=0r/4w liveness=4 alloc time=1116629904.932154 pc=0x45bfe8 Nearby object 2: checked region begins 32B before and ends 0B into mudflap object 0xa095a70: name=`crypt-bug.c:190 R' bounds=[0x80ce560,0x80ce57f] size=32 area=static check=0r/3w liveness=3 alloc time=1116629904.932158 pc=0x45bfe8 number of nearby objects: 2 Fixing that I get a different the abort, can you double check to make sure this code is really valid, from the looks of it, it is not. The code is assuming that L and R come right after each in memory, and that is a false assumption. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID Summary|[4.0 Regression] gcc|[4.0 Regression] gcc |miscompiles with -Os (wrong |miscompiles with -funit-at- |code at least on i386, |a-time |x86_64 and ppc) | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21688
[Bug c/21689] New: Variable declaration after switch case expression causes compile error
If there is a variable declaration as the first statement after the colon at the
end of a case expression, the compiler returns a syntax error. If there any
statements between the case expression and the variable declaration then it will
not produce an error, a partial list of the statements that I have found that
will prevent an error are as follows:
A void statement i.e. ((void) 0);
Using an un-necessary code block i.e. { code}
An empty line with nothing but a semi-colon ;
Any function call
It seems as long as there is SOMEHING in between the case expression and the
variable declaration it is fine.
See example code below:
--- example.c ---
void foo0(void)
{
int test = 0;
switch (test)
{
case 0:
int bar = 1; //error here: " example.c:8: error: syntax error before
"int""
break;
default:
//
break;
}
}
void foo1(void)
{
int test = 0;
switch (test)
{
case 0:
int bar; //error here: " example.c:23: error: syntax error before "int""
bar = 1; //error here: " example.c:24: error: `bar' undeclared (first
use in this function)"
break;
default:
//
break;
}
}
typedef int UINT; //typedef for below
void foo2(void)
{
int test = 0;
switch (test)
{
case 0:
UINT bar = 1; //error here: "example.c:41: error: syntax error before
"bar""
break;
default:
//
break;
}
}
void foo3(void)
{
int test = 0;
switch (test)
{
case 0:
((void) 0); //void statement
int bar = 1; //works
break;
default:
//
break;
}
}
void foo4(void)
{
int test = 0;
switch (test)
{
case 0:
{ //code block
int bar = 1; //works
}
break;
default:
//
break;
}
}
void foo5(void)
{
int test = 0;
switch (test)
{
case 0:
; //empty line
int bar = 1; //works
break;
default:
//
break;
}
}
void foobar(void); //function prototype for below
void foo6(void)
{
int test = 0;
switch (test)
{
case 0:
foobar(); //function call
int bar = 1; //works
break;
default:
//
break;
}
}
void foobar(void) //dummy function
{
//nada
}
--
Summary: Variable declaration after switch case expression causes
compile error
Product: gcc
Version: 3.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matt_hicks at bose dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: gcc exmple.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21689
[Bug c++/21681] [4.0/4.1 Regression] Internal Compiler Error
--- Additional Comments From dave at boost-consulting dot com 2005-05-20
23:12 ---
Subject: Re: [4.0/4.1 Regression] Internal Compiler Error
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
> --- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-20
> 19:59 ---
> (In reply to comment #5)
>> The code is definitely invalid; I was just wondering how you decided that so
>> quickly ;-)
>
> I looked into the source and found where it crashing. It was obvious from
> where the crash was it was
> invalid code as there was a function call as a template argument.
That wasn't a function call; it was a function type.
template struct x {};
x legal;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21681
[Bug c/21689] Variable declaration after switch case expression causes compile error
--- Additional Comments From falk at debian dot org 2005-05-20 23:20 --- (In reply to comment #0) > If there is a variable declaration as the first statement after the colon at > the > end of a case expression, the compiler returns a syntax error. That is exactly as expected. After the label, there needs to be a statement, and declarations are not statements. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21689
[Bug target/21616] [3.4 only] ICE: unable to find a register to spill in class `FLOAT_REGS'
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-21 00:14 --- This was really fixed on the mainline by: 2005-01-07 David Edelsohn <[EMAIL PROTECTED]> PR target/13674 * config/rs6000/rs6000.c (rs6000_legitimize_reload_address): Convert non-word aligned offset address using ld/std into indirect address. There is a work around on the 3.4 branch which looks like it is not working for this case for some reason. -- What|Removed |Added Summary|ICE: unable to find a |[3.4 only] ICE: unable to |register to spill in class |find a register to spill in |`FLOAT_REGS'|class `FLOAT_REGS' Target Milestone|--- |3.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21616
[Bug target/21616] [3.4 only] ICE: unable to find a register to spill in class `FLOAT_REGS'
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-21 00:19 --- The work around for PR 13674 in the 3.4 branch is trying to use a FP register as that is what the work around says to do. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21616
[Bug c/21690] New: gcc misses trivial optimizations ?
hi, i'm using Debian SID experimental gcc-4.0
gcc-4.0 -v
Using built-in specs.
Target: powerpc-linux
Configured with: ../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-multilib --disable-werror --enable-checking=release
powerpc-linux
Thread model: posix
gcc version 4.0.1 20050508 (prerelease) (Debian 4.0.0-6)
i'm compiling the following simple code :
BEGIN_CODE
void
foo(void*);
static inline char*
bar(char * const p)
{
foo(p);
return p;
}
unsigned long
baz(char * const p)
{
return (unsigned long)(bar(p+1) - bar(p));
}
END_CODE
it's obvious that baz(...) == 1. But gcc outputs the following (gcc -O3 -S -Wall
foo.c)
BEGIN_CODE
baz:
stwu 1,-32(1)
mflr 0
stw 28,16(1)
addi 28,3,1
stw 29,20(1)
mr 29,3
mr 3,28
stw 0,36(1)
bl foo
mr 3,29
bl foo
lwz 0,36(1)
subf 3,29,28
lwz 28,16(1)
lwz 29,20(1)
mtlr 0
addi 1,1,32
blr
END_CODE
if i remove the call foo(p) in function bar, gcc outputs
BEGIN_CODE
baz:
li 3,1
blr
END_CODE
I would have expect gcc to output the same trivial code in both cases.
Now,
addi 28,3,1
...
mr 29,3
mr 3,28
...
mr 3,29
...
subf 3,29,28
is a complex way to get 1.
Why gcc is not able to optimize this kind of code ?
gcc-2.95, gcc-3.3 and gcc-4.0 output the same result.
Thank you.
--
Summary: gcc misses trivial optimizations ?
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: TazForEver at dlfp dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21690
[Bug target/21616] [3.4 only] ICE: unable to find a register to spill in class `FLOAT_REGS'
--- Additional Comments From guptan at hotmail dot com 2005-05-21 00:28
---
Thanks Andrew.
[17:00] pinskia, yes I am trying to get an answer if PR21616 existed on
gcc-4.0 :)
[17:01] it might be worked around by optimizing it better :)
[17:01] I suspect its already fixed in rs6000.md, but dont want to go
over the whole setup thingie
[17:02] let me try it
[17:02] than I rather backport that from gcc-4.0
[17:05] did you try the patch for PR 15286?
[17:07] nope, lemme look
[17:08] oh, that will not help
[17:08] I know which bug this is, it has to do with ld not taking any
old offset but only aligned offsets
[17:08] let me find that patch
[17:08] <-- rosalesa has quit ("Leaving")
[17:13] oh ok, i m waiting
[17:14] --> jk- ([EMAIL PROTECTED]) has joined #ppc64
[17:14] ngupta: the patch for PR 13674 is the one which really fixed
the problem I think
[17:15] there is a workaround on the 3.4 branch for PR 13674 but it
looks like it does not work for this testcase :(
[17:16] yup, thats what I was abt to try
[17:16] -fnew-ra
[17:17] in fact I think the work around is causing the ICE to show up,
it is trying to use FP register because that is what the work around says to use
[17:19] so back to, could u try gcc-4.0
[17:20] I did and it worked
[17:20] I have started a build with this patch anyway
[17:20] you might need to revert the work around though
[17:20] oh ok, u mean patch for PR13674?
[17:21] the one which is on the 3.4 branch yes
[17:22] ok, got it
[17:22] thx, will update the bug after testing it
[17:24] 2004-03-10 Alan Modra <[EMAIL PROTECTED]>
[17:24] Hartmut Penner <[EMAIL PROTECTED]>
[17:25] BTW, I will also CC dje/hpenner on this bug.
[17:25] one from http://gcc.gnu.org/ml/gcc-cvs/2004-03/msg00482.html
by the way
--
What|Removed |Added
CC||hpenner at de dot ibm dot
||com, dje at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21616
[Bug tree-optimization/21690] gcc misses trivial optimizations
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-21 00:32 --- This bolls down to combine not working across function calls. The correct way to fix this would to have a tree combiner. -- What|Removed |Added BugsThisDependsOn||15459 Component|c |tree-optimization Keywords||missed-optimization Summary|gcc misses trivial |gcc misses trivial |optimizations ? |optimizations http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21690
[Bug tree-optimization/21690] gcc misses trivial optimizations
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-21 00:32:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21690
Re: Paranoider Deutschenmoerder kommt in Psychiatrie
Hello. Your mail to boris cannot be delivered because that person is no longer here. Your message appears to have been directed to the following address(es): [EMAIL PROTECTED] However, we have a new address for boris: [EMAIL PROTECTED] You should redirect your mail to this new address: your original message has *NOT* been forwarded to the new address. If you have any questions, please contact [EMAIL PROTECTED] Up to the first fifty lines of your message follow: >From gcc-bugs@gcc.gnu.org Fri May 20 20:47:58 2005 Received: from gate.cs.rochester.edu (gate.cs.rochester.edu [192.5.53.207]) by slate.cs.rochester.edu (8.11.6+Sun/005) with ESMTP id j4L0lwg23335; Fri, 20 May 2005 20:47:58 -0400 (EDT) Received: from antivirus3.its.rochester.edu (antivirus3.its.rochester.edu [128.151.57.51]) by gate.cs.rochester.edu (8.11.6+Sun/004) with ESMTP id j4L0lvg05366; Fri, 20 May 2005 20:47:57 -0400 (EDT) Received: from antivirus3.its.rochester.edu (localhost [127.0.0.1]) by antivirus3.its.rochester.edu (8.12.10/8.12.4) with ESMTP id j4L0luvP018373; Fri, 20 May 2005 20:47:56 -0400 (EDT) Received: from pm1.its.rochester.edu (pm1.its.rochester.edu [128.151.57.59]) by antivirus3.its.rochester.edu (8.12.10/8.12.4) with ESMTP id j4L0luO1018370; Fri, 20 May 2005 20:47:56 -0400 (EDT) Received: from qgmmt.org (67-40-130-218.dnvr.qwest.net [67.40.130.218]) by pm1.its.rochester.edu (8.12.11/8.12.11) with SMTP id j4L0lkw5011645; Fri, 20 May 2005 20:47:47 -0400 (envelope-from gcc-bugs@gcc.gnu.org) From: gcc-bugs@gcc.gnu.org To: [EMAIL PROTECTED] Date: Sat, 21 May 2005 00:42:14 UTC Subject: Paranoider Deutschenmoerder kommt in Psychiatrie Importance: Normal X-Priority: 3 (Normal) X-MSMail-Priority: Normal MIME-Version: 1.0 Message-ID: <[EMAIL PROTECTED]> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" X-URPMX-Version: 4.6.1.107272, Antispam-Core: 4.6.1.106808, Antispam-Data: 2005.5.5.21 Lese selbst: http://brandenburg.rz.fhtw-berlin.de/poetschke.html
gcc-3.4.4 build bug
I have a laptop with pentium M centrino 1.7 ghz cpu, 512 mb ram, suse linux prof. 9.2 operating system (with all possible patches installed), and gcc (GCC) 3.3.4 (pre 3.3.5 20040809). I downloaded gcc-3.4.4 full source code from one of the mirrors specified at gcc.gnu.org, and extracted the .tar.bz2 file on my Desktop (So the gcc source is at /jfcgauss/Desktop/gcc-3.4.4). Then I created a directory /gecici (temporary direcroty as objdir) with full access to my account, and created an executable script file named "d" in this directory. This file is attached. Then, in a console I changed the curent directory to /gecici and then I typed the following: ./d > gccOut.txt The gccOut.txt file is also attached. Additionally, there was some output in the concole window, which is attached as console.txt (console output says to report this bug) --- Independent from this bug report, I don't want the "-g" flag to be used at any place during the build; how can I do this? I always see it somewhere. __ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail gccBug.tar.bz2 Description: 2318897097-gccBug.tar.bz2
[Bug c/21691] New: ICE in reload_cse_simplify_operands, at postreload.c:391 (ARM -mthumb -Os)
The following fails, while adding -fno-inline or -O[012345] or removing -mthumb
or reverting to 3.3.2 makes it work.
$ arm-elf-gcc -c -mthumb -Os arm-thumb-Os-inline-bug.c
arm-thumb-Os-inline-bug.c: In function `show':
arm-thumb-Os-inline-bug.c:24: error: insn does not satisfy its constraints:
(insn:HI 43 132 44 3 (set (reg:SI 3 r3 [86])
(mem:SI (plus:SI (reg:SI 2 r2 [114])
(reg/f:SI 13 sp)) [3 S4 A32])) 126 {*thumb_movsi_insn} (nil)
(expr_list:REG_EQUIV (mem:SI (plus:SI (reg:SI 2 r2 [114])
(reg/f:SI 13 sp)) [3 S4 A32])
(nil)))
arm-thumb-Os-inline-bug.c:24: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:391
$ arm-elf-gcc -v
Reading specs from /usr/lib/gcc/arm-elf/3.4.4/specs
Configured with: ../source-tree/gcc-3.4.4/configure --host=i686-pc-linux-gnu
--target=arm-elf --enable-languages=c --with-cpu=arm9tdmi --prefix=/usr
--with-gxx-include-dir=/usr/arm-elf/include/g++-v3
--includedir=/usr/arm-elf/include
--with-headers=/source-tree/gcc-3.4.4/gcc/gincludes --enable-multilib
--enable-big-endian --enable-interwork
Thread model: single
gcc version 3.4.4
--
Summary: ICE in reload_cse_simplify_operands, at postreload.c:391
(ARM -mthumb -Os)
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: radford at indigita dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21691
[Bug c/21691] ICE in reload_cse_simplify_operands, at postreload.c:391 (ARM -mthumb -Os)
--- Additional Comments From radford at indigita dot com 2005-05-21 02:45 --- Created an attachment (id=8941) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8941&action=view) file that triggers the bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21691
[Bug c/21691] ICE in reload_cse_simplify_operands, at postreload.c:391 (ARM -mthumb -Os)
-- What|Removed |Added Known to fail||3.4.1 3.4.4 Known to work||3.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21691
[Bug libgcj/21692] New: unexpected java.lang.NoClassDefFoundError
There are failures on the libjava testsuites for sh4-unknown-linux-gnu
FAIL: Class_1 execution - source compiled test
FAIL: Class_1 execution - bytecode->native test
FAIL: Class_1 -O3 execution - source compiled test
FAIL: Class_1 -O3 execution - bytecode->native test
FAIL: InvokeInterface execution - bytecode->native test
FAIL: InvokeInterface -O3 execution - bytecode->native test
FAIL: PR12416 execution - bytecode->native test
FAIL: PR12416 -O3 execution - bytecode->native test
FAIL: PR260 execution - bytecode->native test
FAIL: PR260 -O3 execution - bytecode->native test
FAIL: SyncTest execution - bytecode->native test
FAIL: SyncTest -O3 execution - bytecode->native test
FAIL: invokethrow execution - bytecode->native test
FAIL: invokethrow -O3 execution - bytecode->native test
FAIL: pr179 execution - bytecode->native test
FAIL: pr179 -O3 execution - bytecode->native test
FAIL: pr8415 execution - bytecode->native test
FAIL: pr8415 -O3 execution - bytecode->native test
FAIL: stringconst2 output - source compiled test
FAIL: stringconst2 output - bytecode->native test
FAIL: stringconst2 -O3 output - source compiled test
FAIL: stringconst2 -O3 output - bytecode->native test
and it looks that the same failures have been seen for {alpha, hppa,
ia64, powerpc, s390}*-*-linux-gnu in gcc-testresults, though there is
no such failure in the testresults on {i686, x86_64}-*-linux-gnu and
powerpc-apple-darwin*. A typical error is:
Exception in thread "main" java.lang.NoClassDefFoundError: two
at InvokeInterface.class$ (Throwable.java:37)
at InvokeInterface.main (InvokeInterface.java:42)
on sh4-unknown-linux-gnu.
--
Summary: unexpected java.lang.NoClassDefFoundError
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kkojima at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org,tromey at redhat dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: sh4-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21692
[Bug c/21691] ICE in reload_cse_simplify_operands, at postreload.c:391 (ARM -mthumb -Os)
-- What|Removed |Added Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21691
[Bug c/21691] ICE in reload_cse_simplify_operands, at postreload.c:391 (ARM -mthumb -Os)
--- Additional Comments From radford at indigita dot com 2005-05-21 02:55 --- Possibly duplicates bug 20810. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21691
[Bug target/21691] ICE in reload_cse_simplify_operands, at postreload.c:391 (ARM -mthumb -Os)
-- What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21691
[Bug c++/21693] New: private member is accessible by a derived class when declaring and defining classes in the same file
In the following code, the private member `n' of class `C' can be accessed by
derived class `D'.
The fact that g++ does not complain depends on the order of the declarations.
Typically, moving the `C::n' initialization elsewhere in the code will trigger
(as expected) the following error:
$ error: `const int C::n' is private
//
// private.cpp
#include
class C {
private:
static const int n;
};
const int C::n = 9;
class D : public C {
public:
void print_n() { std::cout << "n=" << n << "\n"; }
} d;
int main()
{
d.print_n();
return 0;
}
//
Additional information:
* the exact version of GCC;
* the system type;
* the options given when GCC was configured/built;
$ g++ -v
Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.3.2/specs
Configured with: ../configure --prefix=/usr --libdir=/usr/lib
--with-slibdir=/lib --mandir=/usr/share/man --infodir=/usr/share/info
--enable-shared --enabl
e-threads=posix --disable-checking --enable-long-long --enable-__cxa_atexit
--enable-clocale=gnu --enable-languages=c,c++,ada,f77,objc,java,pascal --host=i
586-mandrake-linux-gnu --with-system-zlib
Thread model: posix
gcc version 3.3.2 (Mandrake Linux 10.0 3.3.2-6mdk)
* the complete command line that triggers the bug;
g++ -Wall -Werror -ansi -pedantic -o private private.cpp && ./private
* the compiler output (error messages, warnings, etc.); and
none! It should complain that `const int C::n' is private
--
Summary: private member is accessible by a derived class when
declaring and defining classes in the same file
Product: gcc
Version: 3.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sylvain dot guilley at enst dot fr
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21693
